<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - wrong render result" href="https://bugs.freedesktop.org/show_bug.cgi?id=85919#c15">Comment # 15</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - wrong render result" href="https://bugs.freedesktop.org/show_bug.cgi?id=85919">bug 85919</a> from <a class="email" href="mailto:Thomas.Freitag@alfa.de" title="Thomas Freitag <Thomas.Freitag@alfa.de>"> Thomas Freitag</a> <pre>(In reply to Albert Astals Cid from <a href="show_bug.cgi?id=85919#c14">comment #14</a>) > No, trying tryingToReconstruct == true won't work as it's never true in this > case. I wonder if the difference is because we're having linearization into > account and adobe not? No, Albert. I found now the time to look at the PDF: it is as I guessed, it was an incremental update, but the incremental update section after the original startxref is damaged. It starts with binary data, then have some correct obj's, but also the new startxref is missing. The poppler code without the patch now does not find the xref table and immediately reconstructs the xref table (because of startXRefPos = 0) with a scan of the complete PDF file. This is possible with the PDF, so xref->isOk() is gTrue. But some of the defect objects (esp. not complete objects) of the incremental update overwrites the original objects, therefore it's then no more possible to render the second page correctly. So thinking a little bit more Julius Li patch I think it is okay: if it doesn't find a xref section at the end it tries to find one before, so it finds the xref table if existing of the last correct incremental update. If it doesn't find any it runs in the old manner and reconstructs the xref table by parsing the PDF.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>