rfc2301.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   a value of 3. Bit 0 of this field specifies the encoding used (MH
   only in this mode) and Bit 2 indicates whether the EOL codes are
   byte-aligned or not. If they are byte aligned, then fill bits have
   been added as necessary so that the End of Line (EOL) codes always
   end on byte boundaries. See Section 3.4 for details.

3.2.3. New Fields

   None.

3.3. Recommended TIFF Fields

   None.

3.4. End of Line (EOL) and Return to Control (RTC)

   The handling of End of Line (EOL) codes and Return to Control (RTC)
   sequences illustrate the differences between conventional fax, which
   is bit and stream oriented, and TIFF, which is byte and file
   oriented. Conventional fax, Baseline TIFF and TIFF extensions for fax
   all handle EOLs and RTCs differently.




McIntyre, et. al.           Standards Track                    [Page 20]

RFC 2301              File Format for Internet Fax            March 1998


   In conventional fax, an MH-compressed fax data stream for a page
   consists of the following sequence:

      EOL, compressed data (first line), EOL, compressed data, ... ,
      EOL, compressed data (last line), RTC (6 consecutive EOL codes)

   Baseline TIFF does not use EOL codes or Return to Control (RTC)
   sequences for MH-compressed data. However, the TIFF extension field
   T4Options used in this specification for MH compression (Compression
   = 3) requires EOLs.

   Furthermore, Bit 2 in the T4Options field indicates whether or not
   the EOL codes are byte aligned. If Bit 2 = 1, indicating the EOL
   codes are byte aligned, then fill bits have been added as necessary
   before EOL codes so that an EOL code always ends on a byte boundary,
   and the first bit of data following an EOL begins on a byte boundary.
   Without fill bits, an EOL code may end in the middle of a byte. Byte
   alignment relieves application software of the burden of bit-shifting
   every byte while parsing scan lines for line-oriented image
   manipulation (such as writing a TIFF file). Not all TIFF readers
   historically used for fax are able to deal with non-byte aligned
   data.

   While TIFF extension requires EOL codes, TIFF in fax applications has
   traditionally prohibited RTC sequences. Implementations that want
   common processing and interfaces for fax data streams and Internet
   fax files would prefer that the TIFF data include RTC sequences.

   To reconcile these differences, RTCs are allowed in cases where EOL
   codes are not byte aligned and no fill bits have been added to the
   data. This corresponds to situations where the fax data is simply
   inserted in a strip without being processed or interpreted. RTCs
   should not occur in the data when EOLs have been byte aligned. This
   is formally specified in the next sub-section.

3.4.1. RTC Exclusion

   Implementations which wish to maintain strict conformance with TIFF
   and compatibility with the historical use of TIFF for fax SHOULD NOT
   include the RTC sequence when writing TIFF files. However,
   implementations which need to support "transparency" of T.4-generated
   image data MAY include RTCs when writing TIFF files if the flag
   settings of the T4Options field are set for non-byte aligned data,
   i.e. Bit 2 is 0. Implementors of TIFF readers should be aware that
   there are some existing TIFF implementations for fax that include the
   RTC sequence in MH image data. Therefore, minimal set readers MUST be
   able to process files which do not include RTCs and SHOULD be able to
   process files which do include RTCs.



McIntyre, et. al.           Standards Track                    [Page 21]

RFC 2301              File Format for Internet Fax            March 1998


3.5. File Structure

   The TIFF header, described in Section 2.1.1, contains two bytes which
   describe the byte order used within the file. For the minimal black-
   and- white mode, these bytes SHALL have the value "II" (0x4949),
   denoting that the bytes in the TIFF file are in LSByte-first order
   (little- endian). The first or 0th IFD immediately follows the
   header, so that offset to the first IFD is 8. The headers values are
   shown in the following table:

          +--------+-------------------+--------+-----------+
          | Offset |   Description     |     Value          |
          +--------+-------------------+--------+-----------+
          |   0    |   Byte Order      |  0x4949 (II)       |
          +--------+-------------------+--------+-----------+
          |   2    |   Identifier      |  42 decimal        |
          +--------+-------------------+--------+-----------+
          |   4    | Offset of 0th IFD |  0x 0000 0008      |
          +--------+-------------------+--------+-----------+

   The minimal black-and-white mode SHALL order IFDs and image data
   within a file as follows: 1) there SHALL be an IFD for each page in a
   multi- page fax document; (2) the IFDs SHALL occur in the same order
   in the file as the pages occur in the document; (3) the IFD SHALL
   precede the image data to which it has offsets; (4) the image data
   SHALL occur in the same order in the file as the pages occur in the
   document; (5) the IFD, the value data and the image data it has
   offsets to SHALL precede the next image IFD; and (6) the image data
   for each page SHALL be contained within a single strip.

   As a result of (6), the StripOffsets field will contain the pointer
   to the image data. With two exceptions, the field entries in the IFD
   contain the field values instead of offsets to field values located
   outside the IFD. The two exceptions are the values for the
   XResolution and YResolution fields, both of which are type RATIONAL
   and require 2 4- byte numbers. These "long" field values SHALL be
   placed immediately after  the IFD which contains the offsets to them,
   and before the image data pointed to by that IFD.

   The effect of these requirements is that the IFD for the first page
   SHALL come first in the file after the TIFF header, followed by the
   long field values for XResolution and YResolution, followed by the
   image data for the first page, then the IFD for second page, etc.
   This is shown in the following figure. Each IFD is required to have a
   PageNumber field, which has value 0 for the first page, 1 for the
   second page, and so on.





