Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc798.txt.pdf Дата изменения: Wed Mar 27 23:50:25 2002 Дата индексирования: Tue Oct 2 16:35:25 2012 Кодировка:

Network Working Group Request for Comments: 798

A. Katz ISI September 1981

DECODING FACSIMILE DATA FROM THE RAPICOM 450 I. Introduction This note describes the implementation of a program to decode facsimile data from the Rapicom 450 facsimile (fax) machine into an ordinary bitmap. This bitmap can then be displayed on other devices or edited and then encoded back into the Rapicom 450 format. In order to do this, it was necessary to understand the how the encoding/decoding process works within the fax machine and to duplicate that process in a program. This algorithm is descibed in an article by Weber [1] as well as in a memo by Mills [2], however, more information than is presented in these papers is necessary to successfully decode the data. The program was written in L10 as a subsystem of NLS TOPS20. The fax machine is interfaced to TOPS20 as through a microprocessor-based interface called FAXIE. running on a terminal

Grateful acknowledgment is made to Steve Treadwell of University College, London and Jon Postel of Information Sciences Institute for their assistance. II. Interface to TOPS20 The fax machine is connected to a microprocessor-based unit called FAXIE, designed and built by Steve Casner and Bob Parker. More detailed information can be found in reference [3]. FAXIE is connected to TOPS20 over a terminal line, and a program was written to read data over this line and store it in a file. The decoding program reads the fax data from this file. The data comes from the fax machine serially. FAXIE reads this data into an 8-bit shift register and sends the 8-bit byte (octet) over the terminal line. Since the fax machine assigns MARK to logical 0's and SPACE to logical 1's (which is backward from RS232), FAXIE complements each bit in the octet. The data is sent to TOPS20 in octets, the most significant bit first. If you read each octet from most significant bit to least significant bit in the order FAXIE sends the data to TOPS20, you would be reading the data in the same order in comes into FAXIE from the fax machine. The standard for storing Rapicom 450 Facsimile Data is RFC 769 [4]. According to this standard, each octet FAXIE must be complemented and inverted (i.e. invert the bits in the octet). Thus, the receiving program did described in coming from order of the this before

Alan R. Katz

[page 1]


DECODING FACSIMILE DATA II. Interface to TOPS20

RFC 798

storing the data in a file. When the decoding program reads this file, it must invert and complement each octet before reading the data. Each data block from the fax machine is 585 bits long. The end of this data is padded with 7 0's to make 592 bits or 74 octets. According to RFC 769, this data is stored in a file preceded by a length octet and a command octet. The possible commands are: 56 (70 octal)--This is a Set-Up block (the first file, contains information about the fax image) block of the

57 (71 octal)--This is a data block (the rest of the blocks in the file except for the last one) 58 (72 octal)--End command (the last block of the file) The length field tells how many octets in this block and is always 76 (114 octal) except for the END command which can be 2 (no data). The length and command octets are NOT inverted and complemented. Below is a diagram of each block in the file: +--------+--------+--------+--------+--------+--------+-------| length | command| data | data | ... | | +--------+--------+--------+--------+--------+--------+-------III. The Rapicom 450 Encoding Algorithm An ordinary 8 1/2" by 11" document is made up of about 2100 scan lines, each line has 1726 pels (picture elements) in it. Each pel can be either black (1) or white (0). The Rapicom 450 has three picture quality modes. In fine detail mode, all of the document is encoded. In quality mode only every other scan line is encoded and it is intended that these missing lines are filled in on playback by replicating the previous line. There is also express mode, where only every third line is encoded.

[page 2]

Alan R. Katz


RFC 798

DECODING FACSIMILE DATA III. The Rapicom 450 Encoding Algorithm

Data is encoded two lines at a time, using a special two dimensional run-length encoding scheme. There are 1726 pels on top and 1726 pels on the bottom. Each pair (top-bottom) of pels is called a column. For each of the 1726 columns you can have any one of four configurations (called states): column (top-bottom) -----------W-W W-B B-W B-B

pels ---0,0 0,1 1,0 1,1

state -----0 1 2 3

