Forwarded from this evince bug:
"Please describe the problem:
Certain PDFs have forms that won't save with evince. I built the latest evince
(2.25.2) from source against the latest poppler (0.10.1).
If this is purely a poppler bug, please let me know and I will refile this bug
Steps to reproduce:
1. download http://www.uscis.gov/files/form/I-130.pdf
2. fill out the first field and move your cursor to the next field (seem to be
necessary to make sure that evince knows to save it)
3. "Save A Copy" as I-130-copy.pdf
4. close evince
5. re-open the saved file, from the command-line e.g. evince I-130-copy.pdf
The field's value is not restored. On the command line you see the following
Error: Reference to an invalid or non existant object
one per field field that you filled in the original form
The form data should be restored.
Does this happen every time?
Yes with this file.
Other PDFs with forms work just fine, e.g. filling out and saving:
works fine, so it seems to be a bug specific to certain forms"
The non-working form is an XFA form.
(In reply to comment #1)
> The non-working form is an XFA form.
What's an XFA form? Is there something special about those kinds of forms? Is it planned that poppler support them?
If full XFA support isn't possible in the short term, is it possible for poppler to ignore the scripting part (presumably verification checks etc.) and just allow raw text to be stored in those fields? That way at least you could save the contents of the text in the forms even if they don't trigger scripts within the PDF.
> What's an XFA form?
has about as much info as I know.
A search for XFA on the itext-questions list at sourceforge would likely
be instructive; I recall numerous queries about them and itext's support
for them. But not the details, and I'm writing this reply while offline...
Also, a search there for LiveCycle should yield related details.
(Just a poppler consumer, who was curious why only one of the two worked.)
*** Bug 51998 has been marked as a duplicate of this bug. ***
Is there any progress regarding support for XFA forms? Are there legal or technical issues blocking an implmentation in poppler? Thanks.
*** Bug 55978 has been marked as a duplicate of this bug. ***
Adobe XML Forms Architecture (XFA) Specification, version 3.3 (1584 pages) is available here:
iText provides an online demo that flattens PDF with XFA forms to an ordinary PDF:
Please do not change bug priority if you not a developer of poppler
What is the current status of development for XFA forms in poppler and programs using poppler? I encountered an XFA form for the first time a couple of days ago, and later read that Adobe are removing the downloads for the Linux version of Adobe Reader.
What are the different components that need work in order for at least one Linux pdf reader to support this?
poppler needs to implement XFA forms support.
Are there any near term plans for implementing this feature?
Newer versions of Xpdf do implement XFA Forms, but the implementation is very different from current poppler implemenation which grew from older version of xpdf. There is a "plan" of merging new parts of xpdf code into poppler but afaik there is no people with time to do this.
Savvy article . BTW , you are requiring a I- 130 - USCIS form, my secretary filled out and esigned a fillable document here http://pdf.ac/3IsYYu.
Is this fixed? Editing the listed file using Evince seems to work now.
Created attachment 139512 [details]
Another PDF with XFA
Unfortunately perhaps just for this particular kind of PDF. I'm attaching another one that doesn't open at all.
Gov agencies seem to have weird bias towards technologies that require Adobe abandonware (like Adobe AIR, Acroread).
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/199.