unable to print password protected PDF documents

Hello Juergen,

thank you for taking the time to report this! I have looked into it and the root cause seem to be that we send PDF documents directly to CUPS where most other readers convert them to PostScript first. (This was a deliberate decision since PDF is supposed to be the default format for never CUPS filter pipelines.) But the CUPS API does not seem to give us any way to pass the password along so it can't open and decrypt the file for printing.

I think the proper solution is that we decrypt the file before printing, prompting for the password again since by giving it to the printing system, you have to acknowledge that it will process the data unencrypted. However, Poppler does not seem to have an API to store a decrypted version of a PDF document yet. (It will of course decrypt when converting to PostScript.) But it should be possible to add such an interface.

The alternative would be to convert to PostScript, either always or at least if the file is encrypted which I personally do not like too much, but which can be implemented using the status quo.

Best regards, Adam.

Hi Adam,

thanks for your quick response. Might be worth to take a look at epdfview, which uses poppler/poppler-glib as well. Epdfview is unmaintained and broken on other parts, but printing encrypted documents works.

best regards
Juergen

Hello,

the approach of epdfview is clear: It converts PDF documents to PostScript for printing was usually a necessity back then. This is my fallback solution, but I would prefer not to do that since it is expensive and unnecessary. I just need the necessary interfaces for saving an unencrypted copy.

Best regards, Adam.

Submitted an RFC with a proposal for an API extension to the Poppler mailing list...

I have recently discovered qpdfview, having heard good things about it. After installing and using for awhile, I must agree that it is excellent! A better solution than Evince, Adobe, or FoxIt (my former favorite).

However, I have the same issue as the OP...cannot print password protected PDFs. I have to switch to FoxIt for that. Noting this bug is almost 2 years old, I'm simply chiming in to say "me too...still". If it help to know, I have qpdfviewer v.0.4.14 installed on Lubuntu 16.04, via Lubuntu repo.

Other than this 1 issue, I'd say qpdfviewer is just about perfect, FWIW! Thank you for this software!

Hello James,

this issue is blocked on the related change within upstream Poppler. I already submitted a patch once but I made a mistake and hence it got reverted. Even though I fixed it almost immediately, the maintainers moved on in their bug and patch queue. I probably have to rebase and resubmit the change eventually, but my time is currently very limited...

Best regards, Adam.

Hello Adam,

any chance to get a new version with a fix for this bug soon?

Thanks and best regards
Juergen

The issue unfortunately still persists. I hope for a fix.

Lubuntu 19.10

Same here. Using qpdfview 0.4.18 in Debian 11. How could I help?

Hello Mathias,

I have detached from the Poppler project somewhat and my patches for saving an unencrypted version of the PDF documents never got merged.

I think resurrecting these and proposing them as a merge request at

https://gitlab.freedesktop.org/poppler/poppler/

would be the first step to actually fixing this. You can find the original thread and patch at

https://lists.freedesktop.org/archives/poppler/2015-July/011450.html

Regards,
Adam

Hello Adam,

thanks fot the quick answer and for the link to your original patch.

I apologize in advance, if these questions are too stupid. I didn't check the source of qpdfview, poppler or other viewers and how they handle the problem.

May I ask why you think rewriting a unencrypted pdf instead of converting the pdf to postscript?

Best regards,
Matthias

Hello again,

I don't think the question is simple as there is a lot of context to this. When Poppler's API was conceived, PostScript was the standard format used for printing under Linux and other Unix-like systems. When qpdfview was conceived, this had already changed and PDF was declared as the default format for CUPS-based printing workflows which I would argue has more or less happened by now. (IIRC, printing a PostScript using a contemporary driverless CUPS setups will actually convert it to PDF before rasterizing it into a device-specific manner.)

Therefore, I decided from the start, that qpdfview would not convert PDF into PostScript for printing, but rather hand over the PDF file directly to CUPS which could then process it without loss of quality using e.g. tools like qpdf. I would like to stick to that decision as I see no technical reason why it should not work. The problem is mainly an organizational one of getting the patch into shape, merged, released and then using it in qpdfview.

Regards,
Adam

Hello Adam,

As a workaround, could you please provide an option for
(if a password is supplied) to pipe secure pdf via qpdf?

Tired to wait any CUPS solution for this, I'm using
linuxmint/ubuntu qpdf v9.1.1ubuntu0.1 working like a charm...

BTW, for all of you, qpdf command to decrypt PDF file this way:

  $> qpdf --password='123456' --decrypt secure.pdf output.pdf

Hugs, Domingues