[ On Wednesday, January 12, 2005 at 10:41:48 (-0800), Jeremy C. Reed wrote: ]
> Subject: printer wizards? (was Re: Is ghostscript-esp-7.07 required for CUPS ?)
>
> One thing that I like about CUPS is that is usually very quick and easy
> for a novice to configure a printer. (As long as the cupsd is setup and
> running in the first place -- hopefully done automatically by the package
> installation.)
> 
> Does anyone know of any easy alternatives to CUPS that provide a wizard to
> quickly configure a variety of printers (and using different printer
> interfaces/protocols)?

Well it depends on how you concieve of the idea of print spooling.

My rule of thumb has always been to force the user to submit print jobs
in ready-to-print format.

I.e. if you've got a postscript printer then everyone _always_ submits
postscript data and _only_ postscript data.  K.I.S.S.  Luckily almost
everything (on unix systems) that wants to print can generate PS.

If your printer reliably recognizes and prints several different formats
directly then users can send any one of those formats directly to the
printer, but unless you're talking about just ASCII, PostScript, and
maybe HP-PCL or similar, and your printer has an extremely good
implementation (e.g. as my current ALW does), then going down this road
inevitably leads to less reliable operation from the user's perspective.

However that whole idea of pre-formatting all printer output flies in
the face of how BSD printing grew to be with all its filters and with
explicit command-line flags on the print spooling interface that
identified the type of input within a certain limited range of input
types (nroff, troff, dvi, ascii, etc.)  (I think the BSD idea had some
merit back in the day when it took a _long_ time to run big troff jobs,
but on today's systems, even decade old systems, that's very bogus!)

I used to manage quite a few systems at different times over the years,
each with many different types of printers, some which might be loaded
with different forms at different times, etc.  With a good print spooler
though I was able to queue jobs in queues that were named to identify
the desired print form and an operator could change forms and then
freeze and/or release the appropriate queues.  Note though that I always
used the SysV spoolers.

The problem with the BSD scheme is that it is extremely limited.  One
has to add new command-line flags to identify new types of input, and
the whole idea with it seemed to be to do the batch conversion in the
spooler.  Worse it still didn't help route different types of output to
the right kind of printer.  No matter what you do you can't do
universal format conversions.

I think the problem with CUPS is that it takes the BSD scheme to the
extreme, i.e. it goes further down the wrong path entirely.

The only tricky part is when the printer needs certain control sequences
to change it's mode and where one cannot rely on the jobs to start and
end with the right control sequences.  This is where the spooler does
have to identify the type of data it's handling itself and manage the
state of the printer before and between jobs.

And I think this is where things started to get complicated and perhaps
also lead the way to the BSD scheme, and this is certainly why I highly
prefer PostScript-only printers.  ;-)

If I didn't have a PostScript printer then I think I would want to set
up a filter using GhostScript to make it look like I have a PS printer
and then I'd still always submit everything to the spooler as PS.
Apparently this kind of filter is easy to configure with CUPS, but
fortunately for me I've never had to figure out how to do it with LPD as
luckily I've had one kind of PostScript printer or another for the past
decade or so.  (I think it should be easy with LPD though.)

Currently I use Netatalk to drive my ALW since the LPD/TCP spooler built
into the printer is somewhat limited and has some problems and is also
unable to return PostScript "console" output back to the sender.  With
PAP I can do true printed-page accounting as the PS output is sent back
to the sender.

As for ease-of-use, well setting up /etc/printcap is pretty darn simple
for the most basic kind of "print what you what you send and don't try
to re-format it" style I advocate.  It could probably be made all
menu-driven and user-friendly with something like sushi(8), though I
don't currently see any support in sushi for managing printcap.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>