On Thu, 4 Mar 1999, Richard Rauch wrote:

> After a certain amount of work, I think that I more or less have printing
> sorted out on my NetBSD box & old Epson printer.

Cool. I have an Epson Stylus Pro that works fine under ghostscript.

> For reference, is there a standard place for printer filters? Maybe
> /usr/local/mumble/bar/foo, instead?  (Initially, I naively tried setting
> up GhostScript directly as my filter, but that caused problems, of course,
> since printcap doesn't seem to let one specify parameters to a filter.)

The convention, such as it is, is spelled out in the hier(7) man page.
My own printer filter is under /usr/local/libexec/lpr/.

> My current approach is to find which directory a given man page source is
> in, and invoke groff on the page, and sending the postscript output
> through my ``ps'' printer (i.e., through GhostScript, and then on to the
> physical Epson printer).
> 
> This has two significant flaws:
> 
>  * I have to know the proper directory for a given man-page (unlike using
>    ``man'', where at most one needs to know the manual section).  This
>    could be fixed w/o too much effort if it were sufficiently irritating;
>    it remains a minor annoyance.

`man -w' can help here. You could probably use that to write a little
script that will format the man page for it's argument, and send that
to the printer.

>  * If I queue up a second typeset man page, while the first one is still
>    printing, the tail end (page footer of the last page) of the first
>    job tends to get overwritten with the front of the second job.  Worse,
>    the second job seems to reset the printer, so that confuses the
>    printer, and I end up with my page-breaks skewed thereafter.

I've never seen that with the Stylus Pro. No idea.

> ``lpr -r'' does not seem to delete files.  I tried this when setting up
> and playing with teTeX.  My initial efforts at using dvips involved
> explicitly writing temporary files; the final one was sent to ``lpr -r'',
> but it never actually deleted the files.  Can someone confirm this?  Is
> this perhaps a deliberate feature-removal?  (I notice that the LINUX lpr
> man-page deprecates the use of ``-r'', supporting it only for BSD
> compatibility.  Apparently, some camps feel that it is a Bad Thing to
> have...though I don't readily see the problem, myself.)

I believe this is a known problem. For large files, use `lpr -s'. This
only puts a symlink in the spool directory, and the symlink _will_ be
deleted when finished.

> Related, lprm does not seem to actually remove jobs from the print-queue. 
> The only way that I have found to remove such jobs is to su, then delete
> the queued files by hand.  I have tried on jobs for the default ``lp''
> printer, and for my ``ps'' pseudo-printer (and I did specify ``-Pps'' in
> the latter case); I have tried as root, and as my regular login id (from
> which the jobs were started).  I have tried using both ``25'' and ``job
> 25'' to refer to job #25; I have also tried using ``-'' to remove all
> queued jobs.

Never seen that either. While experimenting with pap last month, I had
occasion to use lprm many times, and it worked fine, on both the
symlinks and the small files. (I'm running -current.) I do seem to
remember having problems making a printcap entry with any name except
"lp," so my only printer is named "lp." I comment out the Epson to use
pap, and vice-versa.

> As far as I can tell, lprm doesn't do what it is supposed to do.  The
> oddity of my system is that the ``ps'' and ``lp'' printers both directly
> drive the same printer harder (``ps'' doesn't pass it off through ``lp''; 
> perhaps a mistake, but it shouldn't affect the queues, should it?).  The
> two printers have seperate /var/spool/output queue directories. 

As above?