Bug 425804
| Summary: | pdftex.map file incomplete, many fonts ignored | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jonathan Underwood <jonathan.underwood> |
| Component: | texlive | Assignee: | Jindrich Novy <jnovy> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | pertusus, pknirsch |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-01-23 05:34:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jonathan Underwood
2007-12-16 01:37:36 UTC
I also had an application that failed because updmap hadn't been run. What about my proposal, that is having a requires(post) on the script in the texmf packages, which would insure that the scripts are run after texmf packages installation? I applied temporary fix for this in rawhide. We need to figure out how to force updmap to create unambiguous entries in pdflatex.map, what I failed to accomplish yet. I used the map files originally shipped within the original TeXLive 2007 and they work perfectly for me. FYI: the pdflatex map files are ambiguously generated in %post scriptlet via the updmap-sys call and in texconfig-sys init call in the scriptlet for the latex subpackage. Closing RAWHIDE for now even though it's not a complete fix but workaround. The discussion could go on here. Isn't it because they are created before all the fonts are installed, or because updmap isn't called with --syncwithtree? Also I may be missing something, but the original line in /usr/share...pdftex.map is ecbm1440 SFBM1440 "T1Encoding ReEncodeFont" <cm-super-t1.enc <sfbm1440.pfb though none of cm-super-t1.enc sfbm1440.pfb is present. After running updmap, the result is: ecbm1440 cm-super-t1 sfbm1440 which seems to come from /usr/share/texmf/fonts/map/dvipdfm/context/cm-super-t1.map is certainly not less problematic. I think I understand the issue a bit more. First the entries in the original pdftex.map come from psfonts_t1.map. It is linked to psfonts_pk.map since we have dvipsPreferOutline true However psfonts_pk.map is not specified while cm-super-t1.map is. Now the entry in cm-super-t1.map is not valid for pdftex because in ecbm1440 cm-super-t1 sfbm1440 sfbm1440 is the file name and it is not included (prefixed with < or <<), and in that case (as said in the pdftex manual) there must be some fontflag and in any case doesn't seems to make much sense. So the issue seems to me that a dvipdfm map format is used for a pdftex map format and they are not compatible. It is very possible that the right cm-super-t1.map is in a font package that is not currently in fedora texlive. And it also seems to me that the dvipdfm maps should be generated from the pdftex/dvips maps, and that dvipdfm maps should not be used directly. I'll ask on the texlive list to be sure. As a side note this was already reported by Robin Fairbairns during the review Bug 229180#35. Ok, I managed to fix it by tuning the updmap.cfg. Basically commenting out the cm-super and fourier maps is enough to calm down pdflatex. |