According to Scott Wellman:
What I am looking for is a print accounting package that would run preferably on either OpenBSD or Fedora. Some of the features that would be helpful are:
- Support for Linux, Mac OSX, and windows workstations
- Some type of charging system for each page the student prints. For example, 10 cents a page
- Web interface for management purposes
Once again, any recommendations would be greatly appreciated.
I looked into this over a year ago, when we were looking to replace our current print spooling system, which is based on the (original?) BSD lpr/lpd spooler running on SunOS 4.x (yes, that's before Solaris 2.x!), with a print filter called papif (part of the CAP system that provided AppleTalk support), and a wrapper script that I cobbled together to implement print quotas (but not actual charge-back to accounts). As you might imagine, there were a few reasons why we'd want to migrate to something newer...
At the time, the two "packaged" solutions that seemed to be the most developed, including (web-based) user and administrator interfaces, were PyKota (http://www.librelogiciel.com/software/PyKota/action_Presentation) and Printbill (http://ieee.uow.edu.au/~daniel/software/printbill/).
Neither one was quite right for us, so I was actually thinking of cobbling something together (again), based on LPRng (http://www.lprng.org/) with the IFHP filter (http://lprng.sourceforge.net/#ifhpdist), since it provides rudimentary accounting (http://lprng.sourceforge.net/DISTRIB/OLD/CTI-ifhp-2.2.2/README.accounting). Its accounting can be made more workable with the "IFHP Accounting Sanatiser" [sic] (http://www.mail-archive.com/lprng@lprng.com/msg04974.html). However, this wouldn't provide the actual charging system, web interfaces, etc.
So, in the end, I'm still waiting for something better to come along, though I haven't looked lately. (It became a lower priority task again.)
There does seem to be two different phylosophies about how best to do printer accounting: either (a) estimate page/resource usage by test-running the job through an emulator (like Ghostscript) before actually printing anything, or (b) printing the jobs first, then querying the printer itself to get the page count.
Printbill only supports (a). The claimed advantages are that it doesn't rely on any printer-dependent feature in order to get actual page counts (hence working with any printer), you can estimate not only page counts but toner usage (though this might be a rather crude estimate), and you can decide ahead of time whether the user's account has enough quota left to print this job or not. Printbill also only works with LPRng.
My own preference is for option (b), which is the way LPRng's IFHP filter works. I don't trust estimates, and the idea of charging before the job is actually run is potentially problematic (e.g. what if the printer jams or resets, and pages are ruined or not actually printed?). Getting the actual usage stats from the printer is the most reliable, and if there are errors, they are likely to work in the user's favour (hence less complaints and exception handling).
I can't remember which way PyKota worked, but it seemed to be the most flexible of the packages I had seen. It works with either LPRng or CUPS, and seemed like the most complete solution. (It's been a while since I looked at it, though, so I can't remember exactly what it provided, nor why I had decided not to go with it.)
Keep in mind, too, that this was all over a year ago, and there may be a better solution out there now, that I'm not aware of. Good luck with your search, and if you find anything else, please let us know.