Re: [9fans] lp

[geoff@collyer.net]

lp has a long list of problems, the most serious of which is that it
isn't a real printer spooler: after trying to print your job twice, lp
tosses it and sends you mail saying "i tossed your print job".  So if
your printer jams, runs out of paper or gets turned off, and you don't
immediately notice and jump up and fix it, lp will happily throw away
all jobs for that printer.  A real printer spooler persists
indefinitely until it either succeeds at printing a job or gets a
permanent fatal error from the printer (e.g., "the postscript you gave
me was bogus"), on the assumption that it may have taken you
considerable effort to generate any given print job and you probably
didn't save a copy (with tee).

And ghod help you if you have more than one sysname or domain name for
a spooling host; lp is likely to loop sending jobs to that host
endlessly because it doesn't go to the trouble to check the current
host's $sysname or output of

	ndb/query sys $sysname dom

against its complete set of sysnames and domain names.

And why is it copying files from Plan 9 machine to Plan 9 machine?  It
could just as easily copy the job into the (shared) printer queue
locally.

But lp loves to copy files.  I haven't counted the number of copies of
a job that lp makes in the process of printing it (and it depends upon
the kind of input), but you'd be amazed at the amount of copying
(sometimes with trivial transformations).

There's an awful lot of unexploited generality in /sys/lib/lp/devices.
What does a spooler really need to know to drive a printer?  If it's
on a serial or parallel port, what machine drives it and on what port
with what (serial) line configuration.  If it's a network printer, how
to contact it (what dialstring to use).  What form(s) of input will
the printer accept (Postscript, PDF, PCL, text, rasters) and what, if
anything, must be emitted to switch a printer from one to another.  A
typical devices entry has 3 or 4 entries of "generic" and much of the
detail of how to drive the printer is jammed into an options or class
field.  The last field is virtually always "FIFO"; it's a little hard
to see why one would want to operate a printer "queue" as a stack or
heap.  The domain name and sysname of a network printer make perfectly
good names, there's no need for a special "printer destination" name
space.  So for the common case of a network Postscript 2 printer
accessible on service "printer" (port 515), all that's really needed
for a devices entry is

	ourprinter ourcpu ps2

and that looks like it could be a minor augmentation to ndb:

	ip=66.120.40.51 ether=08aefc2b2431
		sys=ourprinter dom=ourprinter.dept.company.com
		bootf=/lib/tftpd/66.120.40.51		# so dhcpd will respond to it
		printhost=ourcpu printlangs=ps2

And yes, I did make a stab at replacing lp, on Inferno even.  It's not
a trival job, but it's not rocket science either.