> > 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.
> 
> OK, I just did that, and it seems to work for me.

Huh.  Maybe I should experiment with a different ghostscript output
device.  Or, as I said, try going through a DVI intermediary...


> > refering to when I say that ``lpr -r'' does not seem to work.  The
> > spooling is fine (other than my comments re. ``lprm''...).
> 
> Yes, it really doesn't work. Upon reconsideration, the work-around has
> nothing to do with "-s". (Never mind!) The filter script I use takes

Okay, the question of whether ``-r'' works can be considered laid to rest,
then.  My other question about it stands, though:

  Is it a deliberate feature to not support ``-r'', or is it a bug?
  (If the former, then the man page should be updated...)

I wouldn't have guessed that it would be deliberate, save that the
GNU/LINUX lpr man page seems to have a low opinion of supporting ``-r'';
so, I wondered if perhaps they had a good reason for their attitude, and
our own lpr might have been modified by someone of a like mind?


> postscript on standard input, and emits the raw printer codes to
> standard out. The key line looks like this:
> 
> /usr/pkg/bin/gs -q -sOutputFile=- "@stc.upp" /dev/stdin -c quit
>
> So when I use your command, above (without the -Pps), there's no
> temporary file for lpr to remove. In actual fact, ghostscript makes
> files in /tmp, but those aren't known to lpr, and ghostscript removes
> them itself. 

(nod)  The problem that I had with temporary files was only related to the
other comments because it involved the printing subsystem.  My ``ps''
printer filter doesn't involve any temporary files for lpr to clean up. In
the process of learning something about filters, however, I went through a
couple of scripts, and discovered this inconsistancy between the lpr man
page & the actual program.


> > > 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.
> 
> `lprm' with one job in the queue will remove that job. If there's two
> or three say, `lpq' will list them, and then `lprm N', where N is a

Then it's not working for me.  That was the ``obvious'' syntax that I
first tried; it doesn't work with either of the ``lp'' (default) or ``ps''
printer queues.  Again, the only oddity that I can point to is that both
queues share the same physical (parallel) port.

(However, as I think more about it, I'm 90% sure that I had the _same_
problem before I had a ``ps'' pseudo-printer configured.  So, I am even
more convinced that the fact that I have two printer queues has nothing to
do with this problem.  And, in that case, I am at a loss to explain it.)


> > > > 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
> > know.
> 
> What I should have said was, you can have two _printers_, but you
> can't have two _queues_ running on the same serial port. At one time,
> it seemed like a good idea to me, too, but it just doesn't work. If

Actually, this doesn't seem to be a problem as long as you don't print
files to both (logical) printers simultaneously.  I've been meaning to
play with using the queues simultaneously, and see how best to handle it.

It should work if my ``ps'' printer is directed to /dev/null and the
filter invokes lpr on the default printer (thus nothing would ever get
sent to the ``ps'' data sink, except perhaps GhostScript errors).
Effectively, then, _all_ actual printer data would have to move through
the ``lp'' queue.  This seems like the cleanest approach.

I wanted to also try playing with sharing a single queue directory (for
both logical printers), just to see if it would work.


> that's what you're doing, if "ps" and "lp" are the same printer,
> there's just no way to keep the pages from getting mixed up! It's a
> wonder all the jobs aren't completely garbled.

They might well be if I had each trying to access the port at the same
time.  (I had hoped that it might block multiple writers, but from what
you say, that's not the case.  I haven't yet tried.)  In practice, I use
the ``ps'' printer almost exclusively, so the fact that the ``lp'' printer
could interfere is a moot point.

(Obviously, if I were using this in a multi-user environment, I could be
MUCH LESS sure that such conflicts wouldn't occur.)


> I suppose that you want to print plaintext some times, and postscript
> at other times. The usual way is to install a filter that looks at the
> magic in the beginning of the file, and pipes the input throught the

I hadn't given this much thought.  This is probably reliable enough in
general.  Generally, I'm not accustomed to trusting a computer to guess
the right thing to do with arbitrary data.  This is probably a shortfall
on my part.


> appropriate commands. OTH, my simple needs are met with the following
> script:
> 
> case $1 in
>     -c) cat /dev/stdin 
>     ;;
>      *) /usr/pkg/bin/gs -q -sOutputFile=- "@stc.upp" /dev/stdin -c quit
>      ;;
> esac
> 
> Per printcap(5), the `-c' is passed iff lpr is invoked as `lpr -l'.

I was reluctant to start overloading the meaning of these parameters. None
of the standard parameters addressed PostScript, so I thought it best to
just create a seperate logical printer to handle it.  (I suppose that the
above can be said to be a reasonable interpretation of ``passing control
characters literally'', though...)


> That's only for playing with ghostscript. In all other cases, the job
> is filtered through ghostscript transparently, just as if it were a
> real postcript printer, except, of course, that real postscript
> printers know how to print plaintext. I use "enscript" for plaintext.
> Since "enscript" sends it's output to lpr by default, (as does dvips),

What dvips does by default depends on how you configured it under
texconfig.  At least, so texconfig claims.  I confess that I trusted
texconfig & haven't experimented...


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