Bug 425804 - pdftex.map file incomplete, many fonts ignored
Summary: pdftex.map file incomplete, many fonts ignored
Alias: None
Product: Fedora
Classification: Fedora
Component: texlive   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2007-12-16 01:37 UTC by Jonathan Underwood
Modified: 2013-07-02 23:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-23 05:34:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jonathan Underwood 2007-12-16 01:37:36 UTC
Description of problem:
While building the emacs-auctex package, which uses latex, I see numerous
messages of this type:

pdfTeX warning: /usr/bin/pdflatex (file /var/lib/texmf/fonts/map/pdftex/updmap/
pdftex.map): ambiguous entry for `ecbm1440': font file present but not included
, will be treated as font file not present

All messages are identical except for the font name. The full build.log is here:

Something looks very wrong.

Version-Release number of selected component (if applicable):
texlive-2007.2 I think - whatever is in Rawhide today.

Comment 1 Patrice Dumas 2008-01-11 00:48:13 UTC
I also had an application that failed because updmap hadn't been 

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?

Comment 2 Jindrich Novy 2008-01-16 13:44:09 UTC
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

Closing RAWHIDE for now even though it's not a complete fix but workaround. The
discussion could go on here.

Comment 3 Patrice Dumas 2008-01-16 16:04:51 UTC
Isn't it because they are created before all the fonts are
installed, or because updmap isn't called with --syncwithtree?

Comment 4 Patrice Dumas 2008-01-16 16:29:08 UTC
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 
is certainly not less problematic.

Comment 5 Patrice Dumas 2008-01-17 23:40:39 UTC
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.

Comment 6 Patrice Dumas 2008-01-18 08:18:57 UTC
As a side note this was already reported by Robin Fairbairns
during the review Bug 229180#35.

Comment 7 Jindrich Novy 2008-01-18 13:03:17 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.