Bug 690291

Summary:	Handling of the PJL's Universal Exit Language sequence
Product:	Ghostscript	Reporter:	Jerome Alet <alet>
Component:	PS Interpreter	Assignee:	Default assignee <ghostpdl-bugs>
Status:	RESOLVED WONTFIX
Severity:	normal
Priority:	P4
Version:	0.00
Hardware:	All
OS:	Linux
Customer:		Word Size:	---
Attachments:	Test case patch

Description Jerome Alet 2009-02-15 10:56:56 UTC

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

Comment 1 Ray Johnston 2009-02-15 14:11:28 UTC

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.

Comment 2 Jerome Alet 2009-02-15 23:23:00 UTC

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

Comment 3 Alex Cherepanov 2009-02-16 08:20:55 UTC

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.

Comment 4 Alex Cherepanov 2009-02-17 07:29:47 UTC

There's another approach: detect "@PJL JOB NAME" operation and
skip anything till "LANGUAGE=POSTSCRIPT" using

  currentfile 0 (LANGUAGE=POSTSCRIPT) filter flushfile

Comment 5 Ray Johnston 2009-02-19 08:21:44 UTC

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.