(1)  Short note on bit ordering

If you haven't read the section on TIFF FillOrder (tag 266) in the
disk notes to Chapter 4, then you ought to do so now.

In this chapter we assume TIFF FillOrder=1, or left-to-right bit
ordering.  I believe that when the bit ordering in each octet is the
same as the printed representation, it aids understanding and leads
to fewer bugs. It is certainly true that most output devices don't
understand any other bit ordering.  However, if the image were stored
directly from a modem that produces bytes in what the TR-29.2
committee refer to as direct bit ordering, it ought to have been
stored using TIFF FillOrder=2.  In this case, the bits in the octet
will be filled in from right to left rather than from left to right. 
The statement octet=backward[octet] corrects this situation via a
lookup table which is simply an array of the characters from 0 to 255
with the bit patterns reversed.  You'll find this table on disk in
the file UNHUFF.DAT.

(2)  Short notes on the decoding fragments

i. The C ternary operator ?: can be used to swap decoding trees.  It
may look more elegant to write the line as 

tree = color ? &btree : &wtree ;

but it is arguable whether this is more legible.

ii. Note that for each line of a 2-D image, the tag bit is the sole
method of determining the decoding method ; the k parameter used when
encoding only gives the maximum number of two-dimensional lines that
can occur in succession.  A two-dimensional fax that consists
entirely of on- dimensional lines with all EOL codes followed by a
tag bit of 1 is perfectly legal.

iii. The extensions to handle T.6 data, while not difficult, are not
listed in the book because they make reading the code rather more of
a chore than it otherwise would be. The real problem with presenting
modules of this type is that the series of conditional statements
which this entails tends to make the programs pretty tedious to
read.  The UNFAXIFY.C program on the accompanying disk is
unfortunately of this type ; but careful reading of the code together
with the header files should show that while the code is complex, it
is quite mechanical.

iv.  The actual output of the image is the most complicated part of
the DECODE program on this disk, and is accomplished using three
distinct modules. DOLINE.C takes care of the composition of the data
to be output. SCALES.C ensures that the vertical and horizontal
resolutions specified by T.4 are adjusted to take account of the
different capabilities of various output devices.  OUTPUT.C handles
the physical output of the data.

v.  The output routines are the one part of the code which would have
been better written in C++ rather than in C as there is a natural
polymorphism about printer drivers.  Note that the reason why the
Canon and HP printers appear to have slightly different resolutions
even though both are capable of 300 dpi is because we have assumed a
slightly different printable area on an A4 page for each.  The Canon
LPB4 has an effective print area of 7.8" x 11.3", while we use a
generic figure for all Hewlett- Packard printers (including
Deskjets).  This is based on a default margin of " at the top and
bottom of the paper, with " on each side, giving an effective A4
page size of 8.02" x 10.69"..

vi. Though the ability to generate an uncompressed TIFF file is
useful, it has its limits.  For example, though the uncompressed TIFF
image will inevitably be much larger than the original fax image, we
still use the single strip per image method of storage.  A fine
resolution A4 image would consist of a single strip 2286 x 1728 bits
in size, which is 493,776 bytes.  It is to be expected that some
packages will try and read a whole strip before processing it, and
will therefore get indigestion when faced with a strip of this size. 
It is also true that the routines on the accompanying disk aren't
particularly efficient and can be improved ; for instance, they
perform a redundant scaling of the image 1:1 before writing it to
disk.  This is probably acceptable in a program which is primarily
designed to output visible images and offers an option to generate
images on disk as an extra feature, but would be an unnecessary
overhead if this operation was being performed more intensively There
are a number of graphics packages that specialise in manipulating and
converting images, and anyone who needs to do any serious work with
post-reception fax processing is probably best advised to obtain a
package which is designed to perform whatever function is required.

vii.  The code on this disk shows how to handle output to an IBM
graphics screen.  Detecting the type of graphics screen is quite
straightforward. All three of 480 line VGA, 350 line EGA and 200 line
CGA are supported, with a screen width of 640 dots.  After the
appropriate scaling, the runs are simply written directly to the
screen RAM in byte-wide chunks of 8 adjacent bits at a time. The
initialisation function for writing data to a screen places the video
adapter in graphics mode.  The deinitialisation function returns it
to text mode.  The line output function writes lines of data to the
screen, and the end page function beeps at the user and waits for a
key press before clearing the screen and carrying on with the next
page.

viii. The most complicated printers which the disk has codes for are
those using the Canon CaPSL control language, which requires a set of
seven separate commands.  Hewlett-Packard printers, for which we
provide a generic Laserjet driver, require only three commands.  The
only commands needed by dot-matrix and other multi-slice printers are
ones to set the proper vertical spacing between slices.