McIntyre, et. al.           Standards Track                    [Page 22]

RFC 2301              File Format for Internet Fax            March 1998


                   +-----------------------+
                   |         Header        |------------+
                   +-----------------------+            | First IFD
                   |      IFD (page 0)     | <----------+ Offset
               +---|                       |------------+
               |   |                       |--+         |
         Value |   +-----------------------+  |         |
        Offset +-->|      Long Values      |  |         |
                   +-----------------------|  | Strip   |
                   |  Image Data (page 0)  |<-+ Offset  |
                   +-----------------------+            | Next IFD
                   |      IFD (page 1)     | <----------+ Offset
               +---|                       |------------+
               |   |                       |--+         |
         Value |   +-----------------------+  |         |
        Offset +-->|      Long Values      |  |         |
                   +-----------------------|  | Strip   |
                   |  Image Data (page 1)  |<-+ Offset  |
                   +-----------------------+            | Next IFD
                   |      IFD (page 2)     | <----------+ Offset
                   +-----------------------+
                   |          :            |

   Using this file structure may reduce the memory requirements in
   implementations. It is also provides some support for streaming, in
   which a file can be processed as it is received and before the entire
   file is received.

3.6 Minimal Black-and-white Mode Summary

   The table below summarizes the TIFF fields that comprise the minimal
   interchange set for black-and-white facsimile. The Baseline and
   Extension fields and field values MUST be supported by all
   implementations. For convenience in the table, certain fields which
   have a value that is a sequence of flag bits are shown taking integer
   values that correspond to the flags that are set. An implementation
   should test the setting of the relevant flag bits individually,
   however, to allow extensions to the sequence of flag bits to be
   appropriately ignored. (See, for example, T4Options below.)

      +---------------------------+--------------------------------+
      | Baseline Fields           |  Values                        |
      +---------------------------+--------------------------------+
      | BitsPerSample             | 1                              |
      +---------------------------+--------------------------------+
      | Compression               | 3: 1D Modified Huffman coding  |
      |                           |     set T4Options = 0 or 4     |
      +------------------------------------------------------------+



McIntyre, et. al.           Standards Track                    [Page 23]

RFC 2301              File Format for Internet Fax            March 1998


      +---------------------------+--------------------------------+
      | FillOrder                 | 2: least significant bit first |
      +---------------------------+--------------------------------+
      | ImageWidth                | 1728                           |
      +---------------------------+--------------------------------+
      | ImageLength               | n: total number of scanlines   |
      |                           | in image                       |
      +---------------------------+--------------------------------+
      | NewSubFileType            | 2: Bit 1 identifies single     |
      |                           | page of a multi-page document  |
      +---------------------------+--------------------------------+
      | PageNumber                | n,m: page number n followed by |
      |                           | total page count m             |
      +---------------------------+--------------------------------+
      | PhotometricInterpretation | 0: pixel value 1 means black   |
      +---------------------------+--------------------------------+
      | ResolutionUnit            | 2: inch                        |
      +---------------------------+--------------------------------+
      | RowsPerStrip              | number of scanlines per strip  |
      |                           | = ImageLength, with one strip  |
      +---------------------------+--------------------------------+
      | SamplesPerPixel           | 1                              |
      +---------------------------+--------------------------------+
      | StripByteCounts           | number of bytes in TIFF strip  |
      +---------------------------+--------------------------------+
      | StripOffsets              | offset from beginning of       |
      |                           | file to single TIFF strip      |
      +---------------------------+--------------------------------+
      | XResolution               | 204, 200 (pixels/inch)         |
      +---------------------------+--------------------------------+
      | YResolution               | 98, 196, 100, 200 (pixels/inch)|
      +---------------------------+--------------------------------+
      | Extension Fields                                           |
      +---------------------------+--------------------------------+
      | T4Options                 | 0: MH coding, EOLs not byte    |
      |                           |               aligned          |
      |                           | 4: MH coding, EOLs byte aligned|
      +---------------------------+--------------------------------+

4. Extended Black-and-White fax mode

   This section defines the extended black-and-white mode or Profile F
   of TIFF for facsimile. It provides a standard definition of what has
   historically been known as TIFF Class F and now TIFF-F. In doing so,
   it aligns this mode with current ITU-T Recommendations for black-
   and-white fax and with existing industry practice. Implementations of
   this profile include implementations of Profile S.




McIntyre, et. al.           Standards Track                    [Page 24]

RFC 2301              File Format for Internet Fax            March 1998


   This section describes extensions to the minimal interchange set of
   fields (Profile S) that provide a richer set of black-and-white
   capabilities. The fields and values described in this section are a
   superset of the fields and values defined for the minimal interchange
   set in Section 3. In addition to the MH encoding, Modified READ (MR)
   and Modified Modified READ (MMR) encoding as described in [T.4] and
   [T.6] are supported.

   Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the
   TIFF fields that SHALL be used in this mode. Section 4.3 describes
   the fields that MAY be used in this mode. In the spirit of the
   original TIFF-F specification, Sections 4.4 and 4.5 discuss technical
   implementation issues and warnings. Section 4.6 gives an example use
   of TIFF-F. Section 4.7 gives a summary of the required and
   recommended fields and their values.

4.1 TIFF-F Overview

   Though it has been in common usage for many years, TIFF-F has
   previously never been documen