Shading using the <esc>*c??g PCL Command 2

[JTarshis]

Hi ... Does anyone know how to get Finer dots within the 8 Shading Patterns? I am typesetting Federal tax forms using my own PCL Typesetter. The PDF's the gov't distributes have much finer dots within the shaded areas. Would like to be able to generate finer dots from within the PCL Typesetter. Thanks. Jesse

 

[jlasman]

You will have to define your own custom shading patterns. See the PCL5 technical reference.

Jim Asman

http://www.spectracolorservices.com

 

[DansDadUK]

To get you started, here are some user-defined patterns (each 40 bytes long, for use with {esc}*c40W escape sequences), which match the user-defined patterns.

Cross-hatch patterns:

Cross-hatch 1:
[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 00 00 00 00 00 00 00 00 ]
                  [ 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 ]
                  [ 00 00 00 00 00 00 00 00 ]

Cross-hatch 2:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 01 80 01 80 01 80 01 80 ]
                  [ 01 80 01 80 01 80 01 80 01 80 01 80 01 80 01 80 ]
                  [ 01 80 01 80 01 80 01 80 ]

Cross-hatch 3:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 80 03 00 07 00 0e 00 1c ]
                  [ 00 38 00 70 00 e0 01 c0 03 80 07 00 0e 00 1c 00 ]
                  [ 38 00 70 00 e0 00 c0 01 ]

Cross-hatch 4:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 c0 01 e0 00 70 00 38 00 ]
                  [ 1c 00 0e 00 07 00 03 80 01 c0 00 e0 00 70 00 38 ]
                  [ 00 1c 00 0e 00 07 80 03 ]

Cross-hatch 5:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 01 80 01 80 01 80 01 80 ]
                  [ 01 80 01 80 01 80 ff ff ff ff 01 80 01 80 01 80 ]
                  [ 01 80 01 80 01 80 01 80 ]

Cross-hatch 6:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 c0 03 e0 07 70 0e 38 1c ]
                  [ 1c 38 0e 70 07 e0 03 c0 03 c0 07 e0 0e 70 1c 38 ]
                  [ 38 1c 70 0e e0 07 c0 03 ]

Shading patterns:

Shading 1:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 00 00 00 00 40 40 00 00 ]
                  [ 00 00 00 00 00 00 00 00 00 00 00 00 04 04 00 00 ]
                  [ 00 00 00 00 00 00 00 00 ]
Shading 2:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 00 00 00 00 40 40 00 00 ]
                  [ 00 00 00 00 04 04 00 00 00 00 00 00 40 40 00 00 ]
                  [ 00 00 00 00 04 04 00 00 ]
Shading 3:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 00 00 60 60 60 60 00 00 ]
                  [ 00 00 06 06 06 06 00 00 00 00 60 60 60 60 00 00 ]
                  [ 00 00 06 06 06 06 00 00 ]
Shading 4:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 c1 c1 c1 c1 80 80 08 08 ]
                  [ 1c 1c 1c 1c 08 08 80 80 c1 c1 c1 c1 80 80 08 08 ]
                  [ 1c 1c 1c 1c 08 08 80 80 ]
Shading 5:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 c1 c1 eb eb c1 c1 88 88 ]
                  [ 1c 1c be be 1c 1c 88 88 c1 c1 eb eb c1 c1 88 88 ]
                  [ 1c 1c be be 1c 1c 88 88 ]
Shading 6:

[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 e3 e3 e3 e3 e3 e3 ff ff ]
                  [ 3e 3e 3e 3e 3e 3e ff ff e3 e3 e3 e3 e3 e3 ff ff ]
                  [ 3e 3e 3e 3e 3e 3e ff ff ]
Shading 7:
[ 40 bytes ]      [ 00 00 01 00 00 10 00 10 f7 f7 e3 e3 f7 f7 ff ff ]
                  [ 7f 7f 3e 3e 7f 7f ff ff f7 f7 e3 e3 f7 f7 ff ff ]
                  [ 7f 7f 3e 3e 7f 7f ff ff ]

The values are all shown as arrays of bytes using hexadecimal notation.

 

