rfc2306.txt

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

                   |  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
                   +-----------------------+
                   |          :            |
                   |          :            |

       Figure 3.1     TIFF-F Minimum Subset File Structure

   As depicted in Figure 3.1, the IFD of each page precedes the related
   Image Data for that page.  If present, any long field values appear
   between the IFD and the image data for that page.  For multiple page
   documents, each IFD/image pair is immediately followed by the next
   IFD/image pair in logical page order within the file structure, until
   all pages have been defined.




Parsons & Rafferty           Informational                     [Page 13]

RFC 2306                     TIFF-F Profile                   March 1998


   The format for the TIFF Header is as defined in [TIFF].  When writing
   TIFF-F minimum subset files, the value for the byte order in the
   Header SHOULD be II (0x4949, denoting that the bytes in the TIFF file
   are in LSB first (little-endian) order.

   This results in a TIFF header whose content is as shown in Figure
   3.2.

   | Offset |   Description     | Type   |     Value          |
   +--------+-------------------+--------+--------------------+
   |   0    |   Byte Order      | Short  |  0x4949 (II)       |
   +--------+-------------------+--------+--------------------+
   |   2    |   Version         | Short  |  42                |
   +--------+-------------------+--------+--------------------+
   |   4    | Offset of 0th IFD | Long   |  0x 0000 0008      |
   +--------+-------------------+--------+--------------------+

   Figure 3.2: Image File Header for Minimum Subset TIFF-F Files

 3.7  Technical Implementation Issues

3.7.1   Strips

   Those new to TIFF may not be familiar with the concept of "strips"
   embodied in the three fields RowsPerStrip, StripByteCount,
   StripOffsets.

   In general, third-party implementations that read and write TIFF
   files expect the image to be divided into "strips," also known as
   "bands."  Each strip contains a few lines of the image. By using
   strips, a TIFF reader need not load the entire image into memory,
   thus enabling it to fetch and decompress small random portions of the
   image as necessary.

   The dimensions of a strip are described by the RowsPerStrip and
   StripByteCount fields.  The location in the TIFF file of each strip
   is contained in the StripOffsets field.

   The size of TIFF-F strips is application dependent.  The recommended
   approach for multi-page TIFF-F images is to represent each page as a
   single strip.










Parsons & Rafferty           Informational                     [Page 14]

RFC 2306                     TIFF-F Profile                   March 1998


3.7.2  Bit Order

   The default bit order in Baseline TIFF per [TIFF] is indicated by
   FillOrder=1, where bits are not reversed before being stored.
   However, TIFF-F typically utilizes the setting of FillOrder=2, where
   the bit order within bytes is reversed before storage (i.e., bits are
   stored with the Least Significant Bit first).

   Facsimile data appears on the phone line in bit-reversed order
   relative to its description in CCITT Recommendation T.4.  Therefore,
   a wide majority of facsimile implementations choose this natural
   order for storage. Nevertheless, TIFF-F readers must be able to read
   data in both bit orders.

3.7.3  Multi-Page

   Many existing implementations already read TIFF-F like files, but do
   not support the multi- page field.  Since a multi-page format greatly
   simplifies file management in fax application software, TIFF-F
   specifies multi-page documents (NewSubfileType = 2) as the standard
   case.

3.7.4 Compression

   In Group 3 facsimile, there are three compression methods which had
   been standardized as of 1994 and are in common use.  The ITU-T T.4
   recommendation defines a one-dimensional compression method known as
   Modified Huffman (MH) and a two-dimensional method known as Modified
   READ (MR) (READ is short for Relative Element Address Designate).  In
   1984, a somewhat more efficient compression method known as Modified
   Modified READ (MMR) was defined in the T.6 recommendation.  It was
   originally defined for use with Group 4 facsimile, so that this
   compression method has been commonly called Group 4 compression.  In
   1991, the MMR method was approved for use in Group 3 facsimile and
   has since been widely utilized.

   TIFF-F permits three different compression methods.  In the most
   common practice, the one-dimensional compression method (Modified
   Huffman) is used.  This is specified by setting the value of the
   Compression field to 3 and then setting bit 0 of the T4Options field
   to 0.  Alternatively, the two dimensional Modified READ method (which
   is much less frequently used in historical TIFF-F implementations)
   may be selected by setting bit 0 to a value of 1.

   Optionally, depending upon the implementation requirements, the more
   efficient two-dimensional compression method from T.6 (i.e.  MMR or
   "Group 4 compression") may be selected.  This method is selected by




Parsons & Rafferty           Informational                     [Page 15]

RFC 2306                     TIFF-F Profile                   March 1998


   setting the value of the Compression field to 4 and then setting the
   value of the first two bits (and all unused bits) of T6options to 0.
   More information to aid the implementer in making a compression
   selection is contained in section 3.8 on Implementation Warnings.

3.7.5  Example Use of Page-quality Fields

   Here are examples for writing the CleanFaxData,  BadFaxLines, and
   ConsecutiveBadFaxLines fields:

       1.  Facsimile hardware does not provide page quality
           information: MUST NOT write page-quality fields.
       2.  Facsimile hardware provides page quality information, but
           reports no bad lines.  Write only BadFaxLines = 0.
       3.  Facsimile hardware provides page quality information, and
           reports bad lines.  Write both BadFaxLines and
           ConsecutiveBadFaxLines.  Also write CleanFaxData = 1 or 2 if
           the hardware's regeneration capability is known.
       4.  Source image data stream is error-corrected or otherwise
           guaranteed to be error-free such as for a computer generated
           file:  SHOULD NOT write page-quality fields.

3.7.6   Use of TIFF-F for Streaming Applications

   TIFF-F has historically been used for handling fax image files in
   implementations such as store and forward messaging where the entire
   size of the file is known in advance.  While TIFF-F may also possibly
   be used as a file format for cases such as streaming applications,
   different assumptions may be required than those provided in this
   document (e.g., the entire size and number of pages within the image
   are not known in advance).  As a result, a definition for the
   streaming application of TIFF-F is beyond the scope of this document.

3.7.7  TIFF-F Export and Import

   Fax implementations that do not wish to support TIFF-F as a native
   format may elect to support it as import/export medium.

   Export

   It is recommended that implementations export multiple page TIFF-F
   files without manipulating fields and values.   Historically, some
   TIFF-F writers have attempted to produce individual single-page
   TIFF-F files with modified NewSubFileType and PageNumber (page one-
   of-one) values for export purposes.  However, there is no easy way to
   link such multiple single page files together into a logical multiple
   page document, so that this practice is not recommended.




Parsons & Rafferty           Informational                     [Page 16]

RFC 2306                     TIFF-F Profile                   March 1998


   Import

   A TIFF-F reader MUST be able to handle a TIFF-F file containing
   multiple pages.

3.8  Implementation Warnings

   3.8.1  Uncompressed data

   TIFF-F requires the ability to read and write at least one-
   dimensional T.4 Huffman ("compressed") data.  Uncompressed data is
   not allowed.  This means that the "Uncompressed" bit in T4Options or
   T6Options must be set to 0.

3.8.2  Encoding and Resolution

   Since two-dimensional encoding is not required for Group 3
   compatibility, some historic TIFF-F readers have not been able to
   read such files.  The minimum subset of TIFF-F REQUIRES support for
   one dimensional (Modified Huffman) files, so this choice maximizes
   portability.  However, implementers seeking greater efficiency SHOULD
   use T.6 MMR compression when writing TIFF-F files.  Some TIFF-F
   readers will also support two-dimensional Modified READ files.
   Implementers that wish to have the maximum flexibility in reading
   TIFF-F files SHOULD support all three of these compression methods
   (MH, MR and MMR).

   For the case of resolution, almost all facsimile products support
   both standard (98 dpi) vertical resolution  and "fine" (196 dpi)
   resolution.  Therefore, fine-resolution files are quite portable in
   the real world.

   In 1993, the ITU-T added support for higher resolutions in the T.30
   recommendation including 200 x 200, 300 x 300, 400 x 400 in dots per
   inch based units.  At the same time, support was added for metric
   dimensions which are equivalent to the following inch based
   resolutions: 391v x 204h and 391v x 408h.  Therefore, the full set of
   inch-based equivalents of the new resolutions are supported in the
   TIFF-F writer, since they may appear in some image data streams
   received from Group 3 facsimile devices.  However, many facsimile
   terminals and older versions of  TIFF-F readers are likely to not
   support the use of these higher resolutions.

   Per [T.4], it is permissible for implementations to treat the
   following XResolution values as being equivalent: <204,200> and
   <400,408>.  In a similar respect, the following YResolution values





Parsons & Rafferty           Informational                     [Page 17]

RFC 2306                     TIFF-F Profile                   March 1998


   may also be treated as being equivalent: <98, 100>, <196, 200>, and
   <391, 400>.   These equivalencies were allowed by [T.4] to permit
   conversions between inch and metric based facsimile terminals.

   In a similar respect, the optional support of metric based
   resolutions in the TIFF-F reader (i.e. 77 x 38.5 cm) is included for
   completeness, since they are used in some legacy TIFF-F
   implementations, but this use is not recommended for the creation of
   TIFF-F files by a writer.

3.8.3  EOL byte-aligned

   The historical convention for TIFF-F has been that all EOLs in
   Modified Huffman or Modified READ data must be byte-aligned.
   However, Baseline TIFF has permitted use of non-byte-aligned EOLs by
   default, so that a large percentage of TIFF-F reader implementations
   support both conventions.   Therefore, the minimum subset of TIFF-F
   as defined in this document includes support for both byte-aligned
   and non-byte-aligned EOLs.

   An EOL is said to be byte-aligned when Fill bits have been added as
   necessary before EOL codes such that EOL always ends on a byte
   boundary, thus ensuring an  EOL-sequence of a one byte preceded by a
   zero nibble: xxxx0000 00000001.

   Modified Huffman encoding encodes bits, not bytes. This means that
   the end-of-line token may end in the middle of a byte. In byte
   alignment, extra zero bits (Fill) are added so that the first bit of
   data following an EOL begins on a byte boundary. In effect, 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).

   For Modified READ encoding, each line is terminated by an EOL and a
   one bit tag bit.  Per [T.4], the value of the tag bit is 0 if the
   next line contains two dimensional data and 1 if the next line is a
   reference line.   To maintain byte alignment, fill bits are added
   before the EOL/tag bit sequence, so that the first bit of data
   following an MR tag bit begins on a byte boundary.

