GNOME Bugzilla – Bug 472087
Evince does not load specific documents (.pdf) properly
Last modified: 2008-04-14 08:23:05 UTC
Please describe the problem: Document at http://w3.linux-magazine.com/issue/83/Linux_World_News.pdf does not seem to be loaded properly. All I can see is a big square on the left hand side of the document. This does work on Adobe Reader (on non Linux platforms) Steps to reproduce: 1. Download http://w3.linux-magazine.com/issue/83/Linux_World_News.pdf 2. Use evince to view 3. Actual results: All I can see is a big square on the left hand side of the document Expected results: I should be able to view the document as this works on Adobe Reader (on non Linux platforms) Does this happen every time? Yes Other information:
It seems to be a problem in freetype. With freetype 2.2.1 it's rendered correctly. Thanks for taking the time to report this bug. However, this application does not track its bugs in the GNOME Bugzilla. We kindly ask you to report the bug to the application authors. For a selective list of other bug tracking systems please consult http://live.gnome.org/Bugsquad/TriageGuide/NonGnome. If the affected third party application has a bug tracking system you should investigate whether a bug for the reported issue is already filed in this system. If it has not been filed yet please do so. Also ensure that both bug reports contain a link to each other. Thanks in advance!
(In reply to comment #1) > It seems to be a problem in freetype. With freetype 2.2.1 it's rendered > correctly. I checked up your hint and : [sankar@dhcp1-95 ~]$ sudo rpm -qa|grep freetype freetype-devel-2.3.4-3.fc7 freetype-2.3.4-3.fc7 So, where do I report this ? And, in future how do I isolate an evince issue from a Freetype one ?
(In reply to comment #2) > (In reply to comment #1) > > It seems to be a problem in freetype. With freetype 2.2.1 it's rendered > > correctly. > > I checked up your hint and : > > [sankar@dhcp1-95 ~]$ sudo rpm -qa|grep freetype > freetype-devel-2.3.4-3.fc7 > freetype-2.3.4-3.fc7 > > So, where do I report this ? I'm not sure, I haven't found anything in freetype.org. I've already reported to my distro: https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/136317 > And, in future how do I isolate an evince issue > from a Freetype one ? Actually, it's not so easy. In general, rendering problems are usually poppler bugs or even cairo bugs. This time it took me a while figuring out that the problem was in freetype. First I tried with several poppler versions, then cairo and finally freetype.
If you select the text, it's readable. I don't think it's freetype.
(In reply to comment #4) > If you select the text, it's readable. I don't think it's freetype. > Then, it's probably one of these: https://bugs.freedesktop.org/show_bug.cgi?id=9846 https://bugs.freedesktop.org/show_bug.cgi?id=10401 https://bugs.freedesktop.org/show_bug.cgi?id=11298 So it's NOTGNOME anyway. We have similar problems with a lot of documents that have Type 1C (CID) Embedded Subset fonts. They work with freetype < 2.3.0 but with freetype >= 2.3.0 text is not rendered at all. However, it doesn't seem to be a freetype error (see http://savannah.nongnu.org/bugs/index.php?20948). So it seems the problem is in the cairo-freetype interaction. Cairo is unconditionally returning an OOM error when FT_Load_Glyph fails. Jeff pointed to a possible solution in cairo here: https://bugs.freedesktop.org/show_bug.cgi?id=8399#c5 So any help in this way would be really appreciated. I'm afraid we are going to receive a lot of bugs when the new main distros release a new version with freetype >= 2.3.0
I don't think it has much to do with freetype version, as opposed to cairo version. Cairo started correctly propagating freetype errors, so they end up in the cairo scaled font and any subsequent rendering using the font is ignored. So, most probably there's a problem in poppler or the PDF in the first place, causing a freetype error (an out-of-range glyph for example), and a error propagation problem in cairo which should ignore some minor error. I'll try to fix the latter, but someone should debug the former. Just put a breakpoint on _cairo_error() and see where it triggers.
(In reply to comment #6) > I don't think it has much to do with freetype version, as opposed to cairo > version. Cairo started correctly propagating freetype errors, so they end up > in the cairo scaled font and any subsequent rendering using the font is > ignored. So, most probably there's a problem in poppler or the PDF in the > first place, causing a freetype error (an out-of-range glyph for example), and > a error propagation problem in cairo which should ignore some minor error. > I'll try to fix the latter, but someone should debug the former. > > Just put a breakpoint on _cairo_error() and see where it triggers. I did that now: Breakpoint 1, _cairo_error (status=CAIRO_STATUS_NO_MEMORY) at cairo.c:90 90 assert (status > CAIRO_STATUS_SUCCESS && (gdb) bt
+ Trace 161032
It's failing to look glyph 0 in the font. So, your freetype 2.3 analysis is correct. Let me see what the error is coming from.
So, I uncompressed the PDF and indeed there's a CID 0 rendered, where the font doesn't have any CID 0 glyphs: [<002D00410047004E004500540000>30<0034>129<004500430048004E004F004C004F00470049004500530000>30<004F0052>18<00470041004E0049005A004500440000>30<00410000>30<0043004F004D>]TJ The first run of glyphs is what's causing this cairo traced above, which has the following glyphs array: (gdb) p glyphs[0]@7 $4 = {{index = 45, x = 36.85161999999999, y = 659.05538999999999}, {index = 65, x = 44.681619999999988, y = 659.05537259999994}, { index = 71, x = 49.172619999999988, y = 659.05536261999998}, {index = 78, x = 53.672619999999988, y = 659.05535262000001}, { index = 69, x = 58.838619999999992, y = 659.05534114}, {index = 84, x = 63.167619999999992, y = 659.05533151999998}, {index = 0, x = 65.993619999999993, y = 659.05532524}} So, this is a faulty PDF IMO. The fix belongs to cairo. /me goes doing that.
CID zero is used for the space character in this PDF it seems. Faulty PDF generator. Got to cope with it.
I have no idea why selection works though.
Behdad, thank you very much for looking into it. (In reply to comment #6) > I don't think it has much to do with freetype version, as opposed to cairo > version. With the same cairo and poppler versions, just by changing the freetype version (from >= 2.3.0 to < 2.3.0) the problem is fixed. (In reply to comment #9) > CID zero is used for the space character in this PDF it seems. Faulty PDF > generator. Got to cope with it. > Even if the problem is in the PDF file, the truth is that xpdf, poppler with splash backend and of course acroread render the document perfectly. There are a lot of PDF files with this problem. Anyway, look at what freetype people says here (http://savannah.nongnu.org/bugs/index.php?20948): "This is OK, due to `sloppy' subsetting: The font reports 82 slots, of which many are empty (this is, pointing to the invalid CID 0); FreeType simply renders them starting with glyph index 0, regardless whether it is valid or not (properly returning an CFF_Err_Invalid_Argument in those cases). With other words, I don't see an error here. It must be something else."
(In reply to comment #11) > Behdad, thank you very much for looking into it. > > (In reply to comment #6) > > I don't think it has much to do with freetype version, as opposed to cairo > > version. > > With the same cairo and poppler versions, just by changing the freetype version > (from >= 2.3.0 to < 2.3.0) the problem is fixed. > > (In reply to comment #9) > > CID zero is used for the space character in this PDF it seems. Faulty PDF > > generator. Got to cope with it. > > > > Even if the problem is in the PDF file, the truth is that xpdf, poppler with > splash backend and of course acroread render the document perfectly. There are > a lot of PDF files with this problem. > > Anyway, look at what freetype people says here > (http://savannah.nongnu.org/bugs/index.php?20948): > > "This is OK, due to `sloppy' subsetting: The font reports > 82 slots, of which many are empty (this is, pointing to the > invalid CID 0); FreeType simply renders them starting with > glyph index 0, regardless whether it is valid or not (properly > returning an CFF_Err_Invalid_Argument in those cases). > > With other words, I don't see an error here. It must be > something else." Yes, I read that. There are two errors: - The PDF uses CID 0 which is undefined in the font. - Cairo takes that too seriously.
Ok. lets continue upstream: https://bugs.freedesktop.org/show_bug.cgi?id=9846
*** Bug 527676 has been marked as a duplicate of this bug. ***