<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [Patch] Skip XRef gaps in PDFDoc save methods" href="https://bugs.freedesktop.org/show_bug.cgi?id=107057#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [Patch] Skip XRef gaps in PDFDoc save methods" href="https://bugs.freedesktop.org/show_bug.cgi?id=107057">bug 107057</a> from <a class="email" href="mailto:haxtibal@posteo.de" title="Tobias Deiminger <haxtibal@posteo.de>"> Tobias Deiminger</a> <pre>There's a problem with both of my patches: I realized only by now that the XRef::XRef(BaseStream *strA, ...) Ctor is doing some kind of "lazy load". It only loads the first table/stream and its entries during construction. The 2..n-th streams (linked by Prev) are not yet loaded. They're actually loaded later on demand with first access to a missing entry by XRef::getEntry. We get to this scenario when working with incrementally updated or linearized documents, because in this case there are more then 1 xref tables/streams. As a consequence, when a user calls saveXXX, we have to expect that XRef::entries list may not yet be fully populated. If we simply patch out "load if missing", we avoid not only the bad recovery, but we avoid also the required initial load of an entry into memory. I'm not yet sure how to solve it.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>