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:
So how does it fit together? Well, when the system boots, lpd is
run. It scans the file /etc/printcap to learn which printers
it will be managing spools for. Each time someone runs lpr, lpr
contacts lpd through the named socket /dev/printer, and feeds
lpd both the file to print and some information about who is printing
and how to print it. Lpd then prints the file on the appropriate
printer in turn.
The lp system was originally designed when most printers were line
printers - that is, people mostly printed plain ascii. As it turns
out, only a little extra scripting is needed to make lpd work quite
well for today's print jobs, which are often in PostScript, or text,
or dvi, or...
