[poppler] Filled text field data not visible in saved document

Fabio D'Urso fabiodurso at hotmail.it
Sat Oct 13 17:49:09 PDT 2012


On Tuesday, September 18, 2012 07:52:23 PM Albert Astals Cid wrote:
> El Dimarts, 18 de setembre de 2012, a les 07:49:05, vau escriure:
> > Hi Albert, Hi Fabio,
> > 
> > the solution from Fabio worked quite well to me.
> > There are still some PDFs remaining which do not have their application
> > stream changed - at least it looks like that.
> > 
> > But for most of the files I tried it works fine.
> > Hence, a big "thank you" to Fabio and I would recommend to apply that
> > patch to an upcoming release.
> 
> Spoke with Fabio in private and he seems not to be happy with it, he'll be
> working in a better one once he gets a bit of time.

Here we go. I've rewritten the patches in a cleaner way and now I'm satisfied 
with them.

Short recap: After filling and saving a PDF form, filled text fields are still 
shown with their old value (usually blank) in acroread (and in poppler too,
when you open the resulting PDF file) because we don't update the annotation 
widgets' appearance streams.

With these patches, the appearance stream gets rewritten for text and 
choice fields (for button fields it's not necessary).
Note that choice fields still don't work in acroread, because of some 
unrelated issues that I'll discuss in a new thread.

Patches in detail:

0001

Patch 0001 adds a AnnotWidget::updateAppearanceStream() method that is called 
by form handling code to inform the widget annotation that its appearance 
stream is no longer valid and needs to be rebuilt.
This information was previously obtained by the widget annotation by testing 
field->isModified() before drawing. This new "push" approach has two 
advantages:
1) The appearance is now rebuilt only once after the contents are modified. 
Previously, field->isModified() stayed always true, even after the first 
draw() call, causing the apperance stream to be rebuilt on every subsequent 
draw() call too, even if contents stayed the same.
2) It gives the possibility to react to modifications immediatly, without 
having to wait for the next rendering.

0002

This patch creates the new appearance stream in 
AnnotWidget::updateAppearanceStream() and writes it in the xref. This patch 
fixes the original bug, but...
Note: ...every time the field is modified (eg in okular it happens every time 
the the user adds or removes a character) the old apprearance stream is 
deleted and a new one is generated. This means that the xref entry for the old 
appearance is freed and a new one is allocated. Since every time a xref entry 
is freed its generation number gets incremented, repeated edits result in 
generation numbers rapidily growing. The next patch solves this issue.

0003

This patch avoids going through xref entry deallocation+allocation on every 
modification. Now it only happens the first time, and references to the newly 
allocated xref entry are kept, so that subsequent updateAppearanceStream 
invocations can do a simple overwrite instead.

These patches are supposed to fix exactly the same documents that the previous 
proof-of-concept patch fixed. Please let me know if you find any difference.

Thank you,
Fabio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Killed-FormField-isModified-in-favor-of-a-new-AnnotW.patch
Type: text/x-patch
Size: 8851 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20121014/7f4f34bb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Generate-and-write-the-appearance-stream-in-AnnotWid.patch
Type: text/x-patch
Size: 1878 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20121014/7f4f34bb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-AnnotWidget-Avoid-repeatedly-deleting-and-creating-x.patch
Type: text/x-patch
Size: 3738 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20121014/7f4f34bb/attachment-0002.bin>


More information about the poppler mailing list