Subject: Re: Printing.
To: Frederick Bruckman <>
From: Richard Rauch <>
List: netbsd-users
Date: 03/04/1999 10:49:35
> > 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.

[This is an LQ-850; it seems to work best with the lq850 under GhostScript
5.50, but worked fairly well with epsonc & GhostScript 5.10.]

> > For reference, is there a standard place for printer filters? Maybe
> 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/.

Ah!  I did not know that we had such a man page.  I shall sally forth and
forthwith make amends.  (ahem)  Thank you for pointing this out to me.

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

Yes, or even parse /etc/man.conf.  I postponed the message, and rewrote
parts of it, so I apparently omitted an important point, here:

We have a good user manual (the man page system) that lots of people have
spent lots of time on.  We have some good typesetting tools (in fact, two
more or less unrelated hierarchies, at least---though only the *roff
hierarchy comes as part of the basic system).

I was hoping that someone would explain to me that there was an
undocumented feature of man, or that some similar, standard system tool
would automatically typeset from the man sources to a specified output
format, per groff.

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

Have you tried using groff to drive your printer this way?  So far, I've
only seen this effect with groff, so it may be emitting something
weird that GhostScript doesn't like...or perhaps it is operator error?

The form that I used was something like:

  groff -Tps -man <page>.<section> | lpr -Pps

...where <page>.<section> is the filname of the man source file.  That
works quite well if you do one at a time, but if you "bunch them up" in
the printer queue, I seem to have problems.  If you haven't specifically
done so, you might try the above with a couple of short man pages.

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

Thanks.  Unfortunately, ``-s'' doesn't really help.

> only puts a symlink in the spool directory, and the symlink _will_ be
> deleted when finished.

Everything (essentially) that goes into the spool directory is deleted
when done.  The ``-r'' option has to do with deleting the file that is
being printed (so I understand it).  Maybe a concrete example will

To print DVI files, at first, I did not know about dvips's ``-P''
parameter.  GhostScript 5.10 (binary package, anyway) did not support the
lq850 printer, so I used ``epsonc''.  My ``lpr-dvi'' script looked
something like this, then:

  dvips -o /tmp/ $1
  gs /tmp/ <various options; send to /tmp/epsonc>
  rm /tmp/
  lpr -r -s /tmp/epsonc

...the ``-s'' I had already discovered, because I printed some of the
TeX-and-friends documentation (some of those files are BIG).

The desired result was to have /tmp have nothing in it that wasn't in it
when I started.  Unfortunately, it would ALWAYS have /tmp/epsonc.  My
understanding is that it was this file (and only this file) which ``-r''
affects.  The spool file should be deleted, regardless of whether it is
symlink, and regardless of whether you specify ``-r''.

I hope that I have not insulted your intelligence.  But, this is what I am
refering to when I say that ``lpr -r'' does not seem to work.  The
spooling is fine (other than my comments re. ``lprm''...).

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

Perhaps I am using it incorrectly.  Can you show me a concrete example of
how to use it?  I tried what I thought was the obvious interpretation of
the man page, and one or two less obvious interpretations.  None worked
for me.

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

What is ``pap''?  Is pap the reason for not being able to have more than
one printer?

> > 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?

I am not sure what you mean by ``As above?''  Are you refering to
something that I said, or to something that you said?  I _do_ have two
(active) printers listed in /etc/printcap; I do _not_ have ``pap'' (as far
as I know); I do _not_ run -current.  lpr, lprm, lpc, lpq, groff, nroff,
troff, and corresponding macro packages are all generic 1.3.3, as far as I

  "I probably don't know what I'm talking about."