(1)  Short note on the official definition of inch-based resolutions

Although the fax standards specify resolutions in terms of dots and
lines per millimetre, computer scanners and printers are wedded
firmly to inch-based resolutions.  With these units, normal
resolution can be expressed as 204 x 98 dpi while fine resolution is
204 x 196 dpi.  Additional modes are defined as follows :

Ŀ
 200 dpi   1728 dots per 219.46 mm   
 300 dpi   2592 dots per 219.46 mm   
 400 dpi   3456 dots per 219.46 mm   


Don't be misled into thinking that inch-based machines can have scan
lines longer than 215 mm. The reason for the odd figure of 219.46 mm
occurring in the definition is simply that with a resolution of 200
dpi, 1728 dots will take up 219.46 mm. This is a matter of
arithmetic. The standard could equally well have stated that 200 dpi
was equivalent to 1693 dots per 215 mm. And yes, it's basically a
kludge to make the best of an unsatisfactory situation.

(2)  Short note on the B4 paper size

The intermediate B-series of ISO paper sizes are used when a size
between two of the A-series is needed.

(3)  Short note on interconnecting A4 faxes with A5/A6 faxes

When a machine with only A5 or A6 capability connects with a
machine which is limited to A4 capability, there is an additional
option to allow either the A5 or A6 lines to be encoded with the full
1728 dots despite the fact that they are so much smaller.  The effect
of this is that full-size pages remain full sized, being either
enlarged or reduced to make up for the differences in size.  The
alternative would be for a smaller size fax to extract the middle of
an image received from a larger sized system, and for the larger
machine to add a margin at the sides knowing that the smaller system
would extract the middle portion of a full A4 page width.  However,
the T.4 recommendation is silent on the strategy to be used when a
machine with A3 or B4 capability wants to fax one of its full size
pages to a humble A4 receiver.  This is because an A3 or B4 machine
must also have A4 capability.  It is up to the sender to decide what
to do, but the three most obvious options are either to send just one
part of the document, or to reduce it by scaling and recoding, or
else to abort the session and send the document by post.

(4)  Short note on make-up codes and "modified" Huffman coding

The original encoding scheme developed by Huffman had no make-up
codes, only terminating ones. The introduction of terminating codes
into the T.4 specification was the reason why the term modified is
used when applied to the Huffman encoding scheme used by fax.

(5)  Short note on "Modified Read" coding

Read is an acronym for Relative Element Address Designate. The term
modified presumably relates to the intermingling of this scheme with
one-dimensionally coded lines.  It is possible to implement this type
of coding on its own rather than as an extension to MH coding. Though
for two-dimensional encoding to work it might appear essential that
at least the first line be coded one-dimensionally, there are
implementations of two-dimensional Read encoding that assume an
imaginary all white line exists before the first line of the bitmap.
This enables the coding to start from a known reference point, in
much the same way that all lines in the T.4 one- dimensional encoding
method are assumed to start with a white run-length.  The most
important variation on this theme is the T.6 coding scheme.

(6)  Short note on the font used by the full encoder

The font.dat file in the ENCODE directory is a double width
version of the same font as we used in the quick encoder. Note that
the program there has an implementation of fine resolution that uses
exactly the same font as does normal resolution, with the result that
the text appears as squashed up half-height.  Ideally, the
availability of a proper fine resolution font 32 rows high would
enable digitization of a fine-resolution image by using a different
value for the height of a font.  In practice, there isn't a lot of
point in doubling up the height of the existing font, as the fax
could take twice as long to send with no extra benefit in terms of
legibility.

(7)  Short notes on the two-dimensional coding fragment

i. We maintain a reference line for every scan line in our fragment ;
while this isn't necessary for coding the MH lines, we have based our
fragment on the corresponding function in ENCODE, which always makes
a reference copy for use in T.6 coding.

