[RndTbl] Print Accounting Software

[Gilbert E. Detillieux]

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:
> 
> 1. Support for Linux, Mac OSX, and windows workstations
> 2. Some type of charging system for each page the student prints. For
>    example, 10 cents a page
> 3. 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.

-- 
Gilbert E. Detillieux		E-mail:	<gedetil at cs.umanitoba.ca>
Dept. of Computer Science	Web:	http://www.cs.umanitoba.ca/~gedetil/
University of Manitoba		Phone:	(204)474-8161
Winnipeg, MB, CANADA  R3T 2N2	Fax:	(204)474-7609