On Tue, 3 Apr 2001, Jeremy C. Reed wrote:

> I am trying to configure lpd so it will process the data locally before
> sending it to a remote server (which has the printer).
>
> I have read through the manual pages (lpd and printcap) several times.
>
> First I tried to create two printcap entries. One for "lp" which used a
> "if" filter to process the data (ghostscript if needed) and then piped
> this to lpr using the other "rlp" (remote printer) entry. But it would
> never get to the second printer.

All you should need to do is add
":lp=515@remotehostname:rm=remotehostname:" ("printer" may work for
"515"), and also make sure the remote "lpd" is listening on port
515=printer on the remote (with "netstat -af inet").

That should work as least as well as running "ghostscript" and ssh'ing
the file to the remote "lpr". The only problem with that, is that
"lpd" balks at very large files. You can avoid that issue by running
ghostscript (through an input filter) on the remote.

> Then I tried using lpd with the "-r" option and then using a filter with
> the "of=" setting. (Only one printcap entry for lp which is for the
> remote.) But my remote lpd kept saying "protocol screwup" and "Your
> printer job (stdin) was not printed because it was not linked to the
> original file".

My "lpd", NetBSD-1.5, doesn't even have an "-r" option. What's that
supposed to do? In any case, "lpd" expects the filter to read on stdin
and output to stdout. If you're piping stdout to another printer
instead, no doubt that's what it's complaining about.

> So I added some checks to my "of" filter and then I noticed that no data
> was even going to it.

What does "lpc status" give? If it says the queueing is stopped, or
printing is stopped you could try "lpc restart" or "lpc enable". Once
you get it queueing and printing once, the status is restored from the
"status" file in the spool directory whenever you start "lpd".


Frederick