Subject: Re: Printing.
To: Richard Rauch <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 03/04/1999 09:37:03
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.