 |
 |
 |
 |
 |
 |
Update June 14, 2006
A pdq mailing list has been setup at the http://sourceforge.net/projects/pdq/ website.
And the code has been imported in CVS and a few things are being updated. See http://pdq.cvs.sourceforge.net/pdq/.
Throw away lpr, lp, lpq, lpstat, and lprm, and start planning your vacation! Pdq is guaranteed to be the most straightforward, flexible print subsystem you have ever used, or your money back! (Actually pdq is free software, distributed without warranty.)
Recent changes:
Features:
Requirements:
The utility pdq should compile and run on any unix system. It has been tested on HPUX-10.20, Irix 6.2, AIX-4.3, and Linux. The graphical interface xpdq is built on GTK, which is also portable; it requires GTK and GLIB versions 1.2.0. The supplied lpd utilities lpd_print, lpd_cancel, and lpd_status should also compile on any unix system.What is wrong with BSD and SysV printing?
They make sysadmins earn their money. They make users lose their hair. They require superuser privelege to setup and maintain, and they are prone to clogging up. When the queue comes online, the printer spews out garbage from all the piled-up submissions. Printers have gotten cheaper, and workstations have gotten faster, so that the model of queueing, accounting, and nonlocal processing is obsolete. Most casual unix users regard lp and lpr as black holes to which print jobs disappear, and may or may not emerge. Most users print to the closest printer, and keep on submitting the job until they see it. A better model for printing is that the workstation processes everything, and submits finalized data to the printer when it first becomes available.Without a print queue, won't their be anarchy?
Yes, but there already is anarchy. Go find the nearest lab with 25 workstations and one printer. You'll find a different queue on each workstation, because that is the only way to set it up! So although jobs within a single queue on a single workstation may be nicely queued and prioritized, there is anarchy among the queues. Not only that, such a setup is a nightmare to maintain. Try pdq, it works.What about LPRng?
LPRng complexifies, pdq simplifies. Said differently, it doesn't scratch my itch.What does pdq stand for?
In my mind, it means "print, don't queue; when was the last time you used a line printer anyways?" You may prefer to think of it as "pretty darn quick", "print damnit", or perhaps even "printouts die quickly", "printouts disappear quietly", "please don't quit", or "pretty darn quirky".Give me some details.
Suppose a user types "pdq foo.txt". First pdq parses /etc/pdq/printrc and ~/.printrc. These resource files define printers, drivers, and interfaces. Second, pdq opens foo.txt for reading, forks off a shepherd process to manage the job, and exits. The shepherd copies foo.txt somewhere into ~/.printjobs (or a directory of the user's choice.) The shepherd converts and filters foo.txt in a manner described by the driver and dependent on the filetype of foo.txt. The final document is sent to the printer in a manner described by the interface. If the interface indicates that there was a problem sending the job, the shepherd will attempt to resend the job every 10 seconds for 5 minutes, or as specified in the resource files.The real flexibility is achieved by manipulating the environments that are passed off to the various driver and interface scripts. Drivers and interfaces can define "arguments", which are declared environment variables that the user can supply either in the rc printer definition or on the command line. They can also defined "options", which specify a rigid set of possibilities for a particular environment variable.
See the screenshots section for examples.
Hosted by Sourceforge. Thanks!
Copying, distribution and modification are governed by
the GNU General Public License version 2.