Hi Jerome, thanks for your quick answer.
Am Samstag, den 14.02.2009, 16:13 +0100 schrieb a...@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 : > > > jer...@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 > jer...@lafrime:~$ > > pkpgcounter itself correctly parses the file with its internal parser, > which doesn't try to interpret postscript (and so is limited of course) : > > jer...@lafrime:~$ pkpgcounter --debug testprintfile > Input file is in the 'PostScript' file format. > 1 * page #1 > 1 * page #2 > Internal parser said : 2 pages > 2 > jer...@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 nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
