PDF with forms is not saved in okular

All,

I am filling out a PDF which contains forms. So the PDF actually has input fields and radio buttons you can click. This works fine in okular, locally. When I send the PDF to a different computer (or rename the PDF), what I have filled in is not shown anymore. It seems I have encountered the following bug: https://bugzilla.novell.com/show_bug.cgi?id=815560#c0
This should be solved in 13.1 … but I am running 13.1 (this was a fresh install a few months ago) with up to date packages and I still have this issue. Can someone else confirm this issue still exists in 13.1?

Thanks!

This can mean several things:

  1. That you only use the standard repos andare up to date with zypper patch and/or YaST Online Update;
  2. That you added the stable KDE repo and updated from there.

Please explain what is the case and/or tell us the version og Okular you are using.

I ask this particular because recently there was a thread here about Okular where the problem was not in the standard openSUSE OSS repo version, but in the KDE 4.12 (or something like that) version.

In general it works. You have to call “Save As…” from the File menu though to save your changes of course.

But there are specific PDFs where it apparently does NOT work. That would be a limitation of poppler (maybe the PDF uses some “clever” javascript?).
See here f.e.:
http://forums.opensuse.org/showthread.php/495075-Okular-0-16-loses-form-data-Where-can-I-find-other-versions?highlight=okular+pdf+forms

You can install and use Adobe’s reader though.
http://get.adobe.com/de/reader/

I last tried that around 2 years ago. The different computer (probably a Windows system) was unable to read the saved pdf file. I ended up printing to a pdf file instead, which does gives something readable with the completed forms.

Yes, some time ago, okular didn’t save anything inside a PDF file, because that wasn’t supported by poppler. It saved that stuff to its own files in ~/.kde4/share/apps/okular, so that you at least had the data when opening that file in okular again.

But times have changed.
Poppler does support saving form data into a PDF files now (since version 0.22 I think), and okular does support that as well when compiled against a sufficiently new poppler, which it is at least on openSUSE 13.1. (that’s what the mentioned bug report is about)

On 2014-04-30 12:36, wolfi323 wrote:
>
> kennywest;2640335 Wrote:
>> Can someone else confirm this issue still exists in 13.1?
> In general it works. You have to call “Save As…” from the File menu
> though to save your changes of course.
>

Saving A PDF form filled with data is apparently not part of “the
standard”. It works sometimes, I think it is an extension done by some
PDF readers.

> But there are specific PDFs where it apparently does NOT work. That
> would be a limitation of poppler (maybe the PDF uses some “clever”
> javascript?).

Often PDF forms use javascript, which is ignored by probably all viewers
except adobe acroread. And the version for Linux is not maintained any
more…


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

No, it is part of the standard, apparently since 8.0.

But the creator of the document can disable it by DRM (or rather has to enable it specifically).

There’s an example PDF by Adobe using interactive forms available here:
http://help.adobe.com/en_US/Acrobat/9.0/Samples/interactiveform_enabled.pdf

Okular saves the data entered fine for this. Opening the resulting PDF with a different viewer (evince f.e.) oe even Adobe Reader on a different (Windows) system shows the filled-in data and I can even edit it.

And that form states:

Can I save my form with the data I entered?• If you have Adobe Acrobat you can save the form data—simply save the document. If you are using the free Adobe Reader it will
depend on whether the creator of your form enabled the form for saving form data. The purple document message bar will say:
“You can save data typed into this form” if saving has been enabled.

Printing to a PDF file (as nrickert suggested) would work as well (though you cannot edit it anymore then), but you would have to be able to fill in the data first of course, which may not be possible with specific PDFs (f.e. because of the javascript) I understand.

On 2014-04-30 15:16, wolfi323 wrote:
>
> robin_listas;2640391 Wrote:
>> Saving A PDF form filled with data is apparently not part of “the
>> standard”. It works sometimes, I think it is an extension done by some
>> PDF readers.
>>
> No, it is part of the standard, apparently since 8.0.
>
> But the creator of the document can disable it by DRM (or rather has to
> enable it specifically).
>
> There’s an example PDF by Adobe using interactive forms available here:
> http://tinyurl.com/c9m5bwd

Thanks, I’ll try that later, tomorrow perhaps. Now I have limited internet.


Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

This is a stock 13.1 install. These are the repos I use:

| Alias | Name | Enabled | Refresh

—±--------------------------±-----------------------------------±--------±-------
1 | ftp.gwdg.de-suse | Packman Repository | Yes | Yes
2 | google-chrome | google-chrome | Yes | Yes
3 | libdvdcss repository | libdvdcss repository | Yes | Yes
4 | repo-debug | openSUSE-13.1-Debug | No | Yes
5 | repo-debug-update | openSUSE-13.1-Update-Debug | No | Yes
6 | repo-debug-update-non-oss | openSUSE-13.1-Update-Debug-Non-Oss | No | Yes
7 | repo-non-oss | openSUSE-13.1-Non-Oss | Yes | Yes
8 | repo-oss | openSUSE-13.1-Oss | Yes | Yes
9 | repo-source | openSUSE-13.1-Source | No | Yes
10 | repo-update | openSUSE-13.1-Update | Yes | Yes
11 | repo-update-non-oss | openSUSE-13.1-Update-Non-Oss | Yes | Yes

I just tried it again with the PDF I need to fill out and now it seems to work. It seems the “Save As” is crucial in this process. I’m afraid I hit the “Save Copy As” which led to a PDF without the stuff I filled out.

I am feeling stupid now :shame:
Sorry I have wasted your time …

Please, next time when you post computer text (like you did above), copy/paste it between CODE tags. You get the CODE tags by clicking on the # button in the tool bar of the post editor.