Opened 8 years ago

Last modified 19 months ago

#254 assigned defect

edited fill-in pdfs display/print old data

Reported by: Steven Levine Owned by: Gregg Young
Priority: minor Milestone: 1.4.1
Component: Plugin: PDF Version: 1.3
Keywords: Cc: steve53@…, Steven Levine


If a field in a saved fill-in pdf is edited, the old data reappears after the pdf is saved and reloaded. This is probably a poppler defect/regression. The new data is in the pdf, but so is the old data. Since pdfs are effectively read backwards, it is easy to understand how this could occur.

Attachments (1)

fw9.pdf (116.5 KB) - added by Lewis Rosenthal 4 years ago.
IRS Form W-9, December, 2014, PDF 1.7

Download all attachments as: .zip

Change History (14)

comment:1 Changed 8 years ago by Steven Levine

Cc: Steven Levine added

comment:2 Changed 8 years ago by Silvan Scherrer

Priority: majorFeedback Pending

please try qpdfview, as thats the successor of Lucide.
see for more information on qpdfview

comment:3 Changed 6 years ago by Silvan Scherrer

Resolution: qpdfview
Status: newclosed

no feedback for 18 month, so qpdfview might have worked.

comment:4 Changed 5 years ago by Lewis Rosenthal


Milestone renamed

comment:5 Changed 5 years ago by Steven Levine

Priority: Feedback Pendingminor
Resolution: qpdfview
Status: closedreopened

comment:6 Changed 4 years ago by Lewis Rosenthal

In investigating this issue (which I have not yet been able to replicate), I find the following with poppler 0.42.0 dealing with a PDF 1.7 document:

  1. Form data entered into the fields is saved in the document (when document is Saved as...). Confirmed with hex editor.
  2. Form data is not visible when the file is opened with Adobe Acrobat 8.0 Professional nor Adobe Acrobat Reader DC 2015.017.
  3. Form data is visible when opened with other poppler-using PDF viewers (qPDFView, Evince, Okular), even older popplers (tested to 0.24.4).
  4. Editing the filled-in form in Lucide, and saving as new file does save the new data to the file. The new data is displayed in subsequent openings of the new file from Lucide and qPDFView, however, the old data is still present in the file (confirmed with a hex editor). This is a serious security concern (new bug to be filed).
  5. The new file (containing both the old data and the new data still opens in Acrobat 8.0 and Reader DC showing no filled-in data.
  6. The same document, filled in with qPDFView (using the same poppler) behaves similarly in every way (both sets of saved data stored in the file; file shows empty fields under Acrobat and Reader DC).
  7. The same document, with the fields filled in using qPDFView on Linux with poppler 0.24.4 stores both sets of data in the file, and is likewise unreadable from Acrobat and Reader DC.

Steve, can you provide a test PDF which behaves as you describe, here? This may be a poppler bug (XFA forms are not yet fully supported under even the latest poppler as of this post, TTBOMK).

I am attaching the raw PDF I used for this testing.

Changed 4 years ago by Lewis Rosenthal

Attachment: fw9.pdf added

IRS Form W-9, December, 2014, PDF 1.7

comment:7 Changed 4 years ago by Lewis Rosenthal

Possibly related (if this occurs with an XFA document):

comment:8 Changed 2 years ago by Gregg Young


Ticket retargeted after milestone closed

comment:9 Changed 2 years ago by Gregg Young

Owner: set to Gregg Young
Status: reopenednew

comment:10 Changed 2 years ago by Gregg Young

Status: newassigned

comment:11 Changed 19 months ago by Gregg Young

Is this still an issue with Poppler 0.59.0?

comment:12 Changed 19 months ago by Lewis Rosenthal

This no longer occurs for me with poppler 0.59.0.

Note that the previously filled-in data is still present in the file (this is a design defect of PDF, and not something which can be addressed in Lucide or poppler), but it is no longer visible upon reloading the saved, filled-in form.

Steve, this was your ticket, originally. Can you confirm?

comment:13 Changed 19 months ago by StevenHL

Last time I tested, this appeared to be fixed. I just did a quick retest and the results are what I expected.

Note: See TracTickets for help on using tickets.