Textfield Widget not displaying value after updating.

[boukeas]

Describe the bug (mandatory)

A TextField widget can be added to a pdf programmatically. However, when a user loads the pdf into a viewer and manually updates the text in the field, the new value is not displayed.

To Reproduce (mandatory)

import fitz
doc = fitz.Document()
page = doc.newPage()
page.insertTextbox(fitz.Rect(10, 10, 200, 30), "Some text")

widget = fitz.Widget()
widget.rect = fitz.Rect(10, 40, 200, 60)
widget.field_type = fitz.ANNOT_WG_TEXT
widget.text_fontsize = 16
widget.fill_color = (0.8, 0.8, 0.8)
widget.field_name = "textfield-1"
widget.field_value = "form text"
annot = doc[0].addWidget(widget)

doc.save("test.pdf", clean=True)
doc.close()

Screenshots (optional)

This is how the text field is displayed originally.

The user manually enters new text in the field:

The new value is not displayed:

Your configuration (mandatory)

• Ubuntu 18.04
• Python 3.6.9
• PyMuPDF version 1.16.17

Additional context (optional)

In the past, I have used pdfrw to fill in the forms in a pdf and I had encountered a similar problem. It was solved using the NeedAppearances flag:

# bug fix from https://github.com/pmaupin/pdfrw/issues/84
PdfReader(input_pdf).Root.AcroForm.update(PdfDict(NeedAppearances=PdfObject('true')))

[JorjMcKie]

Cannot reproduce.
Tried your script and successfully changed the field using:

• Adobe Acrobat Reader
• Nitro PDF 5
• Foxit Reader
• PDF-XChange

Even using the Edge internet browser worked.
Also worked changig the field programmatically using PyMuPDF.

[boukeas]

That's interesting. I have been trying this in Ubuntu's default pdf reader (Evince) but I hadn't thought of testing in a browser; I tried it in Mozilla and it did work. I am closing this, thank you.

[JorjMcKie]

... It was solved using the NeedAppearances flag ...

In PyMuPDF, appearance stream objects (/AP) are always generated for annotations and form fields. So this is shouldn't be relevant here.
Except the software you use for filling the form is weird enough to require it.

[JorjMcKie]

Just saw your response concerning evince.
I currently have not Linux machine to confirm. But to be sure let me make the general change in PyMuPDF and always set that property when the PDF has fields.

[boukeas]

I've done some additional testing that may be of use. When I save the pdf form with the updated text value and reload it in my pdf viewer, the updated value is not visible but clicking in the field reveals it has been stored correctly.


Unfortunately, I am not able to do that in a browser. Loading the test pdf in the browser allows you to update the field and the updated value is visible:


When I save the pdf form with the updated text value and reload it in my browser, the original value appears in the text field.

[JorjMcKie]

Another weird phenomenon. Tried to reproduce. You should be aware that all internet browsers use some plugin for PDF handling, and it is not always the same one. E.g. my Firefox (Windows) won't allow field updates at all, but my MS Edge browser does.

1. Changing text value with Edge and closed /saved PDF.
2. Open changed PDF with all available viewers shows the changed value correctly (Edge, Firefox, Adobe, PDF-XChange, Nitro PDF, Foxit Reader).

So it is not clear what is happening at your site. You can send me the updated PDF, so I can have a look at its internals and see how my viewers are digesting it.

BTW I just implemented a Document method need_appearances. It takes one argument which may be None, False or True. None just inquires whether the property exists and returns its value (or None if missing or any error). True and False set the property. After this has happend, only changes to the value can be done (flip between true or false). The property as such cannot be deleted again (which is no problem).

[boukeas]

Thank you. This is the updated pdf:
test.newer.pdf

[JorjMcKie]

Suspicion confirmed: it seems to be the absence of that overall property NeedAppearances.
The appearance stream of your changed field does not contain the new field value - only the field object definition (the /V property has that new string). All my viewers behave exactly like you described it.

Try to check with a form PDF not created with PyMuPDF. Edit the PDF with some text editor and look for that property. Then delete it or put in false instead of true. Your changes must be done such, that the new content has exactly the same number of bytes.

I also did this:

>>> import fitz
>>> doc=fitz.open("test.newer.pdf")
>>> page=doc[0]
>>> w=page.firstWidget
>>> w
'Text' widget on page 0 of test.newer.pdf
>>> w.update()  # just re-update the field w/o changes
>>> doc.save("test-newer-2.pdf")

The resulting file behaves as it should ...
The reason being, that PyMuPDF will in any case (re-) create an appearance stream.

[boukeas]

Try to check with a form PDF not created with PyMuPDF. Edit the PDF with some text editor and look for that property. Then delete it or put in false instead of true. Your changes must be done such, that the new content has exactly the same number of bytes.

I tried with this publicly available pdf form (reportedly created using OpenOffice). The form worked perfectly, both in the browser and my pdf viewer. Setting the property to false did not change anything but removing it altogether stopped the content of the updated fields from appearing.

[JorjMcKie]

So it seems we are coming to this conclusion:
In certain situations or for certain PDF viewers, setting of the Form PDF property NeedAppearances is a required feature.

As I mentioned, the next version will include a method to set this property to true or false.