printing pdf fails without error message

Can you please attach the PDF file which you tried to print and also follow the instructions in the section "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems? Thanks.

Here's the PDF

And the cups error_log.

I have also asked you to follow the instructions in the section "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Can you do so, too? Thanks.

Yes, sorry. I had no more time yesterday. Here's the output + attachment from "Capturing print job data":

sander@sander-thuis:~$ cancel -a

(don't know how to find out the queue name - the wiki document doesn't explain this, so used system-config-printer to disable the print queue)

sander@sander-thuis:~$ lpstat -o
HP-Color-LaserJet-CP2020-42 sander 1385472 Wed 16 Mar 2011 09:47:08 AM CET

sander@sander-thuis:~$ sudo ls -1 /var/spool/cups
d00042-001
tmp

sander@sander-thuis:~$ sudo cp /var/spool/cups/d00042-001 ~/printout

sander@sander-thuis:~$ sudo chmod 777 ~/printout

(re-enabled the print queue using system-config-printer)

sander@sander-thuis:~$ file ~/printout
/home/sander/printout: PDF document, version 1.5

The PDF sent to CUPS from the application (evince) is already completely ineffective. If you open the file captured from the print queue (printout) with the Adobe Reader, it takes several minutes until the first slide is rendered. This PDF is not the original. It is re-rendered by Cairo, the graphics library used by evince. Moving to the Cairo package ...

I have tried with Natty now. When printing your attached original file test.pdf into a file from evince, I get a somewhat smaller file than the one you have captured and it does not have the problem of slow rendering with the Adobe Reader. Perhaps the problem is solved in Natty. Please try to boot a live CD of Natty (Alpha 3 or daily snapshot) set up a print queue equivalent to your original one in the Natty live environment, and try to print your PDF file there. Does it work with a reasonable speed?

OK, I will try this when i get home.

Apart from the fact that this particular problem may have been caused by a problem with the generated file, shouldn't there be some mechanism in place that notifies the user of the "Unable to write print data: Broken pipe" problem via the GUI? I can imagine that the error might also occur in other situations, for example with extremely large or complex files or a slow computer, printer or network link?

The place where users get informed about the status of their print jobs is the job viewer of system-config-printer (reachable through printer icon in the notification area while there are print jobs). Unfortunately, it does not show the error message, but simply a "processing" or "stopped" job. Showing more info here would be very helpful. Therefor I add a feature request task on system-config-printer.

Tim, Jir, could you look into this? Thanks.

I can confirm that printing the same PDF goes much faster in Natty - it finishes within the printer's default timeout.

Even if i lower the timeout on the printer to 5 seconds (the minimum), the PDF still prints without problems.

So, i'd say that the cairo part of this bug is fixed in Natty.

Thank you for testing. Marking the Cairo task as fixed as bug tasks without specification of a release are always for the current release under development, which is Natty at this time.