HPGL macro with embedded PCL escape sequence

[win32dev]

I have a PCL file which also contains HPGL. Embedded in the HPGL command is a PCL code like this:

(some HPGL)
^[&a1r1C
(more HPGL)

Based on observations (sending file to lj4250), it seems the PCL code is moving the HPGL cursor position -7 units vertically (could this be based on the current font definition?).

I cant find any reference to this behavior in the PCL 5 Printer Language Technical Reference Manual, nor in the HP-GL/2 and HP RTL Reference guides.

Does anyone know where (say a manual) where this behavior is documented?

Thanks

 

[webrabbit]

I assume the "^]" represents the escape character.

According to the "PCL Printer Language Technical Quick Reference Guide" (an old one, I can't find a date on it), this should move the cursor one line (row) down and one column (based on the active font) to the right. This is all relative to the current page orientatiion.

PCL5 supports only one page orientation per page (a change in page orientation will cause a page eject), but with HPGL you can change the font orientation as desired.

PCL5 and HPGL can be freely mixed in a document.

 

[win32dev]

While its true you can mix PCL5 and HPGL in a document, the specification also indicates you are supposed to switch from one mode to another using escape codes (Esc%#B) and (Esc%#A). The specs do not appear to dictate the printer behavior in cases where someone has embedded a PCL escape code while the printer is in HPGL mode.

Assume ^[ represents the Escape character
pcl data
^[%0B
hpgl data
SD2,1,4,6,5,0,6,0,7,16602;
PA;PU000,432;PR;
...
ER5,5;
^[&a1r1C
PR;PU000,-17;ER500,-24;
PU002,-07;LBRevision X^M~;PU-2,+7;
...

The PCL sequence is nested inside of an HPGL mode stream. Is this nesting valid?

Our printer accepts the PCL escape sequence, processes it, and move the HPGL vertical cursor position -7 units, the horizontal cursor position seems to be unaffected. Changing the values of "&a1R" or "&a1C" seems to not change the effect. I cant find any references as to why this should occur. Also, I need to quantify the behavior for a programming project.

Am I missing something? Is there an Addendem to one of the HP reference manuals I am missing?

 

[DansDadUK]

As far as I'm aware, the 'switch mode' specification has not changed; the Technical Reference manual states:

As soon as the printer receives [the Enter HP-GL/2 mode] command, it switches to HP-GL/2 mode, interpreting commands as HP-GL/2 commands until it receives an Enter PCL Mode, EcE [PCL reset], or UEL command, or until the printer power is switched off and on.

It appears that the firmware in your printer may extend this to interpret the presence of ANY escape sequence as meaning 'return the printer to PCL mode'.

It may do this rather than abort the job if illegal sequences are detected (I don't think that the specification defines what action is to be taken); but other printers just ignore the 'illegal sequences'.

I'd play it safe, and NOT use the sequences in the way that you describe.


When these sequences ARE acted on, bear in mind that (according to the specifications):

(a) The {esc}&a#C sequence moves the cursor to a new position along the x-axis in terms of columns; the column width is determined by the current Horizontal Motion Index setting).

(b) The {esc}&a#R sequence moves the cursor to a new position along the y-axis, in terms of rows; row height is determined by the current Vertical Motion Index setting.

 

[DansDadUK]

Those escape sequences cannot be setting the device back to 'PCL mode', otherwise the HP-GL/2 commands following those sequences would be interpreted as plain text data (because there is nothing to return the device to 'HP-GL/2 mode').


So I suspect that the result is just your printer's reaction to an illegal command/sequence; another printer may react quite differently.

 

[win32dev]

The file I am working with is most likely generated by an SAP product, so I have no control over the contents (big sigh). I managed to strip most of the content to build a working example.

I have tested the example file on a few HP 2000 and 4000 series LJ printers without issue (a simple set of boxes with some text). The file prints with four neatly aligned rows of data.

Viewing the file with at least one PCL viewer shows the boxes as overlapped. Printing from the viewer also results in overlapped rows. I suspect the viewer is stripping (ignoring) the escape sequence and the printer is 'doing' something with them.

 

[jlasman]

Study the commands...

^[%0A
^[%1A

^[%0B
^[%1B

Depending on the command you use to return to HPGL, you may very well lose all cursor positioning made while in PCL mode.


Jim Asman

http://www.spectracolorservices.com

 

[win32dev]

That not the issue in this case, passing/returning the CAP is definitely important though when switching modes. In this case however, we switch from PCL mode to HPGL. And, within the HPGL mode, we receive an unexpected PCL escape sequence. My HP printers appear to process the sequence instead of ignoring it. My best guess, the printer is advancing the HPGL vertical component of the cursor positition based on the current font height and scaling factor.

I am hoping someone might offer a more quantifiable solution for how the HP printers handles these unexpected PCL escape sequences. Perhaps some comment in the PCL Technical Reference manuals I missed, or a more recent addendum with some insight. Ignoring the sequence does not work, as the files I am trying to render take avantage of the printer behavior.

Please try the test file I linked in the previous post. If you set the second &a1r1C to another value, say &a80r80C, the printer output (to HP printers). The HPGL cursor position still only advances a fixed amount.

I will have to work through a few more test files, using different font heights to see if my guess is correct.

 

[DansDadUK]

On my local HP LJ 1320n, your file prints:

- Several lines of heading text near top of page.
- Centred text half way down (A4) page.
- Four rows of outlined rectangles.
- Some more centred text.

The top two rows of rectangles are split into three (unequal) columns.
Each rectangle (except rightmost columns in first two rows) contains some short text string.
The boundary line between the 2nd and 3rd rows is emphasised by a thicker line than that between the other rows.


If the errant PCL sequences are removed, and the edited file sent to the same printer, it prints differently:

- There are now FIVE rows, of differing height.
First row same height before;
Second row smaller;
Third row much smaller (2nd + 3rd height = 1st height);
Fourth row same as new second row;
Fifth row same as original fourth row.


So the errant PCL does do something - but this might vary from device to device, each handling errors in a different way?

... and if the original HP-GL/2 is wrong, why have they tried to compensate using (erroneous, undefined) PCL within the HP-GL/2, instead of corrcting the HP-GL/2?

I've also used a viewer (PCLWorks) to view the files, and this shows the rows as overlapping.

It also differs from the prints in that it shows the rows as not aligning vertically - this may have something to do with all the whitespace (space characters, and CarriageReturn and LineFeed control codes) within the HP-GL/2.

Are these whitespace characters in your original data, or have they been introduced in some cut & paste operation used to save and upload the file?
I ask this, because I don't think that the HP-GL/2 specification mentions how such characters should be handled (and the effect is therefore also undefined).