Description of problem: When printing a PDF with an image, ghostscript bailed with an error. Version-Release number of selected component (if applicable): ghostscript-cups-8.71-16.fc14.i686 ghostscript-8.71-16.fc14.i686 How reproducible: Every time. The PDF has been created with OpenOffice. Below is the debug output of cups: D [15/Sep/2010:00:24:27 +1000] [Job 56] Error: /rangecheck in --image-- D [15/Sep/2010:00:24:27 +1000] [Job 56] Operand stack: D [15/Sep/2010:00:24:27 +1000] [Job 56] --dict:7/8(L)-- D [15/Sep/2010:00:24:27 +1000] [Job 56] Execution stack: D [15/Sep/2010:00:24:27 +1000] [Job 56] %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1782 1 3 %oparray_pop D [15/Sep/2010:00:24:27 +1000] [Job 56] Dictionary stack: D [15/Sep/2010:00:24:27 +1000] [Job 56] --dict:1159/1684(ro)(G)-- --dict:3/20(G)-- --dict:117/200(L)-- D [15/Sep/2010:00:24:27 +1000] [Job 56] Current allocation mode is local D [15/Sep/2010:00:24:27 +1000] [Job 56] Last OS error: 2 D [15/Sep/2010:00:24:27 +1000] [Job 56] GPL Ghostscript 8.71: Unrecoverable error, exit code 1 D [15/Sep/2010:00:24:27 +1000] [Job 56] renderer exited with status 1 D [15/Sep/2010:00:24:27 +1000] [Job 56] Possible error on renderer command line or PostScript error. Check options.kid3 exited with status 3 D [15/Sep/2010:00:24:27 +1000] [Job 56] Process is dying with "Error closing renderer D [15/Sep/2010:00:24:27 +1000] [Job 56] ", exit stat 3 D [15/Sep/2010:00:24:27 +1000] [Job 56] Cleaning up...
Could you attach the PDF please? If you downgrade to an earlier build of ghostscript (e.g. ghostscript-8.71-14.fc14) do you still see the problem?
Created attachment 447271 [details] PPD file as requested.
I'm not sure if this makes a difference, but the PDF was printed via evince. The same PDF prints correctly to a HP LaserJet 2840 - however that printer talks postscript - not PCL like this printer...
Actually - my apologies... This PDF *does not* print on the HP LJ2840 as I said before. On attempting to print it, I get this: D [15/Sep/2010:00:24:27 +1000] [Job 56] Read 8192 bytes of print data... D [15/Sep/2010:00:24:27 +1000] [Job 56] Wrote 8192 bytes of print data... D [15/Sep/2010:00:24:27 +1000] [Job 56] Error: /rangecheck in --image-- D [15/Sep/2010:00:24:27 +1000] [Job 56] Operand stack: D [15/Sep/2010:00:24:27 +1000] [Job 56] --dict:7/8(L)-- D [15/Sep/2010:00:24:27 +1000] [Job 56] Execution stack: D [15/Sep/2010:00:24:27 +1000] [Job 56] %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1782 1 3 %oparray_pop D [15/Sep/2010:00:24:27 +1000] [Job 56] Dictionary stack: D [15/Sep/2010:00:24:27 +1000] [Job 56] --dict:1159/1684(ro)(G)-- --dict:3/20(G)-- --dict:117/200(L)-- D [15/Sep/2010:00:24:27 +1000] [Job 56] Current allocation mode is local D [15/Sep/2010:00:24:27 +1000] [Job 56] Last OS error: 2 D [15/Sep/2010:00:24:27 +1000] [Job 56] GPL Ghostscript 8.71: Unrecoverable error, exit code 1 D [15/Sep/2010:00:24:27 +1000] [Job 56] renderer exited with status 1 D [15/Sep/2010:00:24:27 +1000] [Job 56] Possible error on renderer command line or PostScript error. Check options.kid3 exited with status 3 D [15/Sep/2010:00:24:27 +1000] [Job 56] Process is dying with "Error closing renderer D [15/Sep/2010:00:24:27 +1000] [Job 56] ", exit stat 3 D [15/Sep/2010:00:24:27 +1000] [Job 56] Cleaning up...
Gah - this will teach me to add comments to bugs at 3:30am. Job 56 was the original error for the failing print job. My last two tests to a HPLJ2840 were unsuccessful - however nothing was written to error_log (which is what threw me). The page_log shows: HP-Color-LaserJet-2840 57 netwiz [15/Sep/2010:03:20:04 +1000] 1 1 - localhost 00000037 - Jet City.pdf - - HP-Color-LaserJet-2840 58 netwiz [15/Sep/2010:03:24:11 +1000] 1 1 - localhost 00000037 - Jet City.pdf - - It's gone from the print spools, but nothing was received printed. I am attaching the error_log from printing to the HPLJ2840.
Created attachment 447281 [details] error_log printing to a HP Laserjet 2840
Created attachment 447379 [details] This prints correctly to a HPLJ2840.
Created attachment 447380 [details] PDF-1.4 - This prints correctly to a HPLJ2840.
Attached 2 x new PDFs. First is a PDF/A-1a standard, second is a PDF-1.3 standard. Both are created in OpenOffice and both print correctly. The file 00000037 - Jet City.pdf (provided directly) is a PDF/A-1a that does not print. It was also created with OpenOffice. The failure is silent - as cups states that the document printed successfully.
Just checked after downgrading to: ghostscript-8.71-10.fc14 ghostscript-cups-8.71-10 Same issue with the same files.
Also just tried recreating the PDF as PDF/A-1a from OpenOffice to rule out an issue with the PDF on disk. Same results.
Created attachment 448255 [details] This PDF fails to print at all.
Interestingly, this works perfect using F13 and these ghostscript packages: ghostscript-8.71-10.fc13.i686 ghostscript-cups-8.71-10.fc13.i686
Even more interesting. These PDFs print correctly on F14 with the official Adobe Acrobat reader. Does this mean it could be an evince issue?
I am starting to think this is more a problem with evince creating invalid output. Following are 2 JPG scans of printouts - one from Adobe Reader, the other from evince. Although both PDFs are displayed on screen correctly, you can see the big difference in the actual print.
Created attachment 449743 [details] Scanned printout from Adobe Reader
Created attachment 449744 [details] Scanned printout from evince
I forgot to mention, both scanned JPGs are copies of the B960 PDF attached here: https://bugzilla.redhat.com/attachment.cgi?id=448255
Please try printing the PDF from the command line with 'lp -d my-queue file.pdf'. If that works, the problem is definitely the application and not the printing system, yes. Evince is particularly bad in this respect. When trying to print a PDF document it tries (badly) to convert it to PostScript first. It must avoid doing this. CUPS provides a list of acceptable document types for each queue, and PDF *will* be present for every driven queue on Fedora. Evince should either consult this list (document-format-supported), or should just send the PDF to the queue *as is*. I've been saying that Evince's printing should do less for years. Changing component and reassigning.
Yep - printing via lp works perfectly. This means it does work via Acrobat Reader & lp - leaving evince the odd one out.
From talking to the guys in #evince on irc.gnome.org, evince uses cairo to do conversions for printing - therefore this may be an issue with cairo and not evince directly.
It isn't that it converts it badly -- it's that it tries to convert it at all. CUPS should be receiving the original PDF, as-is.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping