In order to get printing working well, you need to understand how your spooling software works. All systems work in essentially the same way, although the exact order might vary a bit, and some systems skip a step or two:
- The user submits a job along with his selection of options. The job data is usually, but not always, Postscript.
- The spooling system copies the job and the options over the network in the general direction of the printer.
- The spooling system waits for the printer to be available.
- The spooling system applies the user's selected options to the job, and translates the job data into the printer's native language, which is usually not Postscript. This step is called filtering; most of the work in setting things up lies in getting the proper filtering to happen.
- The job is done. The spooling system will usually do assorted cleanup things at this point. If there was an error along the way, the spooler will usually notify the user somehow (for example, by email).
To print a job with CUPS, you can use both the BSD (see Section 5.3.1, “Printer compatibility list”) and System V commands making it really easy for people with prior experience with either system.
Initially CUPS lacked an LPD backend. This was of course quickly added. Currently there are backends available for at least IPP, LPD, SMB, JetDirect, USB, Netatalk, parallel and serial printers. You may find others on the net or write your own.
There are only a handfull of built-in drivers, allowing you to print with most printers but probably not at the maximum resolution. A PPD file for a Postscript driver can be added to CUPS but if you want to print at best quality with your fancy new HP Deskjet you are out of luck. It is here that Foomatic comes to the rescue. You can use Foomatic in combination with CUPS. Foomatic uses a CUPS filter called foomatic-rip to do its magic. foomatic-rip uses PPD files to describe printer capabilities, even for non-Postscript printers. CUPS + Foomatic is currently the recommended printing system. Some Linux distributions already use it and the number that do will only grow.
The CUPS scheduler does not only accept jobs, it is also a administrative webinterface. Currently you can add/delete printers, cancel jobs, start/stop printers. Moving jobs will be available in a later release.
Lpd stands for Line Printer Daemon, and refers in different contexts to both the daemon and the whole collection of programs which run print spooling. These are:
- lpd
The spooling daemon. One of these runs to control everything on a machine, AND one is run per printer while the printer is printing.
- lpr
The user spooling command. Lpr contacts lpd and injects a new print job into the spool.
- lpq
Lists the jobs in a print queue.
- lpc
The Lpd system control command. With lpc you can stop, start, reorder, etc, the print queues.
- lprm
lprm removes a job from the print spool.
So how does it fit together? The following things happen:
- At boot time, lpd is run. It waits for connections and manages printer queues.
- A user submits a job with the lpr command or, alternatively, with an lpr front-end like GPR, PDQ, etc.Lpr contacts lpd over the network and submits both the user's data file (containing the print data) and a control file (containing user options).
- When the printer becomes available, the main lpd spawns a child lpd to handle the print job.
- The child lpd executes the appropriate
filter(s) (as specified in the
ifattribute in/etc/printcap) for this job and sends the resulting data on to the printer.
The lp system was originally designed when most printers were line
printers - that is, people mostly printed plain ASCII. By placing
all sorts of magic in the if filter, modern
printing needs can be met with lpd (well, more
or less; many other systems do a better job).
There are many programs useful for writing LPD filters. Among them are:
- gs
Ghostscript is a host-based Postscript interpreter (aka a Raster Image Processor or RIP). It accepts Postscript and produces output in various printer languages or a number of graphics formats. Ghostscript is covered in Section 10, “Ghostscript.”.
- ppdfilt
ppdfilt is a standalone version of a CUPS component. It filters Postscript, executing a few basic transformations on it (n-up printing, multiple copies, etc) and adding in user option statements according to a Postscript Printer Definition (PPD) file usually included with Postscript printers.
ppdfilt is best used together with an option-accepting LPD system (like the GNUlpr, or LPRng) and a filter script which parses user-provided options into the equivalent ppdfilt command. VA Linux and HP provide a modified rhs-printfilters package which does exactly this; it produces nice results if you have a Postscript printer. See Section 8.2.2, “LPD for PostScript Printers” for information on this system.
- ps2ps
ps2ps is a utility script included with Ghostscript. It filters Postscript into more streamlined Postscript, possibly at a lower Language Level. This is useful if you have an older Postscript printer; most modern software produces modern Postscript.
- mpage
mpage is a utility which accepts text or Postscript, and generates n-up output—that is, output with several page images on each piece of paper. There are actually several programs which do this, includingenscript, nenscript, anda2ps.
- a2ps
a2ps, aka any-to-ps, is a program which accepts a variety of file types and converts them to Postscript for printing.