Bug 690291 - Handling of the PJL's Universal Exit Language sequence
Summary: Handling of the PJL's Universal Exit Language sequence
Status: RESOLVED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: 0.00
Hardware: All Linux
: P4 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-15 10:56 UTC by Jerome Alet
Modified: 2009-02-19 08:21 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
Test case (21.33 KB, application/octet-stream)
2009-02-15 23:23 UTC, Jerome Alet
Details
patch (601 bytes, patch)
2009-02-16 08:20 UTC, Alex Cherepanov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.