IPP backend and page accounting

Helge Blischke h.blischke at srz.de
Tue Aug 16 04:22:30 PDT 2005

"John A. Murdie" wrote:
> I note that the CUPS IPP backend does not log the correct number of pages printed on an HP LaserJet 8150 with 20041013 (MB7.119) firmware, or on an HP LaserJet 9000 with 20040809 (02.516.0) firmware (and other printers?) when either a PostScript program sent to the printer makes use of the:
> /#copies N def
> PostScript assignment, or uses a loop:
> 1 1 3 {
>         ...
>         showpage
> } for
> In each case, the number of multiple copies printed is not taken into account - i.e.. the number of page impressions ('sides') logged in page_log is the number of pages in the document, not the number printed.
> I can't find this behaviour documented anywhere. I've assumed the normal English meanings for 'sheet' (a sheet of paper, which has two sides) and 'page' (which goes on one side of a sheet, a sheet being printed on both sides if duplexing is turned on, except for the last page when it falls on a new sheet). Even if I'm wrong about these definitions, the printers' failure to count multiple copies is still a problem.
> I see that the IPP backend (ipp) obtains the IPP spec (IPP 1.1 RFC 2911 page 123) 'job-media-sheets-completed' value from the printer (note that that is 'sheets', not 'page impressions'). The previous page of the spec. notes that the 'job-media-sheets' "value MUST include the multiplicative factors contributed by specified by the 'copies' attribute, and a 'number of copies' instruction embedded in the document data, if any."
> If this is also the case for 'job-media-sheets-completed', does this mean that the IPP implementation of the two printers is at fault? I could perhaps sidestep this unwanted behaviour (if not a bug) by using accsnmp, but it seems far neater just to use the CUPS ipp backend if at all possible. Accurate page accounting - and charging - is important to me.
> I'm also peturbed by the RFC's specification of 'job-media-sheets-completed' as the number of "media-sheets completed marking and stacking for the entire job so far whether those sheets have been processed on one side or both"; while I may wish to count the number of sheets (pieces of paper) used for a job, I really wish to know the number of page impressions made, which might be twice the number of sheets if the job has specified duplexing. The definition of 'job-impressions-completed' is promising: "the number of impressions completed for the job so far." However, the definition of 'job-impressions' says "this value MUST NOT include the multiplicative factors contributed by the number of copies specified by the 'copies' attribute, independent of whether the device can process multiple copies without making multiple passes over the job or document data ...".
> It seems that we can't win; how do we get a pagecount that is the total number of page impressions made for a job, with PostScript-commanded multiple copies taken into account?
> John A. Murdie
> Department of Computer Science
> University of York
> UK

Well, not a complete and exhaustive answer but only a few hints:

(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.

(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).

(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.
    Your example from above coearly is not DSC compliant.


Helge Blischke
SRZ Berlin | Firmengruppe besscom

More information about the cups mailing list