Editable .pdf fields disappear (but visible on field focus) after save with evince

Question

First off, let me thank the SO community for helping me so many times in the past; you guys are an amazing resource!

At my job I work on a web application that uses

Answer 1

I have accepted mkl's answer as it hits the nail on the head regarding why the fields do not display properly, and contains much more information than I can provide regarding the issue. However, the suggested fix in the answer's comments did not work because the documents are generated (in this particular case) using iText 2.1.5's PdfCopyFields, which does not respect (strips) the original document's NeedAppearances flag, and calling setNeedAppearances(true) for AcroForm did not solve the issue because of this.

Hacking the createAcroForms() method in PdfCopyFieldsImp to include the line

form.put(PdfName.NEEDAPPEARANCES, PdfBoolean.PDFTRUE);

is what ultimately seems to have solved the issue for me. With this addition, evince properly displays changes to fields after saving and reopening the document.

Answer 2

An inspection of the files supplied by jbowman in the comments to his question --- with special regard to the password field (which is one of the fields entually filled in by evince) --- shows:

Template.pdf

• is the original form which was generated by Scribus PDF Library 1.4.1.svn;
• contains an AcroForm with 9 fields and the flag NeedAppearances set to true;
• has the password field (named passwordField) which contains an empty value and a normal appearance stream painting a rectangle with an empty text.

after_itext.pdf

• is the original form edited by iText 2.1.5, unfortunately not in append mode which would have made analysis easier;
• contains an Acroform with 8 fields (the member number field has been filled in and flattened) without a NeedAppearances flag;
• has the password field (named passwordField:u4woYY1FK9) value and appearances left untouched.

after_itext_edited.pdf

• is the form formerly edited by iText now edited by some other software (evince) in append mode;
• contains an Acroform with 8 fields without a NeedAppearances flag; the only changes have been made to the fields passwordField:u4woYY1FK9 and memberPrefix:u4woYY1FK9:
• has the password field (named passwordField:u4woYY1FK9) with a new associated value asdf but has left its appearances untouched;
• has the member prefix field (named memberPrefix:u4woYY1FK9) with a new associated value asdf but has left its appearances untouched.

Thus, the observed behavior that the value by default is not shown, is to be expected:

The final Acroform has no NeedAppearances flag. This flag is defined in the specification ISO 32000-1:2008 as:

A flag specifying whether to construct appearance streams and appearance dictionaries for all widget annotations in the document (see 12.7.3.3, “Variable Text”). Default value: false.

Thus, your PDF document in its final form says: No appearances for widgets (e.g. AcroForm field visualizations) need to be generated, take the appearances from the document.

The appearance of the password field from the document is the original one, the rectangle with the empty text.

So you see this empty rectangle.

When you click into the field, the PDF viewer prepares for editing its contents and therefore displays the value as it sees fit.

If editing PDF files with evince is intended to have visible results, evince upon changing the value of the fields must also add updated appearance streams or make sure the AcroForm NeddAppearances flag is set. Therefore, this is where evince failed.