[poppler] Incremental update in poppler

[Julien Rebetez]

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
<leonardr at pdfsages.com> 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