Newer PDFs are starting to use a different standard (XFA) to store forms, which reuses parts of the old standard, but it's not backwards compatible.
Okular cannot deal with XFA forms yet (because Poppler does not support them). However, as a consequence of the fact that XFA reuses parts of the old standard, XFA-unaware readers are often fooled into thinking that they support that document's forms.

Since Okular from KDE 4.10 and Poppler 0.22, we've added a warning on such documents:


If you have KDE 4.10 and Poppler 0.22 but still can't see the warning, then there is likely a real bug somewhere, so.... please open a bug report (and remember to attach the pdf file )!

@fabiod:

Great information, thanks for sharing! Is this related to why Adobe Reader can't read the forms saved in Okular, while some other applications, like PDF-Xchange Viewer, can?

I just came across this concept of storing form data, such_as_tax_forms, in some .kde ~ directory. Why? I renamed that directory to try to deal with some kde problem and the data went with it and so to google. I've got over 10 years of records and had no idea the form data of pdfs filled by okular was so precarious. Over that time, even deleting .kde was not uncommon, no warnings of such dire import. GOD DAMN IT. I don't need workarounds or wait for a newer poppler. I need portable pdfs with all the content in one file. god damn it.

Because saving to PDF was not supported in earlier Poppler versions. Also, sometimes it's not possible to write to the original file for various reasons, but Okular still allows you to add annotations to it by saving them to a separate file.

There can be a lot of valuable data saved to .kde, you really shouldn't delete the whole directory.

Hans wrote:There can be a lot of valuable data saved to .kde...

For more than 13 years, this fact has escaped my attention. Apart from this Okular data, what else? Many keep important data from installation to installation by various means, backups, separate data directories, etc. Never have I heard that .kde must be preserved or valuable personal data will be lost. What, besides Okular, demands .kde be preserved for years?

All KDE applications store their preferences, and other relevant data in ~/.kde or ~/.kde4 (depending on the distribution).
Examples include PIM application data, Kopete chat logs, Akregator subscription lists, your Plasma Desktop applet configurations, application colour and style preferences and addons installed via Get Hot New Stuff to name a few items.

bcooksley wrote:All KDE applications store their preferences, and other relevant data in ~/.kde or ~/.kde4 (depending on the distribution).
Examples include PIM application data, Kopete chat logs, Akregator subscription lists, your Plasma Desktop applet configurations, application colour and style preferences and addons installed via Get Hot New Stuff to name a few items.

I make a distinction between preferences and personal data such as form data that I'm required to have the ability to produce for years, such as in IRS tax return forms. Obviously, colors and widgets get lost when .kde/.kde4 is lost. That fact has not escaped my attention for more than 13 years. Do you not see that distinction? Do you not see a difference between re-configuring lost preferences and restoring lost pdf data? I'm asking for examples on the level of lost tax return data that some other application might be storing under .kde/.kde4.

The only notable example of that is Kontact and the other KDE PIM applications (ie. email, calendar, address book, etc) that I am aware of.

I have always used Seamonkey, instead of KDE pim, so never became attuned to that protocol. By analogy, I am careful to save .mozilla and the parallels make Okular seem a little less diabolical, now, thanks.