At 10:25 AM -0800 12/4/05, Greg Thomas wrote:
On 12/4/05, Steve Murdoch <[EMAIL PROTECTED]> wrote:
 >
 >  Any issues I had printing from XP went away when I enabled
 >  LPR Byte counting in the LPR port settings.


Any ideas why that is?

Apparently Windows (in general) does not like to keep a byte-count
for a file.  It is not a saved attribute of a file, so "something"
(I don't know what) has to count the bytes.  This is overhead, so it
defaults to off.  I know little about windows, so that description
might not be 100% accurate.

However, I do know about unix implementations of lpd.  When a file
is transferred, the remote side first says how many bytes it is
going to transfer, and it then transfers that amount of data.  The
RFC for lpr implies that you can put in a zero for the length, in
which case lpd will just keep reading until the end-of-file
condition.  But in fact there are no implementations of lpd for
unix which actually do that (well, none that I've noticed at least.
I guess lprNG might, I haven't checked that one).  If you tell lpd
you're going to send zero bytes, then by golly it thinks you will
send a zero-byte data file.

So if you don't turn on LPR byte-counting, then these Windows
implementations will send the 'count' field to zero, which should
work according to RFC 1179, but won't in fact work with most
implementations of lpd for Unix.

--
Garance Alistair Drosehn            =   [EMAIL PROTECTED]
Senior Systems Programmer           or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute    or  [EMAIL PROTECTED]

Reply via email to