As per Relevance of the word required, we have this rfc below:
Network Working Group L.
Request for Comments: 2301 Xerox
Category: Standards Track S.
Adobe Systems, Inc
R.
Xerox
D.
Xerox
G.
Northern
J.
Human
March 1998
File Format for Internet
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document describes the TIFF (Tag Image File Format
representation of image data specified by the ITU-T
for black-and-white and color facsimile. This file
specification is commonly known as TIFF-FX. It formally
minimal, extended and lossless JBIG modes (Profiles S, F, J)
black-and-white fax, and base JPEG, lossless JBIG and Mixed
Content modes (Profiles C, L, M) for color and grayscale fax.
modes or profiles correspond to the content of the applicable ITU-
Recommendations. Files formatted according to this specification
the image/tiff MIME Content Type
McIntyre, et. al. Standards Track [Page 1]
RFC 2301 File Format for Internet Fax March 1998
Table of
1. INTRODUCTION........................................................4
1.1. Scope..........................................................5
1.2. Approach.......................................................5
1.3. Overview of this draft.........................................5
2. TIFF and Fax........................................................7
2.1. TIFF Overview..................................................7
2.1.1. File Structure.............................................7
2.1.2. Image Structure............................................9
2.1.3. TIFF File Structure for Fax Applications..................10
2.2 TIFF Fields for All Fax Applications...........................11
2.2.1. TIFF Fields required for all fax modes....................12
2.2.2. Additional TIFF Fields required for all fax modes.........13
2.2.3. TIFF Fields recommended for all fax modes.................15
2.2.4. New TIFF Fields recommended for fax modes.................16
3. Minimal Black-and-White Fax Mode...................................18
3.1. Overview......................................................18
3.2. Required TIFF Fields..........................................18
3.2.1 Baseline Fields............................................18
3.2.2 Extension Fields...........................................20
3.2.3 New Fields.................................................20
3.3. Recommended TIFF Fields.......................................20
3.4. End of Line (EOL) and Return to Control (RTC).................20
3.4.1 RTC Exclusion..............................................21
3.5. File Structure................................................22
3.6. Minimal Black-and-White Mode Summary..........................23
4. Extended Black-and-White Fax Mode..................................24
4.1. TIFF-F Overview...............................................25
4.2. Required TIFF Fields..........................................26
4.2.1. Baseline Fields...........................................26
4.2.2. Extension Fields..........................................28
4.2.3. New Fields................................................29
4.3. Recommended TIFF Fields.......................................29
4.3.1. Baseline Fields...........................................29
4.3.2. Extension Fields..........................................29
4.3.3. New Fields................................................29
4.4. Technical Implementation Issues...............................30
4.4.1. Strips....................................................30
4.4.2. Bit Order.................................................31
4.4.3. Multi-Page................................................31
4.4.4. Compression...............................................31
4.4.5. Example Use of Page-quality Fields........................32
4.4.6. Practical Guidelines for Writing and Reading Multi-
TIFF-F Files..............................................33
4.4.7. Use of TIFF-F for Streaming Applications..................34
4.5. Implementation Warnings.......................................34
4.5.1. Uncompressed Data.........................................34
McIntyre, et. al. Standards Track [Page 2]
RFC 2301 File Format for Internet Fax March 1998
4.5.2. Encoding and Resolution...................................35
4.5.3. EOL byte-aligned..........................................35
4.5.4. EOL.......................................................36
4.5.5. RTC Exclusion.............................................36
4.5.6. Use of EOFB for T.6 Compressed Images.....................37
4.6. Example Use of TIFF-F.........................................37
4.7. Extended Black-and-white Fax Mode Summary.....................37
5. Lossless JBIG Black-and-White Fax Mode.............................39
5.1. Overview......................................................40
5.2. Required TIFF Fields..........................................40
5.2.1. Baseline Fields...........................................40
5.2.2. Extension Fields..........................................40
5.2.3. New Fields................................................41
5.3. Recommended TIFF Fields.......................................41
5.4. Lossless JBIG Black-and-White Mode Summary....................41
6. Base Color Fax Mode................................................43
6.1. Overview......................................................43
6.2. Required TIFF Fields..........................................43
6.2.1. Baseline Fields...........................................43
6.2.2. Extension Fields..........................................45
6.2.3. New Fields................................................46
6.3. Recommended TIFF Fields.......................................47
6.4. Base Color Fax Mode Summary...................................47
7. Lossless Color Mode................................................49
7.1. Overview......................................................50
7.1.1. Color Encoding............................................50
7.1.2. JBIG Encoding.............................................50
7.2. Required TIFF Fields..........................................51
7.2.1. Baseline Fields...........................................51
7.2.2. Extension Fields..........................................52
7.2.3. New Fields................................................53
7.3. Recommended TIFF Fields.......................................53
7.4. Lossless Color Fax Mode Summary...............................53
8. Mixed Raster Content Mode..........................................55
8.1 Overview.......................................................55
8.1.1. MRC 3-layer model.........................................55
8.1.2. A TIFF Representation for the MRC 3-layer model...........56
8.2. Required TIFF Fields..........................................58
8.2.1. Baseline Fields...........................................58
8.2.2. Extension Fields..........................................59
8.2.3. New Fields................................................60
8.3. Recommended TIFF Fields.......................................62
8.4. Rules and Requirements for Images.............................62
8.5. MRC Fax Mode Summary..........................................63
9. MIME content-type image/tiff.......................................66
9.1 Refinement of MIME content-type image/tiff for
Applications...................................................66
10. Security Considerations...........................................67
McIntyre, et. al. Standards Track [Page 3]
RFC 2301 File Format for Internet Fax March 1998
11. References........................................................67
12. Authors' Addresses................................................69
Annex A: Summary of TIFF Fields for Internet Fax .....................70
Annex B. IANA Registration for image/tiff Application
Values used for facsimile....................................75
Full Copyright Statement..............................................77
1.
This document describes the use of TIFF (Tag Image File Format)
represent the data content and structure generated by the
suite of ITU-T Recommendations for Group 3 facsimile.
Recommendations and the TIFF fields described here support
following facsimile modes or profiles
S: minimal black-and-white mode, using binary MH
[T.4]
F: extended black-and-white mode, using binary MH, MR and
compression [T.4, T.6]
J: lossless JBIG black-and-white mode, with JBIG
[T.85, T.82]
C: lossy color and grayscale mode, using JPEG
[T.42, T.81]
L: lossless color and grayscale mode, using JBIG
[T.43, T.82]
M: mixed raster content mode [T.44], using a combination
existing compression
Each profile corresponds to the content of ITU-T
shown and is a subset of the full TIFF for facsimile specification
Profile S describes a minimal interchange set of fields, which
guarantee that, at least, binary black-and-white images will
supported. Implementations are required to support this
interchange set of fields
With the intent of specifying a file format for Internet Fax,
draft
1. specifies the structure of TIFF files for facsimile data
2. defines ITU fax-compatible values for existing TIFF fields
3. defines new TIFF fields and values required for
with ITU color fax
This specification of TIFF for facsimile is known as TIFF-FX
McIntyre, et. al. Standards Track [Page 4]
RFC 2301 File Format for Internet Fax March 1998
1.1
This document defines a TIFF-based file format specification
enabling standardized messaging-based fax over the Internet.
specifies the TIFF fields and field values required for
with the existing ITU-T Recommendations for Group 3 black-and-white
grayscale and color facsimile. TIFF has historically been used
handling fax image files in applications such as store-and-
messaging. Implementations that support this file
specification for import/export may elect to support it as a
format. This document recommends a TIFF file structure that
compatible with low-memory and page-level streaming implementations
Unless otherwise noted, the current TIFF specification [TIFF]
selected TIFF Technical Notes [TTN1, TTN2] are the primary
for describing TIFF and defining TIFF fields. This document is
primary reference for defining TIFF field values for
applications
1.2
The basic approach to using TIFF for facsimile data is to insert
compressed fax image data in a TIFF file and use TIFF fields
encode the parameters that describe the image data. These fields
have values that comply with the ITU-T Recommendations. The
content type of the resulting file will be image/tiff, with
optional Application parameter [TIFF-REG]; see Section 9.
This approach takes advantage of TIFF features and structures
bridge the data formats and performance requirements of both
fax machines and host-based fax applications. TIFF constructs
pages, images, and strips allow a TIFF file to preserve the fax
stream structure and the performance advantages that come with it.
TIFF-based approach also builds on an established base of users
implementors and ensures backward compatibility with existing TIFF
based IETF proposals and work in progress for Internet fax
1.3 Overview of this
Section 2 gives an overview of TIFF. Section 2.1 describes
structure of TIFF files, including general guidelines for
multi-page TIFF files. Section 2.2 lists the TIFF fields that
required or recommended for all fax modes. The TIFF fields used
by specific fax modes are described in Sections 3-8, which
the individual fax modes. These sections also specify the ITU
compatible field values (image parameters) for each mode
McIntyre, et. al. Standards Track [Page 5]
RFC 2301 File Format for Internet Fax March 1998
The full set of permitted fields of TIFF for facsimile are
in the current TIFF specification, Section 2 of this document and
sections on specific modes of facsimile operation. This
defines profiles of TIFF for facsimile, where a profile is a
of the full set of permitted fields and field values of TIFF
facsimile
Section 3 defines the minimal black-and-white facsimile mode (
S), which is required in all implementations. Section 4 defines
extended black-and-white fax mode (Profile F), which provides
standard definition of TIFF-F. Section 5 describes the
black-and-white mode using JBIG compression (Profile J). Section 6
defines the base color mode, required in all color implementations
for the lossy JPEG representation of color and grayscale
data (Profile C). Section 7 defines the lossless JBIG color
grayscale facsimile mode (Profile L) and Section 8 defines the
Raster Content facsimile mode (Profile M). Each of these
concludes with a table summarizing the required and
fields for each mode and the values they can have
Section 9 describes the MIME content type image/tiff and the use
the optional Application parameter in connection with TIFF
facsimile. Sections 10, 11, 12 and 13 give Security Considerations
the ISOC Copyright Notice, References and Authors' Addresses. Annex
gives a summary of the TIFF fields used or defined in this
and provides a convenient reference for implementors
To implement only the minimal interchange black-and-white set
fields and values (Profile S), one need read only Sections 1, 2, 3, 9
and 10.
The following tree diagram shows the relationship among profiles
between profiles and coding methods
S (MH
/ \
B&W / \
------------ ----------
/ \ \
/ F (MMR, MR) C (JPEG
/ / \
J (JBIG) ---- \
/ \
L (JBIG) \
\
M (MRC
A profile is based on a collection of ITU-T facsimile coding methods
McIntyre, et. al. Standards Track [Page 6]
RFC 2301 File Format for Internet Fax March 1998
For example, Profile S, the minimal mode, is based on
Huffman (MH) compression, which are defined in ITU-T Rec. T.4.
Profile F specifies Modified Read (MR) and Modified Modified
(MMR) compressions, which are defined in ITU-T Rec. T.4 and T.6.
All implementations of TIFF for facsimile MUST implement Profile S
which is the root node of the tree. All color implementations of
for facsimile MUST implement Profile C. The implementation of
particular profile MUST also implement those profiles on the
that connect it to the root node, and MAY optionally
profiles not on the path connecting it to the root node. For example
an implementation of Profile M must also implement Profiles C and S
and may optionally implement Profile F, J or L. For another example
an implementation of Profile C must also implement Profile S, and
optionally implement Profile F or J
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [REQ].
2. TIFF and
2.1. TIFF
TIFF provides a means for describing, storing and
raster image data. A primary goal of TIFF is to provide a
environment within which applications can exchange image data.
current TIFF specification [TIFF] defines a commonly used, core
of TIFF fields known as Baseline TIFF. The current specification
TIFF Technical Notes 1 and 2 [TTN1, TTN2] define several
extensions. The TIFF- based specification for fax applications uses
subset of Baseline TIFF fields, with selected extensions,
described in this document. In a few cases, this document defines
TIFF fields specifically for fax applications
2.1.1. File
TIFF is designed for raster images, which makes it a good match
facsimile documents, which are multi-page raster images. Each
image consists of a number of rows or scanlines, each of which
the same number of pixels, the unit of sampling. Each pixel has
least one sample or component (exactly one for black-and-
images).
A TIFF file begins with an 8-byte image file header. The first
bytes describe the byte order used within the file. Legal values
"II" (0x4949) when bytes are ordered from least to most
(little- endian), and "MM" (0x4D4D), when bytes are ordered from
McIntyre, et. al. Standards Track [Page 7]
RFC 2301 File Format for Internet Fax March 1998
to least significant (big-endian) within a 16- or 32-bit integer
Either byte order can be used, except in the case of the
black-and-white mode, which SHALL use value "II". The next two
contain the value 42 that identifies the file as a TIFF file and
ordered according to the value in the first two bytes of the header
The last four bytes give the offset that points to the first
file directory (IFD). This and all other offsets in a TIFF file
with respect to the beginning of the TIFF file. An IFD can be at
location in the file after the header but must begin on a
boundary
An IFD is a sequence of tagged fields, sorted in ascending order
tag value. An IFD consists of a 2-byte count of the number of fields
a sequence of field entries and a 4-byte offset to the next IFD.
fields contain information about the image and pointers to the
data. Each separate raster image in the file is represented by
IFD
Each field entry in an IFD has 12 bytes and consists of a 2-byte Tag
2 bytes identifying the field type (e.g. short, long, rational
ASCII), 4 bytes giving the count (number of values or offsets), and 4
bytes that either contain the offset to a field value stored
the IFD, or, based on the type and count, the field value itself
Resolution and metadata such as dates, names and descriptions
examples of "long" field values that do not fit in 4 bytes
therefore use offsets in the field entry. Details are given in
TIFF specification [TIFF].
A TIFF file can contain more than one IFD, where each IFD is
subfile whose type is given in the NewSubfileType field.
IFDs can be organized either as a linked list, with the last entry
each IFD pointing to the next IFD (the pointer in the last IFD is 0),
or as a tree, using the SubIFDs field in the primary IFD [TTN1].
SubIFDs field contains an array of pointers to child IFDs of
primary IFD
Child IFDs describe related images, such as reduced
versions of the primary IFD image. The same IFD can point both to
next IFD and to child IFDs, and child IFDs can themselves point
other IFDs
All fax modes represent a multi-page fax image as a linked list
IFDs, with a NewSubfileType field containing a bit that
the IFD as one page of a multi-page document. Each IFD has
PageNumber field, identifying the page number in ascending order
starting at 0 for the first page. While a Baseline TIFF reader is
McIntyre, et. al. Standards Track [Page 8]
RFC 2301 File Format for Internet Fax March 1998
required to read any IFDs beyond the first, an implementation
reads the files that comply with this specification SHALL
multiple IFDs. Only the Mixed Raster Content fax mode, described
Section 8, requires the use of child IFDs
The following figure illustrates the structure of a multi-page
file
+-----------------------+
| Header |------------+
+-----------------------+ | First
| IFD (page 0) |<-----------+
+---| |------------+
Value | +-----------------------+ |
Offset +-->| Long Values |--+ |
+-----------------------| | Strip |
| Image Data |<-+ Offset |
| strip 1 page 0 | | |
+-----------------------+ | |
| : | : |
|
+-----------------------+ | Next
| IFD (page 1) |<-----------+
+---| |------------+
Value | +-----------------------+ |
Offset +-->| Long Values |--+ |
+-----------------------| | Strip |
| Image Data |<-+ Offset |
| strip 1 page 1 | | |
+-----------------------+ | |
| strip 2 page 1 |<-+ |
+-----------------------+ | |
| : | : |
|
+-----------------------+ | Next
| IFD (page 2) |<-----------+
| : |
2.1.2 Image
An IFD stores an image as one or more strips, as shown in
preceding figure. A strip consists of 1 or more scanlines (rows)
raster image data in compressed form. An image may be stored in
single strip or may be divided into several strips, which
require less memory to buffer. (Baseline TIFF recommends about 8
bytes per strip, but existing fax usage is typically one strip
image.)
McIntyre, et. al. Standards Track [Page 9]
RFC 2301 File Format for Internet Fax March 1998
Each IFD requires three strip-related fields: StripOffsets
RowsPerStrip and StripByteCounts. The StripOffsets field is an
of pointers to the strip or strips that contain the actual
data. The StripByteCounts field gives the number of bytes in
strip after compression. TIFF requires that each strip, except
last, contain the same number of scanlines, which is given in
RowsPerStrip field. This document introduces the new
field that allows a variable number of scanlines per strip, which
required by the Mixed Raster Content fax mode (Section 8).
Image data is stored as uninterpreted, compressed image data
within a strip. The formats of these streams follow the ITU-
Recommendations. The Compression field in the IFD indicates the
of compression, and other TIFF fields in the IFD describe
attributes, such as color encoding and spatial resolution
Compression parameters are stored in the compressed data stream
rather than in TIFF fields. This makes the TIFF representation
compressed data format specification independent of each another
This approach, modeled on [TTN2], allows TIFF to gracefully add
compression schemes as they become available
Some attributes can be specified both in the compressed data
and within a TIFF field. It is possible that the two values
differ. When this happens for values required to interpret the
stream, then the values in the data stream take precedence.
informational values that are not required to interpret the
stream, such as author name, then the TIFF field value
precedence
2.1.3 TIFF File Structure for Fax
The TIFF specification has a very flexible file structure, which
not specify the ordering of IFDs, field values and image data in
file. Individual applications may require or recommend an ordering
This specification recommends that when using a TIFF file
facsimile, A multi-page fax document SHOULD be represented as
linked list of IFDs. It also recommends that a TIFF file
facsimile SHOULD order pages in a TIFF file in the same way that
are ordered in a fax data stream. In a TIFF file, a page consists
several elements: one or more IFDs (including subIFDs), long
values that are stored outside the IFDs, and image data (in one
more strips).
The minimal black-and-white mode (Profile S) specifies a
ordering of pages and elements within a page (Section 3.5).
extended black-and-white mode (Profile F) provides guidelines
ordering pages and page elements (Section 4.4.6). Other
McIntyre, et. al. Standards Track [Page 10]
RFC 2301 File Format for Internet Fax March 1998
SHOULD follow these guidelines. This recommendation is intended
simplify the implementation of TIFF writers and readers in
applications and the conversion between TIFF file and fax data
representations. However, for interchange robustness, readers
be prepared to read TIFF files whose structure is consistent
[TIFF], which supports a more flexible file structure than
recommended here
This specification introduces an optional new
field, defined in Section 2.2.4. This field has type IFD
indicates parameters describing the fax session. While it is
possible to obtain these parameters by scanning the file, it
convenient to make them available together in one place for fast
easy access. If the GlobalParametersIFD occurs in a TIFF file,
SHOULD be located in the first IFD, immediately following the 8-
image file header
2.2 TIFF Fields for All Fax
The TIFF specification [TIFF] is organized as a baseline set
several extensions, including technical notes [TTN1, TTN2] that
be incorporated in the next release of TIFF. The baseline
extensions have required and optional fields
Facsimile applications require (and recommend) a mixture of
and extensions fields, as well as some new fields that are not
of the TIFF specification and that are defined in this document.
sub- section lists the fields that are required or recommended
all modes. In particular, Section 2.2.1 lists the fields that
required by all modes and that have values that do not depend on
mode. Section 2.2.2 lists the fields that are required by all
and that have values which do depend on the mode. Section 2.2.3
the fields that are recommended for all modes. Fields that
required or recommended by some but not all modes are given in
section (Section 3-8) that describes that mode. The sections for
fax mode have sub-sections for required and recommended fields;
sub-section organizes the fields according to whether they
baseline, extension or new
The fields required for facsimile have only a few legal values
specified in the ITU-T Recommendations. Of these legal values,
are required and some are optional, just as they are
(mandatory) or optional in fax implementations that conform to
ITU-T Recommendations. The required and optional values are noted
the sections on the different fax modes
McIntyre, et. al. Standards Track [Page 11]
RFC 2301 File Format for Internet Fax March 1998
This section describes the fields required or recommended by all
modes. The pattern for the description of TIFF fields in this
is
FieldName(TagValueInDecimal) = allowable values.
Count = (omitted if =1) = (if not in current spec but available
Explanation of the field, how it's used, and the values it can have
Default value, if any, as specified in [TIFF
When a field's default value is the desired value, that field may
omitted from the relevant IFD unless specifically required by
text of this specification
2.2.1. TIFF fields required for all fax
The TIFF fields listed in this section SHALL be used by all
modes, but have field values that are not specified by the
standards, i.e. the fields do not depend on the mode. The next sub
section lists the fields that SHALL be used by all fax modes,
which do have values specified by the ITU-specified or mode-
values. Fields that SHALL be used by some but not all modes are
in the sections (3-8) which describe the modes that uses them
ImageLength(257) SHORT or
Total number of scanlines in image
No default, must be specified
PageNumber(297)
RequiredByTIFFforFAX,
Count = 2
The first number represents the page number (0 for the first page);
the second number is the total number of pages in the document.
the second value is 0, then the total page count is not available
No default, must be
RowsPerStrip(278) SHORT or
The number of scanlines per TIFF strip, except for the last strip
For a single strip image, this is the same as the value of
ImageLength field
Default = 2**32 - 1 (meaning all scanlines in one strip
StripByteCounts(279) SHORT or
Count = number of
For each strip, the number of bytes in that strip after compression
McIntyre, et. al. Standards Track [Page 12]
RFC 2301 File Format for Internet Fax March 1998
No default, must be specified
StripOffsets(273) SHORT or
Count = number of
For each strip, the byte offset from the beginning of the file
the start of that strip
No default, must be specified
2.2.2 Additional TIFF fields required for all fax
The TIFF fields listed in this section SHALL be used by all
modes, but the values associated with them depend on the mode
described and the associated ITU Recommendations. Therefore, only
fields are defined here; the values applicable to a particular
mode are described in Sections 3-8. Fields that SHALL be used by
but not all modes are given in the section (3-8) describing the
that uses them
BitsPerSample(258)
Number of bits per image
Default = 1 (field may be omitted if this is the value
Compression(259)
Compression method used for image
Default = 1 (no compression, so may not be omitted for FAX
FillOrder(266)
The default bit order in Baseline TIFF per [TIFF] is indicated
FillOrder=1, where bits are not reversed before being stored
However, TIFF for Fax 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).
Default = 1 (field may be omitted if this is the value
Facsimile data appears on the phone line in bit-reversed
relative to its description in the relevant ITU
Recommendation. Therefore, a wide majority of
implementations choose this natural order for storage. Nevertheless
all readers conforming to this specification must be able to
data in both bit orders
ImageWidth(256) SHORT or
The number of pixels (columns) per scanline (row) of the
No default, must be specified
McIntyre, et. al. Standards Track [Page 13]
RFC 2301 File Format for Internet Fax March 1998
NewSubFileType(254)
A general indication of the kind of data contained in this
Bit 1 is 1 if the image is a single page of a multi-page document
Default = 0 (no subfile bits on, so may not be omitted for FAX
PhotometricInterpretation(262)
The color space of the image
No default, must be
ResolutionUnit(296)
The unit of measure for resolution. 2 = inch, 3 = centimeter
Default = 2 (field may be omitted if this is the value
SamplesPerPixel(277)
The number of color components per pixel; SamplesPerPixel is 1 for
black-and-white, grayscale or indexed (palette) image
Default =1 (field may be omitted if this is the value
XResolution(282)
The horizontal resolution of the image in pixels per
unit. The ITU-T Recommendations for facsimile specify a small
of horizontal resolutions: 100, 200, 300, 400 pixels per inch,
80, 160 pixels per centimeter (or 204, 408 pixels per inch).
allowed XResolution values for each mode are given in the
defining that mode. Per [T.4], it is permissible for applications
treat the following XResolution values as being equivalent: <204,
200> and <400,408> in pixels/inch. These equivalencies were
by [T.4] to permit conversions between inch and metric
facsimile terminals
TIFF for Facsimile Writers SHOULD express XResolution in inch
units, for consistency with historical practice and to
interoperability. See the table below for information on how
convert from an ITU-T metric value to its inch based
resolution
No default, must be
YResolution(283)
The vertical resolution of the image in pixels per resolution unit
The ITU-T Recommendations for facsimile specify a small number
vertical resolutions: 100, 200, 300, 400 pixels per inch, and 38.5,
77, 154 pixels per centimeter (or 98, 196, 391 pixels per inch).
allowed YResolution values for each mode are given in the
McIntyre, et. al. Standards Track [Page 14]
RFC 2301 File Format for Internet Fax March 1998
defining that mode. Per [T.4], it is permissible for applications
treat the following YResolution values as being equivalent: <98,
100>, <196, 200>, and <391, 400> in pixels/inch. These
were allowed by [T.4] to permit conversions between inch and
based facsimile terminals. TIFF for Facsimile Writers SHOULD
YResolution in inch based units, for consistency with
practice and to maximize interoperability. See the table below
information on how to convert from an ITU-T metric value to its
based equivalent resolution. No default, must be
+-----------------------------+-----------------------------+
| XResolution | YResolution |
+--------------+--------------+--------------+--------------+
|ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit
| =2 (inch) | =3 (cm) | =2 (inch) | =3 (cm) |
+--------------+--------------+--------------+--------------+
| 100 | | 100 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 98 | 38.5 |
| 200 | | 100 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 196 | 77 |
| 200 | | 200 | |
+--------------+--------------+--------------+--------------+
| 204 | 80 | 391 | 154 |
+--------------+--------------+--------------+--------------+
| 300 | | 300 | |
+--------------+--------------+--------------+--------------+
| 408 | 160 | 391 | 154 |
| 400 | | 400 | |
+--------------+--------------+--------------+--------------+
2.2.3 TIFF fields recommended for all fax
The TIFF fields listed in this section MAY be used by all fax modes
However, Profile S writers (the minimal fax mode described in
3) SHOULD NOT use these fields. Recommended fields that are mode
specific are described in Sections 3-8.
DateTime(306)
Date/time of image creation in 24-hour format "YYYY:MM:DD HH:MM:SS".
No default
DocumentName(269)
OptionalInTIFFExtension(DocumentStorageAndRetrieval
The name of the scanned document. This is a TIFF extension field
not a Baseline TIFF field
McIntyre, et. al. Standards Track [Page 15]
RFC 2301 File Format for Internet Fax March 1998
No default
ImageDescription(270)
A string describing the contents of the image
No default
Orientation(274) = 1-8.
1: 0th row represents the visual top of the image; the 0th
represents the visual left side of the image. See the current
spec [TIFF] for further values; Baseline TIFF only requires value=1.
Default = 1.
Note: It is recommended that a writer that is aware of
orientation will include this field to give a positive indication
the orientation, even if the value is the default. If
Orientation field is omitted, the reader SHALL assume a value of 1.
Software(305)
The optional name and release number of the software package
created the image
No default
2.2.4 New TIFF fields recommended for fax
The new TIFF fields listed in this section MAY be used by all
modes, but their support is not expected for the minimal fax
described in Section 3. In addition, support for these new
fields has not been included in historical TIFF-F readers
in Section 4 and [TIFF- F]. These fields describe "global"
of the fax session that created the image data. They are optional
not part of the current TIFF specification, and are defined in
document
The first new field, GlobalParametersIFD, is an IFD that
global parameters and is located in a Primary IFD
GlobalParametersIFD (400)
An IFD containing global parameters. It is recommended that a
writer place this field in the first IFD, where a TIFF reader
find it quickly
Each field in the GlobalParametersIFD is a TIFF field that is
in any IFD. Required baseline fields should not be located in
GlobalParametersIFD, but should be in each image IFD. If a
exists between fields in the GlobalParametersIFD and in the
IFDs, then the data in the image IFD shall prevail
McIntyre, et. al. Standards Track [Page 16]
RFC 2301 File Format for Internet Fax March 1998
Among the GlobalParametersIFD entries is a new ProfileType
which generally describes information in this IFD and in the
file
ProfileType(401)
The type of image data stored in this IFD
0 =
1 = Group 3
No
The following new global fields are defined in this document as
entries for use with fax applications
FaxProfile(402) = 0 - 6.
The profile that applies to this file; a profile is subset of
full set of permitted fields and field values of TIFF for facsimile
The currently defined values are
0: does not conform to a profile defined for TIFF for
1: minimal black & white lossless, Profile
2: extended black & white lossless, Profile
3: lossless JBIG black & white, Profile
4: lossy color and grayscale, Profile
5: lossless color and grayscale, Profile
6: Mixed Raster Content, Profile
CodingMethods(403)
This field indicates which coding methods are used in the file.
bit value of 1 indicates which of the following coding methods
used
Bit 0: unspecified compression
Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman),
Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified Read),
Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR),
Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG),
Bit 5: ITU-T Rec. T.81 (Baseline JPEG),
Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color),
Bits 7-31: reserved for future
Note: There is a limit of 32 compression types to identify
compression methods
VersionYear(404)
Count: 4
The year of the standard specified by the FaxProfile field, given
4 characters, e.g. '1997'; used in lossy and lossless color modes
ModeNumber (405)
The mode of the standard specified by the FaxProfile field.
value of 0 indicates Mode 1.0; used in Mixed Raster Content mode
McIntyre, et. al. Standards Track [Page 17]
RFC 2301 File Format for Internet Fax March 1998
3. Minimal Black-and-White Fax
This section defines the minimal black-and-white subset of TIFF
facsimile. This subset is designated Profile S. All
of TIFF for facsimile SHALL support the minimal subset
Black-and-white mode is the binary fax application most users
familiar with today. This mode is appropriate for black-and-
text and line art. Black-and-white mode is divided into two levels
capability. This section describes the minimal interchange set
TIFF fields that must be supported by all implementations in order
assure that some form of image, albeit black-and-white, can
interchanged. This minimum interchange set is a strict subset of
fields and values defined for the extended black-and-white
(TIFF-F or Profile F) in Section 4, which describes extensions to
minimal interchange set of fields that provide a richer set
black-and-white capabilities
3.1.
The minimal interchange portion of the black-and-white facsimile
supports 1-dimensional Modified Huffman (MH) compression, with
original Group 3 fax resolutions, commonly called "standard"
"fine."
To assure interchange, this mode uses the minimal set of fields,
a minimal set of values. There are no recommended fields in
mode. Further, the TIFF file is required to be "little endian,"
means that the byte order value in the TIFF header is "II". This
defines a required ordering for the pages in a fax document and
the IFDs and image data of a page. It also requires that a
strip contain the image data for each page; see Section 3.5.
image data may contain RTC sequences, as specified in Section 3.4.
3.2. Required TIFF
Besides the fields listed in Section 2.2.1, the minimal black-and
white fax mode requires the following fields. The fields listed
Section 2.2.1 and the fields and fax-specific values specified
this sub- section must be supported by all implementations
3.2.1 Baseline
BitsPerSample(258) = 1.
Binary data only
Default = 1 (field may be omitted if this is the value
McIntyre, et. al. Standards Track [Page 18]
RFC 2301 File Format for Internet Fax March 1998
Compression(259) = 3.
3 = 1- or 2- dimensional coding
The value 3 is a TIFF extension value [TIFF]. The T4Options
must be specified and its value specifies that the data is
using the Modified Huffman (MH) encoding of [T.4].
FillOrder(266) = 2.
2 = Least Significant Bit
NOTE: Baseline TIFF readers are only required to support FillOrder =
1, where the lowest numbered pixel is stored in the MSB of the byte
However, because many devices, such as modems, transmit the LSB
when converting the data to serial form, it is common for black-and
white fax products to use the second FillOrder =2, where the
numbered pixel is stored in the LSB. Therefore, this value
specified in the minimal black-and-white mode
ImageWidth(256) = 1728. SHORT or
This mode only supports a page width of 1728 pixels. This
corresponds to North American Letter and Legal and to ISO A4
pages
No default, must be specified
NewSubFileType(254) = (Bit 1=1).
Bit 1 is 1 if the image is a single page of a multi-page document
Default = 0 (no subfile bits on, so may not be omitted for fax
PhotometricInterpretation(262) = 0.
0 = pixel value 1 means
No default, must be
ResolutionUnit(296) = 2.
The unit of measure for resolution. 2 = inch
Default = 2 (field may be omitted if this is the value
SamplesPerPixel(277) = 1.
The number of components per pixel; 1 for black-and-
Default =1 (field may be omitted if this is the value
XResolution(282) = 200, 204.
McIntyre, et. al. Standards Track [Page 19]
RFC 2301 File Format for Internet Fax March 1998
The horizontal resolution of the image is expressed in pixels
resolution unit. In pixels/inch, the allowed values are 200 and 204,
which may be treated as equivalent. See Section 2.2.2 for inch
metric equivalency
No default, must be
YResolution(283) = 98, 100, 196, 200.
The vertical resolution of the image is expressed in pixels
resolution unit. In pixels/inch, the allowed values are 98, 100,
196 and 200; 98 and 100 may be treated as equivalent, and 196
200 may be treated as equivalent. See Section 2.2.2 for inch-
equivalency
No default, must be
3.2.2 Extension
T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1)
RequiredTIFFExtension (when Compression = 3)
Bit 0 = 0 indicates MH encoding
Bit 1 must be 0
Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not
Default is all bits are 0 (applies when EOLs are not byte aligned
Note: The T4Options field is required when the Compression field
a value of 3. Bit 0 of this field specifies the encoding used (
only in this mode) and Bit 2 indicates whether the EOL codes
byte-aligned or not. If they are byte aligned, then fill bits
been added as necessary so that the End of Line (EOL) codes
end on byte boundaries. See Section 3.4 for details
3.2.3. New
None
3.3. Recommended TIFF
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,
is bit and stream oriented, and TIFF, which is byte and
oriented. Conventional fax, Baseline TIFF and TIFF extensions for
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
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
T4Options used in this specification for MH compression (
= 3) requires EOLs
Furthermore, Bit 2 in the T4Options field indicates whether or
the EOL codes are byte aligned. If Bit 2 = 1, indicating the
codes are byte aligned, then fill bits have been added as
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.
alignment relieves application software of the burden of bit-
every byte while parsing scan lines for line-oriented
manipulation (such as writing a TIFF file). Not all TIFF
historically used for fax are able to deal with non-byte
data
While TIFF extension requires EOL codes, TIFF in fax applications
traditionally prohibited RTC sequences. Implementations that
common processing and interfaces for fax data streams and
fax files would prefer that the TIFF data include RTC sequences
To reconcile these differences, RTCs are allowed in cases where
codes are not byte aligned and no fill bits have been added to
data. This corresponds to situations where the fax data is
inserted in a strip without being processed or interpreted.
should not occur in the data when EOLs have been byte aligned.
is formally specified in the next sub-section
3.4.1. RTC
Implementations which wish to maintain strict conformance with
and compatibility with the historical use of TIFF for fax SHOULD
include the RTC sequence when writing TIFF files. However
implementations which need to support "transparency" of T.4-
image data MAY include RTCs when writing TIFF files if the
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
there are some existing TIFF implementations for fax that include
RTC sequence in MH image data. Therefore, minimal set readers MUST
able to process files which do not include RTCs and SHOULD be able
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
The TIFF header, described in Section 2.1.1, contains two bytes
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
(little- endian). The first or 0th IFD immediately follows
header, so that offset to the first IFD is 8. The headers values
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
within a file as follows: 1) there SHALL be an IFD for each page in
multi- page fax document; (2) the IFDs SHALL occur in the same
in the file as the pages occur in the document; (3) the IFD
precede the image data to which it has offsets; (4) the image
SHALL occur in the same order in the file as the pages occur in
document; (5) the IFD, the value data and the image data it
offsets to SHALL precede the next image IFD; and (6) the image
for each page SHALL be contained within a single strip
As a result of (6), the StripOffsets field will contain the
to the image data. With two exceptions, the field entries in the
contain the field values instead of offsets to field values
outside the IFD. The two exceptions are the values for
XResolution and YResolution fields, both of which are type
and require 2 4- byte numbers. These "long" field values SHALL
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
SHALL come first in the file after the TIFF header, followed by
long field values for XResolution and YResolution, followed by
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
PageNumber field, which has value 0 for the first page, 1 for
second page, and so on
McIntyre, et. al. Standards Track [Page 22]
RFC 2301 File Format for Internet Fax March 1998
+-----------------------+
| Header |------------+
+-----------------------+ | First
| IFD (page 0) | <----------+
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 0) |<-+ Offset |
+-----------------------+ | Next
| IFD (page 1) | <----------+
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 1) |<-+ Offset |
+-----------------------+ | Next
| IFD (page 2) | <----------+
+-----------------------+
| : |
Using this file structure may reduce the memory requirements
implementations. It is also provides some support for streaming,
which a file can be processed as it is received and before the
file is received
3.6 Minimal Black-and-white Mode
The table below summarizes the TIFF fields that comprise the
interchange set for black-and-white facsimile. The Baseline
Extension fields and field values MUST be supported by
implementations. For convenience in the table, certain fields
have a value that is a sequence of flag bits are shown taking
values that correspond to the flags that are set. An
should test the setting of the relevant flag bits individually
however, to allow extensions to the sequence of flag bits to
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
This section defines the extended black-and-white mode or Profile
of TIFF for facsimile. It provides a standard definition of what
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
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
fields (Profile S) that provide a richer set of black-and-
capabilities. The fields and values described in this section are
superset of the fields and values defined for the minimal
set in Section 3. In addition to the MH encoding, Modified READ (MR
and Modified Modified READ (MMR) encoding as described in [T.4]
[T.6] are supported
Section 4.1 gives an overview of TIFF-F. Section 4.2 describes
TIFF fields that SHALL be used in this mode. Section 4.3
the fields that MAY be used in this mode. In the spirit of
original TIFF-F specification, Sections 4.4 and 4.5 discuss
implementation issues and warnings. Section 4.6 gives an example
of TIFF-F. Section 4.7 gives a summary of the required
recommended fields and their values
4.1 TIFF-F
Though it has been in common usage for many years, TIFF-F
previously never been documented in the form of a standard.
informal TIFF-F document was originally created by a small group
fax experts led by Joe Campbell. The existence of TIFF-F is noted
[TIFF] but it is not defined. This document serves as the
definition of the F application of [TIFF] for Internet applications
For ease of reference, the term TIFF-F will be used throughout
document as a shorthand for the extended black-and-white mode
profile of TIFF for facsimile
Up until the TIFF 6.0 specification, TIFF supported various "Classes
which defined the use of TIFF for various applications. Classes
used to support specific applications. In this spirit, TIFF-F
been known historically as "TIFF Class F". Previous informal TIFF-
documents [TIFF-F0] used the "Class F" terminology. As of TIFF 6.0
[TIFF], the TIFF Class concept has been eliminated in favor of
concept of Baseline TIFF. Therefore, this document updates
definition of TIFF-F as the F profile of TIFF for facsimile, by
Baseline TIFF as defined in [TIFF] as the starting point and
adding the TIFF extensions to Baseline TIFF which apply for TIFF-F
In almost all cases, the resulting definition of TIFF-F fields
values remains consistent with those used historically in
definitions of TIFF Class F. Where some of the values for
have been updated to provide more precise conformance with the ITU-
[T.4] and [T.30] fax recommendations, these differences are noted
McIntyre, et. al. Standards Track [Page 25]
RFC 2301 File Format for Internet Fax March 1998
4.2. Required TIFF
This section lists the required fields and the values they must
to be ITU-compatible. Besides the fields listed in Section 2.2.1,
extended black-and-white fax mode SHALL use the following fields
4.2.1. Baseline
BitsPerSample(258) = 1.
Binary data only
Default = 1 (field may be omitted if this is the value
Compression(259) = 3, 4.
3 = 1- or 2- dimensional coding, must have T4Options field This
a TIFF Extension value [TIFF].
4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified
Read, must have T6Options field)) This is a TIFF Extension value
Default = 1 (and is not applicable; field must be specified
NOTE: Baseline TIFF permits use of value 2 for Modified
encoding, but data is presented in a form which does not use EOLs
and so TIFF for facsimile uses Compression=3 instead. See
4.4.4, 4.5.1 and 4.5.2 for more information on compression
encoding
FillOrder(266) = 1 , 2.
Profile F readers must be able to read data in both bit orders
but the vast majority of facsimile products store data
first, exactly as it appears on the telephone line
1 = Most Significant Bit first
2 = Least Significant Bit
ImageWidth(256) SHORT or
This mode supports the following fixed page widths: 1728, 2592, 3456
(corresponding to North American Letter and Legal, ISO A4
sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper size),
2432, 3648, 4864 (corresponding to ISO A3 paper size).
No default; must be
NOTE: Historical TIFF-F did not include support for the
widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096
and 4864. Historical TIFF-F documents also included the
values related to A5 and A6 widths: 816 and 1216. Per the most
McIntyre, et. al. Standards Track [Page 26]
RFC 2301 File Format for Internet Fax March 1998
version of [T.4], A5 and A6 documents are no longer supported
Group 3 facsimile, so the related width values are now obsolete.
section 4.5.2 for more information on inch/metric equivalencies
other implementation details
NewSubFileType(254) = (Bit 1=1).
Bit 1 is 1 if the image is a single page of a multi-page document
Default = 0 (no subfile bits on, so may not be omitted for fax
NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single
of a multi-page image. The same bit settings are used when TIFF-F
used for a one page fax image. See Section 4.4.3 for details
multi-page files
PhotometricInterpretation(262) = 0, 1.
0 = pixel value 1 means black, 1 = pixel value 1 means white
This field allows notation of an inverted or negative image
No default, must be
ResolutionUnit(296) = 2, 3.
The unit of measure for resolution. 2 = inch, 3 = centimeter; TIFF-
has traditionally used inch-based measures
Default = 2 (field may be omitted if this is the value
SamplesPerPixel(277) = 1.
1 = monochrome, bilevel in this case (see BitsPerSample
Default =1 (field may be omitted if this is the value
XResolution(282) = 200, 204, 300, 400, 408
The horizontal resolution of the image is expressed in pixels
resolution unit. In pixels/inch, the allowed values are: 200, 204,
300, 400, and 408. See Section 2.2.2 for inch-metric equivalency
No default, must be
NOTE: The values of 200 and 408 have been added to the
TIFF-F values, for consistency with [T.30]. Some existing TIFF-
implementations may also support values of 80 pixels/cm, which
equivalent to 204 pixels per inch. See section 4.5.2 for
on implementation details
YResolution(283) = 98, 100, 196, 200, 300, 391, and 400
The vertical resolution of the image is expressed in pixels
McIntyre, et. al. Standards Track [Page 27]
RFC 2301 File Format for Internet Fax March 1998
resolution unit. In pixels/inch, the allowed values are: 98, 100,
196, 200, 300, 391, and 400 pixels/inch
See Section 2.2.2 for inch-metric equivalency
No default, must be
NOTE: The values of 100, 200, and 391 have been added to
historical TIFF-F values, for consistency with [T.30]. Some
TIFF-F implementations may also support values of 77 and 38.5 (cm),
which are equivalent to 196 and 98 pixels per inch respectively.
section 4.5.2 for more information on implementation details
NOTE: Not all combinations of XResolution, YResolution and
are legal. The following table gives the legal combinations
corresponding paper size [T.30].
+--------------+-----------------+---------------------------+
| XResolution x YResolution | ImageWidth |
+--------------+-----------------+---------+--------+--------+
| 200x100, 204x98 | | | |
| 200x200, 204x196 | 1728 | 2048 | 2432 |
| 204x391 | | | |
+--------------+-----------------+---------+--------+--------+
| 300 x 300 | 2592 | 3072 | 3648 |
+--------------+-----------------+---------+--------+--------+
| 408 x 391, 400 x 400 | 3456 | 4096 | 4864 |
+--------------+-----------------+---------+--------+--------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------+--------+--------+
| Paper Size |
+---------------------------+
4.2.2. Extension
T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1)
RequiredTIFFExtension (when Compression = 3)
T4Options was also known as Group3Options in a prior version
[TIFF].
Bit 0 = 1 indicates MR encoding, = 0 indicates MH encoding
Bit 1 must be 0
Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not
Default is all bits are 0 (applies when MH encoding is used and
are not byte aligned EOLs) (See Section 3.2.2.)
The T4Options field is required when the Compression field has
value of 3. This field specifies the encoding used (MH or MR)
whether the EOL codes are byte-aligned or not. If they are
McIntyre, et. al. Standards Track [Page 28]
RFC 2301 File Format for Internet Fax March 1998
aligned, then fill bits have been added as necessary so that the
of Line (EOL) codes always end on byte boundaries See Sections 3.4,
4.5.3 and 4.5.4 for details
T6Options(293) = (Bit 0 = 0, Bit 1 = 0).
RequiredTIFFExtension (when Compression = 4)
Used to indicate parameterization of 2D Modified Modified
compression. T6Options was also known as Group4Options in a
version of [TIFF].
Bit 0 must be 0.
Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1
indicates uncompressed data is allowed (see [TIFF]).
Default is all bits 0. For FAX, the field must be present and
the value 0. The use of uncompressed data where compression
expand the data size is not allowed for FAX
NOTE: MMR compressed data is two-dimensional and does not use EOLs
Each MMR encoded image MUST include an "end-of-facsimile-block
(EOFB) code at the end of each coded strip; see Section 4.5.6.
4.2.3. New
None
4.3. Recommended TIFF
4.3.1. Baseline
See Section 2.2.3.
4.3.2. Extension
See Section 2.2.3.
4.3.3. New
Three new, optional fields, used in the original TIFF-F
to describe page quality, are defined in this specification.
information contained in th