ii. As well as decrementing the k parameter the tag bit indicating
the coding used for the next line is also inserted at this point. The
version of shiftin in ENCODE differs from the QENCODE version in a
number of other important ways.  The full encoder writes each octet
to the output file as it is completed instead of placing it in a
coded scan line which is written to disk once the line is complete.
The reason why it does this is because it also performs T.6
two-dimensional coding, which doesn't use any end of line markers.
This means that it is not possible to byte-align T.6 scan lines, and
therefore it isn't practical to write out lines at a time.  The
standard macro putc is used to write octets to the output file ;
since this does its own disk buffering, the result of not writing
whole lines at a time has no serious speed impact on the code.  It
does make a difference to the modularity of the software, as the
shiftin module needs access to the output file handle in order to be
able to write octets.

iii.  The version of shiftin used by the full encoder also needs to
be able to cater for the special case where the output file ends in
the middle of an octet.  The code on the disk manages this by calling
shiftin with null pointer, whereupon the octet currently being
composed is padded out with 0 bits and written to disk.  This use of
a null pointer to handle a special case is a deviation from what is
generally recognised to be best programming practice, but I thought
it justified in this context.

iv.  The description of 2-D coding in the text follows the method
outlined in T.4 flowcharts.  Note that for clarity, a number of
checks to stop the various markers running over of line have been
omitted from the listing in the book.  The version on the disk, as
always, is more complete.

(6)  Short note on the T.6 EOFB sequence

Readers will no doubt notice that this EOFB sequence is also derived
from T.4 and is made up of two consecutive EOL codes. The T.6 coding
used by group 4 faxes is sometimes described as two-dimensional
coding with a K parameter of infinity.

(7)  Extended note on Error Limiting Mode (ELM)

Regrettably, I've never come across one fax machine that implements
this feature, and details of how it works are included for
completeness rather than because they are needed.  Actually, I ought
to have said that error limiting mode is included for
incompleteness.  This book includes no code showing how error
limiting mode could be implemented, and I freely admit that I find
the definition of its workings both imprecise and confusing.
Consequently, the account of error limiting mode given here is best
taken as a personal interpretation rather than as an more
authoritative account from someone who's been there and done that.

Error limiting mode is an optional extension to the T.4 coding
scheme, to be found in Annex B to all versions of the recommendation
subsequent to the 1988 Melbourne revision, and first published in the
1989 CCITT/ITU-T Blue Book series.  It was introduced, mostly for
political reasons, at the same time as error correcting mode referred
to above.  ECM was suggested by the British delegation to CCITT/ITU-T
Study Group VIII, and supported by the European and American
contingent.  Error limiting mode was a proposal from the USSR
delegation, and it is possible that both modes were accepted as a
kind of quid-pro-quo to avoid a veto in committee.  While the names
are similar, the logic behind the two proposals was quite different.
None of the various fax specifications prohibit the combination of
error limiting mode with ECM if that is what is desired.

ECM relies on a special form of data transmission.  Its purpose is to
enable a receiver to notify a transmitter of any errors that may have
occurred in normally coded T.4 data, and to provide a means of
accepting a retransmission of those selected frames.  It is something
that requires a real-time dialogue and a fair amount of memory to
work properly.  However, it can be made to work properly and when it
does work, it works well.  ECM is dealt with later in the book when we
come to the additions to the T.30 session protocol.

In contrast, error limiting mode entails a different method of
encoding an image.  The purpose of error limiting mode is to ensure
that when error do occur, they disturb as little of the transmitted
data as possible.  This is managed by means of extensions to the
one-dimensional T.4 coding scheme itself, and requires no real-time
dialogue and very little additional memory to work.  The principle
behind error limiting mode is to extend the existing error limiting
effect of the division of T.4 data into lines consisting of run
lengths totalling 1728 dots with unique EOL separators.  It does this
by further dividing each line into 12 independent parts.  An error in
a single bit will therefore not result in a whole line being lost,
but will instead result in just one relatively small part of the line
being discarded.

Each of the 12 parts of a standard T.4 line consists of 144 dots.  An
Extended scan Line Description or ELD is constructed, which consists
of one bit for each part of a single line.

If a part of a scan line is entirely white then the corresponding bit
is 0 and that section of the line is a white, or W part.  The W-parts
are not encoded any further ; the ELD entry compresses the entire 144
dots into one bit.

