Created attachment 69529 [details] PDT Test case (Flyer A5 size intended to advertise a scouting section) Transfering this bug from GNOME Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=687419 Original message: I'm using evince 3.6.0 on a Ubuntu 12.10 system on a Dell inspiron 1545, pentium dual core CPU T4400 & the graphics reported as Mobile Intel® GM45 Express Chipset x86/MMX/SSE2 . I've found that some .pdf's are not fully displaying on evince. I'm a Scout leader in the UK & I created a flyer using the print centre available to leaders. The flyer consists of a background with images & then boxes containing contact details, venue's etc. The background poster is displaying, but not the boxes with the other information. Does not relate to all of the posters / flyers created using the software on the site. Using the same laptop I've viewed the whole .pdf flyer using ImageMagick (display), but also found that gimp (2.8) suffers from the same problem & only displays the background images. Strangely enough the whole .pdf flyer displays well on my android phone using kindle. The problem does not seem to be related to file size, as evince is happily displaying some files that are much larger. One of the flyers with the problem is attached to this report. Please don't hesitate to contact me if I can help in any way further.
The text is there, but it is now shown properly. I mean, I can select the text, copy and paste it to a text editor. That said, it seems a bug in poppler (or cairo). When I render the document with poppler-glib-demo, I get the following output in the console: $ poppler-glib-demo /tmp/D00196233_00001.pdf Document successfully loaded in 0.0020 seconds some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed some font thing failed poppler (0f7c17d7f92d4cd) and cairo (cf07bd866) from master.
A quick debugging shows that the FoFiTrueType::make is returning null. When debugging a little further, I get that the code that checks for the sanity of the 'loca' table set parsedOk to false and hence the FofiTruetype::make returns Null. Unfortunately, I don't have more font knowledge to know whether this comes from a fault in the pdf file or not. Fwiw, if I comment the lines of the check (2087-2097 in FoFiTrueType.c) and I try to render the file, it renders without any problems. Hope this helps.
Not cairo specific
Created attachment 69563 [details] [review] Don't complain if position at "nGlyphs" is out of bound I'm not a truetype expert, therefore I'm not sure if our code or the PDF is the problem. But with this small patch the PDF is rendered correctly.
Thomas, if we're going to do this, shouldn't we just modify the outer loop?
(In reply to comment #5) > Thomas, if we're going to do this, shouldn't we just modify the outer loop? It was just cowardly: see that also pos = getU16BE(tables[i].offset + j*2, &parsedOk); in the loop can change the parsedOK value, and I'm not sure if this still should be done with j == nGlyphs.
getU16BE is just a getter, sure it might put the parseOk to false, but you are already ignoring one error :D
(In reply to comment #7) > getU16BE is just a getter, sure it might put the parseOk to false, but you > are already ignoring one error :D Okay, okay. Change the outer loop. To be true, when I had a first look at it I was wondering why j runs from 0 to equal nGlyphs. I would thought that having nGlyph it would be sufficient (and just more correct) to run from 0 to less nGlyphs. But because it was regtested by You and seems to work (I really wondered about that), I changed it in that way.
Actually i'm being much more bold and suggesting we remove the whole loop. I've removed it and ran the regtest and besides this it fixes another bug and there is no regression. Looking at the code we only use the "loca" table in one place and it actually has a bit of a different logic for the parsing so since we don't use it I am suggesting to remove it. Comments?
(In reply to comment #9) > Actually i'm being much more bold and suggesting we remove the whole loop. > > I've removed it and ran the regtest and besides this it fixes another bug > and there is no regression. > > Looking at the code we only use the "loca" table in one place and it > actually has a bit of a different logic for the parsing so since we don't > use it I am suggesting to remove it. > > Comments? I would agree!
Will be fixed in poppler 0.22
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.