Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
Hi Jerome, Am Montag, den 23.02.2009, 23:58 +0100 schrieb a...@librelogiciel.com: Unfortunately they've decided against fixing this problem upstream finally, see their BTS link above. If you know for sure these datas were produced with foomatic maybe you could see if its authors would mind putting their Kyocera Prescribe code sequence as part of a @PJL COMMENT as proposed, and if Kyocera printers would still support such a construct (I don't have such a printer so I can't tell) The .ppd file is the one downloaded from http://kyoceramita.com/download/ for Kyocera_FS-C5300DN (German, that is at http://www.kyoceramita.eu/index/service/dlc.false.driver.FSC5300DN._.EN.html the very bottom. I have little hope to get them change their .ppd, especially as it does the job (provide printing). As an alternative just create a new ticket on http://trac.pykota.com, and I'll try to add some filtering facility to pkpgcounter. I’d do that, but http://trac.pykota.com/register does not seem to work... 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
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
On Tue, Feb 24, 2009 at 11:02:10AM +0100, Joachim Breitner wrote: The .ppd file is the one downloaded from http://kyoceramita.com/download/ for Kyocera_FS-C5300DN (German, that is at http://www.kyoceramita.eu/index/service/dlc.false.driver.FSC5300DN._.EN.html the very bottom. I have little hope to get them change their .ppd, especially as it does the job (provide printing). Of course. As an alternative just create a new ticket on http://trac.pykota.com, and I'll try to add some filtering facility to pkpgcounter. I’d do that, but http://trac.pykota.com/register does not seem to work... It should work, but there's probably some caching issue between your web browser and the server. Try to force reload. bye, and thx again for your feedback. Jerome Alet signature.asc Description: Digital signature
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
Hi, On Mon, Feb 16, 2009 at 06:43:26PM +0100, Joachim Breitner wrote: Am Montag, den 16.02.2009, 18:39 +0100 schrieb a...@librelogiciel.com: On Mon, Feb 16, 2009 at 06:23:56PM +0100, Joachim Breitner wrote: I’d expect them so see the latter case (PS interpreter), but from a user point of view, it doesn’t matter much :-) It seems the bug report was accepted by GhostScript's upstream developers, and there's a patch, please see : http://bugs.ghostscript.com/show_bug.cgi?id=690291 Hoping this fixes your problem. ok, even better, thanks for taking care of this! Unfortunately they've decided against fixing this problem upstream finally, see their BTS link above. If you know for sure these datas were produced with foomatic maybe you could see if its authors would mind putting their Kyocera Prescribe code sequence as part of a @PJL COMMENT as proposed, and if Kyocera printers would still support such a construct (I don't have such a printer so I can't tell) As an alternative just create a new ticket on http://trac.pykota.com, and I'll try to add some filtering facility to pkpgcounter. (you can do both if you want) bye Jerome Alet signature.asc Description: Digital signature
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
Hi, Am Sonntag, den 15.02.2009, 18:37 +0100 schrieb a...@librelogiciel.com: On Sun, Feb 15, 2009 at 03:05:04PM +0100, Joachim Breitner wrote: 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. You may be correct. However, simply take pykota and pkpgcounter out of the equation, and use instead the cups-pdf backend for CUPS, written by Volker C. Behr. I bet you'll have the very same problem (untested, but from reading its source code it launches gs and doesn't strip out any PJL). Hmm. I’d assume that for cups-pdf, you would not use the .ppd file for a real printer model (a kyocera printer in my case), so cups would not add the PJL header, and send the plain PS. At least I assume so, as otherwise cups-pdf would not work :-) This means this bug should be reported to any similar software, duplicating efforts needlessly. Really it depends if we consider gs is emulating a printer or is only a PS interpreter. In the first case it should recognize PJL's Universal Exit Language (ESC%-12345X) because the document, as seen from a printer supporting PJL and PostScript, is perfectly correct. In the latter case it doesn't need to. Not sure what GhostScript developers think about this problem. I'm not 100% against implementing a workaround for this problem, but I'd prefer that ghostscript developers handle this situation, otherwise other developers would have to create similar workarounds for their own software. I’d expect them so see the latter case (PS interpreter), but from a user point of view, it doesn’t matter much :-) 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
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
On Mon, Feb 16, 2009 at 06:23:56PM +0100, Joachim Breitner wrote: I’d expect them so see the latter case (PS interpreter), but from a user point of view, it doesn’t matter much :-) It seems the bug report was accepted by GhostScript's upstream developers, and there's a patch, please see : http://bugs.ghostscript.com/show_bug.cgi?id=690291 Hoping this fixes your problem. bye Jerome Alet signature.asc Description: Digital signature
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
Hi, Am Montag, den 16.02.2009, 18:39 +0100 schrieb a...@librelogiciel.com: On Mon, Feb 16, 2009 at 06:23:56PM +0100, Joachim Breitner wrote: I’d expect them so see the latter case (PS interpreter), but from a user point of view, it doesn’t matter much :-) It seems the bug report was accepted by GhostScript's upstream developers, and there's a patch, please see : http://bugs.ghostscript.com/show_bug.cgi?id=690291 Hoping this fixes your problem. ok, even better, thanks for taking care of this! Although I’ll stick to my work-around on the Debian stable machine that I’m using for now. I’m filing a bug against the ghostscript Debian package to link to the upstream bug, and make this bug depend on that, so this is properly tracked. Greetings, 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
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
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
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
On Sun, Feb 15, 2009 at 03:05:04PM +0100, Joachim Breitner wrote: 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. You may be correct. However, simply take pykota and pkpgcounter out of the equation, and use instead the cups-pdf backend for CUPS, written by Volker C. Behr. I bet you'll have the very same problem (untested, but from reading its source code it launches gs and doesn't strip out any PJL). This means this bug should be reported to any similar software, duplicating efforts needlessly. Really it depends if we consider gs is emulating a printer or is only a PS interpreter. In the first case it should recognize PJL's Universal Exit Language (ESC%-12345X) because the document, as seen from a printer supporting PJL and PostScript, is perfectly correct. In the latter case it doesn't need to. Not sure what GhostScript developers think about this problem. 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). pkpgcounter should handle number of copies specified as PJL, but there's currently a bug in it, preventing such PJL statements inserted before the very first page to be taken into account (see http://trac.pykota.com/ticket/2) But as you said this is an entirely different problem. It seems someone reported the same problem in 2004 : https://lists.linux-foundation.org/pipermail/printing-foomatic/2004/001983.html I'm not 100% against implementing a workaround for this problem, but I'd prefer that ghostscript developers handle this situation, otherwise other developers would have to create similar workarounds for their own software. Is it possible with Debian's BTS to have them involved in this discussion ? bye Jerome Alet signature.asc Description: Digital signature
Bug#515184: [Python-apps-team] Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
On Sun, Feb 15, 2009 at 06:37:42PM +0100, a...@librelogiciel.com wrote: I'm not 100% against implementing a workaround for this problem, but I'd prefer that ghostscript developers handle this situation, otherwise other developers would have to create similar workarounds for their own software. Is it possible with Debian's BTS to have them involved in this discussion ? Sure. Just mail them and CC the bug's e-mail address, as you are doing now. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
Package: pkpgcounter
Version: 3.50-4
Severity: normal
Tags: patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
when trying to get ink accounting working here, it failed because the
file that CUPS sent to pkpgcounter (via pykota) contained a PJL header:
$ pkpgcounter -cGC /var/spool/cups/tmp/cupspykota-Insterdrucker-nomeata-21
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:1156/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
Command failed : 'gs -sDEVICE=tiff24nc -dPARANOIDSAFER -dNOPAUSE -dBATCH
-dQUIET -r72 -sOutputFile=/tmp/tmp1TpTnP
/var/spool/cups/tmp/cupspykota-Insterdrucker-nomeata-21'
A test file is appended.
I could work around by adding a PJL-removing script to the package and adding a
second totiffcommand that tries it with that, but I assume that is not the
proper solution.
Thanks,
Joachim
- -- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmW00sACgkQ9ijrk0dDIGwYMgCfcwELg9lGocwWhviGATeIxW1b
bb4AoKsXWiR9kkSQv7auiQ80gW7uSAzL
=4AN/
-END PGP SIGNATURE-
diff -u pkpgcounter-3.50/debian/changelog pkpgcounter-3.50/debian/changelog
--- pkpgcounter-3.50/debian/changelog
+++ pkpgcounter-3.50/debian/changelog
@@ -1,3 +1,9 @@
+pkpgcounter (3.50-4.insterburg1) unstable; urgency=low
+
+ * Make pkpgcounter handle pjl wrapped postscript
+
+ -- Joachim Breitner nome...@debian.org Sat, 14 Feb 2009 14:58:25 +0100
+
pkpgcounter (3.50-4) unstable; urgency=low
* debian/control:
only in patch2:
unchanged:
--- pkpgcounter-3.50.orig/setup.py
+++ pkpgcounter-3.50/setup.py
@@ -68,6 +68,6 @@
author_email = a...@librelogiciel.com,
url = http://www.pykota.com/software/pkpgcounter/;,
packages = [ pkpgpdls ],
- scripts = [ bin/pkpgcounter ],
+ scripts = [ bin/pkpgcounter , bin/unpjl ],
data_files = data_files)
only in patch2:
unchanged:
--- pkpgcounter-3.50.orig/bin/unpjl
+++ pkpgcounter-3.50/bin/unpjl
@@ -0,0 +1,8 @@
+#!/usr/bin/perl
+
+$ps=0;
+while () {
+ print if $ps;
+ $ps = 0 if /%%EOF/;
+ $ps = 1 if /PJL ENTER LANGUAGE=POSTSCRIPT/;
+}
only in patch2:
unchanged:
--- pkpgcounter-3.50.orig/pkpgpdls/postscript.py
+++ pkpgcounter-3.50/pkpgpdls/postscript.py
@@ -30,7 +30,8 @@
class Parser(pdlparser.PDLParser) :
A parser for PostScript documents.
-totiffcommands = [ 'gs -sDEVICE=tiff24nc -dPARANOIDSAFER -dNOPAUSE -dBATCH -dQUIET -r%(dpi)i -sOutputFile=%(outfname)s %(infname)s' ]
+totiffcommands = [ 'gs -sDEVICE=tiff24nc -dPARANOIDSAFER -dNOPAUSE -dBATCH -dQUIET -r%(dpi)i -sOutputFile=%(outfname)s %(infname)s' ,
+ 'unpjl %(infname)s | gs -sDEVICE=tiff24nc -dPARANOIDSAFER -dNOPAUSE -dBATCH -dQUIET -r%(dpi)i -sOutputFile=%(outfname)s -' ]
required = [ gs ]
openmode = rU
format = PostScript
%-123...@pjl
@PJL JOB NAME = maisbrot.ps DISPLAY = 21 nomeata maisbrot.ps
@PJL RDYMSG DISPLAY = 21 nomeata maisbrot.ps
@PJL SET KTRAPPING=2
!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;%-123...@pjl
ENTER LANGUAGE=POSTSCRIPT
%!PS-Adobe-3.0
%%HiResBoundingBox: 0.00 0.00 344.126001 536.100024
%.
%%Creator: ESP Ghostscript 707 (pswrite)
%%CreationDate: 2005/08/12 00:20:41
%%DocumentData: Clean7Bit
%%LanguageLevel: 2
%%For: (nomeata)
%%Title: (maisbrot.ps)
%%Requirements: duplex
%RBINumCopies: 1
%%Pages: (atend)
%%BoundingBox: (atend)
%%EndComments
%%BeginProlog
% This copyright applies to everything between here and the %%EndProlog:
% Copyright 2003 artofcode LLC and Easy Software Products, all rights reserved.
%%BeginResource: procset GS_pswrite_2_0_1001
/GS_pswrite_2_0_1001 80 dict dup begin
/PageSize 2 array def/setpagesize{ PageSize aload pop 3 index eq exch
4 index eq and{ pop pop pop}{ PageSize dup 1
5 -1 roll put 0 4 -1 roll put dup null eq {false} {dup where} ifelse{ exch get
exec}
{ pop/setpagedevice where
{ pop 1 dict dup /PageSize PageSize put setpagedevice}
{ /setpage
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
On Sat, Feb 14, 2009 at 03:21:00PM +0100, Joachim Breitner wrote: Package: pkpgcounter Version: 3.50-4 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, when trying to get ink accounting working here, it failed because the file that CUPS sent to pkpgcounter (via pykota) contained a PJL header: $ pkpgcounter -cGC /var/spool/cups/tmp/cupspykota-Insterdrucker-nomeata-21 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:1156/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 Command failed : 'gs -sDEVICE=tiff24nc -dPARANOIDSAFER -dNOPAUSE -dBATCH -dQUIET -r72 -sOutputFile=/tmp/tmp1TpTnP /var/spool/cups/tmp/cupspykota-Insterdrucker-nomeata-21' A test file is appended. I could work around by adding a PJL-removing script to the package and adding a second totiffcommand that tries it with that, but I assume that is not the proper solution. 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. hth Jerome Alet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515184: pkpgcounter failes to read PJL-wrapped postscript
On Sat, Feb 14, 2009 at 04:13:12PM +0100, a...@librelogiciel.com wrote: This is a bug in GhotScript, not in pkpgcounter as can be seen below : In any case, if you want a workaround to be considered for a future release, please create a ticket asking so on http://trac.pykota.com thx in davance Jerome Alet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