If any bit is black, then the corresponding bit in the ELD is set to
1 and that section of the line is known as a not white, or NW part.
All the run-lengths apart from the final one in each NW-part are then
encoded.  There are two coding schemes ; which one to use depends on
which revision of the specification is being read.

The original version of error limiting mode encoded the NW-part
run-lengths as normal T.4 runs.  The most recent version uses two
different coding tables consisting of code words for all possible
runs up to 144 for black and white respectively.  I'm quite puzzled
by this, but there is no doubt about it.  The original 1988 version
of the specification stated that -

"Run lengths are  encoded  using Tables 1/T.4 and 2/T.4 as described
in Section 4.1.1."

The 1993 version of the specification states that

"Run lengths are  encoded  using Tables B.2."

Tables 1/T.4 and 2/T.4 from the 1988 specification are the two tables
for the terminating and makeup run lengths which we listed earlier in
this chapter.  They appear identically in the 1993 version, though
they have been renumbered as tables 3/T.4 and 4/T.4 respectively.  By
contrast, table B.2/T.4 makes its first appearance in the 1993
version of recommendation T.4 and the run lengths it contains are
very different.  This table covers black and white run lengths from 0
to 144 as follows :


Ŀ
run white       black          
Ĵ
0   0100        -              
01  1000        01111          
02  1010        001            
03  0110        100            
04  1110        11             
05  1100        010            
06  1111        1010           
07  00100       0110           
08  10010       10111          
09  11010       10110          
10  10110       01110          
11  000110      1100010        
12  110110      000110         
13  000100      000111         
14  011100      000010         
15  010100      0000110        
16  001100      00000100       
17  100110      00000110       
18  0000100     000011100      
19  0000001     000011110      
20  0010100     000001010      
21  0011111     0000001000     
22  0011110     0000011100     
23  0011100     0000111010     
24  0101100     00001111110    
25  0111111     00001111100    
26  0111110     00001111111    
27  0111100     00001110110    
28  1001110     00000011000    
29  1011111     00000111100    
30  1011110     00000101100    
31  1011101     00001111101    
32  1011100     00001110111    
33  1101111     000000101000   
34  1101110     000001111100   
35  0001111     000001110100   
36  0001110     000001011100   
37  00010100    000000111100   
38  10011110    000000110100   
39  10011111    000000101100   
40  01110100    000000111000   
41  01110101    0000001001000  
42  01110110    0000011111111  
43  01110111    0000011111110  
44  01111010    0000011111101  
45  01111011    0000011111100  
46  01010100    0000011111011  
47  01010101    0000011111010  
48  01010110    0000011110111  
49  01010111    0000011110110  
50  01011010    0000011110101  
51  01011011    0000011110100  
52  01011100    0000011101111  
53  01011110    0000011101110  
54  00110100    0000011101101  
55  00101100    0000011101100  
56  00001100    0000011101011  
57  00000100    0000011101010  
58  00000101    0000010111111  
59  00000110    0000010111110  
60  00000111    0000010111101  
61  000101100   0000010111100  
62  010111010   0000010111011  
63  010111011   0000010111010  
64  010111110   0000010110111  
65  010111111   0000010110110  
66  001101010   0000010110101  
67  001101011   0000010110100  
68  001101100   0000001111100  
69  001101101   0000001110100  
70  001110100   0000001101100  
71  001010100   0000001011100  
72  001011100   0000001010100  
73  000010100   00000011111111 
74  000011100   00000011111110 
75  001010101   00000011111101 
76  0000111100  00000011111100 
77  0000110100  00000011111011 
78  0000101100  00000011111010 
79  0010111111  00000011110111 
80  0010111110  00000011110110 
81  0010111101  00000011110101 
82  0010111100  00000011110100 
83  0010111011  00000011101111 
84  0010111010  00000011101110 
85  0010110111  00000011101101 
86  0010110110  00000011101100 
87  0010110101  00000011101011 
88  0010110100  00000011101010 
89  0010101111  00000011011111 
90  0010101110  00000011011110 
91  0010101101  00000011011101 
92  0010101100  00000011011100 
93  0011101111  00000011011011 
94  0011101110  00000011011010 
95  0011101101  00000011010111 
96  0011101100  00000011010110 
97  0011101011  00000011010101 
98  0011101010  00000011010100 
99  0011011111  00000010111111 
100 0011011110  00000010111110 
101 0011011101  00000010111101 
102 0011011100  00000010111100 
103 0001011100  00000010111011 
104 0001010100  00000010111010 
105 0001010101  00000010101111 
106 0001010110  00000010101110 
107 00010101111 00000010101101 
108 00010101110 00000010101100 
109 00010110101 00000010101011 
110 00010110100 00000010101010 
111 00010110111 00000010110111 
112 00010110110 00000010110110 
113 00010111011 00000010110101 
114 00010111010 00000010110100 
115 00010111101 00000010011111 
116 00010111100 00000010011110 
117 00010111111 00000010011101 
118 00010111110 00000010011100 
119 00001010101 00000010011011 
120 00001010100 00000010011010 
121 00001010111 00000010011001 
122 00001010110 00000010011000 
123 00001011011 00000010010111 
124 00001011010 00000010010110 
125 00001011101 00000010010101 
126 00001011100 00000010010100 
127 00001011111 00000011001111 
128 00001011110 00000011001110 
129 00001101011 00000011001101 
130 00001101010 00000011001100 
131 00001101101 00000011001011 
132 00001101100 00000011001010 
133 00001101111 00000011001001 
134 00001101110 00000011001000 
135 00001110101 00000011100111 
136 00001110100 00000011100110 
137 00001110111 00000011100101 
138 00001110110 00000011100100 
139 00001111011 00000010100111 
140 00001111010 00000010100110 
141 00001111101 00000010100101 
142 00001111100 00000010100100 
143 00001111111 00000010010011 
144 00001111110 00000010010010 


