Red Hat Bugzilla – Bug 331341
Cups fails to print a PDF file
Last modified: 2008-08-02 19:40:35 EDT
Description of problem:
The attached Chinese-language PDF file causes Cups some major grief.
Running the same PDF file through pdf2ps produces a .ps file that Cups prints
without any complaints.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Attach an HP LaserJet 1320 printer. Cups autoconfigures it as "HP LaserJet
1320 series Postscript (recommended)"
2. lpr alternative-vrf-mandarin-7.26.07.pdf
A) CUPS seems to process this print job, and sends it to the printer
B) No output is produced by the printer. The "attention" light flashes on the
C) Clearing the error condition seems to reset the printer to the "Ready" state.
D) Resubmitting the same PDF file to CUPS immediately generates the "Christmas
tree" status on the printer's console which, according to HP's documentation,
indicates a "Fatal firmware error". The second print job remains stuck in CUPS's
E) The only way to clear the printer is to powercycle it. After the powercycle
CUPS still can't use the printer, and shows the printer in a perpetual "Printer
not connected; will retry in 30 seconds..."
F) The only way to recover the printer is to manually cancel the second print
job out of the queue, clearing it completely, then rebooting and powercycling
the printer at the same time.
A two page document.
Fedora 7 with all current updates.
Running 'ps2pdf' on this PDF file produces a Postscript file that CUPS prints
without a complaint:
The result of pdf2ps on this PDF file prints without any problems whatsoever.
Created attachment 226641 [details]
PDF file that cannot be printed
Created attachment 226651 [details]
This is the output of pdf2ps on the PDF file, Cups can print this.
Please attach the PPD file you are using for this queue. It can be found in the
/etc/cups/ppd/ and has the same name as the queue but with '.ppd' at the end.
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.
Setting status to "CLOSED INSUFFICIENT_DATA". If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.
Thank you in advance.
Note that maintenance for Fedora 7 will end 30 days after the GA of Fedora 9.