printing pdf fails without error message

[Sander-oele]

Binary package hint: cups

When trying to print a PDF document from evince on my HP CP2025, the activity led on the printer blinks for about 2 minutes, after which it stops blinking without printing anything.

'top' on my computer shows a 'pdftops' process chewing up my CPU for some time, after which nothing happens. When the 'pdftop' process stops, /var/log/cups/error_log shows:

Set job-printer-state-message to "Unable to write print data: Broken pipe", current level=ERROR

This happens every time i try to print this document.

After logging in on the web interface of the printer and increasing the "Connection Timeout (I/O)" setting from 120 to 7200, printing works OK - but it takes about 20 minutes before the printer starts printing.

It's clear that the actual problem is caused by the timeout setting on the printer, but ubuntu should tell the user about the fact that the printer dropped the connection. Right now, the only way to find out what's going on is to look in the cups error log file.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: cups 1.4.4-6ubuntu2.3
ProcVersionSignature: Ubuntu 2.6.35-27.48-generic 2.6.35.11
Uname: Linux 2.6.35-27-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Tue Mar 15 22:35:16 2011
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
Lpstat: device for HP-Color-LaserJet-CP2020: socket://192.168.0.201:9100
Lsusb:
 Bus 003 Device 002: ID 045e:00db Microsoft Corp. Natural Ergonomic Keyboard 4000 V1.0
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 003: ID 046d:c042 Logitech, Inc. G3 Laser Mouse
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: PACKARD BELL BV ISTART F9150
Papersize: letter
PpdFiles: HP-Color-LaserJet-CP2020: HP Color LaserJet CP2020 Series Postscript (recommended)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-27-generic root=UUID=a3daa0f2-4672-4c39-99fc-feb292a253b4 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cups
dmi.bios.date: 07/17/2007
dmi.bios.vendor: Phoenix Technologies,
dmi.bios.version: Si671V14
dmi.board.name: GA-T671MG
dmi.board.vendor: PACKARD BELL BV
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: PACKARD BELL BV
dmi.modalias: dmi:bvnPhoenixTechnologies,:bvrSi671V14:bd07/17/2007:svnPACKARDBELLBV:pnISTARTF9150:pvrPB82123486:rvnPACKARDBELLBV:rnGA-T671MG:rvrx.x:cvnPACKARDBELLBV:ct3:cvr:
dmi.product.name: ISTART F9150
dmi.product.version: PB82123486
dmi.sys.vendor: PACKARD BELL BV

[Till Kamppeter (till-kamppeter)]

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.

[Sander-oele (sander-oele)]

Here's the PDF

[Sander-oele (sander-oele)]

And the cups error_log.

[Till Kamppeter (till-kamppeter)]

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.

[Sander-oele (sander-oele)]

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

[Till Kamppeter (till-kamppeter)]

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 ...

[Till Kamppeter (till-kamppeter)]

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?

[Sander-oele (sander-oele)]

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?

[Till Kamppeter (till-kamppeter)]

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.

[Sander-oele (sander-oele)]

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.

[Till Kamppeter (till-kamppeter)]

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.