PCL(?) Printing Problem (Linux Server-Win2K Client)

[klugenratte]

I am having difficulty getting my Windows 2000 Pro client to print correctly to an HP DeskJet 952C connected via parallel port to a RH 8.0 server acting as a PDC.

I can see the printer in Windows 2000 and send data to it, however the print is a bunch of garbage ASCII characters with the only legible text being @PJL ENTER LANGUAGE=PCL3GUI. TO me this error indicates that the printer is not correctly interpretting PCL3 language being sent to it.

I started with the hpijs driver on the RH box and could print all test pages successfully from that box, but received the garbage described above from the Win2K box.

So, I switched to the PCL3 driver on the RH box. After doing so, I got the garbage described above when printing from both systems (Win2K client and RH 8.0 server).

So, I switched to the cdj970 driver on the RH box. After doing so, I could once again print from the RH box, but still got the garbage ASCII when printing from the Windows box.

I have downloaded and installed the most recent Windows printer drivers from HP and have tried sending the data to the printer in both RAW and EMF format.

If I use the generic/text print driver in Windows I can print. But, of course, I can only print text.

Any suggestions? BTW - I do not have an X display on the RH box, so please no suggestions using tools that require you start X.

[cowanrl]

The garbage text you are getting in your printout indicates an incorrect or incompatible printer driver on the Linux machine.

I have found the best thing to do when sharing out a Linux printer with Samba to Windows clients is set the queue type on the Linux machine to Raw.
With this set up, the print driver on the Windows machine does all the work. All the Linux print server does is just pass the print job on to the printer unmodified.

If the printer will also be printed to locally on the Linux machine, I just set up another queue using the proper Linux printer driver and print to it. I don't try to print to that queue from the Windows machines.

I always create my printers using a GUI program so I'm not sure how to do it otherwise. Here's the section from /etc/printcap for an HP890C connected to the parallel port set up with a raw print queue. I share it out with Samba and it works fine from any Windows machine with the proper print driver installed.


HP890C-Raw:\
:sh:\
:ml=0:\
:mx=0:\
:sd=/var/spool/lpd/HP890C-Raw:\
:af=/var/spool/lpd/HP890C-Raw/HP890C-Raw.acct:\
:lp=/dev/lp0:


This is from a Red Hat 7.2 machine using lpd printing. Don't know if that will help out or not.

[bwkaz]

It might work without the modifications that cowanrl is suggesting, if you can set the Windows client(s) to send PostScript instead of converting the print job to the printer language and then sending it.

I think that using the "generic/text-only" driver might work for this, though I really don't know for sure. There might be a PostScript-specific driver, too.

<rant>Why on earth does Microsoft have to come up with its own crap "standards" for everything? The Unix world standardized on PostScript as a printer language before Windows was even around... how hard could it possibly be? But no, that would introduce compatibility! Can't have that! :rolleyes:

Ah, better idea! Let's let the printer driver handle the conversion from our internal GDI buffer format to the printer's language! Yeah, that'll work!</rant>

So now, you have each different Windows driver sending different data down the network pipe to each different printer model.

That data (PCL 3) is what your Samba server is seeing, and either it or the printer queue is probably escaping it, so that the data that it sees is what gets printed.

Local printing works because that escaping doesn't happen, I think.

[klugenratte]

Thank you for your help, the problem is resolved.

I compared cowanrl's /etc/printcap to mine and found I had two additional lines:

:lpd_bounce=true:\
:if=/usr/share/printconf/util/mf_wrapper:

I commented out these two lines and could immediately print from Windows.