Bug 695418

Created attachment 11105 [details]
Postscript file

postscript file that is failing.

This is nothing to do with ps2write (the 'PS writer') since the error occurs even with the display device (and in any event pdfwrite is the PDF writer....)

Concatenating PostScript files is a good way to come up with files that don't work, its highly not recommended. This is because PostScript is a programming language, so in effect you are concatenating multiple programs, and expecting them to work. You might be lucky (people often are) but its a bad way to proceed.

In this case the concatenated files are not simply PostScript, they have been printed to a HP printer driver, so each file includes PJL and, critically, a control-D, end of job marker.

That causes the DSC parser to reset, which causes it to reinitialise on the next job, which picks up the 'Creator' comment (all the files having been produced from the Windows Pscript5.dll driver) and creates a new operator. When the number of operators defined exceeds the size of the operator table, a limitcheck occurs.

Removing the control-D bytes causes the file to run to completion.

The simplest solution seems to me to be not to concatenate files. As an alternative, prepending this:

<004> cvn {} bind def

redefines the Control-D eoj marker as a no-op and the file runs to completion.

I did some regressing testing and 9.10 works fine.  Does 9.14 have a different DSC parser? Also the <004> cvn {} bind def – would I inject that into the Postscript on the first file or every file.

thanks

(In reply to DKM from comment #3)
> I did some regressing testing and 9.10 works fine.  Does 9.14 have a
> different DSC parser?

No, but its not the DSC parser as such but the fact that the DSC parser gets re-initialised on every 0x004 character in the data stream (outside of binary objects such as images and fonts obviously)


> Also the <004> cvn {} bind def – would I inject that
> into the Postscript on the first file or every file.

It redefines the routine to do nothing, you only need to do it once. You don;t even need to put it on any file, you can supply it on the command line.

Please don't change the status of the bug.

Thanks for the response, I’m not familiar with using that command on the command line.  Do you have a sample?  Also is it a defect in 9.14 because 9/10 and 9.09 both work without it.

(In reply to DKM from comment #5)
> Thanks for the response, I’m not familiar with using that command on the
> command line.  Do you have a sample?

See the documentation on -c and -f

>  Also is it a defect in 9.14 because
> 9/10 and 9.09 both work without it.

Not in my opinion. Concatenating PostScript files is a Bad Idea, and liable to fail for any number of reasons.

trying to implement your suggestion to use <004> cvn {} bind def. I'm getting an error trying to use the command line
gswin32c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE#pdfwrite -dCompatibilityLevel#1.4 -sOutputFile#"%2" -f"%1" -c .setpdfwrite cvn {} bind def setdistillerparams

Getting unrecoverable error, exit code 1
ERROR: stackunderflow
OFFENDING COMMAND: cvn
OPERAND STACK:

(In reply to DKM from comment #7)
> trying to implement your suggestion to use <004> cvn {} bind def. I'm
> getting an error trying to use the command line
> gswin32c -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE#pdfwrite
> -dCompatibilityLevel#1.4 -sOutputFile#"%2" -f"%1" -c .setpdfwrite cvn {}
> bind def setdistillerparams

Frankly this is nonsense. It isn't a command line, its part of a batch file, you should start with the commend line (command shell if you like) and only try and turn it into a batch file after you have it working.

I have no idea what the %2 and %1 batch parameters are supposed to be, but you haven't added what I suggested, the <004> is missing, the proposed change "<004> cvn {} bind def" follows the -c, but I see that before that you have a "-f %1" which I take to be the filename, so it'll run the file before it gets to the -c etc.

If you want it to have any effect, it must precede the input file.