Add basic support for PDF forms

[TI_Eugene]

Need show, fill, print and save pdf forms

[Benjamin Eltzner (b-eltzner)]

I concur. This is also the one missing feature I find most important. Adam has so far not excluded adding it some time.

[Adam Reichold (adamreichold)]

This has been on the to-do list for quite some time and should manageable as Poppler supports forms and its Qt4 frontend exposes these features. But since it is quite a project and my spare time is currently severely limited, it could take a lot of time until I can begin with it.

[TI_Eugene (ti-eugene)]

Addition issue - to save populated form "as is" or _flatten_.

02.09.2012 14:22, Benjamin Eltzner:
> I concur. This is also the one missing feature I find most important.
> Adam has so far not excluded adding it some time.
>
> ** Changed in: qpdfview
> Importance: Undecided => Wishlist
>
> ** Changed in: qpdfview
> Status: New => Triaged
>

[Adam Reichold (adamreichold)]

Flattening documents might be a different issue as I have to research whether Poppler supports this first.

[Adam Reichold (adamreichold)]

After toying around with this a bit, I started with a simple and hopefully unintrusive implementation of forms support. (Working much like annotations.) Interested parties might want to have a look at the Bazaar branch "lp:~adamreichold/qpdfview/forms". Testing and comments are appreciated. However, please keep in mind that this is still work in progress and it currently supports only single- and multi-line text edits, radio and check box buttons and combo box and list selection fields.

