unable to print password protected PDF documents

Bug #1476693 reported by Juergen Daubert
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
qpdfview
In Progress
Medium
Adam Reichold

Bug Description

Looks like qpdfview cannot print documents that are protected with passwords, even though qpdfview shows the docs without issues. I have no problems to print unprotetced PDF's with qpdfview.

This is on a CRUX linux system with CUPS as printer spooler. The error mesage:

D [20/Jul/2015:18:49:31 +0200] [Job 555] Set job-printer-state-message to "loadFilename failed: /var/spool/cups/d00555-001: invalid password", current level=ERROR

The same document prints just fine with epdfview, so my guess is that the problem is on the qpdfview side.

Thanks.

Changed in qpdfview:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Adam Reichold (adamreichold) wrote :

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.

Revision history for this message
Juergen Daubert (jue) wrote :

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

Revision history for this message
Adam Reichold (adamreichold) wrote :

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.

Revision history for this message
Adam Reichold (adamreichold) wrote :

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

Changed in qpdfview:
status: Triaged → In Progress
Changed in qpdfview:
assignee: nobody → Adam Reichold (adamreichold)
Changed in qpdfview:
milestone: none → 0.4.17
Revision history for this message
James Shriner (hedon-james) wrote :

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!

Revision history for this message
Adam Reichold (adamreichold) wrote :

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.

Revision history for this message
Juergen Daubert (jue) wrote :

Hello Adam,

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

Thanks and best regards
Juergen

Revision history for this message
Alex (alex-5236) wrote :

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

Lubuntu 19.10

Revision history for this message
Matthias Keller (kristallhawaii) wrote :

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

Revision history for this message
Adam Reichold (adamreichold) wrote :

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

Revision history for this message
Matthias Keller (kristallhawaii) wrote :

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

Revision history for this message
Adam Reichold (adamreichold) wrote (last edit ):

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

Revision history for this message
Luiz Domingues (luizcsdomingues) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.