Filled in form fields are not printed

[Peter Passchier]

Hi Adam,
I have this fillable PDF form. It saves, it reopens and stays editable, but when I try to print it the contents of the fields are not printed, whether to a real printer or to a pdf printer. Evince/Atril does print the contents. It is probably a setting, but I don't like having to open another application for my pdf needs.

qpdfview 0.4.14-1 with qpdfview-djvu-plugin, qpdfview-ps-plugin, qpdfview-translations on Ubuntu MATE 16.04.3.

[Adam Reichold (adamreichold)]

Hello Peter,

I guess this is a known issue in several cups-filters versions: If the fit-to-page option is enabled, then the filter pipeline used to scale the PDF output (I guess this is Ghostscript) loses any form field content. qpdfview is solely affected by this because it directly forwards the PDF documents to CUPS without any intermediate flattening as PDF is supposed to be the default printer chain file format. (You can confirm this by saving the document, making sure the form fields are filled out using another view and then printing the file directly from the command line using "lp -o fit-to-page".)

Currently the only workarounds I know of is to disable the option or flatten the document using Poppler's pdftops before printing.

Best regards, Adam.

[Peter Passchier (peter-passchier)]

Indeed, `lp -o fit-to-page` also empties the fields.

Is it an option to flatten the PDF in case of filled out form fields?? Or perhaps offer an option to do that? (I would use it.)

The vast majority of people wouldn't know about this. Thank you for enlightening me (and all others who might read this). So the real bug is gs losing form field content on scaling?

[Adam Reichold (adamreichold)]

Hello again,

it is certainly an option to flatten the PDF: I could just execute pdftops or use Poppler's internal API to achieve a similar result. The point is that I would like to avoid it.

As I said, PDF is supposed to be the default printing format using by CUPS-based printing solutions. Also, cups-filters already implements the necessary quality-preserving transformations to flatten the interactive features of PDF documents before the actual printing. So that this particular use case does not work is probably a bug in cups-filters or something used by it like qpdf or gs. Hence, I would rather like to push for a fix at the root cause of which everybody would benefit instead of implementing something that I consider a workaround.

Since this is not the first time we discuss this and there are similar issues around encrypted PDF documents which I was unable to fix until now, I'll keep this bug as "Opinion" and will continue to think about it...

Best regards, Adam.