Print Job Lifecycle

A number of events take place between the time a user requests a document to be printed and when it is sent to the physical device for output. In simplified terms, a print request can be broken down into three main stages:

• Saving all the print information locally for subsequent processing (spooling)

• Translating the information into a format compatible with the printer (filtering)

• Providing the parsed output to the appropriate target device (printing)

All these print job stages are executed without the knowledge of the user requesting the output. Each step, however, must be successful for the operation to produce valid output.

Job Spooling

Each request for a print copy of a document is tagged with a request number. This number allows the system to uniquely track the document data, the destination print queue and filters, as well as job accounting information.

The spooler places a snapshot copy of the requested document in a directory under /var/spool/cups. The document, as well as its various instances in the filtering process, reside in the directory until the job successfully prints. On servers that process a large volume of print jobs, a significant amount of disk space can be consumed by pending print requests.

The spooler is responsible for providing job status information upon request to users, as well as routing the data through the various stages of the printing process.

Job status can be verified either through the CUPS web interface (this is shown later in Figure 9.10) on the print server or through the lpstat command using a terminal interface.

Figure 9.10. The CUPS Job management page.

Applying Filters

Printing implementations using the LPR/LPD environment suffer from the lack of cross-platform driver support for various printers. In CUPS, many of the driver issues are solved through abstracting job requirements from the hardware. This is accomplished by a series of conversions that massage the various data formats contained within the print request into a single standard format.

After the data is converted into a standard format, the printing process is reduced to a simple translation from the standard format to one understood by the individual printer.

In CUPS, the standard format is PostScript. The filters used by CUPS are stored in /usr/lib/cups/filter. After a data stream is converted into PostScript, it can then be translated into the required format for the specific printer. Support for specific printers, or printer families, is therefore reduced to providing a single PostScript-aware driver. If the printer is PostScript capable, the file is forwarded to the next step. If it is not PostScript aware, as in the case of the sample Canon BJ200, the file is converted into a raster format compatible with the printer.

Printing the Information

After the data has been massaged into the appropriate format, it is ready to be printed. The last stage in the process involves invoking what is known as a back-end process. This process is responsible for moving the final document version to the printer itself.

In the case of a local printer, the back-end process reports progress, success, or failure of the print job back to the spooler process.

Network print jobs are handled slightly differently than local print jobs. With such jobs, the back-end process is constrained to handing off the document to the spooler service at the remote end. After this is accomplished, the spooler is notified and the local print job is marked as completed. After the hand-off has occurred, however, the local back-end process can no longer report on the status of the spooled job. The remote server also has a method for tracking the now "local" print request. Further tracking at the client end is not possible, but diagnostic information is available on the endpoint server.