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

[alet at 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).

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/python-apps-team/attachments/20090215/754a93f9/attachment.pgp