mjm@bmbcomp.uucp (Michel Mathieu) (04/19/91)
We are a small software development firm involved in a wide variety of
products from data bases, data collection, electronic mail, and graphics, to
networks, supplying our customers with complete problem solutions and
information systems. Whenever we were in a position to need a screen dump,
we sometimes needed graphics, and sometimes text. Not having found any common
format around at that time handling both text and graphics, we developed
our own which we called 'PAL' (sometimes PALR). This was fast, efficient,
and general. In an effort to be a bit more compatible with the rest of the
world, we are now using PCX files for graphics as well. While not as
efficient in its format, it does allow our customers to easily use screen
images in non-proprietary software.
The problem with this is that PCX, and most other screen image formats, do
not store text screens. To allow this, I have made modifications to our
own products which use PCX files so that they can handle textual information.
The changes made are documented here for others to comment on and if you
find this useful, to implement as well.
Standard PCX header
-------------------
Offset Bytes Description
---------------------------
0 1 PCX format identifier, always 10 decimal
1 1 version info (0, 2, 3, or 5)
2 1 encoding (0 means not encoded, 1 means encoded)
I have never seen an unencoded PCX
3 1 bits per pixel
4 2 top left x1 (usually 0) picture size is:
6 2 top left y1 (usually 0) x2 - x1 + 1 = width
8 2 bottom right x2 y2 - y1 + 1 = height
10 2 bottom right y2
12 2 source horizontal resolution (not really used)
14 2 source vertical resolution (not really used)
16 48 set of 16 RGB triplets describing the colour for the image
if the image has 16 or fewer colours
64 1 screen mode (not used)
65 1 number of screen planes
66 2 bytes per line
68 60 filler
All of our own products have a signature in this unused
section, starting with 'BMB ', followed by the product
that created it, and a version number. I believe a few
other companies do this as well, though others have taken
to putting in their name in the RGB triplet area. Doesn't
seem safe enough for me.
--------------------
Rather than use some unused portion, I have just added a version code.
As it is, it is almost always 5. Most packages should look at this byte as
part of the test to see if the file is indeed a PCX image. Any radical change
to this byte should, then, not affect too many other programs. I have noticed
one problem already though, Microsoft Windows Paintbrush will actually try
to read the file as a graphics image, run into problems, and abort.
To signal the PCX as containing text, I put in the character 'A' (value 65)
in the version byte.
The text must be stored as two planes. If consecutive bytes were compressed,
very little savings in space would be achieved since the bytes are stored on
screen as character and attribute pairs. The plane parameter is thus set
to 2.
To distinguish between colour and monochrome screens, I set the bits per pixel
flag to either 1 or 4. This can be a problem since many programs use
bits per pixel * number of planes to determine whether or not they have to
go to the end of the file for a 256 colour palette. If the result is 8,
it expects a value of 12 at the end of the raster information, which is then
followed by the palette. To prevent this, the check must now also make sure
the version is not 'A'.
The x2 value is set to the number of text columns - 1.
The y2 value is set to the number of text rows - 1.
The screen text values are now stored, a row, or plane, of characters,
followed by a row of attributes.
The same compression routine is used, with care to increment by 2 instead
of 1 to get to the next value to compress.
--------------------
-------------------------------------
Michel J. Mathieu |
BMB Compuscience Canada Ltd. |
555 Industrial Drive |
Milton, Ontario |
L9T 5C2 |
-------------------------------------