From: Todd Pfaff (todd@flex.Eng.McMaster.CA)
Date: Tue Feb 04 1992 - 21:13:36 CST

Another tardy summary :-)

I asked:

] Suppose I want to do the following with lpd: I want host A to print to
] a queue on host B, but I want host A to do the if filter before sending
] to B. I tried the following printcap entry on host A, but the if filter
] seems to be ignored.
] lp:if=text2ps:lp=:rm=B:rp=ps:sd=/var/spool/lp
] Other alternatives are I have already considered are:
] 1) Do the filtering on host B. This is not possible in this particular
] case for reasons I don't want to explain.
] 2) Preprocess the input before sending it to lpr:
] text2ps | lpr
] I also want to avoid this solution.
] 3) Have the lp queue on A do the filtering and then launch another lpr
] to send the output to B:
] lp:if=foo:lp=/dev/null:sd=/var/spool/lp
] ps:lp=:rm=B:rp=ps:sd=/var/spool/ps
] where foo is
] #!/bin/csh
] text2ps | lpr -Pps
] This introduces the problem that the second invocation of lpr is owned
] by daemon and thus users can't remove their own jobs. This alternative
] would be fine if it wasn't for this problem. Is there some way I could
] overcome this problem (maybe find out what user did the original lpr
] and setuid to this user?).
] Is there some way I can solve this problem with the Sun supplied lpd/lpr or
] is there an alternative spooler out there which will do what I need?

From: John Valdes <>

I'd be interested in what you find; please summarize. We have a similar
need here. Our PostScript printers are all on an AppleTalk network, which is
bridged to our ethernet with a GatorBox. The software on the GatorBox allows
unix machines to print to the printers behind its AppleTalk net by appearing
to the unix machines to be a remote printer server. However, the software only
supports text filtering, so everything printed must be text or PostScript.
We currently use Transcript and CAP to work around this (actually, I think
using CAP is better anyway, as using the GatorBox for printing will make
printing slower than it already is.
From: (Peter Farmer)

The prelimn filter manager software in Suns NeWSprint system does exactly what
you need. It uses client/ server approach to printing in which the filtering
can be done on either side. It works really well for us, & has a lot of other
excellent features. Of course it costs money :-) ...

Here is how I handled a similar situation, where my local interleaf needed
to do some processing but I wanted the result to go to a printer on another
machine. It uses 2 queues. First, here is the simple queue to get to another

lw|scud line printer:\

Here is the other queue that Interleaf writes to:

        :printerleaf=/interleaf/tps4.0/sysio/ps/pl2ps -RV -r 1270 -T pslw+ \
         %! /usr/ucb/lpr -Plw -h:\
        :other=/usr/ucb/lpr -Plw -h:

Note that this routes the "printerleaf" through a pl2ps filter and then pipes
it ("%!" is a baroque pipe symbol, it turns out!) to lpr explicitly redirecting
to the lw printer.

Works like a charm, hope this helps you out.

] Yes, but as I already pointed out to Tom, this is exactly the alternative
] number 3 in my original posting.
] Note to Tom:
] Get Interleaf 5. You can eliminate all this crap by filtering on the
] desktop and then printing to the physical printer queue. Plus it has
] lots of other new features, and runs under X as well as SunView.

From: johnb@edge (John Benjamins)

I think you've just about exhausted the possibilities with the SunOS
lpr/lpd. You might try looking at hacking up the lpr/lpd sources from
Berkeley. Another alternative that might work is plp, which is like
lpr/lpd, but has a number of enhancements. I have never used it
myself, and I only looked at it once a couple of years ago.

I have set up a situation which may apply to you too.

Essentially there are two printers, one which does the filtering, and looks
to lpd like a local printer, but in fact what it does is pipe the filtered
output to another (remote) printer.

E.g. /etc/printcap looks like this:
amd_flw|fl|AMD laser printer pre-filtered:\
amd_lwf|lf|AMD laser printer plain text:\
amd_lw|lw|lp|amd_vaxlw|AMD laser printer:\\

and /var/spool/lpd/filters/thack.lw looks like:
/usr/local/bin/thack | lpr -Pamd_vaxlw

] Again, I think this would be like alternative 3 mentioned in my posting.
] Once the filtered job has entered the amd_vaxlw queue it's owned by daemon
] and the user who submitted the job can't remove it.

From: (Chuck Smoko - E41)

I was trying the same thing. We have gator boxes that do lpd but they
can't distinguish postscript from text. Users are expected to send ps
to the ps queue and text to the text queue. I would like the filter to
look for the %! and send it as is or if the %! is absent, filter the
data with some sort of ascii to ps filter. If you get anything on this
subject, PLEASE summarize or send me what you find.
From: (Wolfgang Kuehnel )

As far as I know the Athena project encountered exactly the same problem.
They have rewritten the lpd program to do the job just like you want it to be.

The Athena Software is available for SUN from MIT. Get it and check it out.
From: (Eckhard Rueggeberg)

You get the user as $5 in an input filter.
From: trdlnk!mike (Michael Sullivan)

The command line parameters supplied by lpd to the input filter include
the user's login name, see the System Administration manual for details.
From: Kanthan Pillay <svpillay@Princeton.EDU>

One solution that comes to mind is that since transcript is providing a
way of fiddling with the data before it gets sent off to the printer,
you could simply hack the transcript filter script so that instead of
calling psof, it takes the output and pipes it through "su $USER lpr
-Preal_printer" You could even get by with not hacking the transcript
filter script and simply redefining the output filter in .options in the
spool directory.

All of this does require that you be running transcript. (-:

Todd Pfaff                      \ Internet:
Dept. of Mechanical Engineering  \   Voice: (416) 525-9140 x2902
McMaster University               \    FAX: (416) 572-7944
Hamilton, Ontario, CANADA  L8S 4L7 \

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:35 CDT