How to print from Windows XP to cups-lpd

[Kai Lanz]

> Kai Lanz wrote:
>
> >
> > You're right! My little program works better than I thought. If I print
> > from a Mac, it captures only the one line I posted earlier:
> >
> > 00000000  02 61 36 35 2d 6c 61 73 65 72 6a 65 74 0a        .a65-laserjet.
> >
> > But if I print from a Windows XP PC, it captures what looks like the
> > entire data file. To see the file I got, go here:
> >
> >     http://pangea.stanford.edu/~lanz/cups
> >
> > where you should see 3 files, mac2lpd.raw (14b), pc2lpd.raw (53603b), and
> > pc2lpd-hex.txt (a hex dump of pc2lpd.raw). If that doesn't work, you can
> > grab the same files via anonymous ftp to pangea.stanford.edu, in the
> > /ftp/pub/lanz directory.
> >
> > The file captured from the PC print attempt starts with the same line as
> > the Mac capture, but the PC example then continues with what looks to me
> > like the expected PJL preamble, starting with the <ESC>%-12345X at PJL
> > string.
> >
> > I hope this is useful. Thanks for your help.
> >
> > -- Kai
>
> Kai,
>
> what I could deduce immediately from your files is that the LPD service on
> your Windows box obviously does not conform to the LPD protocol as described
> by the RFC 1179 (that is the one cups-lpd is designed after), whereas the
> mac side behaves correctly (as you stated earlier).
>
> What kind of LPD software do you use on your Windows box?
>
> Helge

Helge,

We have no special printing software installed on our Windows boxes -- we're
using whatever LPR/LPD support is standard in WinXP Pro. (That is, we add a
local printer with custom port settings, choosing the LPR protocol, which
automatically selects port 515 on the server.)

However, I have discovered what seems to have been the problem. We must check
the "LPR Byte Counting Enabled" box in the custom-port-settings configuration
panel. With that option turned on, I see the same behavior using a PC to print
to my little lpd-replacement program as I do when printing from a Mac, and if
I restore the real cups-lpd in xinetd, the Windows print files show up in the
queue and in the spool directory, as expected.

So, our problem is solved. Thanks for your comments; they convinced me I needed
to check very carefully what we were doing on the Windows side.

-- Kai