Note that there is no need for a code for a black run of 0, as the
error limiting rules prohibit this ever being coded.  By the same
logic, there should be no need for a white run of 144, as this would
indicate a W-part that didn't need further coding.  The provision of
this unusable code is typical of the mess that characterises this
specification.  The existence of two conflicting versions, with the
later version not acknowledging that the earlier incompatible version
exists, isn't a terribly helpful state of affairs.  Things don't get
any better.  Annex B to Recommendation T.4 goes on to state that -

"In the NW-part the white and black runs alternate.  The coding
always begins with a white run.  If the actual scan line begins with
a black run then a white run of zero will be sent."

When I first read this, I assumed that it meant that each NW-part
began with a white run.  This seemed to made sense because the whole
point of separating the line into parts was to confine the effects of
the corruption of one part, and if a part were corrupted, there would
be no way of deducing the colour of the start of the next run unless
(like each line) it was known to begin with a specific colour.

However, on re-reading the specification a more literal
interpretation would seem to be that the coding for the whole scan
line begins with a white run, and the alternation of colours is
deemed to run across the NW-parts.  I was convinced at that point
that the phrasing must have been inaccurate and the standard ought to
have read

"In the NW-part the white and black runs alternate.  The coding
always begins with a white run.  If the NW-part begins with a black
run then a white run of zero will be sent."

Reference to the text in both the 1988 and 1993 releases of the
specification reveals that the phrasing of this section in both
versions is identical.  I've found from bitter experience that any
deviation from the intention of the specification is eventually found
out and punished with a fax session failure, but since I haven't
found a fax machine that supports error limiting mode, I can't say
which interpretation of the text is accurate.  Anyone seeking to
implement error limiting mode ought to be aware that this matter
needs further investigation.

There is no distinguishing pattern that plays the same role for a
NW-part as the EOL code does in normal T.4 transmissions.  Clearly,
this means that the NW-parts of the line cannot be reconstituted
without some additional information, and this is conveyed as the
mysterious sounding Code Bit Number Variation or CBNV.  The number of
bits used to code each NW-part is totalled and the number of bits for
the previous NW-part is subtracted from this figure.  For the first
NW-part in a scan line, for which no previous NW-part exists, an
imaginary previous code bit number of 40 is used instead.  The
resulting number is encoded according to the following table, where a
leading X is 0 if the number is positive but is set to 1 if the
number is negative.

