PCL5 to PCL6 Migration 2

[VoltechMark]

I got my feet wet with PCL5 last year learning how to get a new product to print results. This seems to work fine on most printers.

Some of the newer printers with PCL6 (PCL XL) don't work. My understanding of PCL6 is that backwards compatability is sketchy, but assuming the printer is backwards compatible, should I be able to switch to PCL5 using PJL commands and print on these machines?

We can live with stating that our product is only PCL5 compatible (niche industrial market).

http://www.voltech.com

 

[jlasman]

In a word, no!

PCL6 is not backwards compatible with PCL5 at all.



Jim Asman

http://www.spectracolorservices.com

 

[VoltechMark]

Thanks for the help. Does this also mean that most PCL6 printers will not also have PCL5 available if I switch languages with PJL?

http://www.voltech.com

 

[jlasman]

Not necessarily.

I would expect that it is all about the price point of the printer. Cheap(er) printers are cheap for a reason.

Some have PCL5, PCL6, as well as postscript.

Others have no internal language built in and everything is generated by the printer driver, probably turning the page into a large bitmap. Some have PCL6 only.

PCL6 output is akin to compiled obect code, so if your application is generating your PCL output directly, then I would think it would be very difficult to create PCL6 code directly. PCL5 is interpreted as it is received by the printer, so it lends itself to generating the output as you are doing it now.

Let's see what Dan'sDad has to say.





Jim Asman

http://www.spectracolorservices.com

 

[DansDadUK]

I agree with Jim's replies.

The only things I'd add are:

(a) The printers which don't support any of the traditional Page Description Languages (PDLs), like PCL5, PCL6 or PostScript, are usually known as 'host-based' printers (sometimes as 'Windows' or 'GDI' printers).

These DO actually support a printer language, but this can vary from model to model, and in all cases the language is proprietary and not publically documented.
Modern ones use 'JetReady', older ones used LIDIL.

As far as I can determine, the current 'JetReady' is a very stripped down variant of PCL6, with a very limited set of commands.

What the driver appears to do is to generate a series of encapsulated, compressed, raster images (one or more per page); the interpreter in the printer just unencapsulates and uncompresses these images, and prints the resultant dots.

(b) It's not that difficult to generate a PCL6 (PCL XL) print stream, ONCE you have understood the structure - for the simple reason that it IS a very structured language.

But it is MUCH more difficult to interpret, or to modify an existing PCL6 print stream than to do the same with PCL5.

 

[VoltechMark]

Our print jobs are very simple, no graphics, just a stream of text. Do I understand PCL6 correctly in that once I open up a data stream with the correct command sequence, I can send ascii (or a binary representation) to the printer then close the job with another sequence?

Or is it similar to some of the posts I have read that the font is encoded and the data is encoded based on the font header, so I am doomed without some chunk of code that can generate the whole job?

http://www.voltech.com

 

[DansDadUK]

You can't just send ASCII text once the printer is in PCL XL mode.

Here is a snippet from an analysis of a PCL XL print stream, showing just a couple of Operators and their (preceding) Attribute lists, which may make things a bit clearer:

Offset(dec)  Type                   Sequence          Data / Interpretation
¯¯¯¯¯¯¯¯¯¯¯  ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯  ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯  ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

0000036381   PCLXL Data Type        0xd3                  sint16_xy
0000036382              Value       0xc0030309            960 2307
0000036386   PCLXL Attribute        0xf84c              Point
0000036388   PCLXL Operator         0x6b              SetCursor
0000036389   PCLXL Data Type        0xc8c11000            ubyte_array
0000036393              Value       0x404142..            "@ABCDEFGHIJKLMNO"
0000036409   PCLXL Attribute        0xf8ab              TextData
0000036411   PCLXL Data Type        0xc8c11000            ubyte_array
0000036415              Value       0xc8c8c8..            ( 200 200 200 200 200 200 200 200 200 200 
0000036425                          0xc8c8c8..              200 200 200 200 200 200 )
0000036431   PCLXL Attribute        0xf8af              XSpacingData
0000036433   PCLXL Operator         0xa8              Text

Note that (for brevity) this snippet is quite a way down the stream (as indicated by the Offset values), so it doesn't show the stream header, any BeginPage or EndPage operators, or any font 'selects', etc.

The Sequence column shows the actual contents if the print stream (in hexadecimal notation).

Note that 0x4c (i.e. hexadecimal 4C) may be an Attribute identifier (Point in this example), or could be the text character L, depending on context.

Similarly, 0x6b (i.e. hexadecimal 6B) may be an Operator identifier (SetCursor in this example), or could be the text character k, again depending on context.

Note also that the XSpacingData attribute of the Text operator must be present in order to specify cursor movement between the text characters, so you need to know the 'Advance Width' of each of your characters in the chosen font, at the chosen point size.
If you don't specify this, all characters will be (over-)printed at the same position.

The XSpacingData values in the snippet are all 200 (earlier Operators (not shown) specified that the chosen units are 600 per inch).
As the values are all the same, this implies that the selected font is almost certainly a fixed-pitch one.

 

[VoltechMark]

Thanks for your help. It looks like we will be stuck generating the entire print job each time. Not something we are likely to be able to do on our current product.

It would be nice if someone had a magic chunk of C code to compile an ascii bit of text into a print job. It is possible in future products to devote some processor time to building our print jobs.

Again, thanks to jlasman and DansDadUK for the help. You guys are real gurus!

http://www.voltech.com

 

[DansDadUK]

If you go to the HP 'developer' web site, which recently moved to:

http://spp.austin.hp.com/sppmain/

and select the "Public Software Development Kits" option, then the "LaserJet and Digital Sender" kit area, you'll find a large amount of publically available documentation, tools, etc.

I haven't visited it in a while, but I vaguely recollect that, somewhere in the PCL6 section, HP supply a 'TextToXL' tool - I can't remember if it is just an executable, or if it also gives you the source code.

It will be quite old, so will probably only generate Class/Revision 1.0 streams, but this should be fine, on most PCL6 printers, for just printing text.

 

[VoltechMark]

Thanks so much!! HP do supply a Text2XL tool, and they provide source code. This type of thing will be exactly what we need. We will need to generate a PCL6 print job from our ascii text results.

You have been a great help.

http://www.voltech.com

 

[jlasman]

Is your intent to produce only a PCL6 version of the document?

I would think that PCL6 only would preclude more printers than PCL5 output. In a plain text file, chances are the PCL5 file would also print properly on a PCL3 inkjet as well.


Jim Asman

http://www.spectracolorservices.com

 

[VoltechMark]

If I have the ability to produce PCL6 print jobs, I can have the user select PCL5 or PCL6 in our menu system. Most people will always be printing to the same printer and will not have to fiddle with the setting very often.

We are adding more advanced USB print capabilities to our Power Analyzers to allow customers to print results directly.

http://www.voltech.com