| |
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).
Pdq stands for "Print, Don't Queue", and the way it works reflects
this design. The following sequence of events happens when you
use PDQ to print:
You run pdq or xpdq, specifying a file.
You specify a printer.
You specify the settings for the various options and arguments
defined in the printer's PDQ driver file (duplex, copies, print
quality, and so forth).
PDQ analyzes the contents of what you printed, and follows the
instructions in the PDQ driver file which tell it how to
process your data for this printer with your options.
PDQ sends the processed data to the printer according to the
interface defined for that printer (straight to
/dev/lp0, or to an LPD daemon on the
network, over the network to an Apple or Microsoft system, or
even to a fax machine).
If PDQ can't send the data to the printer right away, it spawns
a background process to wait and try again until it succeeds or
hits a time limit.
At all times during this process, and afterwards, the state of each
print job can be seen and inspected using xpdq. Jobs that failed are
shown in red and can be resent.
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 if attribute 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.
- 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 VA Linux LPD, 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 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, including
enscript, nenscript, and
a2ps.
- a2ps
a2ps, aka any-to-ps, is a program which
accepts a variety of file types and converts them to
Postscript for printing.
|
