Summary: | Not displaying text in PDF document | ||
---|---|---|---|
Product: | poppler | Reporter: | Germán Poo-Caamaño <gpoo+bfdo> |
Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=687419 | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
PDT Test case (Flyer A5 size intended to advertise a scouting section)
Don't complain if position at "nGlyphs" is out of bound |
Description
Germán Poo-Caamaño
2012-11-04 21:09:38 UTC
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.