Red Hat Bugzilla – Bug 167567
Embeded fonts don't display after upgrade 0.3.x -> 0.4.0-1.2
Last modified: 2007-11-30 17:11:13 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6
Description of problem:
After the update from evince 0.3.?, I have problems viewing some
documents created with embedded fonts. Incorrect letters appear - or
empty boxes. The documents were created with Adobe InDesign CS 3.0.0,
PDF-1.3. The font names are MyriadPro-*, i.e. MyriadPro-Bold. If you
want a sample, search the web for vendors hosting sample Forrester Research documents.
The do display correctly with xpdf 3.0.1.
I see Bugzilla Bug 167399 - I'm not sure if it is the same issue.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open document as described above.
Actual Results: Seems like correct fonts are not available. Document is not readable.
Expected Results: See fonts.
I'm seeing what appears to be the same issue. Not all documents display
corrupted; here's a link to a PDF that exhibits it:
This PDF works fine in Xpdf 3.01 (FC4 updates-released).
In Evince, some fonts work, others don't in this document; if I understand the
Properties page for the document correctly (File>Properties, Fonts tab), all the
used fonts are embedded (as subsets). As far as I can tell, it seems like the
broken fonts are embedded "Type 1C (CID)" fonts, while TrueType fonts seem OK.
I have other documents where the fonts are simply reported as "Type 1"; as far
as I can tell, those documents display correctly.
$ rpm -q evince
$ rpm -q poppler
OK, I saw this in yet another document, again the broken fonts seem to be listed
as "Type 1C (CID)". Looks like there may be some systematics to this?
Again, works fine in Xpdf. This is what the Xpdf program pdffonts has to say
about the fonts here, not sure if it's of any use?
$ pdffonts /tmp/roadmap.pdf
name type emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------
NLWIMQ+AGaramondPro-Regular CID Type 0C yes yes yes 1628 0
IXYEUA+HelveticaNeue-Light CID TrueType yes yes yes 115 0
IXYEUA+HelveticaNeue-Bold CID TrueType yes yes yes 114 0
HPOYGC+HelveticaNeue CID TrueType yes yes yes 123 0
GHESSE+Helvetica-Bold CID TrueType yes yes yes 135 0
GHESSE+AGaramondPro-Italic CID Type 0C yes yes yes 143 0
ERKGQI+AGaramondPro-Semibold CID Type 0C yes yes yes 150 0
BOGOAO+HelveticaNeue-Italic CID TrueType yes yes yes 157 0
Is it of any relevance that pdffonts reports the fonts as "Type 0C" while Evince
reports "Type 1C"? Can't remember ever hearing of Type 0 PostScript fonts...
I rebuilt the cairo and Poppler RPMs from Rawhide (cairo-1.0.0-1 and
poppler-0.4.2-1) and now the documents look beautiful. First, this means that
this actually appears to be a Poppler bug, so it should probably be moved.
Second, it seems that one of two things solved this:
(1) Updating to Poppler 0.4.2
(2) Using the cairo backend. (Evince about dialog reports that the cairo backend
I presume that sticking cairo into FC4 isn't really an option at this point.
Unfortunately I haven't figured out how to force Poppler to use the Splash
backend so I can't test this yet.
This is the CID font bug, was fixed a while ago in poppler cvs. rawhide has
poppler-0.5.4 which has the fix.