PCL Getting off the ground

[rhoaste]

Hi,

I've worked with other printer control type languages, but I'm a total noob to PCL. Some help getting off the ground would be fantastic.

I'm using a HP Laserjet 4050n, and a PCL6 windows 7 x64 driver. I've got some PCL examples, but I just cant get the printer to parse and execute the PCL. All I get is the physical string I send to the printer. Here's my PCL:


%-12345X*p300x400Y*c900A*c1500B*c25G*c2P

To print this I opened a new file in a text/hex editor, entered the text and then tried to print it. All I get is the literal text I entered above. Can someone please give me a clue as to what is happening?

Regards,

 

[DansDadUK]

Those  characters you display are usually the old DOS way of displaying the (non-graphic) escape control code character.

This character is the character with decimal code 27, or hexadecimal 1B, so (as you are using a hex editor) it would be better to enter this directly as (hex) 1B, to make sure that you are entering the correct character.

The other problem might be that after creating the PCL file, you then "tried to print it".
It depends what you/your application mean by 'print' in this context; it may be that your 'print' function is adding and/or subtracting bytes to/from the original.

Once you have created your file, all you need to do is 'copy' it direct to the target printer port.
How you do this depends on how the printer is connected:

- for parallel-port, use the DOS 'copy' command, specifying the /b switch.

- for USB, as per parallel-port, but needs a 'net use' command to link LPT1 to a Windows printer share.

- for TCP/IP-conncted, use 'lpr'.

 

[DansDadUK]

As indicated above, the driver is superfluous if you are generating your own (pre-composed) PCL stream.


... and in any case, the PCL6 driver will generate a PCL XL print stream; PCL XL (the 'proper' name for PCL6) is a totally different, incompatible, language to PCL5 (the language usually meant when referring to PCL).

 

[rhoaste]

Thanks for the information, I'm now able to print PCL and PS using the LPR command directly to my printer:

lpr -S 192.168.0.253 -P raw -o l test.txt

(Lower case L between -o and test.txt)

I now understand the windows print driver is superfluous. How would the selection of a printer be handled by a client application needing to print PCL? (assuming I'm on a network that contains nothing but PCL printers.)

In my nativity, I set up a generic text printer to a LPR TCP/IP port, expecting it to work, but it didn't. I thought this would have sent a "raw" text string to the printer without any device-specific data.

Regards,

 

[DansDadUK]

>> ... using the LPR command directly to my printer:
>> lpr -S 192.168.0.253 -P raw -o l test.txt
>> (Lower case L between -o and test.txt)

With Windows 'lpr', the '-o l' is usually superfluous (don't ask me why!).


>> I now understand the windows print driver is
>> superfluous.
>> How would the selection of a printer be handled by a
>> client application needing to print PCL?


You can 'copy' a specified file to a specified Windows printer share-name.
So if you can obtain a list of available printer shares ...


>> In my nativity

I assume that you meant to type naivity.


>> I set up a generic text printer to a LPR TCP/IP port,
>> expecting it to work, but it didn't.

This should have worked, provided that:
- the target printer supports PCL5 (which implies that it also understand plain ASCII text); cheap 'host-based' printers will not.
- the target printer has the "personality" set to 'Auto' (usual default) or 'PCL'.


>> I thought this would have sent a "raw" text string to
>> the printer without any device-specific data.

I suspect that 'Generic/Text' drivers (and these vary from version to version) DO add things to the print stream, like form-feed characters and (possibly) extra spaces to provide line margins.
I've no idea whether or not they remove anything (like non-graphic control code characters other than FormFeed and LineFeed).