IPP backend and page accounting

[Helge Blischke]

"John A. Murdie" wrote:
> 
> > (1) the IPP stuff like "job-impressions-completed" etc. need a status query and some
> >     policy how to handle all this stuff. I suppose at least part of this will be
> >     implemented in CUPS 1.2.
> 
> I must find out what is expected from 1.2 - I've read some of the change logs of the weekly snapshots, but not found an "executive's overview" anywhere.
> 
> > (2) CUPS supports other backends but IPP; many of them provide no chance to get such
> >     information back (think of non PostScript pritners in this context).
> 
> Of course. That's one reason why PostScript printers which implement IPP (or, at a pinch, AppSocket) are so useful. (I have other reasons not relevant to the current discussion.) I won't have anything else here without a good reason, because I then have to make special accounting/charging arrangements for it.
> 
> > (3) As a conclusion, CUPS must provide means to account for pages by other means than
> >     getting this information back from the printer. The current design is to get this
> >     information from the pstops filter (or alternatively from a filter specified in the
> >     printer's PPD). This design heavily depends on the PS jobs being DSC compliant,
> >     especially the pages must be independent of one another.
> 
> But if one has a printer with an IPP implementation, it may return values for job-impressions-completed and job-media-sheets-completed (alas, this is not REQUIRED by RFC 2911), and the CUPS ipp backend issues an IPP_GET_JOB_ATTRIBUTES call asking for job-media-sheets-completed after the job completes. If the implementation is correct, then we'll get the sheet count we need in a secure manner - (though actually, we need the page impression count - it's easy to adjust for this in principle).
> 
> >     Your example from above coearly is not DSC compliant.
> 
> DSC allows #copies (in BeginSetup .. EndSetup), but not loops. People here also occasionally execute PostScript code which makes use of loops, however, and put calls to showpage and copypage in them. In each case, we must charge for all the output.
> 
> > Helge
> >
> > --
> > Helge Blischke
> > Softwareentwicklung
> > SRZ Berlin | Firmengruppe besscom
> > http://www.srz.de
> 
> Thanks for your reply, Helge; I'm appreciative of your obvious expertise in this area. I'll let people here know of what conclusion and solution I come up with - surely the HP printer IPP implementation can't be wrong, so perhaps my interpretation of RFC 2911 is at fault.
> 
> John A. Murdie
> Department of Computer Science
> University of York
> UK

I'd suggest to look into the current svn snapshot in order to know what will probably be
available with stable CUPS 1.2 and, if needed hack the current ipp backend to pass
the needed information to whatever you use for accounting.

BTW, we mostly use the hpnpf backend and, if needed, pass PostScript code to do the
accounting to the printer via the PPD's JobPatchFile and make use of the backchannel
information the hpnpf backend provides.

Helge

PS: If an approach like this seems acceptible to you, let me know; I easily could give you
some hints how to do that.

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de