(For the benefit of the mailing list at large...)

I believe that I have finally found my problem: I did not have the
"sf" capability on my "raw" printcap entry.  For the sake of posterity,
here is my present understanding of the situation:


Normally, after reading a print job, lpd will append a formfeed (^L) to the
end of the data.

This did not affect me when I used the directly-attached printer because
the FF was attached before running through my filter.  The filter, in turn,
was just a wrapper for GhostScript, which interpreted the FF control
character as whitespace in the PostScript program, and threw it away.  Thus,
the original configuration worked.  The ``ps'' printer using GhostScript
directly dumped to /dev/ulpt0 rather than sending through ``uraw'', so
all was well.

Now, however, I need to forward print jobs to another machine, and the
picture changes somewhat subtly.

When I has my ``ps'' printer pipe into ``uraw'', which then forwarded the
whole thing over the network, the *local* uraw printcap did not append any
FF bytes because it expected the remote printer to handle that.  The
remote printer, however, DID append an FF byte.

As a result, after the print job had finished, my printer was passed
a trailing formfeed and ejected a blank page.

By adding a :sf: capability to the uraw printcap entry on the machine
where the printer was physically attached, I killed this behavior and
it once more behaves as it should.


I've scanned the .../src/usr.sbin/lpr/* sources somewhat to make 100%
sure that :sh: ONLY applies to the FormFeed bytes ADDED by the the
printer system (rather than ``suppressing''/filtering FFs already in
the data).  This appears to be correct.

If others agree that the printcap man-page is a little unclear about
what it means to ``suppress'' formfeeds, I'll send-pr that.  (I may be
a bit biased, having just been bitten by it.  ...of course, the fact
that I *was* bitten is a fairly good argument that it's less than
perfectly clear.  (^&)


Anyway, the happy news is that I seem to have fixed the problem and will
no more be wasting one sheet of paper per print job.  (Well, okay, I
was putting the blanks back into an input tray in a way that I normally
do for duplex printing.  I've not had a paper jam doing it this way, so
I consider the paper "safe" for this...)


Thanks to all who gave help and relayed some of their own anecdotes
about similar problems.  If not for the continual ping-pong of ideas,
I probably would have just given up and bought a USB hub as the cheapest
``solution''.  (^&  (That, or reattached the printer to my main system...)


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/