"Error: /undefined in --.endpage--" with foomatic-rip

[Alex Taylor]

Sorry for the rather lengthy post, but I could really use some help 
with this porting problem, and I figured too much information is better 
than too little...

I'm helping with the OS/2 port of CUPS.  At present, I'm trying to get 
working a number of Japanese-model (mostly Epson) laser printers which 
use foomatic-rip.

First, a quick summary of how CUPS works under OS/2.  Normal OS/2 
applications can only print to an OS/2 print queue.  Every OS/2 print 
queue has associated with it (A) a print driver (which generates the 
native-format print data), and (B) a "port driver" (like a backend) 
which is responsible for sending that data to the printer.  With CUPS, 
for (A) we use an OS/2 PostScript print driver (our own build, but 
mostly based on IBM's code) so that the generated print job is a PS 
file.  For (B) we use a special port driver that we've written which 
waits until the PostScript job file is fully generated, and then runs 
CUPS lpr on it (so it gets passed to cupsd, which takes it over from 
there).  

The port driver makes one minor modification to the PS file: it always 
adds the first line "%!PS-Adobe-3.0" to work around certain problems 
(such as the fact that the PostScript driver generates the header 
"%!PS-Adobe" instead, which I believe is technically incorrect according 
to the DSC).

The problem I'm having is this: when printing to a printer which uses 
foomatic-rip to print via GhostScript, the job is always truncated just 
before the end (so the last few bytes are cut off).  

This is the error output that I get (in this particular instance, 
printing to an Epson LP-9400):


Closing renderer
Error: /undefined in --.endpage--
Operand stack:
   0   true   1   (PAGE: )
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1846   1   3   %oparray_pop   
1845   1   3   %oparray_pop   1829   1   3   %oparray_pop   1723   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   
--nostringval--   --nostringval--   --nostringval--   2   %stopped_push   
--nostringval--   1729   0   3   %oparray_pop   --nostringval--   1809   
1   3   %oparray_pop   --nostringval--   4   --nostringval--
Dictionary stack:
   --dict:1154/1684(ro)(G)--   --dict:1/20(G)--   --dict:80/200(L)--
Current allocation mode is local


Now, this ONLY happens when the PostScript job file was passed through 
our CUPS port driver; if I set the OS/2 print queue to output to file 
only, and then print that file manually (using CUP lpr), then it prints 
fine.

Normally, I'd say this points to a bug in our port driver (or at least 
in the PS data that comes out of it)... and that may turn out to be the 
case.  However, if I take the same output file, and print it from, say, 
an Ubuntu Linux box, it prints perfectly well.

This archive contains two instances of the same printed document:
  http://users.socis.ca/~ataylo00/input_ps_files.zip  (~380 kB)
"blue_good.ps" was generated by printing directly to file; as noted 
above, it prints correctly.  "blue_bad.ps" was generated by printing to 
the CUPS printer through our port driver, then saving the generated 
spooler file; this file exhibits the truncation error.  

(Feel free to try the recipe, BTW.  It's really good. <g>)

Now here's the weird thing.  If I edit "blue_bad.ps" and DELETE the 
line "%!PS-Adobe-3.0" from the top (or change it to simply "%!PS-Adobe"), 
then all of a sudden the file will print correctly!  I _think_ this is 
because not having the correct PS header will cause foomatic-rip to skip 
over the first section, which I guess must result in the error (whatever 
it is) being bypassed somehow.  (This is presumably the same reason why 
"blue_good.ps" prints correctly -- because it lacks this header.)

At the end of the day, I don't know whether it's the PostScript data 
that is invalid somehow, or if there's a bug in our port of foomatic 
(or of GhostScript), or if it's some odd combination of the two.  Since 
I don't really know much about the PostScript language, I can't really 
say.  (That's also one reason I'm posting here instead of on the
foomatic list.)

I turned on foomatic-rip debug logging and compared the output from 
these two files.  
  http://users.socis.ca/~ataylo00/foomatic_output_files.zip (~385 kB)
This archive contains the logfiles and the final foomatic-generated PS 
data files from both the "good" and "bad" jobs.

I wonder if anyone could provide further insights on this problem?

Thanks...

-- 
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00

Please take off hat when replying.