Okular stores PDF form fill-out information separately from the PDF file, in .kde/share/apps/okular/docdata/ as NNNNN.<filename>.pdf.xml. If users aren't told this, they're prone to data loss. My situation was I viewed a PDF in Firefox, chose [Open With a Different Viewer] because pdf.js doesn't support forms yet, I filled it in in Okular, but then I moved it out of my downloads folder and renamed the pdf. So I lost my form fill-out information until I learned about how Okular stores form data. The Okular Advanced Features > Forms page in the handbook needs to have more information about this, it's very bare-bones. Okular handbook > The File Menu says File → Save As... Save the currently open file under a different name using the document backend. With the PDF backend (Poppler >= 0.8 required) it is possible to save the document with the changed values of the form fields. This is misleading. 1) You don't have to do anything for form fill-in information to be saved. When you close the Okular window Okular saves the form information to that docdata directory. 2) For some PDF documents File > Save As... is disabled, e.g http://www.ppt.gc.ca/form/pdfs/pptc054.pdf , yet the form info is saved fine. 3) Saying "Poppler >=0.8" is far too technical, Help > About Backend only tells me "PDF Backend Version 0.6.3" but has no indication what Poppler is or what version of that I'm using. Since File > Save As... was disabled, I tried File > Export As > Document Archive. The Okular help handbook says "allows you to save the document with your annotations into an Okular-specific archive format", but looking at the contents of the archive, it *does not* contain PDF form fill-in information. This also seems worth mentioning in the handbook (and it seems like a bug in Okular?). Reproducible: Always Expected Results: Okular's PDF form-fill is a great feature, but the way it works should be better documented. People are obviously concerned that their form data won't get lost. Okular Handbook Revision 0.15.70 (KDE 4.10) (2012-09-09) on Kubuntu 13.04.
It seems that there is a little misunderstanding with terms. 1. Okular saves its data (annotations, forms, etc.) 2. Okular can save data inside PDF documents (the appropriate Poppler version needed). 3. Okular is not completely compatible with XFA forms (like in the reporter's example). The documents (PDFs) with these forms can then be read in FoxIt PDF reader (filled forms) but cannot be read in Adobe Reader (empty forms). > "allows you to save the document with your annotations into an Okular-specific archive format" H-m-m, there is also misunderstanding here. This sentence tells nothing about forms. It tells about annotations. As you have noticed, it is impossible to keep the Okular internal form data when you move the file. So how it can be explained? The similar "data loss" can happen in any non-destructive editor when you move original file. What is your proposal about explaining it in docs? Thanks in advance for the answers.
OK, so it's more complicated than I thought! I repeat, there's no indication whether I have "the appropriate Poppler", neither KDE nor Okular tells me. I have a libpoppler28 version 0.20.5-1ubuntu3 installed in Kubuntu, maybe my "PDF Backend Version 0.6.3" uses it. I tried another form http://www.irs.gov/pub/irs-pdf/fw4.pdf and File > Save As did seem to store form data into the new file and not in a separate pdf.xml. The first PDF I mention above is encrypted (though password-less), maybe that's why its Okular's File > Save is disabled. So, based on this, the Okular handbook "Forms" page could say something like If you fill out a PDF form, Okular saves your form field entries in a file in $HOME/.kde/share/apps/okular/docdata. If you rename the PDF file, Okular will not be able to show this form data. For some PDFs Okular's File > Save As... command can save your form field entries within the new PDF file. Add under the File > Save As... documentation: "This menu item is disabled if you are viewing an encrypted PDF." Add under the File > Export As > Document Archive "This does not include form field entries." I think these changes would improve the documentation, but what do I know ;-)
(In reply to comment #2) Thanks for your proposals. I will try to implement all necessary changes. > I tried another form http://www.irs.gov/pub/irs-pdf/fw4.pdf and File > Save > As did seem to store form data into the new file and not in a separate > pdf.xml. The first PDF I mention above is encrypted (though password-less), > maybe that's why its Okular's File > Save is disabled. Can you try to uncheck "Obey DRM limitations" (do not know if this is available in Ubuntu but please try) as it is explained in docs? http://docs.kde.org/stable/en/kdegraphics/okular/configgeneral.html > So, based on this, the Okular handbook "Forms" page could say something like > > If you fill out a PDF form, Okular saves your form field entries in a file > in $HOME/.kde/share/apps/okular/docdata. If you rename the PDF file, Okular > will not be able to show this form data. For some PDFs Okular's File > Save > As... command can save your form field entries within the new PDF file. Personally, I do not like this "For some PDFs". It works for all non-XFA PDFs here. Please correct me if I'm wrong. > Add under the File > Save As... documentation: "This menu item is disabled > if you are viewing an encrypted PDF." I might be wrong but it seems that this is not true for the current versions. Please correct me if I'm wrong but Okular can work with properly encrypted PDFs from this page: https://www.setasign.de/products/pdf-php-solutions/setapdf-stamper/demos/stamp-already-encrypted-pdf/ The results (with annotations) can then be opened in Foxit Reader, mupdf and Adobe Reader in my system (Mageia 3, Okular 0.17.60, Poppler 0.24.2). > Add under the File > Export As > Document Archive "This does not include > form field entries." Ok. Will be added.
Need some information from the reporter and confirmation from developers.
Document archive contains forms for me.
I don't know how Okular works, I don't know what "XFA" is, that's why I go to the documentation for an explanation! Why are you asking the bug reporter to figure out how it works?! it seems the engineers who wrote it can best explain it, I'm sorry if that process is broken.