Last modified on $Date$ To account for pages or eventually ink usage PyKota doesn't currently account for ink usage, it only accounts pages. To account for ink usage, you should use PrintBill instead. , you must plug your accounting system somewhere into the printing system you use, be it either CUPS or LPRng. One way to do this without having to modify the printing system itself, is by using a filter. A filter is a computer program which takes data in one format as its input, and outputs the same data but transformed into another format. CUPS already contains many filters. For example there's one filter named pstops which accepts PostScript data as its input, and, as its name implies, outputs PostScript data too, but after having eventually rearranged the pages to fit several pages on a single sheet of paper, or other manipulations like that. The pstops filter described above is also in charge of doing basic page accounting, but PyKota currently doesn't use this facility since it may prove to be unreliable depending on the drivers used or if a paper jam occurs for example. LPRng can also use filters, one often used in combination with LPRng is magicfilter which can convert different input formats to native printers languages like PostScript or ESC/P2. So to do its own accounting, PyKota has its own filters, for CUPS it's named cupspykota, which is in fact a CUPS backends wrapper, and for LPRng it's named ########## TODO ########## . The procedure to plug the correct filter into your printing system is described in the chapter. Currently with a CUPS internal accounting mechanism, the pstops filter can be bypassed. That's why PyKota uses its own backend. The cupspykota backend wrapper ensures that jobs can't bypass the filtering mechanism, so you can use any printer with any driver and any command line option, and you can be sure that your print job will be correctly accounted for. When used with an LPRng backend, the accounting filter is not defined the same way input filters are, so the problem described above doesn't exist, and PyKota may work with non-postscript printers, provided they can report their page counter and you know how to retrieve it. When you submit a print job, PyKota's accounting mechanism is automatically launched by your printing system, so it has to detect which system you are using (CUPS or LPRng) and behave like if it was specifically designed for your printing system. Fortunately there's not a lot of differences, the more important one is the exit codes used to tell the printing environment if a job has to be accepted or rejected. When using the hardware accounting method, the cupspykota CUPS backend asks the printer for its internal page counter at the start and at the end of the print job, and computes the values' difference so accounting is done immediately. When using the software accounting method, and if the user is still allowed to print, the command you specified is launched with the job's data on its standard input. Your command must print the job's size in number of pages on a single line on its standard output. This number is then read by PyKota and used to update the current user's quota information. Of course checks are also done like with the hardware accounting method, to see if the current job is allowed to be printed or not. If a problem occurs, it is logged either to the filter's standard error or to the system logger, depending on your preferences in PyKota's configuration files. Also if a print quota is reached you may choose if the administrator, the user, both or no-one will receive an email message explaining the situation and proposing a solution. You can even configure another action instead of sending email messages if you want.