[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