UNIX System Administration Handbook - Evi Nemeth [423]
rw: device open mode
If a printer can send status information back to the host through its device file, the Boolean variable (rw) should be specified to request that the device be opened for both reading and writing. Read-write mode is useful for accounting and status reporting, and some filters require it.
af: accounting file
Even if you don’t intend to charge for printer use, printer accounting can give you a good feel for how your printing resources are being consumed. We recommend that you enable accounting for all shared printers. You do that simply by specifying an accounting file. The file need only be specified and present on the machine to which the printer is physically connected, since accounting records are not written until a job is actually printed.
For a summary of accounting information, use the pac command. By convention, printer accounting data files are usually called /var/adm/printer-acct. They list the number of pages printed for each job (usually a lie), the hostnames where the jobs originated, and the usernames of the jobs’ owners.
It is the responsibility of the printer’s input filter to generate accounting records. On PostScript printers, unless the filter actually queries the printer for its page count before and after the job, the page counts are extremely suspect.
mx: file size limits
The mx variable sets a limit on the amount of data that can be spooled at one time. File sizes are meaningless for printers other than line printers, however. Small PostScript or PCL files could print hundreds of pages of garbage. This disconnect between file size and page length is particularly evident when students try to print the compiled binary versions of their programming assignments.
On some systems, mx defaults to some value other than 0 (no limit), and an explicit mx#0 entry is necessary to allow large jobs. Note that mx is a numeric field, so the entry mx=0 is incorrect.
If you really need to control how many pages people can print, you will need to use custom filters or switch to LPRng.
rm and rp: remote access information
In most situations, you will want to access a printer from more than one machine on the network. Even if the printer is a network device, you should pick a single machine to be responsible for communicating with it. All other machines should forward jobs to the designated handler. This setup allows lpd to take care of queuing the jobs in order rather than having several machines constantly squabbling over control of the printer. It also gives you a single place to look when printing is not working.
Remote machines (machines that are not directly connected to the printer) have a simple printcap entry that tells where to send the job, as in the example on page 733. The rm variable specifies the machine to which jobs should be sent, and the rp variable gives the name of the printer on that machine. The details of remote printing are described in the OS-specific sections starting on page 729.
The fact that printcap entries are different for local and remote printers necessitates a bit of subterfuge on the part of the system administrator if one printcap file is to be shared among several machines. The fix is to make the local and remote names for a printer distinct; for example, howler-lw-local and howler-lw. This configuration makes howler-lw a “remote” printer even on the machine where it actually lives, but that’s perfectly OK. You will have to refer to howler-lw-local if you want to use the lpc command, however.
of, if, nf: printing filters
Filters serve a number of purposes. The default printing filter (usually /usr/lib/lpf) fixes up various nonprinting sequences and writes out an accounting record, if appropriate. Unfortunately, filters are not standardized. Any of several filter packages could do the same job, but each vendor tends to have unique filters.
If you have a character-only printer, you don’t really need to be concerned with filters. If you have a laser printer, typesetter, or plotter, the necessary filters