<html> <head> <style></style></head> <body class='hmmessage'><div dir='ltr'>Is the difference the italic text "760 W. Swartzville Rd. Reinholds, PA 17569"?<div><br></div><div>That is not the address of Zook Interiors, right?</div><div><br></div><div>Is that a hidden mark added by the person who created the PDF?</div><div><br></div><div>Maybe they intentionally used an incorrect coding.</div><div><div><br></div><div>Then the question might be how the two different methods of extracting information respond to invalid data in the PDF.</div></div><div><br></div><div>pdftotext does not handle that text correctly, and ps2ascii (from ghostscript 9.16) crashes on it with</div><div><br></div><div><div>**** Warning: considering '0000000000 XXXXX n' as a free entry.</div><div><br></div><div>*** Warning: composite font characters dumped without decoding.</div></div><div><br></div><div>If a PDF breaks both poppler and ghostscript, the problem is probably the PDF.</div><div><br></div><div>pdfinfo shows that the file was made by pdftk 1.44, so it could be a bug or intentional change in pdftk.</div><div><br></div><div>William<br><br><div><hr id="stopSpelling">From: peter@scraperwiki.com<br>Date: Tue, 26 May 2015 10:53:52 +0100<br>To: poppler@lists.freedesktop.org<br>Subject: Re: [poppler] Incompatible number of glyphs from glib get_text{, layout}<br><br><div dir="ltr">On 17 January 2014 at 10:30, Peter Waller <span dir="ltr"><<a href="mailto:peter@scraperwiki.com" target="_blank">peter@scraperwiki.com</a>></span> wrote:<br><div class="ecxgmail_extra"><div class="ecxgmail_quote"><blockquote class="ecxgmail_quote" style="border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div dir="ltr"><div>A screenshot from the poppler glib demo app demonstrates this, attached below. Poppler gets 696 characters and 1261 layout rectangles.</div></div></blockquote><div><snip> <br></div><blockquote class="ecxgmail_quote" style="border-left:1px solid rgb(204,204,204);padding-left:1ex;"><div dir="ltr"><div><a href="http://pwaller.net/sw/2014-01-17-broken.pdf" target="_blank">http://pwaller.net/sw/2014-01-17-broken.pdf</a><br></div></div></blockquote></div><snip><br><blockquote style="border-left:1px solid rgb(204,204,204);padding-left:1ex;" class="ecxgmail_quote">I've reported this on bugzilla here: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=73885" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=73885</a><br></blockquote><div><br></div><div>Link to old thread: <a href="http://thread.gmane.org/gmane.comp.freedesktop.poppler/8683" target="_blank">http://thread.gmane.org/gmane.comp.freedesktop.poppler/8683</a> <br></div><div> <br></div><div>I've investigated this briefly. An observation:<br><br><a href="http://cgit.freedesktop.org/poppler/poppler/tree/glib/poppler-page.cc?id=poppler-0.33.0#n825" target="_blank">http://cgit.freedesktop.org/poppler/poppler/tree/glib/poppler-page.cc?id=poppler-0.33.0#n825</a><br><br></div><div>The sel_text->getLength() is 1283 (which doesn't match with the 1261 from poppler_page_get_layout).<br><br></div><div>If I change this to use a g_strndup() with the correct length:<br><br><blockquote style="border-left:1px solid rgb(204,204,204);padding-left:1ex;" class="ecxgmail_quote">result = g_strndup (sel_text->getCString (), sel_text->getLength());<br></blockquote><div><br></div><div>And then look at result[696:], then I find that the rest of the string is filled with 0 bytes.<br><br></div><div>I'm extremely keen to get this fixed, so any pointers would be appreciated. The rate of encountering this bug is increasing all the time!<br><br></div><div>Thanks,<br><br></div><div>- Peter<br></div></div></div></div> <br>_______________________________________________ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler</div></div> </div></body> </html>