In essence, a printer accounting system will keep track of the number of pages printed for later retrieval. Sometimes it's very useful to know that Timmy printed 697 pages Friday at noon. The well-known print accounting systems will provide this information, and more. The idea behind these printer accounting systems is that they will keep track of a per-user quota, or dollar amount, and deduct from that balance each time a page is printed. Printing is then denied if the user has no balance left from which to deduct the cost of the print job. This sounds easy to implement, but three open source packages do it quite differently.

We network and Unix folks don't really live in a bubble, but the only decent software for accomplishing printer accounting runs on Unix-based systems. So if you need your Windows printers to have accounting, you'll have to relay jobs through a CUPS server (or pay for an accounting system that works in Windows). There are a couple of approaches, but they all rely on print jobs running through the software before being sent to the printer. The accounting software will either process the job with ghostscript and figure out how many pages should print, or it will ask the printer before and after the print job to calculate how many pages have printed. Asking the hardware is the most foolproof method, since knowledgeable users can theoretically write their own postscript and trick ghostscript into thinking a 100-page job is only 10 pages. This isn't very likely, but you never know--users never cease to amaze their admins, and asking the printer about the actual page count gets around the issue of a printer jam, where the user's document didn't fully print.

Our open source options are printbill, pykota, and printquota. Printquota doesn't support the ability to just keep track of the number of pages, ignoring a user's balance. This is the main reason it simply won't work for many people. The two front-runners are pykota and printbill. They both accomplish printer accounting, but with feature-sets that vary.

Pykota is written in Python, and implements a real CUPS backend. In the CUPS configuration you simply specify cupspykota://socket/<printer> for the device URL. That's it; now all print jobs for the printer will filter through pykota. If printing is denied, the cupspykota backend will return an error, and the job will be rejected. If users aren't given a quota (because you're just trying to keep track of page counts) then printing will always be allowed after the number of pages and printer name are logged.

Printbill doesn't actually support CUPS (only LPRng), but it does implement a few features that make it stand out from the crowd of three. Printbill's author really understands Postscript, and it shows: printbill can calculate the percentage of ink coverage for each page printed, and then charge accordingly. This is an exceedingly advanced feature, but it comes at a cost: CPU usage. If you're really concerned about the rising cost of toner cartridges and you don't want to be unfair to the users printing only text (which typically covers less than 5% of the page with ink), then printbill is the way to go. Of course, print jobs will be delayed longer with all this processing, and you have to use LPRng.

Also on Unix Printing Printing with CUPS, Part 1 Printing with CUPS, Part 2

Pykota, on the other hand, does a small bit of software processing for a different reason. When the print job enters the cupspykota backend, the job is run through ghostscript to get an estimate of the page count. The user is then looked up in LDAP or a Postgres database, and her balance is consulted to see if the job can be printed. If the user is limited by her quota, the backed will either reject the job or move on to the next step. When printing begins, the job is sent back into CUPS, but not before the backend queries the printer to obtain the current page count. Using SNMP, or any method you define in the configuration file, pykota will obtain the current page counter value from the printer. This functionality assumes that your printer responds to SNMP (define) , and that it's on the network. Directly attached printers will not work with pykota.

Pykota will send SNMP queries to the printer every second, checking to see if the job has completed. When it completes, the new page counter is compared to the old one, and the difference is recorded. Asking the printer for its counter is the only foolproof accounting method, since users will be accurately charged n the event of paper jams or similar problems. If there is a discrepancy between the hardware amounts versus the pre-computed software-based page count, pykota will log this information.

Both viable open source solutions have a Web-based interface for administration, and pykota even has a user-based Web page that allows users to check their balance. The pykota database itself can be queried for a user's balance too, making it very easy to write your own websites or integrate pykota data into intranet sites.

For quickly setting up a solution to the problem of recording how much each user prints, pykota makes that easy. It comes with scripts to populate the database, and the install is just a few simple steps. The author always responds to questions, both on IRC and in the forums. If you run into a problem, help isn't far away. Pykota is also a complete solution to allow you to limit users to printing only certain amount on certain printers. The configuration options are endless, since you can replace many functions of pykota by just making your own scripts.

Finer-grained analysis of print jobs can be gained by using printbill, but unless you really need to know precisely how much ink was used for each print job, pykota's features give it the clear advantage.