On Sun, Mar 17, 2002 at 03:03:16PM -0600, Richard Rauch wrote:
> Could you please format your email as lines of text?  To see how I see it,
> browse http://mail-index.netbsd.org/netbsd-help/2002/03/17/0004.html in
> Netscape.  (^&  Email doesn't (so far as I have heard) really say what to
> do with long lines, save that lines of up to 1000 bytes are permitted.
> It looks a bit better in Konqueror than in Netscape, but...

Hi Richard, 

Sorry about the long lines, old man.  I recently switched to the 
sylpheed GTK-based mail client, and I guess I don't have the wrap
settings turned on.  Thanks for mentioning it.  

Somewhat lengthy response follows, in the hopes of getting enough
feedback to find out whether I'm off base or not.  

> I can't say why printing disabled (all printcap entries are commented out
> by default, yes?).  I can say why I'd do it: Enable any entry and you're
> bound to get it wrong for many people.  It's better to have a *vanilla*
> system fail to print than to have it start spewing pages of garbage.

I think many people are likely to have some sort of ascii, pcl, or 
postscript device attached, if there's any at all.  It seems to me that
having a queue set up -- at the likely place(s), that will politely copy 
what you hand it to its device --  would be harmless.  Granted, if you 
hand postscript to an ascii printer or vice-versa, you'll regret it, 
but a queue that doesn't do any transformation (except NL -> CRLF) 
would surprise only the misinformed.  


> LPRng: Can you summarize why one might use LPRng in a home network?  I
> looked at the LPRng site, but didn't see reason to install it.  Did I miss
> something, or did you mean to exclude home-users?

I think, based on what I read today, that LPRng might fit nicely in a 
GUI environment for non-geeks at home.  It looks pretty heavy-duty, so 
someone would have to preconfigure it.  I'm with you, though: 
the base queuing system should be fine for home use.  

I was only trying to convey my impression that LPRng has completely
superseded the base BSD printing subsystem, and that anyone with
anything other than very basic needs has can't use what NetBSD 
natively provides.

What led me to look at LPRng was my banner page experience.  When I 
realized that my Page One garbage was a banner page coming from -- 
incredibly, to me -- the printer daemon directly.  lpd of course cares
not a whit about postscript or whathaveyou, and its banner page is 
plain ascii.  I found it, hardcoded, thank you cvsweb.  No 
configuration file.  So I asked the obvious question: What do people 
with postscript printers do to get those nice banner pages?  As
far as I can tell, the answer is: swap out the BSD printing subsystem
in favor of LPRng.  

I wondered briefly whether it would be worthwhile to bring the banner 
page generation out of the line printer era, but decided that better
banners wouldn't make it a modern system.  Home users (one should think)
don't *need* banner pages.  The banner page we do generate should 
probably be suppressed by default, and if enabled should probably 
include text similar to the "don't log in as root" suggestion on the
console, something like, "if you need real printer manangement, 
take a look at LPRng".  

I hope no one thinks I'm being critical or sneering.  The base printing
system is quite serviceable, and its relative simplicity is an 
advantage to simple purposes.  I'd just like to see it be a little
more amenable to printers manufactured since the days of the DecWriter.

> /dev/lp*: Default selection of devices may be a problem.  I've used the
> interrupt-based, and interruptless versions of /dev/lp* on port-i386.
> I've used another variant that doesn't reset the port on open.  I
> presently use a USB ulpt.

One answer might be, set up a queue for anything that would be likely to 
have a printer on it.  Some things only take printers, and some 
typically do.  

If that's really distasteful or wasteful, OK, how about *one* default
queue to a symlink that you (or sysinst) creates, called /dev/printer?

> Default filters: I would rather the default printer configuration be kept
> simple.  Attaching a printer will likely require fiddling with any default
> config.  The simpler that the suggested/default configs are, the easier it
> is to figure out what they are doing.

Quite so.  I really really think its a bad idea (from an advocacy point of 
view) to expect people to learn printcap(5) and write their own input 
filter just to plop their README on the printer.  Magic interpretation
we don't need.  

> Perhaps instead of a patch to the system files, you could provide a small
> script that could be make into a package for pkgsrc.  The script could
> parse dmesg's output, query the user for a few things, and rewrite the
> /etc/ files (and create any necessary directories.

If I wanted to make a better printing system, yes, that would be a way 
to go.  It just seems a little lame to punt on the whole question, 
effectively saying, "I don't know what kind of file you might want 
to send or what kind of bizarre printer you might have, so rtfm, pal, 
you're on your own".  Surely we can do better than that.  

Regards, 

--jkl