gmane.comp.printing.pykota.user

| 16 Jul 12:18

duplex accounting

Hi Jerome,

Another feature that would be nice, would be the possibility of having
different prices for duplex printings. I know that most likely it would
always charge you for an even number of pages, because that's what the
printer actually counts. To go around this, you could compare the software
accounting with the hardware accounting, and charge by the lesser value.
From the logs, you are already doing this comparison:

Beware : computed job size (2) != precomputed job size (1)

I know it remains the fact of detecting that a job is duplex...

Anyway, it's just a suggestion, that I hope you consider introducing in the
next release 

Best regards,
Elio

headers

Jerome Alet | 16 Jul 12:32

Re: duplex accounting

On Wed, Jul 16, 2008 at 11:18:58AM +0100, Élio Coutinho wrote:
> Hi Jerome,
> 
> Another feature that would be nice, would be the possibility of having
> different prices for duplex printings. I know that most likely it would
> always charge you for an even number of pages, because that's what the
> printer actually counts. To go around this, you could compare the software
> accounting with the hardware accounting, and charge by the lesser value.
> >From the logs, you are already doing this comparison:
> 
> Beware : computed job size (2) != precomputed job size (1)
> 
> I know it remains the fact of detecting that a job is duplex...
> 
> Anyway, it's just a suggestion, that I hope you consider introducing in the
> next release 

I hope to do so, but this has proven to be difficult to do reliably. In 
particular if someone tries to cheat and asks for duplex printing onto
a simplex-only printer, the printer will probably print in simplex mode
but the job datas will still contain duplex markers. In this case I
don't want PyKota to be cheated, and I'm not yet sure how to do unless
of course we force people who want duplex accounting to use hardware
accounting.

What people currently do is create two different print queues, one for
duplex mode and the other one for simplex, ensure people can't print
in simplex to the duplex queue (remove unwanted options from the PPD file),
and set different costs per page on both. This is more labor intensive of
course, but you can explain to users why they should prefer one queue

(Continue reading)

headers

| 16 Jul 13:35

Re: duplex accounting

On Wed, Jul 16, 2008 at 11:32 AM, Jerome Alet <alet@...>
wrote:

> I hope to do so, but this has proven to be difficult to do reliably. In
> particular if someone tries to cheat and asks for duplex printing onto
> a simplex-only printer, the printer will probably print in simplex mode
> but the job datas will still contain duplex markers. In this case I
> don't want PyKota to be cheated, and I'm not yet sure how to do unless
> of course we force people who want duplex accounting to use hardware
> accounting.
>

Well, that's true. But, wouldn't a per printer variable like DuplexCapable
(true or false) solve this issue? You could assume every printer is simplex
only, unless that variable is set on a particular printer. I have no idea
how software accounting is done, so I might be missing something.

On my case, I'm forcing the move to pykota for it's hardware accounting
capabilities! They seem to be much more reliable on situations where the
software accounting is done, students get billed, and for some reason the
printer just discards the job. I have quite a few of these!

>
> What people currently do is create two different print queues, one for
> duplex mode and the other one for simplex, ensure people can't print
> in simplex to the duplex queue (remove unwanted options from the PPD file),
> and set different costs per page on both. This is more labor intensive of
> course, but you can explain to users why they should prefer one queue
> over the other one, and they'll easily understand (lower cost). This is
> especially true if you set the cost of the simplex queue to more than

(Continue reading)

headers

Jerome Alet | 16 Jul 13:52

Re: duplex accounting

On Wed, Jul 16, 2008 at 12:35:08PM +0100, Élio Coutinho wrote:

> That would generate a bunch of complaints! I suppose I'm better off giving
> up duplex for the time being, unless you reconsider )

The problem is not that I should reconsider adding support for 
duplex : I really WANT to add real support for duplex. The problem is 
that I'm not sure it's easy to make it difficult to be cheated. 

If you want to play with this you could use a shell script of your 
own which launches "pkpgcounter --debug $PYKOTADATAFILE", and adapt 
the number of pages based on pkpgcounter's output, which will tell 
you if duplex mode is used for PCL3/4/5 and PCLXL (aka PCL6). 
There's currently no support for PostScript, and an old bug 
(reported in December 2007) prevents this from working in all cases 
for PCL jobs... Then use your script in "accounter: software(yourscript.sh)" 
in pykota.conf 

As you can see support is partial at best.

bye

Jerome Alet