> I'm thinking of the LPD software that runs on some non-VM > system that controls the network PC printer. I haven't looked > at RSCS LPD support yet. > Could that be a possibility?
The LPD implementation that finally despools the output to the physical printer is the one that matters. That's the one that has the last word about how the incoming data stream is interpreted. That's usually either the one that's embedded in the printer (like a JetDirect card) or in the print server supporting the printer. It's possible that it is causing the problem, but most ASCII-based LPD implementations don't really do any translation on the input stream (they figure the client is the only one that cares, mostly for exactly this reason) and just pass it through to the printer. In this case, you'd still need to get the output to the printer somehow, so I don't think the RSCS LPD would really help you much -- you'd still have to turn around and resend the output to the printer, so you really haven't accomplished any simplification. The RSCS LPR support is likely to be the place to fix this. That's where you'd specify 437 to whatever translation (I'd suggest 8859-1, most everything handles that properly these days). You might try printing a config page from the printer, determining it's direct address, and bypassing whatever is in-between to determine where the confusion lies (direct LPR from RSCS is usually a good test). (And FWIW, if you're not using the RSCS LPR and LPD, you should switch ASAP. It's substantially better (thanks, Les!) and a lot easier to manage. All we need now is IPP support...8-))
