

                                    TIFF CLASS F


                                March 1, 1992

        TIFF Class F was defined in late 1989 by Joe Campbell of
        Everex Systems, Inc. from the results of a poll of the
        facsimile industry. The goal was to define a file format that
        is simultaneously suitable for native use in Group 3 computer
        facsimile products, and as a file interchange medium with the
        outside world.  Since that time, there have been only three
        minor revisions, mostly editorial in nature.  Those wishing
        to participate in the revision and upkeep of TIFF Class F
        should read the section "Revising the TIFF Class F
        Specification," at the end of this document.The revision
        history of the specification is at the end of this document.
        TIFF Class F defines a subset (a "Class") of existing TIFF
        tags, necessary to support Group  3 facsimile data. In many
        cases, the values and sizes of these tags are also defined.
        Three new optional tags are also defined.

        TIFF Classes reduce the information burden on TIFF readers
        and writers that wish to support narrow applications. For
        example, Appendix G-1 of TIFF 5.0 states that classes enable
        TIFF readers "to know when they can stop adding TIFF
        features."  In other words, defining a Class enables
        applications interested only in reading that Class to give up
        if the characteristic tags and values are not present.
        Therefore, TIFF Class F insists on a rather narrow definition
        of tags. In a general TIFF file, for example, the writer
        would be free to create single-page documents without the
        NewSubFileType and PageNumber tags.  Not so for a Class F
        file, where the multi-page tag is required even for a single
        page.

        TIFF Class B (Bilevel) is a sub-class of TIFF. That is, all
        tags that are required in TIFF are also required in Class B.
        TIFF Class F (Facsimile) is a sub-class of Class B (Bilevel).
        That is, all tags that are required in Class B are also
        required in Class F. For some common tags, however, Class F
        limits the range of acceptable values.  The YResolution tag,
        for example, is a Class B tag, but its Class F value is
        limited to either 98 or 196 dpi. Such tags are listed in
        "Required Class F Tags."

        Other Class B tags have a slightly eccentric meaning when
        applied to facsimile images.  These are discussed in the
        section "Bilevel Required." There are also tags that may be
        helpful but are not required. These are listed in the
        "Recommended Tags" section. A brief list of all the tags
        required by TIFF Class F, grouped by class, is in the section
        "Required Facsimile Tags Grouped By Class." Finally,
        technical topics are discussed in the sections "Technical
        Points" and "Warnings."



    REFERENCES

        A machine-readable copy of this document can be downloaded
        from the Aldus Forum on Compuserve.  Type GO ALDUS and look
        through the "Libraries" menu. (Make certain that you download
        the most recent revision.)  Substantive questions about TIFF
        Class F can be faxed to its author: Joe Campbell, Everex
        Systems, Inc: (510) 540-5835 or (510) 841-5441, or via
        Compuserve Mail 71331,1237. Internet users can contact the
        author through the Compuserve gateway as
        71331.1237@CompuServe.COM."


        Group 3 facsimile is described in the "Blue Book," Volume
        VII, Fascicle VII.3, Terminal Equipment and Protocols for
        Telematic Services, The International Telegraph and Telephone
        Consultative Committee (CCITT), Melbourne, 1988.


    CLASS F REQUIRED


             Compression = 3 or 4.  SHORT.

             3   Group 3, one-dimensional encoding with "byte-aligned"
                 EOL's.  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 1 byte preceded by a
                 zero nibble: xxxx0000 00000001.  The data in a Class
                 F image is not terminated with an RTC.  Please see
                 items 4 and 5 in the "Warnings" section.  For Group
                 3 two-dimensional encoding, set bit 1 in
                 Group3Options. Please see item 2 in the "Warnings"
                 section.

             4   Group 4 two-dimensional encoding.  MMR (Modified-
                 Modified READ) compression, formerly found only in
                 Group 4 facsimile, are now available in Group 3
                 devices.  When this option is used, bits zero
                 and one in the Group3Options tag are ignored.


        FillOrder = 1, 2.  SHORT.
           TIFF Class F readers must be able to read data in both bit
           orders, but the  vast majority of facsimile products store
           data LSB first, exactly  as it appears on the telephone
           line.

             1   Most Significant Bit first.

             2   Least Significant Bit first.

       Group3Options = 4,5.  LONG.
           Data may be one- or two-dimensional, but EOL's must be
           byte-aligned. Uncompressed data is not allowed.  When
           Group 4 compression is used, bits zero and one in the
           Group3Options tag should be ignored.

          bit 0   0 for 1-Dimensional, 1 for 2-Dimensional
          bit 1   Must be 0 (uncompressed data not allowed)
          bit 2   1 for byte-aligned EOL's

        ImageWidth = 864, 1216, 1728, 2048, 2432.  SHORT or LONG. LONG
           recommended. These are the fixed page    widths in pixels
           defined in CCITT Group 3.

        NewSubFileType = 2.  LONG.
           The value 2 identifies a single page of a multi-page image,
           even if the document contains only one page.


        PageNumber.  SHORT/SHORT.

           This tag specifies the page numbers in the fax document.
           The tag comprises two SHORT values: the first value is the
           page number, the second is the total number of pages. The
           number of the first page is zero. Single-page documents
           therefore use 00000001 hex. The total number of pages is
           required only in the PageNumber tag associated with the
           first IFD, and is optional in subsequent IFD's.  Writers
           utilizing this option should set the page count portion of
           the subsequent PageNumber tags to zero. (Please remember
           that the first IFD is not necessarily page one.)


        ResolutionUnit = 2,3.  SHORT.
           The units    of measure for resolution:

              2  Inch

              3  Centimeter

        XResolution = 204, 300, 400 (inches).RATIONAL.
           The horizontal resolution of the image expressed    in
           pixels per resolution unit.  See "Technical Point #6,"
           below.

        YResolution = 98, 196, 300, 400 (inches).RATIONAL.
           The vertical resolution of the image expressed in pixels
           per resolution unit. See "Technical Point #6," below.



    BILEVEL REQUIRED


        Although these tags are already required in Class B (Bi-
        Level) files, an explanation of their usage for facsimile
        images may be helpful.

        BitsPerSample = 1.  SHORT.
           Since facsimile is a black-and-white medium, this must be
           1 (the default) for all files.

        ImageLength.  SHORT or LONG.  LONG
           Recommended. The total number of scan lines in the image.

        PhotometricInterp = 0,1.  SHORT.
           This tag allows notation of an inverted ("negative") image:

              0  Normal
              1  Inverted


        RowsPerStrip.  SHORT or LONG.  LONG
           Recommended. The number of scan lines per strip.  When a
           page is expressed as one large strip, this is the same as
           the ImageLength tag.

        SamplesPerPixel = 1.  SHORT.
           The value of 1 denotes a bi-level, gray scale, or palette
           color image.

        StripByteCounts.  SHORT or LONG.  SHORT
           Recommended. For each strip, the number of bytes in that
           strip. If a page is expressed as one large strip, this is
           the total number of bytes in the page after compression.

        StripOffsets.  SHORT or LONG.
           For each strip, the offset of that strip.  The offset is
           measured from the beginning of the file. If a page is
           expressed as one large strip, there is one such entry
           per page.


    NEW TAGS

        There are only three new tags for Class F.  All three tags
        describe page quality.  The information contained in these
        tags is usually obtained from the receiving facsimile
        hardware, but since not all devices are capable of reporting
        this information, the tags are optional.

        Some applications need to understand exactly the error
        content of the data.  For example, a CAD program might wish
        to verify that a file has a low error level before importing
        it into a high-accuracy document.  Because Group 3 facsimile
        devices do not necessarily perform error correction on the
        image data, the quality of a received page must be inferred
        from the pixel count of decoded scan lines. A "good" scan
        line is defined as a line that, when decoded, contains the
        correct number of pixels. Conversely, a "bad" scan line is
        defined as a line that, when decoded, comprises an incorrect
        number of pixels.


             BadFaxLines

             Tag  = 326  (146 hex)

             Type = SHORT or LONG

        This tag reports the number of scan lines with an incorrect
        number of pixels encountered by the facsimile during
        reception (but not necessarily in the file).

                       Note: PercentBad = (BadFaxLines/ImageLength) * 100



             CleanFaxData

             Tag = 327 (147 hex)

             Type = SHORT

             0   The data is "pure": it contains no lines with incorrect
                 pixel counts and no substituted lines.  Computer-generated
                 files should always have a value of 0.

             1   The receiving device substituted good lines for lines having
                 an incorrect pixel count.

             2    Lines with an incorrect pixel count exist in the data.


        Many facsimile receiving devices do not actually output bad
        lines. Instead, when a bad line is encountered, the receiver
        substitutes a good line.  An variety of methods are employed
        to derive the pixel content of the substituted line.  The
        most common are:

        1.  Fixed-pattern substitution (for example, an all-white or
            all-black line).

        2.  Substitution of a previous good line.

        3.  Artificial intelligence may be employed to reconstruct the
            line based upon context.

        Although line substitution usually results in a visual
        improvement in the image, the image data is nevertheless
        corrupted. The CleanFaxData tag describes the error content
        of the data.  That is, when the BadFaxLines and ImageLength
        tags indicate that the facsimile device encountered lines
        with an incorrect number of pixels during reception, the
        CleanFaxData tag indicates whether these lines are actually
        in the data or if the receiving facsimile device replaced
        them with substitute lines.

             ConsecutiveBadFaxLines

             Tag  = 328 (148 hex)

             Type =  LONG or SHORT

        This tag reports the maximum number of consecutive lines
        containing an incorrect number of pixels encountered by the
        facsimile device during reception (but not necessarily in the
        file).

        The BadFaxLines and ImageLength data indicate only the
        quantity of such lines.  The ConsecutiveBadFaxLines tag is an
        indicator of their distribution and may therefore be a better
        general indicator of perceived image quality.


    RECOMMENDED TAGS


       BadFaxLines.  LONG.
           The number of "bad" scan lines encountered by the facsimile
           during reception.

       ConsecutiveBadFaxLines.  LONG or SHORT.
           The maximum number of consecutive scan lines with incorrect
           pixel count encountered by the facsimile device reception.


         DateTime.  ASCII.
           Date and time in the format YYYY:MM:DD HH:MM:SS, in 24-hour
           format. String length including NUL byte is 20 bytes. Space
           between DD and HH.

         DocumentName.  ASCII.
           This is the name of the document from which the document
           was scanned.

         ImageDescription.  ASCII.
           This is an ASCII string describing the contents of the
           image.

         Orientation.  SHORT.
           This tag might be useful for displayers that always want
           to show the same orientation, regardless of the image.
           The default value of 1 is "0th row is visual top of image,
           and 0th column is the visual left."  An 180-degree
           rotation is 3.  See TIFF 5.0 for an explanation of other
           values.

         Software.  ASCII.
           The optional name and release number of the software
           package that created the image.



    REQUIRED TAGS GROUPED CLASS


        Required Tags, all TIFF:
           NewSubFileType, ImageWidth, ImageLength, StripOffsets,
           RowsPerStrip, StripByteCounts, XResolution, YResolution,
           ResolutionUnit

        Required Tags, Class B:
           BitsPerSample, Compression, PhotometricInterp, SamplesPerPixel

        Required Tags, Class F:
           FillOrder, Group3Options, PageNumber


    FILE INTERCHANGEABILITY

        File portability among various TIFF F applications,
        regardless of platform or operating system, is a primary goal
        of TIFF Class F. The following tag values should be used to
        assure maximum portability:

        1.  FillOrder is 2 (least-significant bit first).

        2.  Group3Options = 4 (one-dimensional encoding).

        3.  ImageWidth is 1728 (that is, an A4 page).

        4.  ImageLength must not exceed 1084 for 98
            dpi documents and 2167 for 196 dpi documents (that is, an
            A4 page).  See Note 2, below.

        5.  PhotometricInterp is 0 (normal).

        6.  ResolutionUnit = 2 (inches).

        7.  XResolution is 204.

        8.  YResolution tag is 98 or 196.


    TECHNICAL POINTS


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

            In general, third-party applications that read and write
            TIFF files expect the image to be divided into horizontal
            "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 tags.  The location in the
            TIFF file of each strip is contained in the StripOffsets
            tag.  Is is perfectly acceptable for a Class F file to
            store an entire page in a single strip.

            In addition to strips, TIFF also permits image data to be
            divided into rectangular tiles. Class F images may not be
            organized as tiles.

        2.  EOL Placement in Strips
            As illustrated in FIGURE 1/T.4 in Recommendation T.4 (the
            "Blue Book"), facsimile documents begin with an EOL (End-
            of-Line) code. The last line of the image is not
            terminated by an EOL. Expressed differently, EOL's are
            actually BOL's (Beginning-of-Line).

            When a page is stored as a multi-strip image, one must
            consider where to divide scanline data. With the RTC not
            included, treating EOL codes like BOL codes permits all
            strips to have a consistent format: RowsPerStrip  EOL-
            prefixed lines of data. Consequently, multi-strip Class F
            images must break data such that each strip begins with an
            EOL code. This is easily done if these codes are treated
            like BOL codes.

        3.  Bit Order
            Although the TIFF 5.0 documentation lists the FillOrder
            tag in the category "No Longer Recommended," Class F
            resurrects it. 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 applications choose this natural order for
            storage. Nevertheless, TIFF Class F readers must be able
            to read data in both bit orders.

        4.  Multi-Page
            Many existing applications already read Class F-like
            files, but do not support the multi-page tag.  Since a
            multi-page format greatly simplifies file management in
            fax application software, Class F specifies multi-page
            documents (NewSubfileType = 2). A "multi-page document"
            may contain only one page.

        5.  Two-dimensional Encoding
            PC Fax applications that wish to support two-dimensional
            encoding may do so by setting Bit 0 in the Group3Options
            tag.

        6.  Two-Dimensional Encoding EOL Tag Bits
            When two-dimensional encoding is used, the tag bit that
            specifies whether the next line is one- or two-
            dimensionally encoded is part of the byte that follows the
            byte-aligned EOL code.  That is, the tag bit is logically
            considered to be part of the scan line that it describes.

        7.  Example Use of Page-quality Tags
            Here are examples for writing the CleanFaxData,
            BadFaxLines, and ConsecutiveBadFaxLines tags:

            *  Facsimile hardware does not provide page quality
               information: write no tags.

            *  Facsimile hardware provides page quality information,
               but reports no bad lines.  Write only BadFaxLines = 0.

            *  Facsimile hardware provides page quality information,
               and reports bad lines.  Write both BadFaxLines and
               ConsecutiveBadFaxLines.  Also write CleanFaxData = 1 or
               2 if you know whether the hardware can replace bad
               lines.

            *  Computer generated file:  write CleanFaxData = 0.

        8.  High Resolution
            Although 300 and 400 dpi are, strictly speaking, Group 4
            resolutions, it is virtually certain that they will soon
            be added to Group 3 and, more important, are already in
            common use today capabilities through Group 3's NSF
            mechanism. Only the following resolutions are valid
            (horizontal x vertical): 204 x 98, 204 x 196, 300 x 300,
            400 x 400. Those who choose to store images at the "Group
            4" resolutions risk incompatibility with other fax
            applications.


        9.  Plain Paper Fax

            Many plain-paper printing mechanisms such as those found
            on laser printers are unable to print on the entire
            surface of the paper. The amount of unusable space
            (referred to as the "grabber") varies from device to
            device, but as a general rule, allow about six-tenths of
            an inch. Failure to reduce the image accordingly may cause
            the receiving fax machine to shrink the image to make it
            fit on one page (thus changing its scale), or to print it
            on two sheets of paper.

            The standard paper size for America (8.5 inches by 11.0
            inches), is still not supported by CCITT specifications.
            Therefore, if you wish your images to print at scale on
            American plain paper fax machines, you must limit the
            number of lines per page to 2050 in high resolution and
            1025 in low resolution.

       10.  Minimum TIFF Class F Support
            Fax applications that do not wish to embrace TIFF Class F
            as a native format may elect to support it as
            import/export medium:

            *  Export  The simplest form of support is a Class F
               writer that produces individual single-page Class F
               files with the proper NewSubFile and PageNumber tags.

            *  Import  A Class F reader must be able to handle a Class
               F file containing multiple pages.



    WARNINGS


        1.  Class F requires the ability to read and write at least
            one-dimensional T.4 Huffman ("compressed") data. Due to
            the disruptive effect to application software of line-
            length errors and because such errors are likely in
            everyday facsimile transmissions, uncompressed data is
            not allowed.  In other words, "Uncompressed" bit in
            Group3Options must be 0.

        2.  Since two-dimensional encoding is not required for Group 3
            compatibility, Class F readers may decline to read such
            files. Therefore, for maximum portability write only one-
            dimensional files.  Although the same argument technically
            holds for "fine" (196 dpi) vertical resolution, only a
            tiny fraction of facsimile products support only 98 dpi.
            Therefore, 196-dpi files are quite portable in the real
            world.

        3.  In the spirit of TIFF, all EOL's in data must be byte-
            aligned. 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.

            Recall that 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).

        4.  Aside from EOL's, TIFF Class F files contain only image
            data. This means that the Return-to-Control sequence (RTC)
            is specifically prohibited. Exclusion of RTC's not only
            makes possible the simple concatenation of images, it
            eliminates the mischief failed communications and
            unreadable images that their mistreatment inevitably
            produces.


    REVISING THE TIFF CLASS F SPECIFICATION


        Changes in the specification that reflect changes in the underlying
        CCITT specifications as well as non-technical changes are incorporated
        by editorial fiat. Before substantial modifications are allowed,
        however, the author will consult members of the facsimile industry.

        The main goal in revision is to retain a specification that fulfills
        the original goals and serves the facsimile industry.  It is
        especially important that Class F not be modified to accommodate
        unrelated goals.  For example, there have been proposals to relax
        Class F tag requirements to make it more compatible with other
        flavors of TIFF.  In particular, non-facsimile users seem to be vexed
        by the necessity to byte-align EOL's and to support the multi-page
        format.  Such proposals inevitably originate with users outside the
        mainstream of facsimile vendors, in whose applications both of these
        features are vitally important.  Non-facsimile users who find Class F
        too restrictive might better be served by designing a new TIFF classes
        to accomplish their ends.



    MANUSCRIPT OF PROPOSED REVISION


        Any person or group that wishes to propose an amendment to TIFF Class
        F should prepare the following manuscript:

        1.  Name of the person or group making the request and their
            affiliation (business, academic, etc.).

        2.  The revision date from which you are working.

        3.  The reason for the request.

        4.   A list of changes exactly as you propose that they appear
            in the specification.  Do not submit an edited version
            of the entire specification.  Use inserts, callouts, or
            other obvious editorial techniques to indicate areas of
            change and number each change.

        5.  Referring to each change number, discuss its potential
            effect on other standards that incorporate TIFF Class F
            (e.g., FaxBios).

        6.  A list of phone numbers of persons outside your company
            who may support your position. Include their affiliation
            (business, academic, etc.).

    This manuscript may be faxed to Joe Campbell, Everex Systems,
    Inc: (510) 540-5835 or (510) 841-5441, or via Compuserve Mail
    71331,1237.



    REVISION HISTORY


        11/17/89:     Initial Publication

        4/20/90 : First Revision
             PageNumber tag was incorrectly illustrated as page one. The
        correct number for the first page is zero.

        5/1/91: Second Revision
        1.  Added 300 and 400 valid values to to the XResolution and
        YResolution tags.

        2.  Software tag moved from Bi-level Required (not
        true), to Recommended.

        3.  ImageWidth tag values of  2482 was corrected to 2432.

        4.  New ImageWidth tag values added to conform to the "Blue
        Book,": 864, 1216.

        5.  Corrected miscellaneous typographical errors.

        6.  Added summary of required tags.


        10/1/91: Third Revision,

        1.  Total page count needed only in first tag after IFD.

        2.  Added MMR compression, modification procedure.


        3/1/92: Fourth Revision: EDITORIAL

        1.  Bad fax lines are now said to be "substituted," instead of
        "regenerated."  This generalized approach accommodates techniques
        besides regeneration.

        2.  Clarification of the encoding of EOL 2-d tag bits.

        3.  How to break up data in stripped images.

        4.  Prohibition of using TIFF tiles.

        5.  Deletion of discussion of minimum strip size.

        6.  Added suggestions for adjusting number of scan lines for
            destinations that use plain-paper fax and destinations that use
            U.S. letter-sized paper.