[Buff1]

if you are using standard pcl, you might investigate
Esc*v horizontal h vertical v n g 2P

horizontal - width of shade
vertical - height of shade area
n - 1-100% typically 20 is a good medium shading
chr$(27)+"*v72h120v20g2P"
this gives a medium shading 1 character wide (at 10CPI)
and 1 line high (at 6LPI)

 

[Buff1]

sorry it should be
chr$(27)+"*c....."
instead of "*v...."

 

[DansDadUK]

I think that the pre-defined shading patterns which you get using sequences of the form:

{esc}*c#h#v#g2P

are what JTarshis is saying are too coarse.

 

[JTarshis]

Hi ... Thanks for everyones input. The {esc}*c#h#v#g2P are to coarse. Will try adding the code to be able to select a series of user-defined patterns. Thanks ... Jesse

 

[DansDadUK]

In my earlier post, when I stated:

"To get you started, here are some user-defined patterns (each 40 bytes long, for use with {esc}*c40W escape sequences), which match the user-defined patterns."

I should have said:

"To get you started, here are some user-defined patterns (each 40 bytes long, for use with {esc}*c40W escape sequences), which match the PRE-DEFINED patterns."

i.e. these user-defined ones are basically 300 dpi equivalents of the pre-defined patterns.

By making appropriate changes to the given values, you can obviously define different, less coarse, user-defined patterns.

 

[Buff1]

I've been recreating federal tax forms for over 20 years.
the *c#g2P sequence works fine for me. I have to say it is
difficult to tell many of my forms from the real thing.
the # can be 1-100 i think as a percentage with some pre-set. If your printer supports color, you might try that
instead though i know some mono printers will ignore color
commands.

 

[JTarshis]

Hi ... Thanks for all the info. I believe after some testing that what I would like to find is a PCL method that would allow me to get shading in 600 or even 1200 dpi. That would give much more refined shading (I believe) but trying several different approaches give me the same Default PCL shading. Jesse.

 

[jlasman]

I believe that you only need to change the first byte of the 300 dpi examples from DansDad to 0x14 to be working in a 600 dpi shading grid. That is probably what you are seeing on the gov't forms.

Finer shading patterns, though, are affected more by the print density setting on the printer.


Jim Asman

http://www.spectracolorservices.com

 

[DansDadUK]

Jim

You're almost right.

Changing the first byte to 0x14 turns the pattern from an original Format=0 pattern into a Format=20 pattern.

