Cannot print a PDF with AcroForms using fit-to-page

Can you try the newest Ubuntu version (life image on USB or DVD)? Does the problem persist there?

Most probably this is a QPDF problem. QPDF is the PDF processing library used by pdftopdf, the filter which processes fit-to-page.

Created an upstream bug report on QPDF:

https://github.com/qpdf/qpdf/issues/72

Till Kamppeter (till-kamppeter),

I tested in Xenial too (see the head message), and it has the same issue. However I cannot use Xenial since I cannot upgrade from 14.04 for some specific reasons.

See https://bugs.linuxfoundation.org/show_bug.cgi?id=1315 why this cannot work.
And QPDF won't be able to do anything about it, either...
There might even be PDF-capable printers on the market (i.e. where the rasterization is not done by gs / poppler on the host), where the form content will not be printed even without the fit-to-page option.

The PDF format generally does not allow arbitrary transformations (as used by pdftopdf in certain cases) to be applied to the ("interactive") Form content - which is stored separately from the Page content.
The usual solution for printing is that the viewer application (Evince, Google Chrome, ...) converts (hard-codes) any Form content into regular Page content before sending the data to the printing chain. Using lpr skips this (non-trivial) step.

For example, here some java/PDFBox-based implementation of how to flatten simple forms:
 https://gist.github.com/jribble/beddf7620536939f88db
(IIRC there are more form elements than those 2-3 handled here(?)).

Note that QPDF does not have something like the PDAcroForm class (and its friends) used there to easily access the form data. So any QPDF/C++ based form flattener has to implement that, too.

Dmitry, can you print your filled-form PDF when opening it in a PDF viewer (evince, some KDE viewer, ...) set fit-to-page in the printing options in the print dialog and print? The viewers usually re-generate the PDF in a simpler way with the interactive forms replaced by static PDF content and send that to the printing subsystem.

Try also

ps2pdf PDFForm3.pdf - | lpr -o fit-to-page

ps2pdf runs your PDF through Ghostscript, which also re-generates it in a static form.

I have done the tests of my previous comment with the attached file and printing this way works, meaning that both evince and Ghostscript re-generate the PDF file for printing, so that a static file is sent.

A point of improvement for cups-filters would be here to let pdftopdf somehow recognize that the incoming PDF has non-static content and if so, running it through some Ghostscript/Poppler/MuPDF command line utility for flattening the file into a completely static one.

I'll try pdf2ps (did you mean that?). I cannot try any of X11 applications since X11 is not installed there and I have no control over that.

I meant ps2pdf, as ps2pdf generates PDF. It was originally made for converting PostScript to PDF, but it works also with PDF as input as Ghostscript accepts also PDF as input. This way it converts PDF (non-static) to PDF (static). So use ps2pdf as shown in my comments above.

If I'm reading this correctly, it looks like there's no short-term change to qpdf required. Is that correct? I'm thinking doing this type of flatting in qpdf is probably out of scope, but in any case, I wouldn't have time to work on it any time soon. I haven't studied interactive forms enough to know exactly what would be involved.

There are certainly limitations of just directly printing PDF, and it's unlikely that qpdf or a filter that only does structural transformation will ever be able to handle all these kinds of issues.

If I've misread this and there is something expected to be done with qpdf in the short term, please clarify so I don't inadvertently decide not to do something that needs to be done. Thanks.

Jay, QPDF could be used for identifying whether a file contains forms or not. See

https://bugs.linuxfoundation.org/show_bug.cgi?id=1315

nad there comment #9 with the link to

https://github.com/smilingthax/pdfformflatten

This code identifies PDFs with forms but does not actually flatten them. pdftopdf could use this and if a form is found pass the PDF through Ghostscript/Poppler/MuPDF to flatten it and after that do the usual QPDF treatment of pdftopdf.

Jay, would you be able to add PDF form flattening functionality like implemented in

https://gist.github.com/jribble/beddf7620536939f88db

into QPDF? Or is a real PDF interpreter (Ghostscript, Poppler, MuPDF) needed for this?

The trick with ps2pdf works fine. I am able to convert to a static PDF and then print it with fit-to-page.

Jay, what about implementing PDF form flattening in QPDF? As suggested in comment #13?

I'll have to study it. Sorry, I have been quite starved for time to work on qpdf. I would like to fix this, but I can't commit to a timeframe.

For the time being (cups-filters 1.17.4) I have now applied a solution where pdftopdf detects PDF forms using QPDF (thanks to Tobias Hoffmann, smilingthax) and if there is a form uses and external utility for the flattening, preferrably pdftocairo, if not present, Ghostscript. After the flattening the original treatment by QPDF is performed.

If none of the utilities is available, no form-flattening is performed (but as cups-filters-core-drivers depends on poppler-utils, pdftocairo is always there).

The originally planned QPDF-based solution is still in the works and will most probably added in a later release of cups-filters. Therefore the QPDF task stays open.

This bug was fixed in the package cups-filters - 1.17.4-0ubuntu1

---------------
cups-filters (1.17.4-0ubuntu1) artful; urgency=medium

  * New upstream release
    - pdftopdf: If the input PDF file contains an interactive
      form, flatten it to static PDF so that further manipulation,
      like scaling, number-up, ... do not let the filled for
      content getting lost. This is implemented by using the
      pdftocairo utility of Poppler and if this fails Ghostscript
      (9.22 or later recommended). This will probably replaced by
      a QPDF-based solution later. Thanks to Tobias Hoffmann for
      the QPDF-based detection of PDF forms (Upstream bug #1315,
      LP: #1564249).

 -- Till Kamppeter <email address hidden> Sun, 10 Sep 2017 16:14:50 -0300

I think this bug can be closed now, right?

Yes, the QPDF task is now done, too. Thank for all the hard work on this, Jay.