The encoding algorithm can be described in terms of a non-deterministic finite-state automaton shown in Fig. 1 (after Mills [2]). You start out in a state (0-3) and transform to another state by emitting the appropriate bits marked along the arcs of the diagram. For example, suppose you are in state 1 (WB). To go to state 2 (BW), you would output the bits 101 (binary); to go to state 0 (WW) you would output the bits 1000. Note that the number of bits on each transition is variable. In states 0 (WW) and 3 (BB), a special run length encoding scheme is used. There are two state variables associated with each of these states. One variable is a run-length counter and the other is the field length (in bits) of this counter. Upon entry to either of these two states, the counter is initialized to zero and is incremented for every additional column of the same state. At the end of the run, this counter is transmitted, extending with high order zeros if necessary. If the count fills up the field, it is transmitted, the field length is incremented by one, and the count starts again. This count is called the run length word and it is between 2 and 7 bits long. For example, suppose we are in state 0 (WW) and the run length for this state (refered to as the white run length) is 3. Suppose there are three 0's in a row. The first 0 was encoded when we came to this state, there are two more 0's that must be encoded. Thus we would send a 010 (binary). Similarly, if there are seven 0's in a row, we would send a 110, but eight 0's would be sent by 111 followed by 0000 and the white run length becomes 4. (Ten 0's would be encoded as 111 followed by 0010 and the white run length would be 4).

Alan R. Katz

[page 3]


DECODING FACSIMILE DATA III. The Rapicom 450 Encoding Algorithm

RFC 798

0100 ------------------------>----------------------------------| | | -------------------<------------------------------| | | 1 | | | V | | -------------------------------| | | | | | | | | | 010 | | | | |->| 2 |---------------------->| 1 |->| | | || | | ||| | 0| | B-W | 101 | W-B | |1 | | |<-| |<----------------------| |<-| | | | | | | | | | | ----->| | | | ---------------| ----------------| | | ^ | | | ^ | | | | ------------>------| | | | | | | | | 1 | | | | | | | | | | | ^ V | | | | | | | | 0111| |1 | | 1000| |1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1011 | | | | | | | | ----------<----------| | | | V | | | V | | | ---------------| ----------------| | | |<--| | | | | | 0 | | | | | 3 |<----------------------| 0 |-----| | | | | | | B-B | | W-W | | | |---------------------->| |<--------| | 0 | | | | | | -------------------------------| ^ | ^ | | | | ----------run run Figure 1. Non-deterministic finite-state machine diagram for RAPICOM 450

[page 4]

Alan R. Katz


RFC 798

DECODING FACSIMILE DATA III. The Rapicom 450 Encoding Algorithm

Run length word lengths must be between 2 and 7. The field length is decremented if the run is encoded in one word and: 1. If the run length is 3 and the highest order bit is 0.

2. Or, if the run length is 4, 5, 6, or 7 and the highest order 2 bits are 0. In addition to all this, occupies at least two run word size) and the run this case, the last word previous words in the run An Example: To confirm the reader's understanding of the encoding procedure, suppose we had the following portion of a document (1=black, 0=white): top row: bottom row: ----------state: 0 1 1 1 1 1 0 0 0 0 0 1 1 0 0 0 ... 1 1 1 1 1 0 0 0 0 0 0 0 0 1 0 0 ... ------------------------------1 3 3 3 3 2 0 0 0 0 0 2 2 1 0 0 ... run field length is 2, the white run is 1. (This example comes from there is a special rule words (and can involve ends exactly at the end of the run is tested for did not exist. to follow if the run incrementing the run of a scan line. In decrement as if the

Suppose also that the black length is 3, and the state reference [1].)

This portion would be encoded as: 1 1011 11 000 1 0100 100 1 0 010 1000 ... NOTE: It turns out in reverse order. However, since each encoded bit pattern that This run would the Rapicom 450 sends the bits of a field will be discussed in the section V. length field is sent reversed, the above actually be sent as:

1 1011 11 000 1 0100 001 1 0 010 1000 ... ^ |-this is actually 100 reversed

Alan R. Katz

[page 5]


