How to ignore old PCL commands

[k_j_r]

Hi

I have old programs which generate text files with PCL commands to select bold, different fonts and landscape when printing.

One command seems to be no longer supported on the replacement printer HP LJ M452dn we have started using and this stops the print job from completing.

&k6W

I found some documents detailing this as a HP PCL deskjet command , specifically "text scale off". Opening these in a editor and deleting the command produces a print out.  Editing the old programs would then require QAing.

Can this printer be made to process or ignore this PCL command ?

KJR

[dansdaduk]

The escape sequence you refer to does indeed appear to be a PaintJet/DeskJet sequence (although it appears to indicate "text scale ON" rather than "text scale OFF") :

 

As a PaintJet/DeskJet sequence, it is not relevant to LaserJet devices, and anyway, it appears to be an obsolete sequence.

PCL5 printers usually ignore syntactically valid sequences which they do not support/understand, so I don't really know why "... this stops the print job from completing ...".

In what way is the job stopped? Do you get an error message, or a corrupt image, or what?

As to your question "...  Can this printer be made to process or ignore this PCL command ?...", the only way would be for the firmware to be modified and updated - this is something that only HP can do (if they choose to).

[k_j_r]

Hi

I only found the definition in one place , didn't see anywhere else to verify if it was ON or OFF.

The text file is generated with a line along the form of :

<esc>E <esc>&k6W <esc>&l8D <esc>&l1O .........

The printer seems to be confused by the &k6W , does not see the &l1O as the landscape command.
Sometimes it prints a blank page with &l1O on it and stops there. But I also see a page with "&l1O" and some text not in landscape ( and off the right hand margin.)

I didn't see anything in the printer setting and thought ignoring the &k6W would require a firmware change.

But I now see if I make another command invalid the printer ignores it , but does see the landscape command. I wonder what is different about &k6W. I assume this silently ignoring invalid commands is okay for most customers.

[dansdaduk]

I don't know for sure why the escape sequence represented as:

<Esc>&k6W

confuses your printer such that it appears to ignore some of the following sequences, but I'd hazard the following explanation:

• As the excerpt I provided in my previous response noted:

• As far as I know, all other parameterised escape sequences which use "W" as the termination character are expected to be followed by # bytes of binary data (where # is the value preceding the termination character).

• Since your LaserJet  printer almost certainly doesn't know about this (obsolete) DeskJet escape sequence, the firmware may assume that (in ignoring the sequence), it also has to ignore the following 6 bytes of (assumed binary) data.

• This means that your set of sequences:

• <Esc>E<Esc>&k6W<Esc>&l8D<Esc>&l1O .........

  would probably be interpreted as:

  <Esc>E&l1O .........

i.e. you've completely lost the 'line spacing' sequence, and the 'set orientation' sequence has lost its introductory <Esc> control-code byte, so that it is no longer recognised as an escape sequence, but is just treated as plain ASCII text.

This explanation seems to fit your symptoms.

You could perhaps test that this explanation is valid by slightly modifying your set of sequences to include six text bytes following the rogue sequence; e.g.:

<Esc>E<Esc>&k6W??????<Esc>&l8D<Esc>&l1O .........

[Jim_Asman]

Could it just be a corrupt file or do you have several instances with the same problem?

It doesn't feel right.

[dansdaduk]

I've set up a couple of very simple PCL test files (based on your 'snippets', and my previous comments), and tested them on my two local (LaserJet) printers (albeit with differing results).

The two files are attached (within a .zip file), together with analyses of the content of those files.

Analysis of the first file (test01.pcl) shows:

<Esc>E            Printer Reset
<Esc>&k6W         Print Mode (Text): Text Scale On
<Esc>&l8D         Line Spacing (8 lines-per-inch)
<Esc>&l1O         Orientation: Landscape
<Esc>*p600x       Cursor Position Horizontal (600 PCL units)
       600Y       Cursor Position Vertical   (600 PCL units)
ABCDE
<Esc>E            Printer Reset

which indicates that the text "ABCDE" should be printed after setting the orientation to Landscape.

When the content of this file is sent to my local LaserJet Pro 400 MFP M475dn printer, the result is:

• A portrait page.
• The text "&l1O" is printed at the top-left  of the page.
• The text "ABCDE" is printed lower down the page.

This result appears to imply that the LJ M475 printer treats the rogue sequence much like your printer does.

When the content of this file is sent to my local LaserJet 1320n printer, the result is:

• A landscape page.
• The text "ABCDE" is printed lower down the page.

This result appears to imply that the (older) LJ 1320 ignores the rogue sequence, but does not ignore the following 6 bytes.

Analysis of the second file (test02.pcl) shows:

<Esc>E            Printer Reset
<Esc>&k6W         Print Mode (Text): Text Scale On
??????
<Esc>&l8D         Line Spacing (8 lines-per-inch)
<Esc>&l1O         Orientation: Landscape
<Esc>*p600x       Cursor Position Horizontal (600 PCL units)
       600Y       Cursor Position Vertical   (600 PCL units)
