Written by Urs-Jakob Rüetschi
as part of the pracc project.
Printer accounting means to count who printed how much (and where and when). This information is useful for statistics and for charging printing costs to those who caused them. The unit of the counting is usually pages; some elaborate systems also include ink coverage.
There are two principles for charging costs:
The debit principle is ideal for students, the credit principle is more appropriate for staff members.
Pracc is the name of a collection of conventions and tools for printing with accounting. Specifically, pracc consists of
Pracc maintains a printing account per user who is subject to printer accounting. Optionally, group accounts can also be created and used by pracc. Printing accounts are simple plain-text files, so-called pracc files. For consistency, they should be modified only using the tools supplied with pracc. Each account works after the credit principle (unlimited printing) or the debit principle (printing only allowed until some minimal balance is reached). Accounts can be changed between the two billing principles.
The CUPS backend replaces the standalone programs netprint and print of earlier versions. It sends print jobs to printers on the network using the "AppSocket" (aka "JetDirect" or "Port 9100") protocol, which is supported by almost all network printers today. The backend only sends the print job if the job originator has enough credits. While printing, the backend tries to figure out how many pages are printed and charges the costs for those pages to the job originator's printing account.
Details about pracc can be found in the following documents:
Printers have not been designed with accounting in mind. There is no standard protocol for sending print jobs to a printer and having the printer reply with the number of pages printed (or the amount of ink used).
However, most printers can tell when it is time to replace the ink and how many pages they printed since having left the factory. The latter is implemented as a hardware register that is incremented for each page printed. It can be read using PostScript and/or PJL (but it cannot be changed other than by printing pages). This feature can be used for page counting. The PJL language, if supported by a printer, has a feature that reports the number of pages printed by a print job.
Unfortunately, both methods of page counting have problems. When using PostScript to read the page counter there is no way of determining when a print job has finished printing. To work around this problem, the page counter is read repeatedly till it stabilises, but this tends to slow down printing. Further, timeout and network problems can afflict both methods by disrupting communication between host and printer before the final pagecount could be read. As a result, printer accounting is never 100% accurate. Bear this in mind.
A problem specific to the "debit" approach to charging printing costs to users is that the resources used by a print job are available only after the job was printed, hence not at the time when we ought to decide whether or not this user should be allowed to print at all.
So why not use a software to count the pages in the print job? Wouldn't that also fix the problems mentioned above? Commercial printer accounting solutions use this approach. But what seems to be a simple and obvious solution has serious problems: such software uses resources on the server (especially CPU cycles), is usually easy to defeat by the gifted user, is an attractive way to break into a system, and last but not least: the number of pages in a print job is not the number of pages actually printed. Since counting pages in a print job tends to count more pages than get printed (think of paper jams), you are bound to get complaints...
My present implementation tries to determine both, the pages in the job and the pages actually printed, and uses whatever information is available when billing an account.