raster mysteries again

[palovidiu]

I am having a problem with image printing in raster mode
when data is compressed in CCITT modified Huffman.
I want to draw (for ex.) 2 black lines using the
encoding mentioned before. I am encoding each row, and
what I am getting (using EscapeE as a PCL viewer) is
an interlaced image, this is after i double the number of
rows. Somehow i am inserting in the raster empty rows,
having in the end 4 rows instead of 2, alternating black
with white.

the code :

IMG 2 rows
00110101 White 0
000000010101 Makeup Black 2170
000011011100 Term Black 0

packed as bytes

IMG 2 rows
00110101 35
00000001 01
01010000 50
11011100 DC

so my pcl code whould look something like this

*r4T // doubled raster rows
*r2176S
*b6M // compression mode ModHuff
*r1A
*b4W5
PÜ // row 1
*b4W5
PÜ // row 2
*rB

with the side effect before mentioned
any ideea why ?

thank you for your patience if u reached the end
of the message

 

[jlasman]

I am not familiar with <esc>*b6M compression.
Where are the specs for it? If you are actually going to be sending this output to a printer, you will need to make sure that the printer supports the compression scheme.

Have you made this work without compression?

Raster scaling requires <esc>*r#A where #=2 or 3, not the <esc>*r1A that you show.

If your destination is ultimately a printer, be suspicious of a PCL viewer as a proofing mechanism. I use Swiftview myself, but it has its areas of weakness. I tried EscapeE along the way and it too had areas where it failed. Do you know that EscapeE supports 6M compression?

Once you identify any weakness in one of these viewers, they can be invaluable in debugging PCL code.



Jim Asman

 

[palovidiu]

first of all, thank you for answering
then to reply to some of your observations :
I hava a document wich states that standard
parameters for the *r#A command are 0,1 and
the meaning of the command is starting raster
mode , where parameter defines the starting
position (up-left corner), and 1, means start
at the current cursor position.

Yes, I was succesfull with mode 1,2, RLE and Tiff.rev4.
But these encodings are not as efficient in compression
as CCITT Group 3 - modified Huffman is. (G4 are even better).
EscapeE states it can handle *b6M, and it does, cause
it succsefully decodes line (rows). but when I give
a succesion of rows.. for some reason, after it decodes
a row it leaves a white row, and then decodes the second encoded row. So an image of N rows whould be drawn on a
raster with 2*N rows.

I know for sure the printer which will be my final target
knows also *b6M, but I have do write my code only testing
it with EscapeE.

thank you

 

[jlasman]

Well, HP says that the compression algorithm requires
<esc>*r2A or <esc>*r3A. Infer from that what you want.

The efficiency of the compression algorithm will depend on the nature of the image.

I am curious as to what printers support 6M.

Jim Asman

 

[jlasman]

OK, I see that the HP D640 printer supports b6M, but I don't know that it is supported in the 4xxx, 5xxx, etc.

As far as the raster scaling is concerned, have a look at pages 6-36 - 6-37 in the PCL color reference.


Jim Asman

 

[palovidiu]

thank you for answering, once again

What I know is that the printer knows this compression
mode and it handles it in a different manner, or I am
missing something. I have been sent some pcl format
outputs which embed, images compressed with *b6M, but
the way information is passed to the printer is NOT
in a row after row encoding manner, it is passed as a
block.

As I have read in the PCL5 HP Tehnical Manual, after the
*r1A/*r0A (starting raster mode) such commands like raster
rows, raster width and some other are ignored. page(15-15)

This files which print out just fine, enter raster mode
and give the width PCL command in this order:

<esc>*b6M
<esc>*r1A
<esc>*r#S
<esc>*r17890W
[data block]

maybe I am missing something. + the images are monochrome
images.
*r2A r*3A are indeed starting raster mode in a scaled mode.

 

[jlasman]

It would seem reasonable to me that you would define the raster width and height BEFORE the start raster graphics command. Have you tried moving the width/height commands to see if that changes the output? Also, for a sanity check you might actually send the test file to a real LaserJet.

But WHY do you insist on 6M exclusively. If you are working with a bi-livel BW image, my experience has been that 3M tends to be more effective over a range of images. Of course you may have very good reasons for using 6M.

It is NOT necessary to use the same compression scheme for the entire image. You can, in fact, use a different compression scheme on each raster row. A combination of 0M, 2M, and 3M may be most effective.

Jim Asman

 

[palovidiu]

I found out exactly with which printers I am dealing
in the end. They are a couple of Siemens OCÉ 2140.
I found in the tehnical manual following you'r suggestion
written clearly that from 6 up , all of them are
block based encodings (I am talking about compression
modes), as for thouse below 6 , are row based. Why give
the height of the raster, after the *r1A command, again
beats me ...
I sent two file with 60 images embeded, with encodings 1 and 2. I came out only garbage. They told me .. it is the
out of memory sindrome ...
So then I turned again on this compression mode which they
claims it works just fine. More so .. the imaages encoded
start with a Huffman code wich does not exist. )

mode 3 yes, it's delta compression
and yes .. you can use 5 , adaptative, though I can make
many mistakes and send another test file which comes out
with garbage chars.

thank you for the support, jlasman

 

[palovidiu]

It's ok, I got my hands on some raster documentation
from the tehnical manual of this OCE 2140.
I know only 0,6,7,8 as compression modes, and the
format in which handles raster is not standard.
<esc>*r1A
<esc>*r#T
<esc>*r#W
[Data .. and the first 4 bytes express in Motorola
order, the width of the image]

it should work just fine now

thanks for the suport

 

[Buff1]

Unless this is a learning program for future use of raster
graphics for more complex drawings, if you are merely
printing black lines, let me suggest some alternate methods.

Ec*cxhyv0P
(where x=width in 720ths of an inch and y=height in 720ths
of an inch)

you can also use shading to an extent instead but not all
inkjets support this - depends on PCL version I think.

Ec(10U
Ec(s0p10h12v0s0b0T
use box line drawing characters after this font/char set
change. you can redraw the vertica/horizontal lines by
relocating the "cursor" to make them appear "thicker"

I have even done little arrows and big arrows, up arrows
and down arrows with routines to simulate those printed
on federal tax forms in order to replace the use of the
Line Draw char set.

Just a thought