sam@oxford.berkeley.edu (Sam Leffler) (03/27/91)
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? 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. 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". Sam sam@sgi.com
whitcomb@aurs01.UUCP (Jonathan Whitcomb) (03/29/91)
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.
-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.
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.
-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?
-
- Sam
-
-sam@sgi.com
Perhaps I just don't understand your application.
Jonathan
**********************************************************************
Jonathan Whitcomb UUCP: <whitcomb%aurgate@mcnc.org>
Alcatel Network Systems, Raleigh, NC Delphi: JBWHIT
sam@oxford.berkeley.edu (Sam Leffler) (03/29/91)
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
Steve Elias <eli@cisco.com> (03/30/91)
Sam Leffler writes: > 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, i'm no modem manufacturer and i'm no Kennedy, but it seems to me that there is indeed an ambiguity. why not just support both modes, with one as an option... like "-tageol" ?? this way, your faxTIFF code can be all things to all faxmodems! (sort of.) ; Steve Elias, eli@cisco.com ; 415 688 4517 (work phone & voice mail) ; 508 294 0101 (SCO Unix inbound fax->email)
sam@oxford.berkeley.edu (Sam Leffler) (03/30/91)
| why not just support both modes, with one as an option... | like "-tageol" ?? | | this way, your faxTIFF code can be all things to all faxmodems! | (sort of.) For the TIFF code, the reason is compatbility w/ anyone else that claims they support Class F. More importantly, my main reason for asking is because I'm trying to talk to a Class 2 modem and I want to know what it does (or is supposed to do). Sam