(The blue frame around form fields is configurable, I just haven't added the settings support for it yet.)

[TI_Eugene (ti-eugene)]

Ok, I'll test it.
1. It not fills "letterboxes" (linedit splited by chars). See attaches.
2. If you have testing pdfs - please send me.
3. Test working w/ non-ascii chars. E.g. Pdfviewer not shows them after saving (but can edit again).
4. "Fill for w/ fdf/xfdf file" need to.

On Mon, 15 Oct 2012 20:02:22 -0000
Adam Reichold <email address hidden> wrote:

> After toying around with this a bit, I started with a simple and
> hopefully unintrusive implementation of forms support. (Working much
> like annotations.) Interested parties might want to have a look at the
> Bazaar branch "lp:~adamreichold/qpdfview/forms". Testing and comments
> are appreciated. However, please keep in mind that this is still work in
> progress and it currently supports only single- and multi-line text
> edits, radio and check box buttons and combo box and list selection
> fields.
>
> (The blue frame around form fields is configurable, I just haven't added
> the settings support for it yet.)
>
> ** Changed in: qpdfview
> Status: Triaged => In Progress
>
> ** Changed in: qpdfview
> Assignee: qpdfview-bugs (qpdfview-bugs) => Adam Reichold (adamreichold)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1044943
>
> Title:
> Add support for PDF forms
>
> Status in qpdfview:
> In Progress
>
> Bug description:
> Need show, fill, print and save pdf forms
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qpdfview/+bug/1044943/+subscriptions

[Adam Reichold (adamreichold)]

Helllo Eugene,

ad 1: I had a look at your attachments and I can fill them out just like any other normal text field. I am using Poppler 0.20.3 at the moment.

ad 2: Sadly, I test using PDF files that I found on the web, e.g. search for "PDF form example" and things like that.

ad 3: Confirmed. They are not rendered correctly with Poppler warnings like "warning: layoutText: cannot convert U+0442". So I think this is a Poppler problem and I will test its latest development snapshot soon and report my findings.

ad 4: I am not sure I understand? Do you mean file select text fields which then contain an absolute file path and usually have a "browse" button?

[Adam Reichold (adamreichold)]

ad 3: After trying the latest Poppler snapshot from Git, there problem seems to persist with a slight changed warning message like "Error: AnnotWidget::layoutText, cannot convert U+043E". I would propose filing a Poppler bug for that. (I assume Okular, PdfViewer and qpdfview show the same behaviour.)

[TI_Eugene (ti-eugene)]

On Tue, 16 Oct 2012 06:48:14 -0000
Adam Reichold <email address hidden> wrote:

> Helllo Eugene,
>
> ad 1: I had a look at your attachments and I can fill them out just like
> any other normal text field. I am using Poppler 0.20.3 at the moment.

Hm... I have 0.18.4 (from official Fedora repo).
I'll try upgrade

> ad 4: I am not sure I understand? Do you mean file select text fields
> which then contain an absolute file path and usually have a "browse"
> button?

No.
FDF is official RDF form data format.
You can save form data to FDF file - or populate form with this file.
XFDF is XML version of XFDF.
See attach. These are:
* pdf form
* xfdf for it (django template)
* testing xfdf
* my java tool to merge xfdf and pdf form

[TI_Eugene (ti-eugene)]

This is simple note.
Forms that I sent you are using in my django project.
Now I fill them via java application (in previous mail).
So - I'm interesting as in qpdfview (for me and for tens of my win users to replace greedy Adobe Reader) - as in pypoppler binding (to make populating pdf form in django project more accuracy).

[Adam Reichold (adamreichold)]

I am not sure if import and export of XFDF data is a sensible feature for qpdfview. (Which tries to have a minimal code base.) What improvement would that bring versus giving the user a (possibly populated) PDF form and processing the resulting PDF file afterwards using your command-line tools? As I understand it, a user could use any PDF viewer with all XFDF processing being kept on the server.

[Adam Reichold (adamreichold)]

Also, for discussing this, it would probably be much more helpful to have the source code of "xdftool" instead of the binaries.

[Adam Reichold (adamreichold)]

Maybe discussion of XFDF support should be moved into a separate bug report anyway so that this we can concentrate on the basic form support here...

[TI_Eugene (ti-eugene)]

On Tue, 16 Oct 2012 11:41:47 -0000
Adam Reichold <email address hidden> wrote:

> Also, for discussing this, it would probably be much more helpful to
> have the source code of "xdftool" instead of the binaries.

No problem.
But it uses itext features - builtin pdf forms processing

[TI_Eugene (ti-eugene)]

On Tue, 16 Oct 2012 11:44:34 -0000
Adam Reichold <email address hidden> wrote:

> Maybe discussion of XFDF support should be moved into a separate bug
> report anyway so that this we can concentrate on the basic form support
> here...

Yes, I agree.
After testing PDF forms at all.

[Adam Reichold (adamreichold)]

By the way, the Poppler bug for unicode characters in form fields is here: "https://bugs.freedesktop.org/show_bug.cgi?id=36111".

[Adam Reichold (adamreichold)]

Since this will hardly see any testing outside of trunk, I decided to merge this rudimentary support and interpret this bug as covering only this level of support and hence targeting the next milestone.

The unicode issue will have to be solved upstream. Additional features like form flattening and XFDF support should get additional wishlist bugs.

[TI_Eugene (ti-eugene)]

On Tue, 16 Oct 2012 06:48:14 -0000
Adam Reichold <email address hidden> wrote:

> Helllo Eugene,
>
> ad 1: I had a look at your attachments and I can fill them out just like
> any other normal text field. I am using Poppler 0.20.3 at the moment.

I can't replace my poppler w/ newer version:

bash-4.2$ LC_ALL=C sudo rpm -Uvh poppler-0.20.2-1.fc17.i686.rpm
error: Failed dependencies:
        libpoppler.so.19 is needed by (installed) texlive-2007-70.fc17.i686
        libpoppler.so.19 is needed by (installed) poppler-glib-0.18.4-3.fc17.i686
        libpoppler.so.19 is needed by (installed) poppler-utils-0.18.4-3.fc17.i686
        libpoppler.so.19 is needed by (installed) poppler-qt-0.18.4-3.fc17.i686
        poppler(x86-32) = 0.18.4-3.fc17 is needed by (installed) poppler-glib-0.18.4-3.fc17.i686
        poppler(x86-32) = 0.18.4-3.fc17 is needed by (installed) poppler-utils-0.18.4-3.fc17.i686
        poppler(x86-32) = 0.18.4-3.fc17 is needed by (installed) poppler-qt-0.18.4-3.fc17.i686

If I try to remove these 3 libs:

Removing:
 poppler-glib i686 0.18.4-3.fc17 installed 270 k
 poppler-qt i686 0.18.4-3.fc17 installed 388 k
 poppler-utils i686 0.18.4-3.fc17 installed 450 k
Removing for dependencies:
...
cups
...
firefox
...
kde-baseapps
...
kde-runtime
...
konsole
...
 redhat-lsb-core i686 4.1-5.fc17 @updates 22 k
 redhat-lsb-cxx i686 4.1-5.fc17 @updates 0.0
 redhat-lsb-languages i686 4.1-5.fc17 @updates 814
 redhat-lsb-printing i686 4.1-5.fc17 @updates 0.0

etc

So - I will wait for Fedora 18 (http://fedoraproject.org/wiki/Releases/18/Schedule) with poppler-0.20.2.

[TI_Eugene (ti-eugene)]

On Tue, 16 Oct 2012 06:48:14 -0000
Adam Reichold <email address hidden> wrote:

> Helllo Eugene,
>
> ad 1: I had a look at your attachments and I can fill them out just like
> any other normal text field. I am using Poppler 0.20.3 at the moment.

Sorry, I solve problem (removing lyx, okular, epydoc, inkscape etc).
Now I have 0.20.2.
Letterboxes edited as separate lineedit yet - not as is (each char in its cell - as Acrobat Reader do).

[Adam Reichold (adamreichold)]

Hhhmmm, the thing is that Acrobat probably implements the form fields "inline", i.e. as part of the PDF document whereas I chose to separate presentation and editing (as with the annotations). The reason is that I don't think matching their inline appearance will work using Qt controls and I do not feel like implementing my own controls mimicking the PDF rendering. Hence the current implementation makes a clear cut between inline presentation and editing using native Qt controls in pop-up window.

So, long story short, it's a design choice...

[TI_Eugene (ti-eugene)]

ok, I agree

Пользователь Adam Reichold <email address hidden> писал:

>Hhhmmm, the thing is that Acrobat probably implements the form fields
>"inline", i.e. as part of the PDF document whereas I chose to separate
>presentation and editing (as with the annotations). The reason is that I
>don't think matching their inline appearance will work using Qt controls
>and I do not feel like implementing my own controls mimicking the PDF
>rendering. Hence the current implementation makes a clear cut between
>inline presentation and editing using native Qt controls in pop-up
>window.
>
>So, long story short, it's a design choice...
>
>--
>You received this bug notification because you are subscribed to the bug
>report.
>https://bugs.launchpad.net/bugs/1044943
>
>Title:
> Add basic support for PDF forms
>
>Status in qpdfview:
> Fix Committed
>
>Bug description:
> Need show, fill, print and save pdf forms
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/qpdfview/+bug/1044943/+subscriptions