DECODING FACSIMILE DATA III. The Rapicom 450 Encoding Algorithm

RFC 798

Another Example: This example illustrates the rule for decrementing the run length word lengths: top row: bottom row: ----------state: 0 1 1 0 0 1 1 1 1 1 0 0 ... 1 1 1 1 1 0 1 1 1 1 1 0 ... ----------------------1 3 3 1 1 2 3 3 3 3 1 0 ...

Here, let us suppose that the black run field length is now 4, the white is still 3, and the state is 1. This portion would be encoded as: 1 1011 0001 1 1 101 0111 011 1 1000 ... ^ ^ |-goes to 3 |-blk cnt goes to 2 When we reverse the order of the run fields, the bit pattern that is actually sent is: 1 1011 1000 1 1 101 0111 110 1 1000 ... ^ |-this is actually 0001 reversed, etc. IV. The Setup Block and the Data Header Each data block from the fax machine is 585 bits long. The number of blocks in a picture is variable and depends on the size and characteristics of the picture. It should be emphasized that a block can end in the middle of a scan line of the document. There can in fact be many scan lines in a block. The 585 bit data block is composed of a 24 bit sync code which is used to recognize the beginning of a block, a 37 bit header, 512 bits of actual data, and a 12 bit CRC checksum: -----------------------------------------------------------------| 24-bit | 37-bit | 512-bit | 12-bit | |sync code | header | data | checksum | -----------------------------------------------------------------The number of useful data bits is variable and can be between 0 and 512 (although there are always 512 bits there, some of them are to be ignored). The number of data bits to be used is given in the header.

[page 6]

Alan R. Katz


RFC 798

DECODING FACSIMILE DATA IV. The Setup Block and the Data Header

The 37 bits of header is composed of: -----------------------------------------------------------------| 2-bit |5-bit| 10-bit | 12-bit | 3-bit | 3-bit |2-bit| |seq num|flags|data count| x position|black size|white size|state| -----------------------------------------------------------------An explanation of these fields follows: IMPORTANT NOTE: Most (but not all) of these fields are sent by the fax machine in REVERSE ORDER. The order of each n-bit field must be inverted. Sync code This is used to synchronize on each block. The value of this 24 bit field is 30474730 octal (not reversed). Sequence number This number cycles through 0, 1, 2, 3 for the data blocks. is 0 for the Set-Up block (not reversed). Flags Each of these flags are 1 bit wide: Run Purpose unknown, it always seems to be 1. Cofb Purpose unknown, it always seems to be 0. Rpt 1 for Set-Up blocks (which are repeated when coming from the fax machine though only one of them is transfered by FAXIE to TOPS20 and stored in the file) and 0 for data blocks. Spare Purpose unknown, doesn't matter. It

Alan R. Katz

[page 7]


DECODING FACSIMILE DATA IV. The Setup Block and the Data Header

RFC 798

Sub 1 if this is a Set-Up block. Data Count Number of the number means of useful bits to 512 data bits are can be 0 (usually to throw away this use out used, in one block. of the 512 data bits. NOT ALL only this number of them. This of the first data blocks) which (This field is reversed!)

