Bug 690101

Created attachment 4444 [details]
pdftoraster.c

First prototype of a Ghostscript-based pdftoraster filter for CUPS

Created attachment 4445 [details]
gutenprint.ppd

PPD file used for the test (of Gutenprint 5.2.0beta4)

Created attachment 4446 [details]
walking-map-portland-1.pdf

PDF input file used for the test

Created attachment 4447 [details]
raster.out

CUPS Raster output of the test command line.

Created attachment 4448 [details]
raster.err

STDERR output of the test command line

Created attachment 4449 [details]
raster-debug.err

Like raster.err, but now with "-dDEBUG" added to the Ghostscript command line

Created attachment 4450 [details]
raster-NOMEDIAATTRS-debug.err

This is the error output with both "-dDEBUG" and "-dNOMEDIAATTRS" added

As one can see at the lines commented out in pdftoraster.c one can see that I
have already tested more things:

- Supplying Postscript commands for the imaging bounding box and margins does
not prevent from the error and the Ghostscript output device should find this
info by itself, as it reads the PPD file.

- Supplying "-dSeparations=false" or "-dcupsNumColors=..." leads to other errors.

One remark on how I supplied PostScript commands: I used the "-c" command line
option:

gs ... -c '<</cupsImagingBBox[10.0000 12.0000 585.0000 830.0000]>>setpagedevice'
'<</ImagingBoundingBox[10 12 585 830]>>setpagedevice' '<</Margins[10
12]>>setpagedevice' -f -_

Note that after supplying PostScript code with "-c" the "-f" option has to be
used to let Ghostscript return to interpret command line areguments as input
file names.

The shown settings cannot be supplied with the "-d" or "-s" command line options
as their values are arrays. "-d" or "-s" support only simple boolean, numerical,
or string values.

I have also tried to feed PostScript (the CUPS test page) into the shown
Ghostscript command lines and then Ghostscript renders the input without any
errors. So the problem is some bad interference when PDF is rendered with the
"cups" output device.

I had a look at bug 690032 and this bug seems to have the same "fingerprint". If
I run

gs -sDEVICE=cups -sOutputFile=x ~/walking-map-portland-1.pdf

and press Enter at the prompt I get the same error output as with the command
line shown in bug 690032. The stacks shown in the message have practically the
same content, except some of the numerical parameters of the "--dict:...--" items.

Error message of

gs -sDEVICE=cups -sOutputFile=x ~/walking-map-portland-1.pdf


Error: /rangecheck in .installpagedevice
Operand stack:
   --nostringval--   false   --nostringval--   --dict:109/128(ro)(L)--  
--nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   1904
  1   3   %oparray_pop   1888   1   3   %oparray_pop   --nostringval--  
--nostringval--   2   1   1   --nostringval--   %for_pos_int_continue  
--nostringval--   1834   3   7   %oparray_pop   --nostringval--   1818   3   7 
 %oparray_pop   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1150/1684(ro)(G)--   --dict:1/20(G)--   --dict:97/200(L)--  
