|
|
A filter is a program that you can use for any of three purposes:
A default filter is provided with the print service to provide simple printer fault detection; it does not convert files or handle any of the special modes. It may, however, be adequate for your needs.
What follows is a closer examination of the three tasks performed by filters.
For each printer (local or remote), you can specify what file content types it can print. When a user submits a file to print on any printer and specifies its content type, the Print Service finds a printer that can handle files of that content type. Because many applications can generate files for various printers, this is often sufficient. However, some applications generate files that cannot be printed on your printers.
By defining and creating a filter that converts such files into a type that your printers can handle, you can begin to support more applications in the print service. (The print service comes with a few filters for converting various types of files into PostScript.) For each filter you add to the system, you must specify one or more types of input it can accept and the type of output it can produce (usually only one).
When a user specifies (by executing lp -T) a file content type that no printer can handle, the Print Service tries to find a filter that can convert the file into an acceptable type. If the file to be printed is passed through a filter, the Print Service will then match the output type of that filter with a printer type or the input type of another filter. The print service will continue to match output types to input types in this way, thus passing a file through a series of filters, until the file reaches a printer that accepts it.
The user Chris has run a spreadsheet program and has generated a file containing a copy of a spreadsheet. Chris now wants to print this file using the print service. You have only HP DeskJet 500 printers on your system. Fortunately, the spreadsheet application understands how to generate output for several printers, and Chris knows it is necessary to request output that can be handled by the HP DeskJet 500. When Chris submits the file for printing, the print service queues it for one of the printers; no filter is needed.
User Marty created a graphic image that can be displayed on a Tektronix 4014 terminal. Marty now wants to print this image, but all of the printers are PostScript printers. Fortunately, your system provides a filter called posttek that converts Tektronix type files to PostScript. Because you set the printer type to PostScript, the print service recognizes that it can use the posttek filter to convert Marty's output before printing it.
Filters can
handle special printing modes.
Each filter you add to the filter table can be registered
to handle special modes and other aspects of printing:
special modes
printer type
character pitch
line pitch
page length
page width
pages to print
character set
form name
number of copies
A filter is required to handle the special modes and printing of specific pages; the print service provides a default handling for the rest. However, it may be more efficient to have a filter handle some of the rest, or it may be that a filter has to know several of these aspects to fulfill its other roles properly. A filter may need to know, for example, the page size and the print spacing if it is going to break up the pages in a file to fit on printed pages. As another example, some printers can handle multiple copies more efficiently than the print service, so a filter that can control the printer can use the information about the number of copies to skip the print service default handling of multiple copies.
Just as converting a file and handling special printing modes is a printer-specific role, so is detecting printer faults. The print service attempts to detect faults in general, and for most printers it can do so properly. The range of faults that the Print Service can detect by itself, however, is limited. It can check for hang-ups (loss of carrier, the signal that indicates the printer is online) and excessive delays in printing (receipt of an XOFF flow-control character to shut off the data flow, with no matching XON to turn the flow back on). However, the Print Service can't determine the cause of a fault, so it can't tell you what to look for.
A properly designed filter can provide better fault coverage. Some printers are able to send a message to the host describing the reason for a fault. Others indicate a fault by using signals other than the dropping of a carrier or the shutting off of data flow. A filter can serve you by detecting more faults and providing more information about them than you would otherwise receive.
A filter can wait for a printer fault to clear and then resume printing. This service allows for more efficient printing when a fault occurs because the print request that was interrupted does not have to be reprinted in its entirety. Only a real filter, which has knowledge of the control sequences used by a printer, can ``know'' where a file breaks into pages; thus only such a filter can find the place in the file where printing should resume.
The print service has a simple interface that allows a filter to send you fault information and to restart printing if it can. The alerting mechanism is handled by the print service; the interface program that manages the filter takes all error messages from the filter and places them in an alert message that can be sent to you. Thus you'll see any fault descriptions generated by the filter. If you've set the printer configuration so that printing should automatically resume after a fault is cleared, the interface program will keep the filter active, so that printing can pick up where it left off.
It is tempting to use a program such as troff, nroff, or a similar word-processing program as a filter. However, the troff and nroff programs have a feature that allows references to be made in a source file to other files, known as ``include files.'' The print service does not recognize include files; it will not enqueue any that are referenced by a source file when that file is in a queue to be printed. As a result, the troff or nroff program, unable to access the include files, may fail. Other programs may have similar features that limit their use as filters.
Here are a few guidelines for evaluating a program for use as a filter:
See if the program expects any files other than those submitted by a user for printing. If it does, those files must be in the directory of the person using the filter, or they must be readable by all users authorized to use the filter. The latter prerequisite is necessary because filters are run with the user ID and group ID of the user who submitted the print request.
Referenced files that are always specified by full pathnames may be acceptable, but only if the filter is used for local print requests. When used on requests submitted from a remote machine for printing on your machine, the filter may still fail if the referenced files exist only on the remote machine.