Created attachment 8051 [details] pdf file to feed ghostscript (I am using Debian's ghostscript 9.04~dfsg-2 on an i386 Thinkpad T60.) With the attached pic.pdf file, running gs like this: PPD="psc.ppd" /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout pic.pdf > /dev/null using this two-line psc.ppd file (which I will also attach): *PPD-Adobe: "4.3" *HWMargins: 18 36 18 36 produces this error: INFO: Start rendering... INFO: Processing page 1... ERROR: Unable to get scanline 0! Error: /unknownerror in --showpage-- Operand stack: 1 true Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1793 0 9 %oparray_pop --nostringval-- --nostringval-- Dictionary stack: --dict:1161/1684(ro)(G)-- --dict:1/20(G)-- --dict:82/200(L)-- --dict:82/200(L)-- --dict:108/127(ro)(G)-- --dict:291/300(ro)(G)-- --dict:23/30(L)-- --dict:6/8(L)-- --dict:22/40(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript 9.04: Unrecoverable error, exit code 1 INFO: Rendering completed This problem originally showed up in CUPS's gstoraster filter when I tried to print pic.pdf to a HP Photosmart PSC 2710 ("lp pic.pdf"). The above ppd is the minimal version of the CUPS-supplied ppd that reproduced the error. If I change the HWMargins slightly, to *HWMargins: 16 16 16 16 then the problem disappears. Although the output is still a bit suspicious: INFO: Start rendering... INFO: Processing page 1... INFO: Processing page 2... INFO: Rendering completed The PDF file has only one page, so I don't understand why the output reports "processing page 2."
Created attachment 8052 [details] ppd file to supply ghostscript via the PPD environment variable
Bug 687702 may be related (I can confirm that bug 687702 is present with gs 9.04, at least in Debian's version).
Don't worry about the "INFO: Processing page 2...". Ghostscript generates only one page, as there is only one input page.
This bug report is already near seven years old. Therefore I am closing it with WONTFIX. If you are still suffering this problem please re-open.
The problem is still present in gs v9.22 (Debian package 9.22~dfsg-2.1 for amd64). Here is the output of the same command as in 2011: INFO: Start rendering... INFO: Processing page 1... ERROR: Unable to get scanline 0! Error: /unknownerror in --showpage-- Operand stack: 1 true Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 2015 1 3 %oparray_pop 2014 1 3 %oparray_pop 1998 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 1 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1890 0 9 %oparray_pop --nostringval-- --nostringval-- Dictionary stack: --dict:986/1684(ro)(G)-- --dict:1/20(G)-- --dict:83/200(L)-- --dict:83/200(L)-- --dict:133/256(ro)(G)-- --dict:301/450(ro)(G)-- --dict:32/32(L)-- --dict:6/9(L)-- --dict:7/20(L)-- Current allocation mode is local Last OS error: No such file or directory GPL Ghostscript 9.22: Unrecoverable error, exit code 1 INFO: Rendering completed
(In reply to Sanjoy Mahajan from comment #5) > The problem is still present in gs v9.22 (Debian package 9.22~dfsg-2.1 for > amd64). Here is the output of the same command as in 2011: I'm afraid we're not able to debug CUPS. If you can supply us with a Ghostscript command line, and an input file which will reproduce the problem, then we can look into it. If you can't supply that, then you'll have to contact the CUPS developers and enlist their help in getting this information, then come back to us when you have it.
The issue is pretty obvious, when you look at the PPD contents: *HWMargins: 18 36 18 36 The bottom left and top right coordinates are identical, meaning there is no imageable page area. For a Postscript device (and any other sane device) that's just not a valid configuration and Ghostscript therefore signals an error. At least partly due to the configuration coming from the innards of the cups device, rather than coming about due to a "normal" route (i.e. a Postscript setpagedevice operation), we end up with an "unknown error". So, Ghostscript seems, to me, to be behaving in a pretty sensible manner.