UNIX System Administration Handbook - Evi Nemeth [418]
To print to a non-PostScript printer, you often need special software to convert the print job into the printer’s preferred PDL. Some vendors can provide the appropriate UNIX software—usually for a price. The alternative is to use the free package ghostscript, which can convert from PostScript to the custom PDLs of hundreds of printers. You will need to specify a printing filter to properly invoke ghostscript on the fly. The ghostscript documentation contains examples. LPRng can make this task easier, too.
See page 740 for more information about ghostscript.
23.3 BSD PRINTING
BSD’s printing system was designed specifically for use with line printers. Fortunately, efficient design has allowed the system to scale to support most of today’s printers and PDLs. The network portion of the BSD printing system also extends well to large, heterogeneous networks and permits many computers to share printers. The lpd print spooler has become such a de facto standard that it has found its way inside many network printers.
Among our example systems, Red Hat and FreeBSD use the BSD system as the basis of their printing software.
An overview of the printing process
Under BSD, access to printers is controlled by the lpd daemon, which usually lives in /usr/sbin and is normally started at boot time. lpd is responsible for accepting print jobs from users or other (remote) lpds, processing them, and sending them on to an actual printer. To accomplish these last three steps, lpd reads printer configuration information from /etc/printcap, the system’s printer information database.
Users invoke the lpr program to submit their print jobs to lpd. These two processes communicate through the UNIX socket /dev/printer.
When determining what printer to send the job to, lpr first looks at the command line. If a -Pprinter argument is passed to lpr, printer becomes the destination. Otherwise, lpr checks the environment to see if the PRINTER variable is defined, and if so, lpr uses the variable’s value. If all else fails, the job is submitted to the system-wide default printer, which is the printer named lp, or if there is no lp, to the first entry in the /etc/printcap file. Almost all printing-related commands, including lpq and lprm, understand the PRINTER environment variable and the -P argument.
As soon as lpr knows where the current job is headed, it looks up the printer in the /etc/printcap file. This file tells lpr into which directory print jobs for that printer should be placed. This “spool directory” is often /var/spool/lpd/printername.
lpr creates two files in the spool directory for each job. The first file’s name consists of the letters cf (control file) followed by a number that identifies the job.1
This file contains reference and handling information for the job, such as the identity of the user who submitted it. The numeric portion of the filename allows space for only three digits, so the printing system becomes confused if more than 999 jobs are queued. The second file’s name begins with df (data file) followed by the same number. This file contains the actual data to be printed. After the file has been spooled, lpr notifies the lpd daemon of the job’s existence.
When lpd receives this notification, it consults the printcap file to determine if the destination is local or remote. If the printer is connected locally, lpd checks to be sure a printing daemon is running on the appropriate printer’s queue and creates one (by forking a copy of itself) if necessary.
If the requested printer is connected to a different machine, lpd opens a connection to the remote machine’s lpd and transfers both the data and the control file. lpd then deletes the local copies of these files.
Scheduling for print jobs is done on a first-in, first-out basis, but the system administrator can modify the printing agenda by using lpc on individual jobs. Unfortunately, there is no way to permanently instruct the printing