Ŀ
0  100000               
1  X00001               
2  X00010               
3  X00011               
4  X00100               
5  X00101               
6  X00110               
7  X00111               
8  X01000               
9  X01001               
10 X01010               
11 X01011               
12 X01100               
13 X01101               
14 X01110               
15 X01111               
16 X10000               
17 X10001               
18 X10010               
19 X10011               
20 X10100               
21 X10101               
22 X10110               
23 X10111               
24 X11000               
25 X11001               
26 X11010               
27 X11011               
28 X11100               
29 X11101               
30 X11110               
31 X11111 000001        
32 X11111 000010        
33 X11111 000011        
34 X11111 000100        
35 X11111 000101        
36 X11111 000110        
37 X11111 000111        
38 X11111 001000        
39 X11111 001001        
40 X11111 001010        
41 X11111 001011        
42 X11111 001100        
43 X11111 001101        
44 X11111 001110        
45 X11111 001111        
46 X11111 010000        
47 X11111 010001        
48 X11111 010010        
49 X11111 010011        
50 X11111 010100        
51 X11111 010101        
52 X11111 010110        
53 X11111 010111        
54 X11111 011000        
55 X11111 011001        
56 X11111 011010        
57 X11111 011011        
58 X11111 011100        
59 X11111 011101        
60 X11111 011110        
61 X11111 100000        
62 X11111 100001        
63 X11111 100010        
64 X11111 100011        
65 X11111 100100        
66 X11111 100101        
67 X11111 100110        
68 X11111 100111        
69 X11111 101000        
70 X11111 101001        
71 X11111 101010        
72 X11111 101011        
73 X11111 101100        
74 X11111 101101        
75 X11111 101110        
76 X11111 101111        
77 X11111 110000        
78 X11111 110001        
79 X11111 110010        
80 X11111 110011        
81 X11111 110100        
82 X11111 110101        
83 X11111 110110        
84 X11111 110111        
85 X11111 111000        
86 X11111 111001        
87 X11111 111010        
88 X11111 111011        
89 X11111 111100        
90 X11111 111101        
91 X11111 111110        
92 X11111 X11111 000001 
93 X11111 X11111 000010 
94 X11111 X11111 000011 
95 X11111 X11111 000100 
96 X11111 X11111 000101 
97 X11111 X11111 000110 
98 X11111 X11111 000111 
99 X11111 X11111 001000 
100X11111 X11111 001001 
101X11111 X11111 001010 
102X11111 X11111 001011 
103X11111 X11111 001100 
104X11111 X11111 001101 
105X11111 X11111 001110 
106X11111 X11111 001111 
107X11111 X11111 010000 
108X11111 X11111 010001 
109X11111 X11111 010010 
110X11111 X11111 010011 
111X11111 X11111 010100 
112X11111 X11111 010101 
113X11111 X11111 010110 
114X11111 X11111 010111 
115X11111 X11111 011000 
116X11111 X11111 011001 
117X11111 X11111 011010 
118X11111 X11111 011011 
119X11111 X11111 011100 
120X11111 X11111 011101 
121X11111 X11111 011110 
122X11111 X11111 100000 
123X11111 X11111 100001 
124X11111 X11111 100010 
125X11111 X11111 100011 
126X11111 X11111 100100 
127X11111 X11111 100101 
128X11111 X11111 100110 
129X11111 X11111 100111 
130X11111 X11111 101000 
131X11111 X11111 101001 
132X11111 X11111 101010 
133X11111 X11111 101011 
134X11111 X11111 101100 


The CBNV words for all the NW-parts in the line are sent
consecutively, in series, after the extended scan line descriptor but
before any of the coded run-lengths, which are then all sent
consecutively.  It is important to realize that what we are conveying
here isn't the number of bits we are sending, but the number of bits
in the original bit-map which we have coded.  Since the last
run-length isn't included in the NW-part, the number of bits each
NW-part represents will vary.

