The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
| Version |
Location |
Description |
Submitted by |
Date submitted |
| Printed |
Page 30
It seems to me that the order of the third and fourth paragraphs are |
|
Anonymous |
|
| Printed |
Page 68, 70
Figures 3-1 and 3-3 are identical. It appears that the intended |
|
Anonymous |
|
| Printed |
Page 267
In "Atari ST Graphics Formats" under "DEGAS Format", the three values of |
"Resolution" are described as "Left", "Off", and "Right". These should be
"Low", "Medium", and "High".
|
Anonymous |
|
| Printed |
Page 269
bottom |
This isn't really a technical mistake, but worth pointing out anyway. I would
suggest that some clarification text be inserted in this section - perhaps at
the front?
The Atari NeoChrome format is rich enough to handle most of the tasks needed
for basic picture storage. For instance it can, in a single file type, handle
all of the file types represented by the multiple DEGAS PI* formats, the IC
formats, and the Tiny format.
So why are there so many formats on the ST? Well the NEO format, used by the
NeoChrome program from Atari, went unreleased and it's format stayed out of
developer view. During the first few months to a year of being on the market
many graphics programs for the machine were shipped which had to invent their
own formats.
A year or so later NEO was finally released but by that time the formats had
already become entrenched in the market.
|
Anonymous |
|
| Printed |
Page 350
In the section on Lotus PIC, the header is quoted as |
01 00 00 00 01 00 08 00 44 00 00 00 0C 7F 09 06
The correct header, I believe, is
01 00 00 00 01 00 08 00 44 00 00 00 00 0C 7F 09 06
|
Anonymous |
|
| Printed |
Page 373
The header of a DVM version 1.0 file doesn't contain the info flag. |
Also, it is not possible to include text in a version 1.0 file. So the header
of a v1.0 file should be:
typedef struct _DVM_HEADER
{
char ID[3]; /* File ID "DVM" */
char Size; /* Q or F */
WORD Wait; /* Time (ms) to wait between frames */
} DVM_HEADER;
The last sentence says that version 1.0 or higher should use an enhanced
palette. Only version 1.0 should use one, because the header of version 1.0
doesn't have an info entry that defines that there's no enhanced palette.
If an enhanced palette occurs, before every frame comes the palette. So there
are three frames, there are three enhanced palettes. The file would be like
this:
[header][palette 1][frame 1][palette 2][frame 2][palette 3][frame 3]
In DVM version 4.0 (which is not discribed in the book), it is also possible
to use one palette for the whole file.
|
Anonymous |
|
| Printed |
Page 374
In the C source, the following lines are untrue |
palette[r*36+g+b+16].r=(BYTE)(ROUND((DOUBLE)r*12.6));
palette[r*36+g+b+16].g=(BYTE)(ROUND((DOUBLE)g*12.6));
palette[r*36+g+b+16].b=(BYTE)(ROUND((DOUBLE)b*12.6));
They should be:
!!
palette[r*36+g*6+b+16].r=(BYTE)(ROUND((DOUBLE)r*12.6));
palette[r*36+g*6+b+16].g=(BYTE)(ROUND((DOUBLE)g*12.6));
palette[r*36+g*6+b+16].b=(BYTE)(ROUND((DOUBLE)b*12.6));
|
Anonymous |
|
| Printed |
Page 382
entire page contains multiple errors |
EPS's created using the preview format shown on this page will not work
properly due to a number of errors in the description.
The typedef listing shows the checksum as a DWORD, or 4 bytes long. It is in
fact a 2 byte (WORD?) field instead.
Later on the page the book notes "if the checksum field is zero, ignore it",
this too is incorrect, the proper flag for ignoring the checksum is FFFF. Nor
is the way to construct the checksum mentioned, which is to XOR bytes 0 to 27
of the header.
Thus when describing the EPS header format and length, the book reads "so it's
offset is always 32". This is wrong because the checksum is smaller, the
header is only 30 bytes long.
Using the information as provided will make the EPS fail to view properly as
the EPS parser will "miss" the start of the EPS and consider it invalid!
Finally the book suggests that these formats for previews are not recommended,
and that authors should look to the plaftorm-independant EPSI format instead.
In reality I have yet to find a single program that supports EPSI, whereas
every program I have supports the TIFF preview format.
So another change I would make to this page would be to suggest the use of
TIFF preview files, specifically little-endian ones because MS's previewer
can't read big-endian versions.
page 438
typedef struct _Win3xBitmapInfoHeader
{
WORD Headersize:
should be DWORD rather than WORD.
|
Anonymous |
|
| Printed |
Page 441
6th paragraph (2nd paragraph from the bottom) |
In the second sentence describing Windows BMP RLE compression escape sequences, the
values for the "end of image" and "end of line" are reversed. A programmer writing
an RLE decompressor for the BMP file format would only be able to decompress the
first line. The sentence should read:
" A value of 0 in the second byte signals the end of a scan line; a value of 1
indicates the end of the image; ...."
|
Anonymous |
|
| Printed |
Page 513
in the paragraph that begins with "Extension code", the "13h" should be |
|
Anonymous |
|
| Printed |
Page 664
The description of the PCX format states that the "identification value |
defined by the PCX specification as always being 10h." It is customary to add
the letter "h" to a number that is in base sixteen, so 10h would mean 10 in
base sixteen, but the actual value for the identifier is 10 decimal or 0A
hexadecimal.
|
Anonymous |
|
| Printed |
Page 667
The second sentence of the paragraph immediately below the table reads: |
"The number of bits per pixel per plane is multiplied by the
number of color planes and shifted to the left by one.
MaxNumberOfColors = (1L << (BitsPerPixel*NumBitPlanes)) ; "
The code is correct, but not the explanation. The above line of C code shifts
the bits of 1 to the left by the number in (BitsPerPixel*NumBitPlanes).
|
Anonymous |
|
| Printed |
Page 674
In the 7 steps for "Encoding PCX Image Data", the 5th step should have |
an additional clause before "then", namely "or the count is 1 and the data
value has the two MSB's on".
|
Anonymous |
|
| Printed |
Page 706
line 4: |
This defines the values for the PNG file IHDR marker as "69484452h". The
correct value is 49484452h.
|
Anonymous |
|
| Printed |
Page 901
|
On page 901/2, describing the PackBits RLE scheme, the two coding schemes are the
wrong way around.
At the bottom of page 901
'The actual run-count value stored is in the range 0 to 127 and represents the values 1 to 128 (run count + 1).'
This should be
'The actual run-count value stored is in the range -1 to -127 and represents the values 2 to 128 (-run count + 1).'
Similarly the description of the literal run packet is wrong on page 902.
|
Anonymous |
|
| Printed |
Page 956
In the Wavefront RLA description you have |
ImageHeight = (ActiveBottom - ActiveTop) + 1;
Up above, it says that the RLA format uses a lower-left coordinate system
(standard for SGI's), which means that you should have:
ImageHeight = (ActiveTop - ActiveBottom) + 1;
|
Anonymous |
|