On 12/11/05, Garance A Drosihn <[EMAIL PROTECTED]> wrote: > 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. >
Cool. Thanks for the explanation and it makes complete sense because the queue on the server always stuck at 0 bytes. I do know that the lpd on the little wireless print server I have doesn't require byte counting from XP boxes. Greg