3.8.4  EOL

   As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded
   with Modified Huffman begin with an EOL (which in TIFF-F may be
   byte-aligned). The last line of the image is not terminated by an
   EOL.  In a similar respect, images encoded with Modified READ two
   dimensional encoding begin with an EOL, followed by a tag bit.




Parsons & Rafferty           Informational                     [Page 18]

RFC 2306                     TIFF-F Profile                   March 1998


3.8.5  RTC Exclusion

   Aside from EOLs, TIFF-F files have historically only contained image
   data. This means that implementations which wish to maintain strict
   conformance with the rules in [TIFF] and compatibility with
   historical TIFF-F, SHOULD NOT include the Return To Control sequence
   (RTC) (consisting of 6 consecutive EOLs) when writing TIFF- F files.
   However, implementations which need to support "transparency" of
   [T.4] image data MAY include RTCs when writing TIFF-F files if the
   flag settings of the T4Options field are set for non-byte aligned MH
   or MR image data.  Implementors of TIFF readers should also be aware
   that there are some existing TIFF-F implementations which include the
   RTC sequence in MH/MR image data.  Therefore, TIFF-F readers MUST be
   able to process files which do not include RTCs and SHOULD be able to
   process files which do include RTCs.

3.8.6  Use of EOFB for T.6 Compressed Images

   TIFF-F pages which are encoded with the T.6 Modified Modified READ
   compression method MUST include an "end-of-facsimile-block" (EOFB)
   code at the end of each coded strip. Per [TIFF], the EOFB code is
   followed by pad bits as needed to align on a byte boundary.   TIFF
   readers SHOULD ignore any bits other than pad bits beyond the EOFB.

3.9  TIFF-F Fields Summary

   Implementations may choose to implement a TIFF-F Reader, TIFF-F
   Writer or both, depending upon application requirements.  The TIFF- F
   Reader is typically used to read an existing TIFF-F file which
   resides on a computer or peripheral device.  The TIFF-F Writer is
   typically used to convert a bi-level image bit stream into a TIFF-F
   compliant file. For many Internet applications, only the Reader needs
   to be implemented. The specific field support required for TIFF-F
   Readers and Writers is summarized below.

3.9.1  TIFF Reader

   The fields in the following table are specified for a TIFF-F Reader.
   The range of values for required and recommended fields are as shown.