[Python-apps-team] Bug#515184: pkpgcounter failes to read PJL-wrapped postscript

[Joachim Breitner]

Hi Jerome,

thanks for your quick answer.

Am Samstag, den 14.02.2009, 16:13 +0100 schrieb alet at librelogiciel.com:
> On Sat, Feb 14, 2009 at 03:21:00PM +0100, Joachim Breitner wrote:
> This is a bug in GhotScript, not in pkpgcounter as can be seen below :
> 
> 
> jerome at lafrime:~$ gs testprintfile
> GPL Ghostscript 8.62 (2008-02-29)
> Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> Error: /undefined in
> !R!CRES;SCRN0;RGBL0,0;RGBL1,0;RGBL2,0;HUE0,0;HUE1,0;HUE2,0;HUE3,0;HUE4,0;HUE5,0;HUE6,0;LGHT0,0;LGHT1,0;SATU0;EXIT;
> perand stack:
> 
> Execution stack:
>    %interp_exit   .runexec2   --nostringval--   --nostringval--
>    --nostringval--   2   %stopped_push   --nostringval--
>    --nostringval--   --nostringval--   false   1   %stopped_push   1905
>    1   3   %oparray_pop   1904   1   3   %oparray_pop   1888   1   3
>    %oparray_pop   1771   1   3   %oparray_pop   --nostringval--
>    %errorexec_pop   .runexec2   --nostringval--   --nostringval--
>    --nostringval--   2   %stopped_push   --nostringval--
> Dictionary stack:
>    --dict:1151/1684(ro)(G)--   --dict:0/20(G)--   --dict:92/200(L)--
> Current allocation mode is local
> Current file position is 262
> GPL Ghostscript 8.62: Unrecoverable error, exit code 1
> jerome at lafrime:~$
> 
> pkpgcounter itself correctly parses the file with its internal parser,
> which doesn't try to interpret postscript (and so is limited of course) :
> 
> jerome at lafrime:~$ pkpgcounter --debug testprintfile
> Input file is in the 'PostScript' file format.
> 1 * page #1
> 1 * page #2
> Internal parser said : 2 pages
> 2
> jerome at lafrime:~$
> 
> but when pkpgcounter wants to convert this file to TIFF to do ink usage
> based print accounting, it uses GhostScript (because it was easier ;-)
> and so it fails because of GhostScript's own failure to read this file.
> 
> not sure how to reassign this bug to ghostscript, but this is what to
> do.
> 
> in any case, thanks a lot for your feedback.

I’m not sure if I can follow this argument. The attached print file was
not valid postscript, but rather postscript wrapped in an PJL print job,
if I understand it correctly. Therefore, it can not be a bug in
ghostscript.

OTOH, pkpgcounter tries to handle data as sent to the printer, therefore
passing this file to pkpgycounter (as done by pykota in my case) is
correct.

It seems that the included simple postscript parser is liberal enough to
skip the PJL header, but I think it’s still pkpgcounter’s responsibility
to make sure ghostscript understands the data it passes to it.

Also, it seems there might be PJL SET COPIES command that needs to be
taken in account (but this is probably a different issue, and I’m not
sure if it should be handled by pykota or pkpgcounter).

Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/python-apps-team/attachments/20090215/fadf4440/attachment.pgp