Re: [9fans] lp

Re: [9fans] lp

[geoff]

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.

[9fans] lp

[Paul]

lp was first written for 8th Edition Unix and was ported to Plan 9.

FIFO doesn't seem like such a good idea when printers are expensive and slow
and there is a mix of jobs queued (long and short).  There used to be other
schedulers.

lp was first written to handle Imagen printers and a hand rolled printer
that we had at the Labs designed by Tom Killian using Canon print engines.

The lpdaemon and lpdsend commands accept and deliver lpd/lpr protocol,
respectively.
Lpdaemon sniffs the input for 'lp' or 'lpr' style jobs.

A replacement for lp would be a good idea.  I thought about it for a long
time.  Hopefully there is a fool out there willing to take on the task.
I'll provide all the help I can give.

By the way, I retired from Lucent/Bell Labs in July and I am also looking
for work.

    Paul Glick

Re: [9fans] lp

[Scott Schwartz]

Speaking of lp, I'd kinda like to have an lpd server written in inferno,
so it could be run everwhere.  (Escaping from lprng would be wonderful.)
Does Vita ship one of those?

Re: [9fans] lp

[Russ Cox]

> It was written by Paul Glick and ran on both our Unix systems
> and Plan 9.  He didn't want to support 2 different versions.
> I agree that having it as a file system would have been a
> lot nicer.  Since all our printers are on the net, we still would
> have to deal with the network protocols but the interface would
> be a lot nicer for programs, just open a file and write into it.

It'd also be nice if all n^2 conversions didn't have to be coded.
Instead, you could specify a list of possible conversions and 
run a shortest path algorithm from what you have (say, troff)
to what you need (say, PCL for a BubbleJet).

Russ

Re: [9fans] lp

[presotto]

It was written by Paul Glick and ran on both our Unix systems
and Plan 9.  He didn't want to support 2 different versions.
I agree that having it as a file system would have been a
lot nicer.  Since all our printers are on the net, we still would
have to deal with the network protocols but the interface would
be a lot nicer for programs, just open a file and write into it.

Any volunteers?

Re: [9fans] lp

[peh]

I'm thinking about volunteering for it.

I'm looking into it at any rate and trying to balance
work, family and learning.

Pat

[9fans] lp

[peh]

'lp' doesn't seem very plan9-like. It looks
more like software which works on standard Unix
and was ported to Plan9.  Has there been any effort
to integrate printing more into plan9?

An example would be spooling. Rather than sending
the files from one host to the next via the lp
protocol why not bind the directory of the printer
host onto a local directory and copy?

Another idea would be to hide the type of printer
(PostScript, PCL, bitmap) in a filesystem server
and have programs copy the data to a file, allowing
the filesystem server to convert the data as 
necessary and perform the necessary communications
with the printer.

Anyway, just wondering.

Warm regards,
Pat