Hi, (reposting to the list, I forgot to CC it to the list, sorry for double mail Leonard) First, thanks for your feedback.
On Tue, 11 Jul 2006 17:19:53 -0400, Leonard Rosenthol <[EMAIL PROTECTED]> wrote: >>The main change is the addition of the 'addIncrementalObject' function >>to PDFDoc : >>When you call this function, the object given as argument is 'queued' in >>the document. > > So then all new objects are indirect? How do you plan to > handle direct objects? Since when using incremental update the Xref is used to specify which objects are updated and the Xref only store reference to indirect object, I don't see how it is possible to handle direct object update with this approach. But this is a limitation of the incremental update approach and a good reason to take another way :-) >>The next time 'PDFDoc::SaveAs' is called, all the queued objects are >>written (with a new XRef/Trailer and all the needed stuff) to the file. > > What are you doing about existing Linearization? You can't > keep it there as it is no out of sync with the new data you've written... (I'm not sure I fully understood what you said here) Do you speak of the case where a Linearized PDF is incrementally updated ? Refering to the appendix F.4.6 of the specs, this is up to the viewer app to handle this case. If poppler doesn't handle that, it adds some work.. > >>This part works almost correctly (though Acrobat wants to repair the >>updated file before reading it). > > If Acrobat wants to repair, that means that it is NOT > working correctly. Open it back up with Poppler or Xpdf and watch > for error messages. Xpdf/poppler don't give me any error message, acrobat isn't very verbose, do you know another way to get more informations ? > >>The last point is not implemented at the moment (you can 'simulate it' >>by saving the document and re-opening it) because Object are only >>written to the file when PDFDoc::SaveAs is called. > > Also, I suspect that you aren't rewriting Appearance streams > for you fields - which means that Acrobat will display them incorrectly. I currently only tested with text fields, but since the text appearance is generated by the viewer based on some informations given by the field dictionnary, I don't see the problem. And at the moment, Acrobat display my fields correctly. (even with some tax form in which user-entered text is in blue). > > >>I'm not a Poppler-guru, but the only way I see to add this 'live update' >>feature is that PDFDoc::addIncrementalObject should add the updated >>Object/Xref/Trailer directly into the stream. > > Or follow my original suggestion of doing real object > handling in Xpdf - which would then enable live changes/updates to any > object. Mmh yeah, I think you convinced me that your approach is better though it would require a lot of work. For example if you take a Page for which you want to change the cropBox. Since in the Page class the cropBox is stored as a PDFRectangle, it would require to store the cropBox as a reference to the 'real' Object in order to have the modifications propagated through poppler ? And we need to do that for every Class that rely on 'updatable' Objects, this would end up rewriting a large part of Poppler, wouldn't it ? (but I think the benefits would be very great) I'll give a try to your 'real object handling' idea, to see where it'll take me. Julien _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