--dict:97/200(L)--   --dict:106/127(ro)(G)--   --dict:275/300(ro)(G)--  
--dict:21/25(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 8.63: Unrecoverable error, exit code 1



Error message of

gs -sDEVICE=bjc600 -sOutputFile=x ~/walking-map-portland-1.pdf


Error: /rangecheck in .installpagedevice
Operand stack:
   --nostringval--   false   --nostringval--   --dict:59/72(ro)(L)--  
--nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   1904
  1   3   %oparray_pop   1888   1   3   %oparray_pop   --nostringval--  
--nostringval--   2   1   1   --nostringval--   %for_pos_int_continue  
--nostringval--   1834   3   7   %oparray_pop   --nostringval--   1818   3   7 
 %oparray_pop   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1153/1684(ro)(G)--   --dict:1/20(G)--   --dict:97/200(L)--  
--dict:97/200(L)--   --dict:106/127(ro)(G)--   --dict:275/300(ro)(G)--  
--dict:21/25(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 8.63: Unrecoverable error, exit code 1



In both cases the size of the output file x suggests that the job got actually
rendered.

So it is not excluded that Ghostscript has a general bug in rendering PDF, but
it is also possible that some drivers ("cups", "bjc600", "bjc800", ...?) have
bugs which trigger the same error.

I have done some more investigations. If you run

gs -sDEVICE=cups -sOutputFile=x <file>

everything works fime with any PostScript file. If you supply a PDF file, the
error shown in comment #11 always occurs on the second page. The first page gets
always printed. So one-page documents get correctly printed but Ghostscript
exits with an error exit value. On multiple-page documents only the first page
comes out.

The problem seems to be in the parameter list. For the first page it gets
correctly set up. From the second page on the parameter list is messed up and so
gdev_prn_put_params() gives the error.

You can see it if you run the above command line with "-dDEBUG":

gs -dDEBUG -dNOPAUSE -sDEVICE=cups -sOutputFile=x ~/walking-map-portland-1.pdf
>x.err 2>&1

You see in the attached x.err that shortly before the error occurs, the
parameter list contains items where the names are composed of random non-ASCII
characters. This happens even on the two last calls of gdev_prn_put_params() (a
call of gdev_prn_put_params() usually happens shortly after "DEBUG: max_color",
when lines not beginning with "DEBUG" appear).

It seems that the parameter list gets overwritten with unrelated data after the
first page or not correctly initialized for the second page.

Created attachment 4455 [details]
x.err

GhostScript error output for command line above

Created attachment 4461 [details]
gs-valgrind

Ran Ghostscript through valgrind:

valgrind gs -dDEBUG -dNOPAUSE -sDEVICE=cups -sOutputFile=gs.out
~/walking-map-portland-1.pdf >gs-valgrind 2>&1

Valgrind output attached.

The valgrind trace shows a problem in cups_put_params() which suggests it is a
corruption problem inside gdevcups.

Created attachment 4463 [details]
gs-valgrind-debug

Valgrind output with above command line but with gs built in debug mode

Are the param_read_float() and familiy return values documented?
Where? 
I'd like to know what is in the gs_param_list * plist, but it seems
to be a complicated thing.

Kai-Uwe @17: The plist api is documented in gsparam.h. Or perhaps I should say,
what documentation there is, is there. It's also helpful to look at some
examples in of how it's used by some of the output devices.

In particular, gsparam.h says:

 *      - 'reading' procedures ('put' operations from the client's viewpoint)
 * return 1 for a missing parameter, 0 for a valid parameter, <0 on error.
 *      - 'writing' procedures ('get' operations from the client's viewpoint)
 * return 0 or 1 if successful, <0 on error.

Ghostscript API documentation is generally in header files, except for the
client and device apis which are described in doc/API.htm and doc/Drivers.htm
respectively.

Created attachment 4469 [details]
gdevcups.c

Attached is a version of cups/gdevcups.c where I have done some small casting
fixes. Unfortunately, this did not fix this bug.

When the code below param_write_int(plist, "cupsNumColors" ... in
cups_get_params():~830 is outcommented, the backend runs cleanly.
I could not check the resulting output. 

Without that following error occurs:
DEBUG2: before gdev_prn_put_params()
DEBUG2: error gdev_prn_put_params() -21
Error: /rangecheck in .installpagedevice
Operand stack:
   --nostringval--   false   --nostringval--   --dict:125/144(ro)(L)--  
--nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
--nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   1904
  1   3   %oparray_pop   1888   1   3   %oparray_pop   --nostringval--  
--nostringval--   2   1   1   --nostringval--   %for_pos_int_continue  
--nostringval--   1834   3   7   %oparray_pop   --nostringval--   1818   3   7 
 %oparray_pop   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1147/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--  
--dict:75/200(L)--   --dict:106/127(ro)(G)--   --dict:275/300(ro)(G)--  
--dict:21/25(L)--
Current allocation mode is local
Last OS error: 2
GPL Ghostscript 8.63: Unrecoverable error, exit code 1
DEBUG2: cups_close(0x8d95144)

My guess is that the gs_param_list stuff is messed up.
Can this be veryfied or falsified? How?

Created attachment 4512 [details]
gdevcups_wrong.c

This version allows to run through cups output with a simple PDF like
tiger.pdf (from tiger.eps). Several param_write_xxx calls are omitted in
this version.

The error code of 
DEBUG2: before gdev_prn_put_params()
DEBUG2: error gdev_prn_put_params() -21
is defined as "gs_error_undefined".

Created attachment 4513 [details]
gdevcups.c

Correct test version to run cups.

Fixed in revision 9165. Fixed broken duplex in addition.

As the "cups" output device is working with PDF input now, I have added a
pdftoraster filter to the SVN repository (to build with "make cups" and to
install together with the other CUPS files with "make install-cups".

This filter can be used with the other PDF filters from OpenPrinting to have a
PDF-based printing workflow:

https://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format

And thank you for all the help and contributions to make me fix this bug.