BUT you also need to add in four bytes, representing the X and Y design resolutions, after the original 8-byte header, making the header 12 bytes in length (and also add four to the value field in the accompanying {esc}*c#W sequence).

My original (format=0) patterns each have 8 bytes of header, followed by 32 bytes of pattern; the header bytes are:

byte 0 format (= 0)
byte 1 continuation (= 0)
byte 2 pixel encoding (= 1)
byte 3 reserved (= 0)
bytes 4-5 pattern height (pixels)
bytes 6-7 pattern width (pixels)

For a format 20 header, apart from changing the first byte, you need to add:

bytes 8-9 X resolution (dots-per-inch)
bytes 10-11 Y resolution (dots-per-inch)


So, for a resolution-specified 300 dpi pattern, the original 'Cross-hatch 1' pattern would be:

Cross-hatch 1:
[ 44 bytes ]      [ 14 00 01 00 00 10 00 10 01 2c 01 2c 00 00 00 00 ]
                  [ 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 ]
                  [ 00 00 00 00 00 00 00 00 00 00 00 00 ]

which should provide the same output as the original format=0 pattern.

... and, for a resolution-specified 600 dpi pattern, the original 'Cross-hatch 1' pattern would be:

Cross-hatch 1:
[ 44 bytes ]      [ 14 00 01 00 00 10 00 10 02 58 02 58 00 00 00 00 ]
                  [ 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 ]
                  [ 00 00 00 00 00 00 00 00 00 00 00 00 ]

which should provide finer hatching.


Note that the PCL5 Technical Reference Manual is incorrect (at least, my printed copy from 1992 is) in that whilst it refers to the extended pattern header, it indicates that the Format value should still be 0 - it should, as you've pointed out, be 20 (= 0x14).

Chris

 

[jlasman]

Thanks for the clarification. It has been a while.

For my own purposes, I just about always define custom area fills with HP-GL/2. It is quite convenient for business forms etc. as HP-GL/2 is my preferred choice for drawing the forms to begin with.

Also, you can lay out the grid for the RF command in such a way that you have a visual(sort of) sense of the symmetry of the pattern. It is very easy to end up with "artifacts" in the shading if you are not careful. As the pattern is tiled across and down the print area, you need to ensure that there is no distinction between adjoining tile boundries and the centre of the tile itself.


Jim Asman

http://www.spectracolorservices.com

 

[DansDadUK]

Jim

It's been a while for me, too!

I only got it right after several failing attempts (and then, of course, I had to try to find out why!).

I agree that HP-GL/2 is probably much better if you want to generate anything other than relatively simple vector graphics objects - and you're probably much more knowledgeable than me in that area.

Chris

 

[JTarshis]

Hi ... Still playing but not sucessful yet. Have the following to first select a User Defined Pattern, then the pattern, then the Shaded box area, then position in Decipoints, and the 4P for User Defined Pattern :

*v4T

*c44W1400010000100010025802580000000040400000000000000404000000000000404000000000000004040000

&a600v1872H

*c1320v1512h10g4P

Must be missing something because I still get the course 10% pattern.

Jesse

 

[DansDadUK]

Lokking at your 'snippet', I would say that your pattern definition string is incorrect, and is hence being ignored, thus a default pattern is produced.

I think that it is incorrect because you are sending the required hexadecimal characters as a string of ASCII characters.

e.g. the first character after the {esc}*c44W should be hexadecimal 14 (conventionally represented in documentation as 0x14), but you are including this as the ASCII characters 14 (which is hexadecimal 3134).

 

[DansDadUK]

... and I think that you also need a 'select pattern ID' sequence (in your case {esc}*c10G) in front of the pattern definition download sequence, so that the pattern is 'stored' with that identifier, for later reference within your final sequence.

 

[DansDadUK]

i.e. you need something like:

<Esc>*c10g        Assign Pattern ID
       44W        Download User-Defined Pattern
[ 44 bytes ]      [ 14 00 01 00 00 10 00 10 02 58 02 58 00 00 00 00 ]
                  [ 40 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
                  [ 04 04 00 00 00 00 00 00 00 00 00 00 ]
<Esc>&a600v       Cursor Position (decipoints): Vertical
       1872H      Cursor Position (decipoints): Horizontal
<Esc>*c1320v      Rectangle Size (decipoints): Vertical
       1512h      Rectangle Size (decipoints): Horizontal
       10g        Assign Pattern ID
       4P         Fill Rectangular Area: User Pattern

where I've split the sequences with line feeds, and added comments, for clarity; the <Esc> flag represents the escape character (0x1b), and the 44 bytes of pattern are shown as the hexadecimal values.

 

[JTarshis]

Hi DansDadUK ... Thanks ... I was under the impression from something I read that the *c44W command expected Hexadecimal notation, i.e., 44 characters in hexidecimal format or 88 bytes in length. Jesse.

 

[DansDadUK]

Any 8-bit ASCII character can be represented by two hexadecimal (4-bit) characters; for example:

(a) The ASCII character at code-point 27 (which is the escape character) is represented by hexadecimal 1B (commonly referred to as 0x1B, or 0x1b).

(b) The ASCII character at code-point 65 (which is the upper-case A character) is represented by hexadecimal 41 (commonly referred to as 0x41).

{esc}*c44W expects to be followed by 44 bytes of data, which can be represented by 88 hexadecimal characters.

Given that most of the expected ASCII characters (e.g. 0x14) are non-graphic, you HAVE to insert them as a hexadecimal string, or using something like the Chr$() notation used in some elementary languages.

How you do this depends on which language (C, C++, C#, Java, JavaScript, COBOL, Delphi, etc.) which your 'PCL Typesetter' application is written in.