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

[Helge Blischke]

Alex Taylor wrote:

> 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...
> 

Well, the PS file generated by your OS/2 generator is by no means DSC 
compliant which is essential for foomatic-rip to function properly.

For test, I have modified the bue_good.ps to be formally DSC compliant
(though the statements semantically belonging to the prolog and setup 
section, respectively, are intermixed) and attached it to my reply. It 
should then go through foomatic-rip without producing errors.

The reason why the unhacked (good) PS file prints correctly simply is that 
the CUPS pstops filter does not recognize it as DSC compliant and therefore
treats the whole file as a single page. But then all features like number-up 
printing, reversed output etc. are disabled in fact.

If you compare the attached test file against ypur "good.ps", ypou'll easily 
see how to settle your issue, even for jobs with more than one page.

BTW. many thanks for the recipe!.

Helge


-------------- next part --------------
A non-text attachment was scrubbed...
Name: blue_test.ps
Type: application/postscript
Size: 901932 bytes
Desc: not available
URL: <http://lists.cups.org/pipermail/cups-devel/attachments/20100912/056617f0/attachment.ps>