On Tue, 3 Apr 2001, Frederick Bruckman wrote:

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

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

I am able to talk to my remote printer -- but I want to process/filter the
mail locally first. I tried "of" to point to my filter, but no data was
sent to the filter. When I use "if", it is ignored (not even used).

My question is: how can I get lpd to filter the mail locally before
sending it out to the remote lpd?

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

My remote print server is old, slow and doesn't have much disk space. I'd
rather not install ghostscript and use it to process/filter the print
jobs.

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

Strange. I am trying to look at the lpd history and even older lpd's
(before 1.5) have "-r":
     -r      The -r flag allows the ``of'' filter to be use if specified for a
             remote printer.  Traditionally, lpd would not use the output fil-
             ter for remote printers.
(I am using 1.5.1_ALPHA under i386.)

But I don't really understand "of=" because this filter is executed but no
data is piped to it.

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

I think that is my first error from when I had two printcap entries --
lp filter piped to lpr using -P to the remote printer.

But this error happens when I only have one lpd entry and it doesn't pipe
to another lpr.

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

It doesn't indicate any problems.

> you get it queueing and printing once, the status is restored from the
> "status" file in the spool directory whenever you start "lpd".

This is what I have:

/etc/printcap:

lp|hplj5|HP LaserJet 5:\
        :lp=515@pilchuck:\
        :rm=pilchuck:\
        :rp=raw:\
        :sd=/var/spool/output/lpd/lj5:\
        :lf=/var/log/lpd-errs:\
        :of=/home/reed/scripts/hplj5:\
        :mx#0:\
        :sh:

/home/reed/scripts/hplj5:

#!/bin/sh

gs="/usr/pkg/bin/gs -q -dSAFER -dNOPAUSE -r300 -sDEVICE=lj5mono
-sOutputFile=- -"

read first_line

first_two_chars=`expr "$first_line" : '\(..\)'`

# for testing
# this shows data if ran manually, but has no value when ran via lpd
logger -i -p lpr.info -t lpd echo first_two_chars is $first_two_chars
logger -i -p lpr.info -t lpd echo first_line is $first_line

if [ "$first_two_chars" = "%!" ]; then
   $gs && (
     logger -i -p lpr.info -t lpd user $USER printed with ghostscript ;
     exit 0 )
else
   echo $first_line 
   echo -n ^M 
   # This filter eliminates the "staircase effect"
   awk '{print $0, "\r"}'
   printf "\014"
   logger -i -p lpr.info -t lpd user $USER printed in plain text
fi

When I print a postscript file:
Apr  3 18:32:14 rainier lpd[3379]: echo first_two_chars is
Apr  3 18:32:14 rainier lpd[3380]: echo first_line is
Apr  3 18:32:14 rainier lpd[3383]: user reed printed in plain text

The remote lpd says:
Apr  3 18:32:11 pilchuck lpd[3032]: protocol screwup

From looking at the time stamps, I guess that the remote lpd is
communicated with even before this "of" filter is used.

When simply done manually (cat same postscript through my script):
Apr  3 18:32:57 rainier lpd[3395]: echo first_two_chars is %!
Apr  3 18:32:57 rainier lpd[3396]: echo first_line is %!PS-Adobe-1.0
Apr  3 18:32:59 rainier lpd[3399]: user reed printed with ghostscript

(Junk is just dumped to console.)

(Remote lpd is not NetBSD, but this shouldn't matter I don't think. It is
Debian Linux 2.2.)

   Jeremy C. Reed
   http://www.reedmedia.net/