pdftopdf filter fails to output form field values

Status changed to 'Confirmed' because the bug affects multiple users.

An Ubuntu and qpdfview user seems to have had the same problem trying to print "https://service.rundfunkbeitrag.de/e360/e364/e1685/e1699/resources1700/Buergerinnen_und_Buerger_Wohnungsabmeldung_0106.pdf".

Form values are also lost with the old pdftopdf implementation (used in cups-filters before 1.0.21).
Probably only the pdf->ps workflow ever worked.

The form values are also lost by just using qpdf to 'non-destructively' rewrite the pdf. Therefore the problem is already present in the underlying libqpdf.
The provided pdf files all use xref-streams, which I'm currently not able to accurately debug.

I have some faint memories that to enable form-filling with Adobe Reader the original pdf has to be specially 'signed', and this signature can only be generated by the Adobe Acrobat Professional application... this might play a role here.

Another thing: When I use evince to print the form, it seems to work.
Could it be that the problem only occurs when using Adobe Reader to fill and/or print the form? Or at least that it works, when evince is used to fill/print?

Concerning printing with Evince: I think it converts the PDF to PostScript before sending it to CUPS for printing hence "flattening" the interactive features. The problem manifests only if one tries to use "lp" (or similar commmands) directly or if the application (like qpdfview) tries to take advantage of CUPS's internal PDF workflow.

(I was under the impression that PDF is supposed to be the default format for internal processing at least since CUPS 1.6, is this correct?)

It's true that the example form has the Acrobat Professional extensions enabled. They're not required for basic form-filling, but they are for certain features such as comments and digital signatures. It's possible that doing pdf-pdf conversion will fail in this circumstance...

Printing these forms using lp used to work in Karmic (not sure what cups version that was). Maybe it was using the pdf-ps pipeline at the time?

Sorry, I forgot to subscribe and did not get your comment by mail...

I think a recent evince will directly send pdf (and not ps) to cups. But it will 'rewrite' quite heavily.
And yes, PDF is the new internal default format in the linux printing chain. This has more to do with having the appropriate cups-filters than the cups version, though.

AFAICT it probably was the pdf-ps pipeline.

But, regarding this bug, I have tracked down the problem in libqpdf to the use of stale object-cache entries, and reported it to the author; the next libqpdf update will fix this bug.

For anyone watching, qpdf_4.0.1-2 in debian has had a fix for this problem since February 25. The patch should be easy to backport to the version in 12.10.

Jay, thanks for the info, I have found out this now, too by building the experimental package on Raring. Can you attach the patch here or post a link to it, so that I can apply it to the Quantal package? Thanks.

This patch is relative to 4.0.1. I suspect that it will apply cleanly to 3.whatever-you-have with at most offsets. The change is very localized. If you run into any problems, you can post here. I'm subscribed to this bug.

The attachment "patch to fix this problem" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Fixed in Raring by updating QPDF to 4.0.1.