Opened 12 years ago
Last modified 6 years 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 |
Description
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)
Change History (14)
comment:1 by , 12 years ago
Cc: | added |
---|
comment:2 by , 12 years ago
Priority: | major → Feedback Pending |
---|
comment:3 by , 10 years ago
Resolution: | → qpdfview |
---|---|
Status: | new → closed |
no feedback for 18 month, so qpdfview might have worked.
comment:5 by , 9 years ago
Priority: | Feedback Pending → minor |
---|---|
Resolution: | qpdfview |
Status: | closed → reopened |
comment:6 by , 8 years ago
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:
- Form data entered into the fields is saved in the document (when document is Saved as...). Confirmed with hex editor.
- Form data is not visible when the file is opened with Adobe Acrobat 8.0 Professional nor Adobe Acrobat Reader DC 2015.017.
- Form data is visible when opened with other poppler-using PDF viewers (qPDFView, Evince, Okular), even older popplers (tested to 0.24.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).
- 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.
- 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).
- 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.
comment:7 by , 8 years ago
Possibly related (if this occurs with an XFA document): https://bugs.freedesktop.org/show_bug.cgi?id=18935
comment:9 by , 6 years ago
Owner: | set to |
---|---|
Status: | reopened → new |
comment:10 by , 6 years ago
Status: | new → assigned |
---|
comment:12 by , 6 years ago
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 by , 6 years ago
Last time I tested, this appeared to be fixed. I just did a quick retest and the results are what I expected.
please try qpdfview, as thats the successor of Lucide.
see svn.netlabs.org/qtapps for more information on qpdfview