Bug forwarded from evince: http://bugzilla.gnome.org/show_bug.cgi?id=545398 It always crashes when rendering in both cairo and splash backends with similar backtrace: (gdb) bt #0 0xb7186d28 in strcmp () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7548cf9 in ?? () from /usr/lib/libfreetype.so.6 #2 0xb7526f2c in FT_Get_Name_Index () from /usr/lib/libfreetype.so.6 #3 0xb7fc9a97 in CairoFont::create (gfxFont=0x0, xref=0x8aa4f80, lib=0x8aa7110, useCIDs=1) at CairoFontEngine.cc:136 #4 0xb7fc9d67 in CairoFontEngine::getFont (this=0x8aa82f0, gfxFont=0x8bcc698, xref=0x8aa4f80) at CairoFontEngine.cc:379 #5 0xb7fcd1e6 in CairoOutputDev::updateFont (this=0x8aa6bf8, state=0x8bcf468) at CairoOutputDev.cc:389 #6 0xb7e90fc2 in Gfx::opShowText (this=0x8bca4d8, args=0xbfbf3a60, numArgs=1) at Gfx.cc:3172 #7 0xb7e88922 in Gfx::execOp (this=0x8bca4d8, cmd=0xbfbf3c00, args=0xbfbf3a60, numArgs=1) at Gfx.cc:740 #8 0xb7e88afe in Gfx::go (this=0x8bca4d8, topLevel=1) at Gfx.cc:611 #9 0xb7e8e43f in Gfx::display (this=0x8bca4d8, obj=0xbfbf3cdc, topLevel=1) at Gfx.cc:580 #10 0xb7ecc4e6 in Page::displaySlice (this=0x8aa6028, out=0x8aa6bf8, hDPI=72, vDPI=72, rotate=0, useMediaBox=0, crop=1, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=0, catalog=0x8aa4ff0, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:415 (gdb) bt #0 0xb71a9d28 in strcmp () from /lib/tls/i686/cmov/libc.so.6 #1 0xb756acf9 in ?? () from /usr/lib/libfreetype.so.6 #2 0xb7548f2c in FT_Get_Name_Index () from /usr/lib/libfreetype.so.6 #3 0xb7f4e681 in SplashFTFontFile::loadType1Font (engineA=0x9aabc70, idA=0x9ab0b90, src=0x9ab07e8, encA=0x9ab0600) at SplashFTFontFile.cc:45 #4 0xb7f4df42 in SplashFTFontEngine::loadType1CFont (this=0x9aabc70, idA=0x9ab0b90, src=0x9ab07e8, enc=0x9ab0600) at SplashFTFontEngine.cc:79 #5 0xb7f4f263 in SplashFontEngine::loadType1CFont (this=0x9aabd48, idA=0x9ab0b90, src=0x9ab07e8, enc=0x9ab0600) at SplashFontEngine.cc:156 #6 0xb7e73b6c in SplashOutputDev::doUpdateFont (this=0x9aa28b8, state=0x9ab38e8) at SplashOutputDev.cc:1045 #7 0xb7e743ec in SplashOutputDev::drawChar (this=0x9aa28b8, state=0x9ab38e8, x=94.730000000000004, y=119.28, dx=18.34, dy=0, originX=0, originY=0, code=56, nBytes=2, u=0x9ab26a0, uLen=1) at SplashOutputDev.cc:1323 #8 0xb7eb315f in Gfx::doShowText (this=0x9ab0430, s=0x9ab0b68) at Gfx.cc:3389 #9 0xb7eb3f8e in Gfx::opShowText (this=0x9ab0430, args=0xbfeefaa0, numArgs=1) at Gfx.cc:3176 #10 0xb7eab922 in Gfx::execOp (this=0x9ab0430, cmd=0xbfeefc40, args=0xbfeefaa0, numArgs=1) at Gfx.cc:740 #11 0xb7eabafe in Gfx::go (this=0x9ab0430, topLevel=1) at Gfx.cc:611 #12 0xb7eb143f in Gfx::display (this=0x9ab0430, obj=0xbfeefd1c, topLevel=1) at Gfx.cc:580 #13 0xb7eef4e6 in Page::displaySlice (this=0x9aa3760, out=0x9aa28b8, hDPI=72, vDPI=72, rotate=0, useMediaBox=0, crop=1, sliceX=-1, sliceY=-1, sliceW=-1, sliceH=-1, printing=1, catalog=0x9aa3560, abortCheckCbk=0, abortCheckCbkData=0x0, annotDisplayDecideCbk=0, annotDisplayDecideCbkData=0x0) at Page.cc:415 And this error is prompted in stdout: "Error: Mismatch between font type and embedded font file" The PDF file is attached to the original bug report.
Created attachment 29058 [details] [review] Maintain Type0 fonts when using embedded font type This patch should fix the bug. As I understand, the PDF is malformed. The font with object number 58 has type /Type0 has a descendant font (57 0 R) whose font descriptor (56 0 R) points to (via /FontFile3) embedded font program 71 0 R. Object 71 has type /Type1C, which, from table 5.23, can only appear in Type1 or MMType1 fonts. This is where the "Mismatch between font type and embedded font file" is coming from. Poppler uses the embedded font's type when the types do not match. However, it blindly sets the type, ignoring the fact that Type0 fonts get a different class (GfxCIDFont instead of Gfx8BitFont) and a different set of types (fontCIDType*). Later, when the font is used, we downcast by reinterpreting the pointer based on the type. When the type is wrong, a GfxCIDFont is interpreted as a Gfx8BitFont and Bad Things happen. Assuming I did this right, the patch should fix this. When we set the type from a mismatch, we check if the font is CID and pick the equivalent font type from CID set and vice versa. Also, a helpful warning is displayed. (Disclaimer: I don't actually understand PDF fonts... skimmed the spec for relevant-looking bits to implement this. It does successfully render the PDF without extra warnings, which is a good sign.)
The patch makes sense, i've been trying to find out a simple solution for the problem and yours seems okaish, just wondering why did you decide to "fallback" to a specific type and not other, not saying it's wrong just that i'd like to know your rationale :-) I'm in process of regtest it, will commit it in a few days if everything works as expected.
Commited
(Oh hey, I never added myself to the CC list for this bug, so I only just saw this.) The original code already fell back to the embedded font's format. (And this PDF file spews out a ton of errors if you pick the type specified in the font dictionary. And I guess it makes sense that the type nearest the font data is most accurate.) As far as exactly which type, my impression is that there's a correspondence between the CID and the non-CID types, so I just picked the one that matched.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.