Prind Direction and Text Direction not working 1

[webrabbit]

I have a small test file which I'm handing to my HP Laserjet 2200D: (~ represents the esc character.)

~E
~&u600D
~&l1oE
~*p3178x0Y~*c4a5000bp150a600b11g2p
~*p3245X~&a1R~&c1TTEST~&aT
Beginning of text
~&a2P
First line of next page

"TEST" should be printed vertically.
"First line of next page" should be printed upside down, right to left, at the bottom right of the page.
Neither of these is working.
So the question is: have I done something wrong or does my printer just not support these commands?

 

[jlasman]

I am not familiar with ~&c1T or ~&aT which are not mentioned in my PCL5 reference.

I seem to recall, a long time ago now, reference to PCL5 commands to stack text vertically but these commands were only supported on printers sold in Japan.

For a vertical path for text, look at the DV command in HP-GL/2.

Your ~&a2P is not valid. Only arguments of 0, 90, 180, 270 are valid.


Jim Asman

http://www.spectracolorservices.com

 

[webrabbit]

~&c1T is supposed to stack the characters vertically. If, as you said, it works only in Japan, then I can't use it. ~&aT should have been ~&cT, to switch back to horizontal.

I suppose the code for parsing 2-byte characters is also only for Japan. I cannot see any other used for it.

I misinterpreted the number code in the ~&a#P command. It should be 180.

I have achieved vertical stacking with a series of cursor movements. It's a bit complex, but it works. It's good that I only have a maximum of 12 characters to stack.

Thanks much for your help.

 

[DansDadUK]

>> I suppose the code for parsing 2-byte characters is also only for Japan. I cannot see any other used for it.

I think that it is also used elsewhere, using <Esc>&t83P to indicate UTF-8 text parsing (or perhaps Unicode text parsing?), although I've no direct experience with this.

If I get time in the next couple of days, I'll try the 'vertical rotated characters' sequences with my printers (but I don't have a Japanese market one).

 

[DansDadUK]

For what it's worth:

The Character Text Path Direction sequence (<Esc>&c#T) is described in the PCL5 Comparison Guide manual.

The sequence "allows the user to vertically rotate text for use in vertical writing applications".

A # value of 1 (as per the original post) is not defined; the two allowed values are:

0
the printer’s current active position (CAP) advances left to right, and linefeed advances top to bottom with horizontal, upright characters.

-1
the following actions occur:
[ul]
[li]Full-width characters in large fonts are rotated counter-clockwise 90 degrees (“vertical rotated” characters).[/li]
[li]Vertical substitutes are made for characters which change their appearance, orientation, or positioning when written vertically.[/li]
[li]All other characters are unaffected by this setting.[/li]
[/ul]

It is unclear exactly what is meant by 'full-width characters in large fonts'.

The manual indicates that large fonts "such as the MS Mincho and MS Gothic fonts supplied in the [LaserJet 4PJ] printer, are fonts which are bound to large symbol sets".

It also states that:
"In the MS-Mincho and MS-Gothic fonts provided in the HP LaserJet 4PJ, font metric calculation is somewhat easier than for the Latin-based fonts. Width calculations are easier because all characters of these fonts conform to one of two different character widths at a particular point size. The characters are either considered full-width or half- width. One-byte characters are always half-width and two-byte characters are always full-width".

It is unclear whether this implies that vertical rotated characters are retricted to characters which have two-byte character codes (in the Windows 3.1 Japan symbol set 19K presumably) in just these two fonts.

This is unlikely, but it doesn't really explain what may happen with other symbol sets (which may include characters which (in the chosen symbol set) use two byte character codes) and fonts (which may have characters of various different character widths, not just two widths).


All that I can conclude at present is that the feature will probably only work with (certain) Japanese (or other Eastern language) fonts and symbol sets; it won't work with standard fonts & symbol sets, or with ASCII characters.

 

[DansDadUK]

The PCL5 Comparison Guide manual also includes an example (written as 'C' program code) of using the Character Text Path Direction sequence, in combination with the Text Parsing Method sequence, to write some Kanji text in both non-rotated and rotated forms.

The attached file contains the print file generated using this example code; perhaps some-one with access to a Japanese LaserJet printer could confirm that it works as described.

 

[DansDadUK]

... and this is an analysis of that print file:

<Esc>%-12345X     Universal Exit Language (UEL)
@PJL ENTER LANGUAGE=PCL[0a]
<Esc>E            Printer Reset
<Esc>&a4L         Left Margin (column 4)
<Esc>&t31P        Text Parsing Method: 1|2-byte Shift-JIS
<Esc>(19K         Primary Font: Symbol Set (identifier = 19K)
<Esc>(s1p         Primary Font: Spacing: Proportional
       24v        Primary Font: Height (24 points)
       0s         Primary Font: Style (Upright, solid)
       0b         Primary Font: Stroke Weight: Medium
       28752T     Primary Font: Typeface (identifier = 28752)
<LF>              Line Feed
<LF>              Line Feed
<LF>              Line Feed
<CR>              Carriage Return
                  [8250][8250][8c8e][8250][8255][93fa][8160][8250][8250]
                  [8c8e][8250][8256][93fa]
<Esc>&c-1T        Text Path Direction: Vertical Rotated
<LF>              Line Feed
<LF>              Line Feed
<LF>              Line Feed
<CR>              Carriage Return
                  [8250][8250][8c8e][8250][8255][93fa][8160][8250][8250]
                  [8c8e][8250][8256][93fa]
<FF>              Form Feed
<Esc>%-12345X     Universal Exit Language (UEL)

The Kanji characters are represented by two-byte hexadecimal values enclosed within [ and ] characters.

Note that these code values are not Unicode code-points; they are character codes used within the Windows 3.1 Japan symbol set (19K), although they do have Unicode equivalents; for example:
[ul]
[li]character code 8250 in 19K is mapped to Unicode code-point ff11[/li]
[li]character code 93fa in 19K is mapped to Unicode code-point 65e5[/li]
[/ul]

 

[webrabbit]

I have abaondoned printing horizontal oriented characters stacked vertically and have decided to simply rotate by 270°.

 

[DansDadUK]

@webrabbit:

I realise that you've found a different method of achieving your required output.

I just thought that I'd flesh out some details in the thread, so that anyone else finding it (e.g. as the result of a search) will have some basic details of the sequences in question.