<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - PDFDoc::saveIncrementalUpdate() saves the trailer dict twice" href="https://bugs.freedesktop.org/show_bug.cgi?id=96529#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - PDFDoc::saveIncrementalUpdate() saves the trailer dict twice" href="https://bugs.freedesktop.org/show_bug.cgi?id=96529">bug 96529</a> from <a class="email" href="mailto:jakubkucharski97@gmail.com" title="Jakub Kucharski <jakubkucharski97@gmail.com>"> Jakub Kucharski</a> <pre>My current understanding of PDFDoc::saveIncrementalUpdate() is that it prints the original file in whole first. Then it appends the new versions of updated objects, writes another xref table and another trailer dict. I don't think this is permitted by the PDF reference. In the PDF reference v7 there is a figure (3.2) at page 91 showing that a PDF file is divided into 1. header, 2. body, 3. cross-reference table, 4. trailer. So I don't think it's ok to print anything after the trailer. Correct me if I'm wrong. If I'm right, I may write another function like PDFDoc::getEndXRefTablePos() (added by my suggested patch) which would find the end of PDF "body". PDFDoc::saveIncrementalUpdate() would then append all the updated objects and every time (no matter if there are any updated objects) would append xref table and trailer dict (not copy it from the original file). Feel free to correct me about any possible misunderstandings.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>