The reason why the code bit number variation table only goes up to a
value of 134 when there are 144 bits in each part of the scan line
was something that originally eluded me.  Like the problem of whether
the NW-parts all begin with a white run, I though it had to be yet
another source of confusion.  I understood perfectly why variations
of 144 and 143 aren't catered for.  A difference of 144 bits could
only arise if we were comparing an all-white part and and all-black
part, and this is clearly impossible.  In the first place, no
all-white part is ever sent, and in the second place, an all-black
part would have a black run of 144 as its last run and this would
therefore never be sent either.  A white run of zero would be sent
instead.  Logically, the longest run that could ever be sent would be
a black run of 143.  Similarly, the shortest run is 1 rather than 0.
According to my calculations, this means the the CBNV table ought to
go up to 142 to cater for the case of the following consecutive
NW-parts :


 143 white dots + 1 black dot - 1 white dot + 143 black dots
 ----------------------------   ----------------------------
        ERL = white 143               ERL = white 1
      Code Bit Number 143           Code Bit Number 1
 ----------------------------   ----------------------------

 Code Bit Number Variation = -142



So I constructed an extension to the table in the 1988 version of the
error limiting mode as follows :


Ŀ
135X11111 X11111 101101 
136X11111 X11111 101110 
137X11111 X11111 101111 
138X11111 X11111 110000 
139X11111 X11111 110001 
140X11111 X11111 110010 
141X11111 X11111 110011 
142X11111 X11111 110100 



Once again, I checked this against the table in the 1993 version of
the standard once it arrived.  The relevant table B1/T.4 in this
version was indeed extended.  Though I was gratified to see that my
assumption about how extensions the CBNV table would be generated, I
was still puzzled as the new table only went up to 140 and not to
142.  I await the next version of the T.4 standard with some
interest.

The EOL code 000000000001 is sent before the start of the page in
error-limiting mode, and every coded scan line ends with an EOL code
just as it does in normal T.4 coded data.  Additionally, an EOL code
can be preceded by fill bits to pad the line out to the minimum scan
line time negotiated during phase B.  All pages sent in ELM should
also be terminated with the standard RTC sequence used in normal T.4
data.

Annex B to the T.4 recommendation describes how, in error limiting
mode, a totally white line has an ELD consisting of twelve 0 bits and
is sent as 000000000000 followed by an EOL code.  It goes on to point
out that a line which was totally white for the first 1584 dots would
have an ELD with the identical pattern 000000000001 to the EOL code
itself, and that any decoding algorithm should take account of this.

Error limiting mode also states what a receiver ought to do when data
does arrive corrupted.  The recommended procedure is to replace the
affected part with the same portion of the previous line.  Any
corruption can be detected quite easily when part of a line exceeds
144 bits, or when the CBNV cannot be decoded.

Where a fax is using a non-standard width, the division of each scan
line into parts containing 144 dots is still used.  The number of
parts in the line and the number of bits in the ELD is increased as
required, and the last part of the line is shortened.  So a line from
a A3 page being sent as 2432 dots would be sent in 17 parts, with the
last part comprising only 128 rather than 144 dots.  A line from a B4
page being sent as 2048 dots would be sent in 15 parts with the final
part shortened to only 32 dots.

I ought to say in conclusion that I'm not surprised that error
limiting mode isn't found more frequently.  Apart from the fact that
the specification is quite confusing in parts, and almost is almost
certainly inconsistent between versions, the success of the whole
enterprise appears to depend entirely on the successful transmission
of the extended scan line description and any subsequent code bit
number variations.  There is no reason to suppose that the ELD and
CBNV words would be any less susceptible to corruption than any of
the other data in the scan line.

In fact, there is at least one additional sources of undetectable
errors caused by this scheme.  Consider the case of a line with a
number of 0 fill bits occurring before the final 1 in an EOL
sequence.  If one of these bits were flipped to a 1, a phoney EOL
would be detected.  The following 12 zero bits would be interpreted
as the ELD of a blank line, and a dummy blank line would appear to be
inserted in the fax.  Since the use of multiple fill bits is quite
common, this is by no means a fanciful scenario.
