Running Linux, 5th Edition - Matthias Kalle Dalheimer [272]
The print management system is controlled by cupsd, the daemon that has necessary privileges to access printers on behalf of the user. (Older Linux systems used BSD LPD or LPRng. These daemons were called lpd rather than cupsd, but they filled the same basic role.) Once the print management system is installed, cupsd is started every time the Linux system is booted. Files in /etc/cups provide the control information cupsd needs to manage the files the user wants to print.
Two paths exist for printing on a Linux system that runs CUPS. The first path involves lpr or lp. These programs are named after the utilities in BSD printing systems (BSD LPD and LPRng) or SysV printing systems, respectively. They accept a file that's to be printed and behave much like their namesakes in the older printing systems, at least as far as the calling application or user is concerned. Behind the scenes, though, these programs are really just gateways into the second printing path.
This second printing path involves CUPS-specific system calls. Applications that use this path can communicate bidirectionally with CUPS. In addition to passing plain-text, PostScript, or other files to the print daemon (as in old-style printing systems), applications can query CUPS about a printer's capabilities. CUPS can then deliver a PostScript Printer Definition (PPD) file to applications. These files describe a PostScript printer's features: its page sizes, printable area, color capabilities, and so on. As described in "Managing Print Services," PPD files are key components of Linux printer driver packages, even for non-PostScript printers. (For such printers, Linux printer driver packages include PPD files that describe the printer's capabilities as driven via Ghostscript.) Because of this bidirectional communication, CUPS-aware programs can set more printer features, such as printer resolution, than can older programs that are not CUPS-aware.
* * *
Tip
You can turn some old-style (CUPS-unaware) applications into CUPS-aware applications by changing their printing paths. Specifically, if you call kprinter rather than lpr, the result is that print jobs will be processed by KDE's printing system, which is CUPS-aware. You can then set CUPS-specific options, such as changing the printer resolution. This option works best for GUI programs because kprinter is an X-based application. You could also use this approach for printing from text-mode programs run from within an xterm terminal program.
* * *
Whether the program is CUPS-aware or not, once cupsd has received a print job, it's stored in the print spool directory (usually /var/spool/cups), along with a file that describes the print job. CUPS then orders the list of print jobs and sends them to the printer in an organized fashion, preventing conflicts in accessing the printer. Each print queue has associated with it a set of filters, which are programs that process files of particular types. The details of print filter configuration are hidden from view, even from system administrators, unless you dig pretty deeply into the CUPS workings. Typically, applications deliver plain text or PostScript to CUPS. Plain text may be sent on to the printer without processing, but PostScript is usually processed through Ghostscript, which converts the PostScript into a format that the printer can understand.
Managing Print Services
Linux has a fairly complicated printing system, compared with the printing services most PCs use. Configuring the printing system is usually either very easy (because the semiautomated tools get it right) or very hard (because the semiautomated tools fail or because your printer is poorly supported under Linux). The next few pages describe the Linux printing system, beginning with an overview of the software and moving on to hardware configuration and testing, configuring the Common Unix Printing System (CUPS) to enable its web-based