ABCDE
<Esc>E            Printer Reset

which is based on test01.pcl, but has six bytes (each being the "?" character) following the 'rogue' sequence.

When the content of this file is sent to my local LaserJet Pro 400 MFP M475dn printer, the result is:

• A landscape page.
• The text "ABCDE" is printed lower down the page.

This result again appears to imply that the LJ M475 printer treats the rogue sequence much like your printer does; the sequence and the following six bytes (the "??????" text) are ignored (but the 'set landscape' sequence is retained).

When the content of this file is sent to my local LaserJet 1320n printer, the result is:

• A portrait page.
• The text "??????" is printed at the top-left of the page.
• A landscape page.
• The text "ABCDE" is printed lower down the page.

The (slightly odd) result obtained from the LJ 1320n is probably because:

• This printer has ignored the rogue sequence, but not the following six bytes (as indicated by the first test).
• These six bytes "??????" are hence printed, on a Portrait page (at this stage, the default orientation is Portrait).
• The 'set landscape' sequence is then executed, which initiates a page eject (since the oriention has changed after 'page marking' has occurred on the current page).
• A landcape page is started, and the text "ABCDE" is printed.

[Jim_Asman]

Could the difference in behavior you are seeing be as simple as one printer being monochrome and the other being color? 

[dansdaduk]

>> ... Could the difference in behavior you are seeing be as simple as one printer being monochrome and the other being color?

I don't think that this is relevant (even though the results we have so far indicate that the LJ M452 and LJ M475, which are both colour devices, exhibit the problem, whilst the (much older) monochrome LJ 1320 does not.

There are a number of current escape sequences (although they won't all be supported on all printers) which use the "W" termination character:

<Esc>&a#W     Define Logical Page (data length = #)
<Esc>&b#W     Configuration (I/O) (data length = #)
<Esc>&c#W     Cluster Printing (data length = #)
<Esc>&i#W     Underware Function Configuration (data length = #)
<Esc>&n#W     Alphanumeric ID (data length = #)
<Esc>&p#W     Escapement Encapsulated Text (data length = #)
<Esc>(f#W     Define Symbol Set (data length = #)
<Esc>(s#W     Download Character (data length = #)
<Esc>)s#W     Download Font Header (data length = #)
<Esc>*b#W     Transfer Raster Data By Row/Block (data length = #)
<Esc>*c#W     Download User-Defined Pattern (data length = #)
<Esc>*d#W     Palette Configuration (data length = #)
<Esc>*g#W     Configure Raster Data (data length = #)
<Esc>*i#W     Viewing Illuminant (data length = #)
<Esc>*l#W     Colour Lookup Tables (data length = #)
<Esc>*m#W     Download Dither Matrix (data length = #)
<Esc>*o#W     Driver Configuration (data length = #)
<Esc>*v#W     Configure Image Data (data length = #)

With all of these, the # value signifies the length (in bytes) of the (usually binary) data following the termination character.

There are also a few sequences which are now considered to be obsolete, and probably not supported on any current printer:

<Esc>&k#W     Print Mode (Text) (# = discrete value)
<Esc>&l#W     Define VFC Table (data length = #)
<Esc>*t#W     GPIS Data Transfer (data length = #)

Of these, the only one which does not follow the convention of the # value signifiying the length of following data, is the 'rogue' sequence we've been discussing.

There are a couple of other sequences which use the "W" termination character:

<Esc>(#W      Primary Font: Symbol Set (identifier = #W)
<Esc>)#W      Secondary Font: Symbol Set (identifier = #W)

but:

• These sequences have no Group character, so are not really the same as the normal parameterised sequences.
• I'm not aware of any standard symbol set with identifier of the form 'nnnW'.

I think that the issue is merely down to how the different generations of printers (which almost certainly have the PCL intepreters in the firmware written by different teams, or third-parties) handle 'unknown'  PCL escape sequences:

• They all ignore unknown (but syntactically-valid) escape sequences.
• The more modern printers appear to assume that all parameterised sequences (even 'unknown' ones) which use the "W" termination character are followed by associated data (the length of which is given by the # value preceding the temrination character) and remove not just the sequence, but its (assumed) associated data.
• Since the sequence in question is 'unknown', it is a moot point as to whether the approach taken by the modern printers is any more, or less, correct than that taken by the older printer.

[k_j_r · Accepted solution]

Glad to see you were able recreate the problem.

I am told a 4250 was being used to print these text files previously and it was hoped we could replace it with a 452 we had available.

As we cannot easily change the programs being used to generate the text files for printing , in order to quickly get past this issue  we are looking at getting another 4250.

It has been useful to learn more about the meaning of these variaous PCL commands as at some point in the future there will be an opportunity to alter the programs generating before any planned QA.

Thanks for your investigations and help.

KJR