[Poppler-bugs] [Bug 85919] wrong render result

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=85919

--- Comment #15 from Thomas Freitag <Thomas.Freitag at alfa.de> ---
(In reply to Albert Astals Cid from comment #14)
> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20141228/5e8fdb70/attachment.html>