Subject: Printing.
To: None <netbsd-users@netbsd.org>
From: Richard Rauch <rauch@eecs.ukans.edu>
List: netbsd-users
Date: 03/04/1999 09:05:36
After a certain amount of work, I think that I more or less have printing
sorted out on my NetBSD box & old Epson printer.

As far as I could see, there was precious little information re. setting
up a printer under NetBSD.  A few man-pages (printcap(5), lpr(1), etc.),
and a very minimal /etc/printcap sample file.  I don't mind having to work
a little to get the printer set up, but I had to make some guesses (it
took me a while to decide whether the "filters" for "accounting" could
probably be used for running GhostScript), and introduce a personal
convention.

The convention was where to put my "input filter" (or was that an "output
filter"?  I forget which I used).  I ended up creating a sub-directory in,
I think, /usr/sbin.  In there, I stuck a script to invoke GhostScript from
a ``ps'' printer entry.

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.)

 ---

Also, I've been peering at some of the man-pages, and thought that I'd see
about proofreading a (small) subset of them---some of the man pages are
very well written; others definitely needed a proof-reader.  Experience
teaches me that it's easier to do this kind of thing with a colored pen or
pencil, on paper.  So...I began trying to get _nice_ (i.e., typeset)
printings of the man-pages.

As far as I can tell, there is no way to do this with the same ease as
with which one views the online man pages.  Am I missing something? 

(Well, I _can_ do ``man [<section>] <topic> | lpr'', but that screws up
the spacing (and general page-breaks); also, for the efficiency-minded, I
would point out that piping ``man'' into ``lpr'' actually takes up more
space (despite compressing runs of blank lines), than does a properly
typeset page.  And if one gets clever with post-processing, and doesn't
mind the visual compression, one can fit multiple logical pages onto a
physical page...)


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.

 * 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.

   This effectively means that I have to ``babysit'' the system if I want
   to print out several such man-pages.  I'm not sure how best to fix
   this one.  (It occurs to me that it might work to have groff emit DVI
   files; queueing multiple DVI files with ``dvips -Pps'' seems to work
   pretty well, but the result is an explicit temporary DVI file---dvips
   doesn't like to work with pipes, unfortunately.)

 ---

A last pair of problems.

``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.)


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. 

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. 

I assume that I'm not the only one who occasionally uses printed
media.  Can anyone make suggestions, or confirm/deny this behavior on
their system?

I am using 1.3.3, more or less vanilla.


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu