Printing encrypted PDFs on a non-PostScript printer gives a blank page

Hi,

Please do the following to capture some logs to help us understand the issue.
      a)Open /etc/cups/cupsd.conf in root mode and replace
        LogLevel warn
          with
       LogLevel debug
       hpLogLevel 15
    b) Restart cups using following command:
        /etc/init.d/cups restart (in root mode)
                  or
       service cups restart
    c) Try to print the file and then send the /var/log/messages (if present) file and /var/log/cups/error_log
    d) Send the file with latest timestamp (hpcups_jobNN.out where NN=some number and timestamp is the time when job print was tried in step c) generated in /tmp directory.
    e) Send the file with latest timestamp hpcupsfilterc_1.bmp and hpcupsfilterk_1.bmp (If present)

Thanks,
Sanjay

Hi Dawid,

It looks like you are trying to print a secure pdf in linux. Unfortunately secure/encrypted pdf printing is not supported by CUPS (HPLIP uses cups) currently. Please try to convert the pdf to non secure pdf. We will let you know if there is any update on this. Thanks for contacting HPLIP.

FYI (More details about the bug):
http://www.linuxquestions.org/questions/mandriva-30/cannot-print-pdf-files-294782/

Thanks,
Sanjay

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.

I am attaching two files (adobereaderps.types and adobereaderps.convs) to this and to the next comment. These make CUPS detecting PostScript coming from the Adobe Reader and not applying the PDF printing workflow on them (keeping them PostScript until processed by the printer driver). Note that all PostScript files from Adobe Reader will get treated this way as CUPS is not able to distinguish PostScript from encrypted and unencrypted PDFs (CUPS only takes into account the first 4096 bytes of an input file to auto-type it).

Install the files by copying them into your /etc/cups/ directory and making sure that they are readable for everyone ("sudo chmod 644 /etc/cups/adobereaderps.*"). Then restart CUPS with

sudo restart cups

After that try to print your files. Does it work now?

I just tested the files as you suggested and printing the document now works as expected. As to printing the document with Evince - I would not bother with Acrobat indeed, but not only the document is protected (which I was not aware of prior to reporting this bug), it is also a pre-filled form document which Evince does not support.
Anyway, your solutions works just fine so hopefully this change will be accepted as a SRU. Thanks!

Thank you very much. I have committed the fix to the Debian BZR repository of CUPS now, so that the next CUPS packages in Debian unstable and Ubuntu Oneiric will contain the fix. The SRU for Natty will follow.

I have uploaded the fix into the natty-proposed repository. As soon as it gets approved it will be available for testing. Please test if you are asked to do so here. To test correctly, please remove the files adobereaderps.types and adobereaderps.convs which you have added to your system for the tests in comments #7, #8, and #9, restart CUPS, check whether the bug occurs again and only after that install the new CUPS package (1.4.6-5ubuntu1.2) from -proposed. If then the bug is solved again, the new package is OK and ready for release as the SRU.

A new fixed CUPS package for Natty is now uploaded the -proposed queue. As soon as it gets approved please test the new package. A comment with instructions will be posted here then. A debdiff of the changes is attached.

The new CUPS package does not fix only this bug, but in total five bugs (therefore the somewhat bigger debdiff): bug 711779, bug 782309, bug 790378, bug 792309, bug 793265. Any help on verifying these fixes is also welcome.

Accepted cups into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package cups - 1.4.6-7

