Currently gs doesn't seem to ignore PJL statements located between PJL's Universal Exit Language sequence (<ESC>%-12345X) and the "@PJL ENTER LANGUAGE=POSTSCRIPT", but fails when presented with a PostScript print file containing such PJL code, which is valid for any physical printer supporting both PJL and PostScript. It seems several other software would greatly benefit from gs supporting such PJL constructs, or instead each of them would have to implement a workaround, which duplicates code needlessly : having gs read but ignore these statements instead of failing would solve the problem for everyone. Please see the discussion attached to Debian bug #515184 at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515184 We'd be glad to receive your opinion on this problem. TIA
Please attach a sample file for which Ghostscript misbehaves. There is code in Resource/Init/gs_init.ps that skips @PJL commands, and I regularly process MANY files from users and customers that are prefixed with PJL junk.
Created attachment 4797 [details] Test case It seems the problem is due to the !R!... byte sequence, I think this is Kyocera's Prescribe page description language. I think the file was generated with foomatic, but I'm not sure since I'm not the original Debian bug reporter for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515184
Created attachment 4798 [details] patch here's a possible approach: look ahead for (LANGUAGE=POSTSCRIPT) in @PJL command and skip everything before (LANGUAGE=POSTSCRIPT), otherwise just skip to the end of the line as before. Current filter buffer sizes limit looking ahead to 1023 bytes. Although the patch fixes reported bug, larger PCL fragments will break.
There's another approach: detect "@PJL JOB NAME" operation and skip anything till "LANGUAGE=POSTSCRIPT" using currentfile 0 (LANGUAGE=POSTSCRIPT) filter flushfile
I consider this file as invalid PostScript. The data sequence beginning with !R!CRES... is not valid PostScript, nor is it a PJL command. Alex's suggestion in comment #4 won't work since PJL can have spaces between tokens. I think this is a case where the file should be fixed by pre-filtering to remove the non-PS data sequence before the valid PS. This can be done with perl, sed or awk, but I am against adding some kind of partial solution to Ghostscript that might break other files that have PJL headers. Of course, since full source is provided an individual is welcome to modify their local copy to do as Alex suggests.