The PCL commands are coming from the HP printer driver. (Obviously) The
leading data isn't making it to the print server, or it cannot pass it on to
the printer. Some of the print servers use "unique" character sequences for
control, and strip them from the data sent to the printer.
Turns out that this is not an uncommon problem, as we've given up on the
units for similar reasons. A printserver can loose leading data from pages
sent as "RAW" as well. I believe the Mfr took several models off the market
sevral years ago for similar reasons. An old solution was to begin and end
each "job" with a seperator sheet, so that the errors occurred on that
sheet, and did not impact actual printed output.
Admittedly, the problem may actually be a lan related probleml. File
transfer may succeed (some what slowly) under conditions that cause problems
with a simple print server.
"Michael Covington" <for.address.look@newsgroup> wrote in
> Michael Covington wrote:
>> Michael Covington wrote:
>>> Alan Morris [MSFT] wrote:
>>>> Disable Bidirectional on the Ports tab in any of the Windows
>>>> configurations. Linksys states this on their support site.
>>> It is a standard TCP/IP port, LPR protocol, and "Enable bidirectional
>>> support" is already unchecked and grayed out.
>>> Where does Linksys say this? Maybe there are other clues there. I have
>>> not found their support site to be very well organized.
>> I found it (or rather found where somebody had quoted it) and the crucial
>> setting, described along with what you mention, is "Print Directly to
>> Printer." Apparently the corruption was connected with spooling.
>> Thanks for the pointer.
> No, that didn't actually fix it either. The problem is somewhat
> intermittent (happens maybe 75% of the time, but there are occasional runs
> when I can print several jobs in a row without seeing it). I'm still
> eager to know if it's fixable.