Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!ucbvax!ucbvax.berkeley.edu!sam
From: sam@oxford.berkeley.edu (Sam Leffler)
Newsgroups: comp.dcom.fax
Subject: Re: 2-d encoding and padding EOL
Message-ID: <41491@ucbvax.BERKELEY.EDU>
Date: 29 Mar 91 07:24:49 GMT
References: <59686@aurs01.UUCP> <41468@ucbvax.BERKELEY.EDU>
Sender: nobody@ucbvax.BERKELEY.EDU
Reply-To: sam@sgi.com (Sam Leffler)
Lines: 84

In article <59686@aurs01.UUCP> whitcomb@aurs01.UUCP (Jonathan Whitcomb) 
writes:
| In article <41468@ucbvax.BERKELEY.EDU> sam@oxford.berkeley.edu (Sam 
Leffler) writes:
| -If you're padding the EOL indicator to a byte boundary (say
| -for a modem or when placing data in a file), does the tag bit
| -used to signal the type of the next row in 2-d encoded data
| -go *in the byte*, or after?  That is, should the EOL byte include
| -the tag bit, or does the tag bit go in the immediately following
| -byte?
| 
| What do you mean EOL byte?  The EOL character is 13 bits long.
I meant that the last 8 bits of the EOL mark.
| 
| -Putting the bit in with the EOL is a lot more convenient,
| -but it seems like the tag bit is logically part of the line of data
| -and so belongs after.
| 
| Considering that the protocol is bit oriented, and not byte
| oriented, why do you care?  Just keep packing the bits into
| bytes until you get an EOF (which is six consecutive EOL's, if
| memory serves).  Any software that is reading the file
| should not be sensitive to byte boundaries either. 
When you're dealing with a modem connected by a serial
line it matters.  If the tag bit is placed in the same byte
with the last 7 bits of the EOL, then things can be
simplified.  Otherwise you have to send an additional byte
with the tag at the front and the question then arises whether
or not the first 7 bits of the next row of data should be included,
in the byte.  In addition, there is the issue of what to do for the
last EOL+tag that comprises the RTC.  Likewise, when putting
data in a file, the same question arises.  The obvious reason for
having EOL's padded to byte boundaries is to insure alignment
of data.  If the tag bit is not included in the byte w/ the last
7 bits of the EOL, then the alignment property only becomes true
for 1-d encoded data.
| 
| If for some reason you want to have each line of data to
| line up on byte boundaries, just pad the EOL with leading
| zeros (which will be ignored).  The tag bit is defined as 
| the bit after the EOL character for 2-d coding.  The tag 
| bit indicates whether the *following* line will be one or 
| two dimensionally encoded, so I would assume you want to 
| keep it with the EOL character. 
| 
| Considering that 2-d encoded lines always depend on the
| preceding line for reference, it should be pretty arbitrary
| where you put the bit, but my inclination would be to keep
| it with the EOL character.
This is exactly the question I wask asking -- when you're padding
EOL marks to a byte boundary, does the tag bit go in the byte
with the last 7 bits of the EOL, or does it go in the byte that
follows?  The answer to the question does matter because it
can require that the byte with the tag bit be held around until
the first 7 bits of encoded data for the next row arrive (unless
the modem expects a single byte with only the tag bit). 
| 
| -TIFF Class F has an option that says to pad EOL's to byte
| -boundaries, but does not specify which of the two cases is to
| -be used.  Modem manufacturers that have controls for padding
| -EOLs to byte boundaries don't seem to acknowledge 2-d encoded
| -data.  I've looked in the CCITT specs, and they seem to indicate
| -that the tag bit goes with the row it "modifies".
| 
| Where in CCITT Rec T.4 do you see this?
As I said above, TIFF Class F DOES NOT SPECIFY WHICH
WAY TO IMPLEMENT THIS (according to the drafts that I
have).  As to T.4, I don't have the document in front of me, but
it's nowhere stated verbatim.  I simply was saying that I
perceived that the document implied that the tag bit went
with the data it modified, as opposed to the previous row.
T.4 describes a bit-oriented protocol and as such does not (need)
to get involved with these issues.

To summarize *again* I feel there is an ambiguity as to how to
interpret padding EOL marks to byte boundaries when doing
2-d encoding.  Should the tag bit for the following row go in
the same byte with the last 7 bits of the EOL, or should it go
in the "next" byte?  I know that several modem manufacturers
read this newsgroup and I'm just hoping to get an answer to
the question so that my fax+TIFF software will be consistent
with what they do.

	Sam