UNIX System Administration Handbook - Evi Nemeth [424]
Filters are usually just shell scripts that call a series of translation programs. The filter program must accept the print job on standard input, translate the job to a format appropriate for the device, and send the result to standard output.
If the user does not specify a filter when executing lpr, either the if (input filter) or the of (output filter) will be used. The names are deceptive—both actually send data to a printer.
If the printcap entry lists an input filter but does not specify an output filter, the device will be opened once for each job. The filter will be expected to send one job to the printer and then exit.
Conversely, if an output filter is specified without an input filter, lpd will open the device once and call the filter program once, sending all the jobs in the queue in a big clump. This convention is OK for devices that take a long time to connect to; however, such devices are rare.
If both an input filter and an output filter are specified, the banner page will be sent to the output filter (and the output filter will be called even if banners are turned off). The input filter will be called to process the rest of the job. This combination of options is really too confusing for mere mortals. Avoid it. Use LPRng if you have complex filtering requirements.
If you have to write new filters, stick to using input filters, as they are easier to debug.
Input filters are called with numerous arguments, which vary among implementations. The most interesting are the username, host of origin, and accounting file name. If you want to do accounting for the printer, the input filter must generate the accounting records and append them to the accounting file. If you want to restrict access to a printer (for example, to deny printing to the user “guest”), the input filter must also take care of that since lpd has no built-in way to prevent individual users from printing.
To clarify the uses of filters, let’s look at a simple example of an input (if) filter. The example is for a PostScript printer connected to a serial line on the local machine:
#!/bin/csh -f
/usr/local/bin/textps $* | /usr/local/bin/psreverse
Because the printer is serially connected, lpd takes care of opening the device with the correct modes, as specified in /etc/printcap. The first program called is textps, which looks at the input and decides if it is PostScript (which our printer expects), and if not, converts it to PostScript. textps gets all the filter arguments that were passed (the $*) and is expected to generate accounting records from that information. The second program, psreverse, reverses the order of the pages so that they come out in a proper stack.
printcap variables for serial devices
The next few printcap variables are useful only for local serial printers. If you are setting up a network printer, skip the rest of this section. Otherwise, open your manual, look up your printer’s communication specifications, and read on.
You control three types of communication settings through printcap: the baud rate, the “flag” bits, and the “local mode” bits.
br: baud rate
If your printer is connected to a serial port, you will need a br entry. A serial printer is like any other piece of hardware: for correct operation, it and its host computer must agree on a common set of communication parameters such as speed, parity, and flow control. Configuration of a printer is much like the configuration of a terminal. See Chapter 7 for general information about serial devices and cabling.
The baud rate is the speed at which communication occurs (in bits per second) and is a simple integer. Since it is a numeric value, you use the pound sign (#) to set it. For example, br#9600 sets the baud rate to 9,600 bps.
fc and fs: flag bits
Mucking with the flag bits is usually