[lug] Inexpensive Laser Printer (a quick review)

[J. Wayde Allen]

On Mon, 1 Oct 2001, Riggs, Rob wrote:

> Part of the problem is the proliferation of printing systems. CUPS only
> helps if *every* Linux distribution chooses to use it.

I'm assuming that "printing systems" here means programs such as lpr,
cups, etc.?

> PostScript is the de facto standard for printing under Unix. The problem
> that CUPS still faces, and is the root of the problem I was trying to
> highlight, is that unless your printer speaks PostScript, you are going to
> need support for in in ghostscript. (At least we have *that* standard!)

Yes, OK ... at the very least you need a filter to convert the postscript
generated by most of the *nix software to whatever language the printer
uses.  That is often the ghostscript package, but it really doesn't have
to be.

> If it's a new printer, your entire ghostscript package needs to be
> updates. And what happens when your distribution releases an update to
> ghostscript (without your new printer driver)? Bye, bye printer.

Yes and no.  This makes the assumption that you are always going to use
the ghostscript package as your printer filter.  You don't necessarily
have to do that, and the printer company "could" built this filter for
us.  Essentially that is what they do when they create a driver for the
printer.

> After that the printer needs to be registered with the printing system, be
> it CUP, LPRng, LPD, etc. Each is different. Each has different config files
> located in different places. And each distribution does things differently
> enough to make it a pain for the printer manufacturer.

OK, but here is where things start to get confusing.  Sure, different
print systems would be configured differently, but so far we've heard of
lpr and cup.  The lpd daemon and lpr work together don't they, and as such
are not different systems?

That different distributions may use different packages, and locate pieces
in varying locations really seems to be at the heart of the matter.  For
the printer manufacturer this is problematic if they choose to support
things at the distribution level because then they've got to choose which
of the hundereds of distributions they will support.  If however, they
chose the building block model they could simply provide the kernel module
and print filter and let the guys building the distribution put the blocks
together in the correct place.  Of course that means that they'd have to
trust the distribution builders to do this, but it wouldn't really be in
the best interest of the distribution builders to do otherwise.  It would
also empower the end user to make the printer work even if the
distribution doesn't specifically build this hypothetical printer into its
design.  It also let's the end user choose the printer package (cup, lpr,
etc.) that he/she prefers.

> To make matters even more fun, we have to deal with bi-directional printer
> protocols. None of the current systems that I know of deal with this problem
> at all. At that point, we really do need printer support either in the
> kernel or somewhere between the printer daemon and the printer device.

I don't know about the bi-directional printer issues, but if we hold to
the *nix paradigm then this would be part of the kernel module.  I think
that lpd does deal with such bi-directional info as "printer not ready",
"out of paper", etc., but would have to check for certain.

- Wayde
  (wallen at lug.boulder.co.us)