Comment 6 for bug 782309

This is not an HPLIP problem (Sanjay, but thank you anyway for your help), the problem is general and is caused by a recent change in Ghostscript.

I can reproduce it with a print queue which uses Ghostscript's built-in "pxlmono" driver.

Adobe Reader sends PostScript to CUPS when printing PDF files. If the original PDF was encrypted (DRM applied to it) then the PostScript is marked as such and standards-conforming PostScript interpreters are supposed to not turn it into PDF again, as the new PDF would not carry the DRM settings any more. Ghostscript is also a standards-conforming PostScript interpreter.

We have a PDF-centric printing workflow in Ubuntu. Therefore all incoming print jobs are turned into PDF at first if they are not already PDF. Currently the only exception is if the input is PostScript AND the printer is a PostScript printer, to avoid forth-and-back conversion.

So in our case of the printer not being PostScript, the first step CUPS does is converting the PostScript input to PDF using the pstopdf filter which is based on Ghostscript. As the problem is known, the pstopdf filter re-renders PostScript which comes from printing encrypted PDFs with Adobe Reader with Ghostscript's "ps2ps" utility before running it through Ghostscript again to turn it into PDF. This worked fine until Maverick (Ghostscript 8.71). Natty ships Ghostscript 9.01 and there the Ghostscript developers reworked the PostScript output devices. The old "pswrite" device got deprecated as it produces awkwardly big files and the "ps2write" device got improved so that it produces DSC-conforming PostScript. The "ps2ps" utility got switched from "pswrite" to "ps2write" after that, so now "ps2write" is used for the re-rendering of the PostScript from Adobe Reader. The problem is that "ps2write" uses the same code as the PDF output device "pdfwrite" and so it refuses to render the PostScript of the DRMed PDFs, too.

There are two approaches to solve this problem:

1. Report a bug to Ghostscript that for PostScript output with "ps2write" DRMed input files should not get refused.

2. A second PDF workflow exception for DRMed PostScript input.

I will apply (2) soon and will ask you for testing. I will do it by adding a new file type (MIME type) "application/vnd.adobe-drm-postscript" to CUPS which is selected when the incoming file is PostScript from printing an encrypted PDF with Adobe Reader and only one conversion rule for it which lets it get converted to "application/vnd.cups-postscript" with the "pstops" CUPS filter. So CUPS will never try to convert it to PDF.

Please watch out for further messages here when I ask for testing.

The changes to be done are simple, so I will also propose this fix as a Stable Release Update (SRU) for Natty.

Workaround: Open your PDF files with evince (Document Viewer) and print from there. This works for me.