Bug 343852 - okular's pdf form data isn't compliant with the standard FDF format, which results in severe pdf usability problems
Summary: okular's pdf form data isn't compliant with the standard FDF format, which re...
Status: RESOLVED DUPLICATE of bug 267350
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: unspecified
Platform: Other FreeBSD
: NOR major
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-06 08:53 UTC by Yuri
Modified: 2015-04-03 00:11 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri 2015-02-06 08:53:02 UTC
Currently forms data is stored in some XML files located away from the pdf file: ~/.kde4/share/apps/okular/docdata/299074.<pdf-file-name>.pdf.xml

There is the standard for the form field data defined in section "8.6.6 Forms Data Format" of PDF reference: http://partners.adobe.com/public/developer/en/pdf/PDFReference16.pdf

In short, field data by default should be embedded in the pdf file itself. User can also export (or extract) it into the separate .fdf file, that can be stored separately. FSF is just the directory-style format, defined in the same fashion as the pdf format itself.

Current implementation doesn't follow this standard, and doesn't store the data with the document. Forms data becomes not portable, and it is difficult/impossible to keep several versions of the filled form.

In short, the way how forms are currently implemented is barely usable, and prone to user confusion and accidental data loss. (!!! Why forms data dies when user deletes ~/.kde4 ? !!!) One can fill the form and print it, but people can't keep backup copies or send filled document to others.

Anybody experienced with pdf forms will have a problem with the current implementation.

This is the major usability problem.

Reproducible: Always
Comment 1 Albert Astals Cid 2015-02-06 09:27:12 UTC
Yeah, just use the File->save
Comment 2 Yuri 2015-02-06 20:44:21 UTC
No, users shouldn't be able to close the document without any warning that document isn't saved. Not many will know they need to save it unless prompted.
Additionally, there is no "File->Save" option in the menu at all, only "Save As" which isn't the same thing.

Also, currently copying such file and opening it in the new place shows the filled form, but changing it in one place changes the other document's form data too (!!!), which is a highly confusing behavior.

So the forms functionality should be fixed:
1. Users should be prompted to save document when the form data is changed
2. Menu item "Save" should appear under "File", and be enabled whenever form data was changed by user
3. Opening the copy of pdf file should never pull the form data from some "hidden" location, only from that file itself.
4. There should also be another menu option "Save Form as FDF". Apparently, office users utilize FDF files to store data in various cases, ex. when they receive filled by customers forms.

Form data should always be per-pdf file. Copying the file should naturally copy the form data.

There is really no use for the above-mentioned xml files, I don't see what is the purpose of having them. They give no benefit, only cause confusion.
Comment 3 Albert Astals Cid 2015-02-07 16:25:45 UTC
Yeah, there's various bugs about this, subscribe to one of them.
Comment 4 Yuri 2015-04-03 00:11:48 UTC

*** This bug has been marked as a duplicate of bug 267350 ***