PostScript problem with Xerox Phaser 6280DN

[Helge Blischke]

Steve Kleene wrote:

>> That means, there is something wrong with how the job patch file is
>> set up in the PPD. I already have a suspicion but I'll need some more
>> work to either very- or falsify the hypothesis.
>>
>> Helge
>>
> I really appreciate the time you're putting into this.  In case it may be
> of any help, I have now also posted the whole PPD file:
> 
>   http://syrano.acb.uc.edu/tmp/Phaser_6280DN.ppd

Well, Adobe Reader is the culprit. After installing a printer (print to 
file) using the Phaser_6280DN.ppd on both MacOS 10.5 and SuSE Linux 11.1 and 
doing some test prints from Adobe Reader (9.2 on the Mac and 9.1.2 on Linux) 
revealed
(1) no problems on MacOS 10.5
(2) same issue as yours on Linux.

Further investigation showed up that AdobeReader on Linux by itself included 
some defaults/options from the printer's PPD, the JobPatchFile among them,
but bracketed with PS code that caused the error.

I haven't checked if the newest Adobe Reader 9.2 on Linux exhibits the same 
issue, but I have a solution to your problem (tested on my Linux install):

(1) Get the filter oopstops from the CUPS website (search the links for this 
    name) and install it in your /usr/lib/cups/filter directory (or what the 
    directory is named in your installation).
(2) Edit your printer's PPD as follows:
    After the line reading "*cupsVersion: 1.1", insert the line
    *cupsPreFilter: "application/postscript 0 oopstops"

That's all - provided you have a CUPS version 1.3.x or higher (the prefilter 
stuff has been introduced with 1.3.0) - otherwise contact me directly.

If your don't succeedto download the mentioned filter, drop me an e-mail to
"h dot blischke at acm dot org".

Helge

P.S.: For all who are interested in the technical details:

The reason why the Reader generated PostScript jobs fail is that the
job patch file is bracketed by
"[{" and "} stopped cleartomark", that is, the job patch file gets executed 
as the body of a PostScript procedure.
Normally, this doesn't cause any problems except in cases as like this:
the job patch file begins with "currentfile eexec". But, as the executon is 
deferred until the PS interpreter reaches the stopped operator, the file 
"position" returned b y currentfile is just behind the stopped operator 
instead of behind the eexec operator in the procedure body.

The filter I suggested to use has originally been designed to solve a 
similar issue with OpenOffice 2.x and 3.x and eliminates (among other things 
it does) a job patch file specified just as the Adobe Reader does as well.
The CUPS pstops filter safely inserts the job patch file without the 
delicate procedure stuff around it.