---------------
cups (1.4.6-7) unstable; urgency=low

  * debian/patches/cups-avahi.dpatch: Updated Avahi patch so that it does
    not generate too long service names which Avahi does not accept. Printers
    did not get advertized via DNS-SD then. (LP: #793265).
  * debian/patches/cups-avahi.dpatch: Updated Avahi patch to add the text
    field entry "URF=none" and the service subtype "_universal" so that
    mDNS/Bonjour-advertized printers are recognized by AirPrint clients
    (iPhone/iPad with iOS 4.2 or newer). (LP: #711779).
  * debian/patches/cups-avahi.dpatch: In contrary to the libdns_sd API the
    Avahi API requires port numbers in host order and not in network order.
    This made the Avahi-based DNS-SD broadcasting of CUPS advertizing wronmg
    port numbers. Updated the Avahi patch to fix it. Thanks to Tim Waugh
    from Red Hat on confirming this (LP: #792309).
  * debian/local/filters/pdf-filters/pdftopdf/P2PResources.cxx: Fixed
    memory leak in pdftopdf filter which made the filter taking up several
    gigabytes when processing certain PDF files. Thanks to upstream
    author Koji Otani for the quick fix (LP: #790378).
  * debian/local/pstopdf.convs, debian/local/pstopdf.types: Do not apply
    the PDF printing workflow to PostScript input coming from the Adobe
    Reader. If this PostScript comes from an encrypted (DRM) PDF, it cannot
    be converted to PDF again by Ghostscript (LP: #782309).
 -- Martin Pitt <email address hidden> Tue, 07 Jun 2011 07:04:11 +0200

I am still waiting for my mirror to sync, I will update here after I test the package.

I'm not to use a printer and I don't know how I get to no upgrade of all

It's been a couple days now since I am waiting for the package to appear in natty-proposed. The policy here still shows 1.4.6-5 being most recent available version. I even switched to main repository server (archive.ubuntu.com), but that didn't help either.

cups:
  Installed: 1.4.6-5ubuntu1.2
  Candidate: 1.4.6-5ubuntu1.2
  Version table:
 *** 1.4.6-5ubuntu1.2 0
        400 http://archive.ubuntu.com/ubuntu/ natty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     1.4.6-5ubuntu1.1 0
        900 http://archive.ubuntu.com/ubuntu/ natty-updates/main amd64 Packages
     1.4.6-5ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ natty/main amd64 Packages

Dawid, you have installed cups 1.4.6-5ubuntu1.2 and this is the correct one. Please go ahead testing and tell us whether the problem is solved for you. Thanks.

Excerpts from Dawid Wróbel's message of Fri Jun 10 20:54:38 UTC 2011:
> It's been a couple days now since I am waiting for the package to appear
> in natty-proposed. The policy here still shows 1.4.6-5 being most recent
> available version. I even switched to main repository server
> (archive.ubuntu.com), but that didn't help either.
>

David, 1.4.6-5ubuntu1.2 includes the proposed fix for this issue.

Thanks for clearing this up for me, I was expecting the 1.4.6-7 as described by Launchpad Janitor.
Anyway, I just tested the 1.4.6-5 cups package by printing exactly the same document I used in my initial report and everything seems fine so this bug can now be closed.

This bug was fixed in the package cups - 1.4.6-5ubuntu1.2

---------------
cups (1.4.6-5ubuntu1.2) natty-proposed; urgency=low

  * debian/patches/cups-avahi.dpatch: Updated Avahi patch so that it does
    not generate too long service names which Avahi does not accept. Printers
    did not get advertized via DNS-SD then. (LP: #793265).
  * debian/patches/cups-avahi.dpatch: Updated Avahi patch to add the text
    field entry "URF=none" and the service subtype "_universal" so that
    mDNS/Bonjour-advertized printers are recognized by AirPrint clients
    (iPhone/iPad with iOS 4.2 or newer). (LP: #711779).
  * debian/patches/cups-avahi.dpatch: In contrary to the libdns_sd API the
    Avahi API requires port numbers in host order and not in network order.
    This made the Avahi-based DNS-SD broadcasting of CUPS advertizing wronmg
    port numbers. Updated the Avahi patch to fix it. Thanks to Tim Waugh
    from Red Hat on confirming this (LP: #792309).
  * debian/local/filters/pdf-filters/pdftopdf/P2PResources.cxx: Fixed
    memory leak in pdftopdf filter which made the filter taking up several
    gigabytes when processing certain PDF files. Thanks to upstream
    author Koji Otani for the quick fix (LP: #790378).
  * debian/local/pstopdf.convs, debian/local/pstopdf.types: Do not apply
    the PDF printing workflow to PostScript input coming from the Adobe
    Reader. If this PostScript comes from an encrypted (DRM) PDF, it cannot
    be converted to PDF again by Ghostscript (LP: #782309).
 -- Till Kamppeter <email address hidden> Mon, 5 Jun 2011 13:51:59 +0200

Hi,

I have cups 1.4.6-5ubuntu1.4 installed and I am still experiencing the same issues: printing directly from Acrobat or printing ps files created by Acrobat results in one blank page.

I also tried fix suggest in post #7 and #8 with no luck.

Any ideas?

PS. I am trying to print Canadian visitor visa forms (e.g. filled IMM5252e.pdf form since it cannot be saved when filled). Cheers.

Radek, can you attach your files

/usr/share/cups/mime/pstopdf.types
/usr/share/cups/mime/pstopdf.convs

Do you have files

/etc/cups/pstopdf.types
/etc/cups/pstopdf.convs

If so, can you attach them, too?

Can you also follow the instructions of the section "CUPS error_log" of https://wiki.ubuntu.com/DebuggingPrintingProblems? Thanks.

Hi Till,

Here is the cups error log file.

The only files in /etc/cups/ are the two you posted earlier (adobereaderps.*)

The /usr/share/cups/mime contains both files. I am not sure how to attach more than one file ....
Here are the files (omitting comments)

pstopddf.types
application/vnd.adobe-reader-postscript priority(150) contains(0,4096,"%%Creator: Adobe Acrobat") + \
    (ai eps ps string(0,%!) string(0,<04>%!) \
                                 contains(0,128,<1B>%-12345X) + \
                                 (contains(0,4096,"LANGUAGE=POSTSCRIPT") \
                                  contains(0,4096,"LANGUAGE = Postscript") \
                                  contains(0,4096,"LANGUAGE = PostScript") \
                                  contains(0,4096,"LANGUAGE = POSTSCRIPT") \
                                  (contains(0,4096,<0a>%!) + \
                                   !contains(0,4096,"ENTER LANGUAGE"))))

pstopdf.convs
application/postscript application/pdf 22 pstopdf
application/vnd.adobe-reader-postscript application/vnd.cups-postscript 66 pstops

I hope it helps.

Cheers, Radek

PS: My workaround so far: print to printer, scan it, save as pdf :-)

Your problem is caused by cups-pdf. So please file a new bug on cups-pdf (and attach this error_log also there).

First, the Ghostscript called by the cups-pdf backend errors out, but the backend is closed without error exit code, making CUPAS assuming that the job got correctly printed. This one can see here in the error_log:

D [19/Sep/2011:22:24:44 -0600] [Job 61] GPL Ghostscript 9.01: Unrecoverable error, exit code 1
D [19/Sep/2011:22:24:44 -0600] PID 23327 (/usr/lib/cups/backend/cups-pdf) exited with no errors.
D [19/Sep/2011:22:24:44 -0600] cupsdMarkDirty(-----S)
I [19/Sep/2011:22:24:44 -0600] [Job 61] Job completed.

Second, the cups-pdf saves a PDF file consisting of one blank page. In this case where Ghostscript has errored out it should not write a file at all.

Third, and this is the most important, Ghostscript refuses to turn Adobe Reader's PostScript into PDF if the original PDF was encrypted (had DRM settings). This measure is done to prevent from simply stripping off the DRM settings.