X Position Current position on the scan line, a value between 0 and 1725. If this number is greater than where the previous block left off, the intervening space should be filled with white (0's). If this number is less than where the previous block left off, set the X position to this value and replace the overlapped data with the new data from this block. If this number is greater than 1726, ignore this field and continue from where the previous block left off. (This field is reversed!) Black Size The size of 7. This is differ from (This field White Size The size of the white run length field, must be between 2 and 7. It may differ from what was found at the end of the previous block. (This field is reversed!) State The current state. This is the correct state. It may differ from the state at the end of the previous block. (This field is not reversed.) Data 512 bits of the actual encoding of the document. NOT ALL of this data is used in general, only the amount specified by the the black run length field, must be between 2 and the correct value for the black size. It may what was found at the end of the previous block. is reversed!)

[page 8]

Alan R. Katz


RFC 798

DECODING FACSIMILE DATA IV. The Setup Block and the Data Header

data count. If this is a set up block, the data information about the type of document (see below). Checksum CRC checksum on the entire x**12+x**8+x**7+x**5+x**3+1. block. Uses

contains

polynomial

In a setup block, the data portion of the data block consists of: ----------------------------------------------------------| 6-bit | 5-bit | 1-bit | 20-bits | 480-bits | flags | spare |multi page| of zeros | 1's and 0's ----------------------------------------------------------Specifically these are: 6 flags (each are 1 bit): Start bit Always 0. Speed Is 1 if express mode. Detail Is 1 if detail mode. (NOTE: If the Detail and Speed flags are both 0, then data is in Quality mode). 14 inch paper is 1 if 14 inch paper length. 5.5 inch paper is 1 if 5.5 inch paper length. (NOTE: If the 14 inch and 5 inch flags are both 0, then paper length is 11 inch). paper present is 1 if paper is present at scanner (should be always 1).

Alan R. Katz

[page 9]


DECODING FACSIMILE DATA IV. The Setup Block and the Data Header

RFC 798

Spare: These 5 bits can be any value. Multi-page: 1 if multi page mode Rest of data of set-up block: The above fields are followed by twenty 0 bits and the rest of the 512 bits of the block are alternating 0's and 1's. There are a number of important points to be remembered in regard to the header of a data block. First of all, the data count, the x-position, and the black and white run sizes must be read IN REVERSE ORDER. The reason for this is that the fax machine sends these bits in reverse order. However, the sequence number and the state fields ARE NOT REVERSED. In addition to this, each run field in the data IS REVERSED. This reversing of the bits in each n-bit field is completely separate from the reversing and complementing of each octet mentioned earlier. Second, only the first n bits, where n is the value of the data count field (remember its reversed!), of the data is valid, the rest is to be ignored. If n is zero, the whole block is to be ignored. Third, if the x position is beyond where the last block ended, fill the space between where the last block ended and the current x postion with white (0's). If the x postition is less then where the last block ended, replace the overlapped data with the data in the new block. If the x postition is greater than 1726, ignore it and continue from where the previous block left off. Fourth, the black size, white size (reversed), and state (not reversed!) given in the header are the correct values even if they disagree with the end of the previous block. Finally, 0,1,2,3. the sequence number (not reversed) If it does not, a block is missing. should count through

[page 10]

Alan R. Katz


RFC 798

DECODING FACSIMILE DATA V. The Decoding Algorithm

V.

The Decoding Algorithm Upon first glance at the finite state seem that it would be difficult to create example, if you are in the WW state, and you know whether to do a transition to WB is to recognize that every arc out of the every arc out of WB begins with 1. Thus, and the next bit is 1, followed by a 0, state. If the next bit is 1, followed by WB state. diagram in Figure 1, it may a decoding procedure. For the next bit is a 1, how do or BW? The answer to this BW state begins with 0 and if you are in the WW state, you know to go to the BW a 1, you know to go to the

In writing the decoding program it was necessary to have two ways of reading the next bit in the data stream. The first way reads the bit and "consumes" it, i.e. increments the bit pointer to point at the next bit. The other way does not "consume" it. Below are four statements which show how to decode fax data. The numbers in parentheses are not to be consumed, that is to say they will be read again in making the next transition. If I am in state BW (2) 0 (0): go 0111: go 010 (1): go 0100: go If I am in state WB (1) 1 (1): go 1000: go 101 (0): go 1011: go and to to to to and to to to to the next bits are: BW BB WB WW the next bits are: WB WW BW BB then first bits are: BB BW WB then first bits are: WW BW WB go through the run length

If I am in state WW (0), algorithm, then if the next 0: go to 1 (0): go to 1 (1): go to If I am in state BB (3), algorithm, then if the next 0: go to 1 (0): go to 1 (1): go to

go through

the run length

For the run length algorithm, remember, look at the next n bits, where n is the length of either the black or white run length

Alan R. Katz

[page 11]


DECODING FACSIMILE DATA V. The Decoding Algorithm

RFC 798

word, REVERSE the bits, and output that many BB's or WW's (depending on whether black or white run). If the field is full, increment the size of the word, and get that many bits more, i.e. get the next n+1 bits, etc. Also, the run length word length can be decremented according to the rules given in section III. You always go through the run length even if there is only one WW or BB, in this case, the run field will be 0. Let us look at the first example given in section III. Suppose we want to decode the bits: 110111100010100100100101000... (we have already reversed the run lengths to make things easier). We are in state 1 (WB) and the black run length word length is 2 and the white length is 3. We get these initial values either from the block header, or by remembering them from the previous transitions if this is not the start of the block. According to our rules, we would parse this string as follows: 1(1) 1011 11 000 1(0) 0100 100 1(0) 0(0) 010(1) 1000... The numbers in parentheses are numbers that were read but not "consumed", thus the next number in the sequence is the same as the one in parentheses. First, we see a 1 and that the next bit is a 1, this means that we go to WB. Then we have a 1011 which means to go to BB. Then we do a run, we have a 11 followed by a 000 which means the black run length gets incremented by 1 (it is now 3) and we get 3 MORE BB's. Now we have a 1 followed by 0 which means go to BW. Next a 0100 which is WW. Then we have a run, 100, which means four more WW's. We keep going like this and we get the original bit pattern given in the first example of section III. It is important to always start fresh when dealing with each block. There are many reasons for this. The first is that sometimes blocks are dropped, and you can recover from this if you resynchronize at the start of each block. Also, if at the end of the previous block, there is about to be a transition, instead of making it at the beginning of the next block, the fax machine gives the new state in the header of the next block and goes from there. Thus it is important to always start at whatever state is given in the header, and to align yourself at the current X position given there also. Sometimes, while decoding a block, a bit pattern will occur which

[page 12]

Alan R. Katz


RFC 798

DECODING FACSIMILE DATA V. The Decoding Algorithm

does not correspond to any transition. If this happens, the rest of the block may be bad and should be discarded. The decoding program decodes the fax data block by block until it comes to an END command in the data, or runs out of data. VI. Program Performance The L10 NLS DEC KL10 to mode, the disk pages program takes about two CPU minutes to run on TOPS20 on a decode the average document in fine detail mode. In this picture is about 1726 by 2100 pels, and takes about 204 to store.

We have a program which displays bit maps on an HP graphics terminal and have been able to display portions of documents. (not all of an 8.5" by 11" document will fit in the display). We can use the terminal's zoom capability to look at very small portions of the document.

Alan R. Katz

[page 13]


DECODING FACSIMILE DATA References

RFC 798

References [1] Weber, D. R., "An Adaptive Run Length Encoding Algorithm", International Conference on Communications, ICC-75, IEEE, San Francisco, California, June 1975. [2] Mills, D. L., "Rapicom 450 Facsimile Data Decoding", WP2097/MD33E, COMSAT Laboratories, Washington D.C., undated. [3] Casner, S. L., "Faxie", ISI Internal Memo, USC/Information Sciences Institute, February 1980. [4] Postel, Jon, "Rapicom 450 Facsimile File Format", USC/Information Sciences Institute, September 1980. RFC 769,

[page 14]

Alan R. Katz


RFC 798

DECODING FACSIMILE DATA Appendix

Appendix In this appendix is given the first portion of the data which comes from the fax machine, this same data in RFC 769 format, and some of this data decoded into a bitmap. The data is represented in octal octets. The following is data of the form which comes out of the fax machine with length and command octets added: 114 125 125 125 125 330 366 177 111 377 377 0 0 0 13 100 234 327 200 114 73 346 270 63 70 125 125 125 125 40 110 377 337 377 344 70 0 0 331 71 200 57 1 71 162 377 236 330 142 125 125 125 125 0 237 377 377 377 10 100 0 0 204 0 344 377 310 142 376 321 235 352 171 125 125 125 125 102 102 377 377 377 0 7 0 0 0 370 7 325 1 171 276 75 217 345 330 125 125 125 125 326 211 377 377 360 160 20 34 7 114 270 156 331 313 330 234 256 136 313 13 125 125 125 125 270 365 377 377 177 23 75 275 41 71 271 100 36 220 340 277 113 203 320 377 125 125 125 125 152 111 377 377 12 301 0 0 310 142 0 1 56 0 77 376 245 220 71 377 125 125 125 125 42 171 377 377 0 160 0 0 34 171 162 310 47 0 40 67 377 75 34 377 125 125 125 125 42 336 377 377 114 137 0 0 200 330 0 16 325 7 142 265 262 166 270 371 125 125 125 121 44 51 376 377 71 376 0 0 0 241 71 107 324 241 160 301 160 166 46 53 125 125 125 21 111 244 104 377 142 204 0 0 0 137 174 43 344 330 0 16 136 364 57 200 125 125 125 261 0 247 213 377 171 352 344 0 344 26 134 323 3 0 0 20 247 177 0 0 125 125 125 114 42 377 241 377 330 135 0 0 0 302 100 263 227 0 0 171 13 305 5 125 125 125 71 151 377 41 163 141 27 0 0 0 160 162 220 40 137 0 1 251 366 125 125 125 125 142 267 111 111 301 137 353 0 0 0 0 0 365 71 342 162 311 350 72 125 125 125 125 171 122 362 377 361 177 264 0 0 71 16 34 313 35 200 71 313 374 107

The following is the same data after put into RFC 769 format (with each data octet reversed and complemented): 114 125 125 125 125 344 220 1 70 125 125 125 125 373 355 0 271 125 125 125 125 377 6 0 141 125 125 125 125 275 275 0 344 125 125 125 125 224 156 0 57 125 125 125 125 342 120 0 0 125 125 125 125 251 155 0 0 125 125 125 125 273 141 0 0 125 125 125 125 273 204 0 140 125 125 125 165 333 153 200 53 125 125 125 167 155 332 335 376 125 125 125 162 377 32 56 377 125 125 125 114 273 0 172 137 125 125 125 71 151 0 173 125 125 125 125 271 22 155 155 125 125 125 125 141 265 260 0

Alan R. Katz

[page 15]


DECODING FACSIMILE DATA Appendix

RFC 798

155 0 0 377 377 377 57 375 306 24 376 114 43 230 342 63

4 0 330 343 377 377 144 143 376 13 177 71 261 0 206 344

0 0 357 375 377 377 336 377 330 0 354 271 200 164 106 250

0 0 377 37 377 377 377 340 37 124 177 141 202 103 16 130

0 360 361 367 307 37 114 342 211 144 54 344 306 212 205 54

0 1 67 103 102 173 71 142 375 207 366 370 2 55 76 364

0 257 174 377 377 354 271 377 177 213 377 3 200 132 366 143

0 377 361 377 377 307 141 261 354 33 377 373 23 0 103 307

0 114 5 377 377 376 344 377 217 124 37 271 122 262 221 342

0 71 200 377 377 377 172 143 35 324 172 361 174 361 221 233

0 271 336 377 377 377 5 301 73 330 344 377 217 205 320 13

0 141 250 330 377 330 227 305 64 77 377 377 367 32 1 377

0 344 105 377 377 377 274 375 62 26 377 377 141 57 134

61 171 27 377 377 377 361 261 366 373 5 377 177 152 220

174 5 50 377 377 377 377 377 120 143 270 261 154 350 243

160 1 322 377 377 143 217 307 54 107 376 143 54 300 35

The following is the first part of the expanded bitmap of this data (there are about 4 scan lines here, or 2 pairs of scan lines): 177 377 377 377 377 377 337 377 377 377 377 377 377 377 374 0 0 20 31 4 137 377 377 0 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 0 0 10 310 0 377 276 337 207 374 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 356 0 0 7 153 240 377 357 376 315 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 0 0 250 137 0 377 377 70 3 135 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 177 0 0 2 377 0 377 377 371 33 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 377 0 0 0 0 377 14 375 377 370 111 377 377 377 377 377 367 377 377 377 377 377 377 377 377 377 377 10 1 204 57 377 70 377 227 352 377 365 203 377 377 377 377 377 377 377 377 377 377 377 377 377 374 0 140 10 100 377 0 372 345 300 167 67 377 377 377 377 377 377 377 377 377 377 377 377 377 377 0 201 0 0 100 177 0 20 314 213 337 343 236 377 377 377 377 377 377 377 377 377 377 377 377 377 4 200 0 0 2 32 0 140 175 373 377 55 175 377 377 377 377 377 377 377 377 377 377 377 377 377 327 0 0 10 100 176 0 45 63 371 1 377 376 377 377 377 377 377 377 377 377 377 377 377 377 377 377 0 0 0 100 344 0 376 215 377 323 377 236 377 377 377 377 377 377 377 377 377 377 377 377 377 377 0 0 0 164 2 2 377 202 377 365 377 337 377 377 377 377 377 377 377 377 377 377 377 377 377 377 0 0 0 0 200 47 377 6 343 177 377 273 377 377 377 377 377 377 377 377 377 377 377 377 377 377 100 0 100 20 216 137 377 347 73 377 357 347 377 377 377 377 377 377 377 377 377 377 377 377 377 377 0 0 0 21 0 336 237 143 334 177 377 377

[page 16]

Alan R. Katz


RFC 798

DECODING FACSIMILE DATA Appendix

376 200 40 0 40 0 377 40 20 316 255 377 43 366 377 377 0 0 0 30 30 367 377 376 50 7 377 366 0 0 300 121 4 376 377 377 377

77 102 200 0 20 6 233 0 141 375 373 377 51 175 377 376 0 0 74 376 0 347 377 336 77 357 357 377 44 0 0 20 32 125 306 363 377

377 177 0 0 1 100 377 0 321 167 153 1 277 376 377 367 0 100 341 55 40 377 377 356 377 76 377 377 373 100 0 351 4 207 214 277 377

377 377 0 0 0 103 354 0 376 215 377 223 377 234 377 357 0 2 234 277 0 357 377 10 353 216 377 377 377 0 0 300 345 210 10 377 77

377 277 0 0 100 376 0 62 377 202 377 367 277 377 340 272 20 100 103 177 0 377 377 17 75 377 377 377 77 1 0 206 367 233 67 377 377

377 377 4 0 0 0 241 47 377 6 353 377 377 271 0 300 0 10 4 377 0 377 177 320 333 211 375 377 377 10 0 74 200 21 377 377 377

377 377 100 0 140 120 217 157 377 300 377 373 357 347 0 2 1 201 157 377 311 377 377 105 377 207 367 377 377 0 0 167 103 364 373 377 355

377 377 0 0 0 121 1 376 327 143 104 167 377 377 0 0 144 10 300 367 200 377 377 235 377 176 377 377 177 0 6 0 60 361 377 377 373

377 376 0 4 20 31 30 173 377 377 0 377 377 376 0 4 0 0 0 377 24 170 357 275 377 257 377 377 177 0 100 30 177 277 377 267

377 377 0 0 210 332 0 373 376 237 267 376 377 157 0 0 0 20 2 371 0 305 177 377 377 217 377 377 377 0 220 64 372 1 377 177

377 366 0 10 101 243 240 377 377 374 315 77 373 377 177 0 0 75 0 376 0 5 377 377 363 377 377 377 377 0 0 41 177 50 377 377

377 365 0 0 374 177 0 377 377 70 203 137 177 377 377 0 0 0 141 100 0 276 76 373 337 377 375 377 337 200 0 234 233 16 377 377

300 173 0 0 3 377 0 377 377 175 13 377 377 377 37 0 0 0 372 15 62 377 207 377 343 367 377 340 376 160 140 172 377 140 377 377

0 302 2 0 200 377 12 377 377 330 311 345 377 377 377 0 0 40 0 61 55 377 246 347 277 357 377 0 170 0 4 30 377 120 367 377

0 12 5 200 155 377 150 377 237 377 177 165 223 377 377 0 4 142 0 16 377 377 340 335 356 357 356 0 173 223 3 175 377 41 377 377

0 0 354 10 304 377 202 377 216 304 377 67 377 377 377 0 4 0 20 200 316 357 147 317 171 277 377 0 0 160 30 300 377 335 377 237

Alan R. Katz

[page 17]