Bad PostScript data generated -- any way to diagnose?

[Helge Blischke]

Alex Taylor wrote:

> I'm trying to get CUPS + foomatic-rip working in our environment, but I
> have a problem with GhostScript apparently choking on the final PS file.
> 
> My problem is basically this: we have an initial PostScript file (which
> is generated by our own application).  Here is an example:
>   http://users.socis.ca/~ataylo00/input_ps_ok.zip  (110 KB)
> 
> This file, although it generates a couple of minor DSC warnings, renders
> without trouble in GSView, and prints just fine when sent directly to a
> PostScript printer, or when printed through GhostScript.
> 
> The problem is that running the file through CUPS results in an
> unprintable file.  Here is the output of the same file, immediately
> after being processed by pstops and foomatic-rip:
>   http://users.socis.ca/~ataylo00/output_ps_bad.zip  (114 KB)
> 
> Attempting to run this file through GhostScript
>   gs -sDEVICE=lp9400 -dBATCH -dNOPAUSE -sOUTPUTFILE=blah foomatic-rip.ps
> yields the following:
>  
> GPL Ghostscript  9.00 (2010-09-14)
> Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> Error: /undefined in --.endpage--
> Operand stack:
>    0   true   1   (PAGE: )
> Execution stack:
>    %interp_exit   .runexec2   --nostringval--   --nostringval--
> --nostringval-
> -   2   %stopped_push   --nostringval--   --nostringval--  
> --nostringval-- fa
> lse   1   %stopped_push   1862   1   3   %oparray_pop   1861   1   3
> %oparray_
> pop   1845   1   3   %oparray_pop   1739   1   3   %oparray_pop
> --nostringval-
> -   %errorexec_pop   .runexec2   --nostringval--   --nostringval--
> --nostringv
> al--   2   %stopped_push   --nostringval--   1745   0   3   %oparray_pop
> --nos
> tringval--   1825   1   3   %oparray_pop   --nostringval--   4
> --nostringval--
>  
> Dictionary stack:
>    --dict:1154/1684(ro)(G)--   --dict:1/20(G)--   --dict:87/200(L)--
> Current allocation mode is local
> Last OS error: No such file or directory
> Current file position is 203561
> GPL Ghostscript  9.00: Unrecoverable error, exit code 1
>  
>  
> And, sure enough, the output file is truncated right before the last few
> bytes of the job.  Obviously, the same problem occurs if the file
> actually gets sent to the printer: the printout is always missing the
> last portion.
> 
> Using CUPS 1.4.4; the problem occurs with multiple versions of
> GhostScript and foomatic-rip, on multiple different operating systems.
> 
> Is there any way to trace this error inside GhostScript?  Something
> must be wrong with the PostScript data, but I don't have enough
> knowledge of PostScript to work it out on my own.
> 

Alex, 

isn't this just the case we fiddled around about a month ago (the OS/2 
issue)?
If you - as a test - edit the foomatic-rip.ps and comment out the end 
statement immediately preceding the showpage (i. e. prepend a % the the 
end), it will be rendered by ghostscript (yes, even 9.00) and print OK on a 
real printer (a OKI C3600 in my case).

The reason for the failure is that the setup section (the first one) 
contains a  a "200 dict begin" near the beginning (to be precise, in line 
99), and this (anonymous) dictionary is popped off from the dictionary stack 
just preceding the showpage statement.

I think as you may not be able to modify the presentation manager of OS/2, 
the only way to settle this issue is to implement a prefilter in CUPS for 
the file type "application/postscript" that checks for 
%%Creator: Presentation Manager
and, if true, edits the PS file appropriately.

In order to know what to do in detail I'd need to know how jobs look like 
that contain more than only one page.

Helge