[要約] RFC 2306は、TIFF形式の画像ファイルに関するプロファイルであり、ファクシミリ用のFプロファイルを定義しています。このRFCの目的は、ファクシミリ通信における画像ファイルの標準化と相互運用性の向上です。
Network Working Group G. Parsons
Request for Comments: 2306 Northern Telecom
Category: Informational J. Rafferty
Human Communications
March 1998
Tag Image File Format (TIFF) - F Profile for Facsimile
タグ画像ファイル形式（TIFF）-ファクシミリ用のFプロファイル
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Overview
概観
This document describes in detail the definition of TIFF-F that is used to store facsimile images. The TIFF-F encoding has been folklore with no standard reference definition before this document.
このドキュメントでは、ファクシミリ画像の保存に使用されるTIFF-Fの定義について詳しく説明します。 TIFF-Fエンコーディングは民間伝承であり、このドキュメントの前の標準参照定義はありません。
Internet Fax Working Group
インターネットFAXワーキンググループ
This document is a product of the IETF Internet Fax Working Group. All comments on this document should be forwarded to the email distribution list at <ietf-fax@imc.org>.
このドキュメントは、IETF Internet Fax Working Groupの製品です。このドキュメントに関するすべてのコメントは、<ietf-fax@imc.org>の電子メール配布リストに転送する必要があります。
This document references the Tag Image File Format (TIFF) to define the F profile of TIFF for facsimile (TIFF-F) as a file format that may be used for the storage and interchange of facsimile images.
このドキュメントは、ファクシミリ画像の保存と交換に使用できるファイル形式として、ファクシミリ用のTIFF（TIFF-F）のFプロファイルを定義するために、タグ画像ファイル形式（TIFF）を参照します。
TIFF (Tag Image File Format) Revision 6.0 is defined in detail within [TIFF].
TIFF（Tag Image File Format）リビジョン6.0は、[TIFF]で詳細に定義されています。
A brief review of concepts used in TIFF is included in this document as background information, but the reader is directed to the original TIFF specification [TIFF] to obtain specific technical details.
TIFFで使用されている概念の簡単なレビューが背景情報としてこのドキュメントに含まれていますが、読者は特定の技術的な詳細を取得するために元のTIFF仕様[TIFF]に導かれます。
TIFF provides a method to describe and store raster image data. A primary goal of TIFF is to provide a rich environment within which implementations can exchange image data. [TIFF] characterizes Baseline TIFF as being the core of TIFF, the essentials that all mainstream TIFF developers should support in their products. Applications of TIFF are defined by using Baseline TIFF as a starting point and then defining "extensions" to TIFF that are used for the specific "application", as well as specifying any other differences from Baseline TIFF.
TIFFは、ラスターイメージデータを記述および格納する方法を提供します。 TIFFの主な目的は、実装が画像データを交換できるリッチな環境を提供することです。 [TIFF]は、ベースラインTIFFをTIFFのコアであると特徴付けています。これは、すべての主流TIFF開発者が製品でサポートする必要のある要素です。 TIFFのアプリケーションは、ベースラインTIFFを開始点として使用し、特定の "アプリケーション"に使用されるTIFFの "拡張"を定義し、ベースラインTIFFとのその他の違いを指定することによって定義されます。
Though it has been in common usage for many years, TIFF-F has previously never been documented in the form of a standard. An informal TIFF-F document was originally created by a small group of fax experts led by Joe Campbell. The existence of TIFF-F is noted in [TIFF] but it is not defined. This document defines the F application of [TIFF]. For ease of reference, the term TIFF-F will be used throughout this document as a shorthand for "F Profile of TIFF for Facsimile". TIFF-F files are intended for use with the image/tiff MIME media content-type which includes support for the "application" parameter (e.g., application=faxbw).
TIFF-Fは長年にわたって一般的に使用されていますが、これまで規格の形で文書化されたことはありません。非公式のTIFF-Fドキュメントは、ジョーキャンベルが率いる少数のFAXエキスパートグループによって最初に作成されました。 TIFF-Fの存在は[TIFF]に記載されていますが、定義されていません。このドキュメントは、[TIFF]のFアプリケーションを定義します。参照しやすいように、このドキュメントでは、TIFF-Fという用語を「ファクシミリ用のTIFFのFプロファイル」の省略形として使用します。 TIFF-Fファイルは、「アプリケーション」パラメータ（application = faxbwなど）のサポートを含むimage / tiff MIMEメディアコンテンツタイプでの使用を目的としています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [REQ].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [REQ]で説明されているように解釈されます。
Up until TIFF 6.0, TIFF supported various "Classes" which defined the use of TIFF for various applications. Classes were used to support specific applications and in this spirit, TIFF-F has been known historically as "TIFF Class F". Previous informal TIFF-F documents used the "Class F" terminology.
TIFF 6.0までは、TIFFはさまざまなアプリケーションに対するTIFFの使用を定義するさまざまな「クラス」をサポートしていました。クラスは特定のアプリケーションをサポートするために使用され、この精神のもと、TIFF-Fは歴史的に「TIFFクラスF」として知られています。以前の非公式のTIFF-Fドキュメントでは、「クラスF」という用語が使用されていました。
As of TIFF 6.0 [TIFF], the TIFF Class concept has been eliminated in favor of the concept of Baseline TIFF. Therefore, this document updates the definition of TIFF-F as the F profile of TIFF for facsimile, by using Baseline TIFF as defined in [TIFF] as the starting point and then defining the differences from Baseline TIFF which apply for TIFF-F. In almost all cases, the resulting definition of TIFF-F fields and values remains consistent with those used historically in earlier definitions of TIFF Class F. Where some of the values for fields have been updated to provide more precise conformance with the ITU-T [T.4] and [T.30] fax recommendations, these differences are noted.
TIFF 6.0 [TIFF]の時点で、TIFFクラスのコンセプトは廃止され、ベースラインTIFFのコンセプトが採用されました。したがって、このドキュメントでは、[TIFF]で定義されているベースラインTIFFを開始点として使用し、TIFF-Fに適用されるベースラインTIFFとの違いを定義することにより、ファクシミリのTIFFのFプロファイルとしてTIFF-Fの定義を更新します。ほとんどすべての場合において、TIFF-Fフィールドと値の結果の定義は、TIFFクラスFの以前の定義で歴史的に使用されていたものと一貫性を保ちます。フィールドの値の一部は、ITU-Tへのより正確な準拠を提供するために更新されています。 T.4]および[T.30]ファックスの推奨事項、これらの違いが記載されています。
The intent of this specification is to document:
この仕様の目的は、次のことを文書化することです。
1) The fields and values which are applicable for this F profile of TIFF for facsimile. 2) A minimum set of TIFF-F fields and values which should be able to interwork with virtually all historic TIFF-F readers. 3) A broader range of values for the traditional TIFF-F fields that will provide support for the most widely used facsimile compressions, page sizes and resolutions, consistent with the ITU-T [T.4] and [T.30] recommendations.
1）ファクシミリのTIFFのこのFプロファイルに適用できるフィールドと値。 2）事実上すべての歴史的なTIFF-Fリーダーと相互作用できるはずのTIFF-Fフィールドと値の最小セット。 3）ITU-T [T.4]および[T.30]の推奨事項に準拠して、最も広く使用されているファクシミリ圧縮、ページサイズ、および解像度をサポートする、従来のTIFF-Fフィールドのより広い範囲の値。
The structure of the TIFF-F definition will be as follows. A brief review of the structure of TIFF files and practical guidelines for the writing and reading of multi-page TIFF-F files is provided in sections 3.1.3 and 3.1.4.
TIFF-F定義の構造は次のようになります。 TIFFファイルの構造と、マルチページTIFF-Fファイルの書き込みおよび読み取りに関する実用的なガイドラインの簡単なレビューは、セクション3.1.3および3.1.4に記載されています。
A review of TIFF-F fields follows. Section 3.2 reviews the fields from Baseline TIFF that are applicable for black and white (bi-level) images and are also used by TIFF-F.
TIFF-Fフィールドのレビューを以下に示します。セクション3.2では、白黒（バイレベル）画像に適用可能で、TIFF-Fでも使用されるベースラインTIFFのフィールドを確認します。
Section 3.3 reviews the other required TIFF-F fields. Several fields that are specific extensions for TIFF-F are reviewed in section 3.4. There are also fields that may be helpful, but are not required. These recommended fields are listed in the section 3.5. Section 3.6 defines the requirements for the minimum subset of TIFF-F fields and values to maximize interoperability. Several technical topics, including implementation issues and warnings are discussed in subsequent sections. Finally, section 3.9 introduces the TIFF-F Reader and Writer. A table of the required and recommended fields for a TIFF-F Reader is provided, along with details on the permitted set of values.
セクション3.3では、他の必須のTIFF-Fフィールドを確認します。 TIFF-Fに固有の拡張であるいくつかのフィールドについては、セクション3.4で説明します。役立つかもしれないが必須ではないフィールドもあります。これらの推奨フィールドは、セクション3.5にリストされています。セクション3.6では、相互運用性を最大化するためのTIFF-Fフィールドと値の最小サブセットの要件を定義しています。実装の問題や警告など、いくつかの技術的なトピックについては、後続のセクションで説明します。最後に、セクション3.9でTIFF-Fリーダーおよびライターを紹介します。 TIFF-Fリーダーの必須フィールドと推奨フィールドの表を、許可された値のセットの詳細とともに提供します。
The structure of TIFF files is specified within [TIFF]. In this section, a short summary of the TIFF structure is included for the informational purposes. In addition, some practical guidelines for the use of this structure in reading and writing TIFF-F files are addressed in the following section 3.1.4. The structure for writing "minimum subset" TIFF-F files is defined in section 3.6.2.
TIFFファイルの構造は[TIFF]内で指定されます。このセクションでは、情報提供のためにTIFF構造の短い要約が含まれています。さらに、TIFF-Fファイルの読み取りと書き込みでこの構造を使用するためのいくつかの実用的なガイドラインは、次のセクション3.1.4で対処されています。 「最小サブセット」TIFF-Fファイルを書き込むための構造は、セクション3.6.2で定義されています。
A TIFF file begins with an 8-byte image file header that defines the byte order used within a file (see section 3.9.1), includes a magic number sequence that identifies the content as a TIFF file, and then uses an offset to point to the first Image File Directory (IFD). An IFD is a sequence of tagged fields, sorted in ascending order (by tag value), that contains attributes of an image and pointers to the image data. TIFF fields (also called entries) contain a tag, its type (e.g. short, long, rational, etc.), a count (which indicates the number of values/offsets) and a value/offset. However, the actual value for the field will only be present if it fits into 4 bytes; otherwise, an offset will be used to point to the location of the data associated with the field. In turn, this offset may itself be used to point to an array of offsets.
TIFFファイルは、ファイル内で使用されるバイトオーダーを定義する8バイトの画像ファイルヘッダーで始まり（セクション3.9.1を参照）、コンテンツをTIFFファイルとして識別するマジックナンバーシーケンスを含み、オフセットを使用してポイントします。最初のイメージファイルディレクトリ（IFD）。 IFDは、タグ属性で昇順にソートされた一連のタグ付きフィールドで、画像の属性と画像データへのポインターが含まれます。 TIFFフィールド（エントリとも呼ばれます）には、タグ、そのタイプ（短い、長い、有理など）、カウント（値/オフセットの数を示す）、および値/オフセットが含まれます。ただし、フィールドの実際の値は、4バイトに収まる場合にのみ存在します。それ以外の場合、オフセットは、フィールドに関連付けられたデータの場所を指すために使用されます。次に、このオフセット自体を使用して、オフセットの配列を指すことができます。
For the case of facsimile data, many documents consist of a series of multiple pages. Within TIFF, these may be represented using more than one IFD within the TIFF file. Each IFD defines a subfile whose type is given in the NewSubfileType field. For the case of facsimile data that is placed in a TIFF-F file, each facsimile page in a multi-page document has its own IFD. For bi- level facsimile files, multiple IFDs are organized as a linked list, with the last entry in each IFD pointing to the next IFD (the pointer in the last IFD is 0). (There is also another technique for organizing multiple IFDs as a tree, that uses the SubIFDs field, but this technique is not applicable for TIFF-F images.) Within each IFD, the location of the related image data is defined by using fields that are associated with strips. These fields identify the size of strips (in rows), the number of bytes per strip after compression and a strip offset, which is used to point to the actual location of the image strip.
ファクシミリデータの場合、多くのドキュメントは一連の複数のページで構成されます。 TIFF内では、これらはTIFFファイル内の複数のIFDを使用して表すことができます。各IFDは、NewSubfileTypeフィールドでタイプが指定されるサブファイルを定義します。 TIFF-Fファイルに配置されるファクシミリデータの場合、複数ページのドキュメントの各ファクシミリページには独自のIFDがあります。 2層ファクシミリファイルの場合、複数のIFDがリンクリストとして編成され、各IFDの最後のエントリは次のIFDを指します（最後のIFDのポインターは0です）。 （SubIFDsフィールドを使用して、複数のIFDをツリーとして編成する別の手法もありますが、この手法はTIFF-F画像には適用されません。）各IFD内で、関連する画像データの場所は、ストリップに関連付けられています。これらのフィールドは、ストリップのサイズ（行数）、圧縮後のストリップあたりのバイト数、およびイメージストリップの実際の場所を指すために使用されるストリップオフセットを識別します。
TIFF has a very flexible file structure, but the use of some practical guidelines for implementors when writing multi-page TIFF-F files can produce TIFF structures which are easier for readers to process. This is especially for implementations in environments such as facsimile terminals where a complex file structure is difficult to support.
TIFFは非常に柔軟なファイル構造を持っていますが、マルチページTIFF-Fファイルを書き込むときに実装者向けの実用的なガイドラインを使用すると、読者が処理しやすいTIFF構造を生成できます。これは特に、ファクシミリ端末など、複雑なファイル構造をサポートすることが難しい環境での実装に適しています。
Traditionally, historical TIFF-F has required readers and writers to be able to handle multi-page TIFF-F files. Based on the experience of various TIFF-F implementors, it has been seen that the implementation of TIFF-F can be greatly simplified if certain practical guidelines are followed when writing multi-page TIFF-F files. However, for interchange robustness, TIFF-F readers SHOULD be prepared to read TIFF files whose structure is consistent with [TIFF], which supports a more flexible file structure than is recommended here.
従来、歴史的なTIFF-Fでは、リーダーとライターがマルチページTIFF-Fファイルを処理できる必要がありました。さまざまなTIFF-F実装者の経験に基づいて、マルチページTIFF-Fファイルを書き込むときに特定の実用的なガイドラインに従うと、TIFF-Fの実装を大幅に簡略化できることがわかっています。ただし、インターチェンジの堅牢性のために、TIFF-Fリーダーは、構造が[TIFF]と一致するTIFFファイルを読み取る準備をする必要があります。これは、ここで推奨されるよりも柔軟なファイル構造をサポートします。
The structure for a multi-page TIFF-F file will include one IFD per page of the document. Therefore, each IFD will define the attributes for a single page. For simplicity, the writer of TIFF- F files SHOULD present IFDs in the same order as the actual sequence of pages. (The pages are numbered within TIFF-F beginning with page 0 as the first page and then ascending (i.e. 0, 1, 2,...). However, as noted in section 3.1.3, any field values over 4 bytes will be stored separately from the IFD. TIFF-F readers SHOULD expect IFDs to be presented in page order, but be able to handle exceptions.
マルチページTIFF-Fファイルの構造には、ドキュメントのページごとに1つのIFDが含まれます。したがって、各IFDは単一ページの属性を定義します。簡単にするため、TIFF-Fファイルの作成者は、実際のページのシーケンスと同じ順序でIFDを提示する必要があります（SHOULD）。 （ページは、TIFF-F内で、最初のページとしてページ0から始まり、次に昇順で番号が付けられます（つまり、0、1、2、...）。ただし、セクション3.1.3で説明したように、4バイトを超えるフィールド値はTIFF-Fリーダーは、IFDがページ順に表示されることを期待する必要がありますが、例外を処理できます。
Per [TIFF], the exact placement of image data is not specified. However, the strip offsets for each strip of image are defined from within each IFD. Where possible, a second simplifying assumption for the writing of TIFF-F files is to specify that the image data for each page of a multi-page document SHOULD be contained within a single strip (i.e. one image strip per fax page). The use of a single image strip per page is very useful for implementations such as store and forward messaging, where the file is usually prepared in advance of the transmission, but other assumptions may apply for the size of the image strip for implementations which require the use of "streaming" techniques (see section 3.7.6). In the event a different image strip size assumption has been used (e.g. constant size for image strips which may be less than the page size), this will immediately be evident from the values/offsets of the fields that are related to strips. From the TIFF-F reader standpoint, one image strip per page permits the image data to be found through reference via a single offset, resulting in a much simplified image structure and faster processing.
[TIFF]によると、画像データの正確な配置は指定されていません。ただし、画像の各ストリップのストリップオフセットは、各IFD内から定義されます。可能な場合、TIFF-Fファイルの書き込みに関する2つ目の簡略化の前提は、複数ページのドキュメントの各ページの画像データが単一のストリップ内に含まれるように指定することです（つまり、FAXページごとに1つの画像ストリップ）。ページごとに1つのイメージストリップを使用することは、ファイルが通常転送の前に準備されるストアアンドフォワードメッセージングなどの実装に非常に役立ちますが、他の仮定が必要な実装のイメージストリップのサイズに適用される場合があります。 「ストリーミング」技術の使用（セクション3.7.6を参照）。異なる画像ストリップサイズの仮定が使用された場合（たとえば、ページサイズよりも小さい可能性がある画像ストリップの一定サイズ）、これは、ストリップに関連するフィールドの値/オフセットからすぐに明らかになります。 TIFF-Fリーダーの観点からは、ページごとに1つのイメージストリップを使用することで、1つのオフセットを介した参照を通じてイメージデータを見つけることができるため、イメージ構造が大幅に簡素化され、処理が高速になります。
A third simplifying assumption is that each IFD SHOULD be placed in the TIFF-F file structure at a point which precedes the image which the IFD describes. If any long field values are present (see section 3.1.3) then these SHOULD be placed after their referencing IFD and before the image data they describe.
3つ目の単純化の前提は、各IFDは、IFDが記述するイメージの前のポイントでTIFF-Fファイル構造に配置する必要があることです。長いフィールド値が存在する場合（セクション3.1.3を参照）、これらは、参照するIFDの後、それらが記述する画像データの前に配置する必要があります（SHOULD）。
A fourth simplifying assumption for TIFF-F writers and readers is to place the actual image data in a physical order within the TIFF file structure which is consistent with the logical page order. In practice, TIFF-F readers will need to use the strip offsets to find the exact physical location of the image data, whether or not it is presented in logical page order.
TIFF-Fのライターとリーダーの4番目の単純化する前提は、実際の画像データを論理的なページ順序と一致するTIFFファイル構造内の物理的な順序で配置することです。実際には、TIFF-Fリーダーは、ストリップオフセットを使用して、論理的なページ順序で提示されているかどうかに関係なく、画像データの正確な物理的な場所を見つける必要があります。
TIFF-F writers MAY make a fifth simplifying assumption, in which the IFD, the value data and the image data for which the IFD has offsets precede the next image IFD. These elements MUST precede the next image IFD in the minimum set TIFF-F files (see section 3.6.2). However, this principle has been relaxed in the case of TIFF-F to reflect past practices.
TIFF-Fライターは、IFD、値のデータ、およびIFDがオフセットを持っている画像データが次の画像IFDに先行するという5番目の簡略化仮定を行うことができます（MAY）。これらの要素は、最小セットのTIFF-Fファイルで次の画像IFDに先行する必要があります（セクション3.6.2を参照）。ただし、TIFF-Fの場合、この原則は緩和され、過去の慣行が反映されています。
So, a TIFF-F file which is structured using the guidelines of this section will essentially be composed of a linked list of IFDs, presented in ascending page order, which in turn each point to a single page of image data (one strip per page), where the pages of image data are also placed in a logical page order within the TIFF-F file structure. (The pages of image data may themselves be stored in a contiguous manner, at the option of the implementor).
したがって、このセクションのガイドラインを使用して構造化されたTIFF-Fファイルは、基本的に昇順のページ順で表示されるIFDのリンクリストで構成され、各ページが画像データの単一のページを指します（ページごとに1つのストリップ）。 ）、画像データのページもTIFF-Fファイル構造内の論理ページ順に配置されます。 （画像データのページ自体は、実装者のオプションで、連続した方法で保存できます）。
Baseline TIFF per [TIFF] requires that the following fields be present for all BiLevel Images: ImageWidth, ImageLength, Compression, PhotometricInterpretation, StripOffsets, RowsPerStrip, StripByteCounts, XResolution, YResolution and ResolutionUnit. TIFF-F uses all of these fields, but in some cases specifies a different range of acceptable values than Baseline TIFF. Per [TIFF], if fields are omitted, the Baseline TIFF default value(if specified) will apply.
[TIFF]ごとのベースラインTIFFでは、すべてのBiLevel画像に次のフィールドが存在する必要があります：ImageWidth、ImageLength、Compression、PhotometricInterpretation、StripOffsets、RowsPerStrip、StripByteCounts、XResolution、YResolution、およびResolutionUnit。 TIFF-Fはこれらのフィールドをすべて使用しますが、ベースラインTIFFとは異なる許容範囲の値を指定する場合もあります。 [TIFF]ごとに、フィールドが省略されている場合、ベースラインTIFFのデフォルト値（指定されている場合）が適用されます。
In the field definitions which follow in this section and subsequent sections, the fields will be presented in the following form:
このセクション以降のフィールド定義では、フィールドは次の形式で表示されます。
Fieldname (tag-number) = values (if applicable). TYPE
フィールド名（タグ番号）=値（該当する場合）。タイプ
A brief summary of the Baseline TIFF fields and their use in TIFF-F follows:
ベースラインTIFFフィールドの概要とTIFF-Fでのそれらの使用法は次のとおりです。
ImageWidth(256) = 1728, 2048, 2432, 2592, 3072, 3648, 3456, 4096, 4864. SHORT or LONG. These are the fixed page widths in pixels. The permissible values are dependent upon X and Y resolutions as shown in sections 2 and 3 of [T.4] and reproduced here for convenience:
ImageWidth（256）= 1728、2048、2432、2592、3072、3648、3456、4096、4864。SHORTまたはLONG。これらは、ピクセル単位の固定ページ幅です。 [T.4]のセクション2と3に示されているように、許容値はX解像度とY解像度に依存し、便宜上ここに再現されています。
XResolution x Yresolution | ImageWidth
--------------------------------------------|------------------
204x98, 204x196, 204x391, 200x100, 200x200 | 1728, 2048, 2432
300x300 | 2592, 3072, 3648
408x391, 400x400 | 3456, 4096, 4864
--------------------------------------------|------------------
Historical TIFF-F did not include support for the following widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096 and 4864. Historical TIFF-F documents also included the following values related to A5 and A6 widths: 816 and 1216. Per the most recent version of [T.4], A5 and A6 documents are no longer supported in Group 3 facsimile, so the related width values are now obsolete. See section 3.8.2 for more information on inch/metric equivalencies and other implementation details.
過去のTIFF-Fには、高解像度に関連する次の幅のサポートは含まれていません：2592、3072、3648、3456、4096、および4864。過去のTIFF-Fドキュメントには、A5およびA6の幅に関連する次の値も含まれています：816および1216。 [T.4]の最新バージョンでは、A5およびA6ドキュメントはGroup 3ファクシミリでサポートされなくなったため、関連する幅の値は廃止されました。インチ/メトリックの同等性およびその他の実装の詳細については、セクション3.8.2を参照してください。
ImageLength (257). SHORT or LONG. LONG recommended. The total number of scan lines in the image.
ImageLength（257）。 SHORTまたはLONG。 LONGをお勧めします。画像内のスキャンラインの総数。
Compression (259) = 3,4. SHORT. This is a required TIFF-F field. The permitted values for TIFF-F purposes are 3 and 4 as shown. The default value per Baseline TIFF is 1 (Uncompressed), but this value is invalid for facsimile images. Baseline TIFF also permits use of value 2 (Modified Huffman encoding), but the data is presented in a form which does not contain EOLs. Instead, TIFF-F specifies the value 3 for encoding one-dimensional T.4 Modified Huffman or 2-dimensional Modified READ data. The detailed settings which apply for T.4 encoded data are specified using the T4Options field. TIFF-F also permits use of the value 4 for the compression field, which indicates that the data is coded using a [T.6] compression method (i.e the Modified Modified READ two-dimensional method). The detailed settings which apply for T.6 encoded data are specified using the T6Options field.
圧縮（259）= 3,4。ショート。これは必須のTIFF-Fフィールドです。 TIFF-Fの目的で許可される値は、3と4です。ベースラインTIFFごとのデフォルト値は1（非圧縮）ですが、この値はファクシミリ画像では無効です。ベースラインTIFFでは、値2（Modified Huffmanエンコーディング）の使用も許可されますが、データはEOLを含まない形式で表示されます。代わりに、TIFF-Fは、1次元のT.4 Modified Huffmanまたは2次元のModified READデータをエンコードするために値3を指定します。 T.4エンコードデータに適用される詳細設定は、T4Optionsフィールドを使用して指定されます。 TIFF-Fでは、圧縮フィールドに値4を使用することもできます。これは、データが[T.6]圧縮方式（つまり、Modified Modified READ 2次元方式）を使用してコード化されていることを示します。 T.6エンコードされたデータに適用される詳細設定は、T6Optionsフィールドを使用して指定されます。
Please refer to the definitions of the T4Options and T6Options fields in section 3.3, and section 3.8 for more information on the encoding of images and conventions used within TIFF-F.
TIFF-F内で使用される画像のエンコーディングと規則の詳細については、セクション3.3のT4OptionsフィールドとT6Optionsフィールドの定義、およびセクション3.8を参照してください。
PhotometricInterpretation (260) = 0,1. SHORT. This field allows notation of an inverted ("negative") image: 0 = normal 1 = inverted
PhotometricInterpretation（260）= 0、1。ショート。このフィールドでは、反転した（「負の」）画像を表記できます。0=通常1 =反転
StripOffsets (273). 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.
StripOffsets（273）。 SHORTまたはLONG。各ストリップについて、そのストリップのオフセット。オフセットは、ファイルの先頭から測定されます。ページが1つの大きなストリップとして表現される場合、ページごとにそのようなエントリが1つあります。
RowsPerStrip (278). 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 field.
RowsPerStrip（278）。 SHORTまたはLONG。 LONGをお勧めします。ストリップあたりの走査線の数。ページが1つの大きなストリップとして表現される場合、これはImageLengthフィールドと同じです。
StripByteCounts (279). LONG or SHORT. LONG 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. Note that the choice of LONG or SHORT depends upon the size of the strip.
StripByteCounts（279）。 LONGまたはSHORT。 LONGをお勧めします。各ストリップの、そのストリップのバイト数。ページが1つの大きなストリップとして表現される場合、これは圧縮後のページ内の合計バイト数です。 LONGまたはSHORTの選択は、ストリップのサイズに依存することに注意してください。
ResolutionUnit (296) = 2,3. SHORT. The units of measure for resolution: 2 = Inch 3 = Centimeter
ResolutionUnit（296）= 2,3。ショート。解像度の測定単位：2 =インチ3 =センチメートル
TIFF-F has traditionally used inch based measures.
TIFF-Fは伝統的にインチベースのメジャーを使用しています。
XResolution (282) = 204, 200, 300, 400, 408 (inches). RATIONAL. The horizontal resolution of the TIFF-F image expressed in pixels per resolution unit. The values of 200 and 408 have been added to the historical TIFF-F values, for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 77 (cm). See section 3.8.2 for more information on inch/metric equivalencies and other implementation details.
XResolution（282）= 204、200、300、400、408（インチ）。合理的な。解像度単位あたりのピクセルで表されるTIFF-F画像の水平解像度。 [T.30]との一貫性を保つため、過去のTIFF-F値に200と408の値が追加されました。一部の既存のTIFF-F実装でも77（cm）の値をサポートしている場合があります。インチ/メトリックの同等性およびその他の実装の詳細については、セクション3.8.2を参照してください。
YResolution (283) = 98, 196, 100, 200, 300, 391, 400 (inches). RATIONAL. The vertical resolution of the TIFF-F image expressed in pixels per resolution unit. The values of 100, 200, and 391 have been added to the historical TIFF-F values, for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 77, 38.5 (cm). See section 3.8.2 for more information on inch/metric equivalencies and other implementation details.
YResolution（283）= 98、196、100、200、300、391、400（インチ）。合理的な。解像度単位あたりのピクセル数で表されるTIFF-F画像の垂直解像度。 [T.30]との一貫性を保つため、100、200、および391の値がTIFF-Fの履歴値に追加されました。既存のTIFF-F実装の一部では、77、38.5（cm）の値もサポートされている場合があります。インチ/メトリックの同等性およびその他の実装の詳細については、セクション3.8.2を参照してください。
In addition to the Baseline TIFF fields, there are additional required fields for TIFF-F. A review of the additional required fields for TIFF-F follows:
ベースラインTIFFフィールドに加えて、TIFF-Fには追加の必須フィールドがあります。 TIFF-Fの追加必須フィールドのレビューは次のとおりです。
BitsPerSample (258) = 1. SHORT. Since TIFF-F is only used for black-and-white facsimile images, the value is 1 (the default) for all files.
BitsPerSample（258）= 1. SHORT。 TIFF-Fは白黒のファクシミリ画像にのみ使用されるため、すべてのファイルの値は1（デフォルト）です。
FillOrder (266) = 1, 2. SHORT. TIFF 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.
FillOrder（266）= 1、2。SHORT。 TIFF Fリーダーは両方のビットオーダーでデータを読み取ることができる必要がありますが、大部分のファクシミリ製品は、電話回線に表示されるとおりにデータをLSBファーストで格納します。 1 =最上位ビットが最初。 2 =最下位ビットが最初。
NewSubFileType (254)= (Bit 1 = 1). LONG.
This field is made up of 32 flag bits. Unused bits are
expected to be 0 and bit 0 is the low order bit. Bit 0 is set
to 0 for TIFF-F. Bit 1 is always set to 1 for TIFF-F,
indicating a single page of a multi-page image. The same bit
settings are used when TIFF-F is used for a one page fax image.
See sections 3.1.1 and 3.1.2 for more details on the structure
of multi-page TIFF-F image files.
PageNumber (297). SHORT/SHORT. This field specifies the page numbers in the fax document. The field comprises two SHORT values: the first value is the page number, the second is the total number of pages. Single-page documents therefore use 0000/0001 hex. If the second value is 0, the total number of pages in the document is not available.
ページ番号（297）。 SHORT / SHORT。このフィールドは、ファックスドキュメントのページ番号を指定します。このフィールドは2つのSHORT値で構成されています。最初の値はページ番号、2番目の値はページの総数です。したがって、単一ページのドキュメントでは、0000/0001 16進数を使用します。 2番目の値が0の場合、ドキュメントの合計ページ数は利用できません。
SamplesPerPixel (277) = 1. SHORT. The value of 1 denotes a bi-level, grayscale, or palette color image.
SamplesPerPixel（277）= 1. SHORT。値1は、バイレベル、グレースケール、またはパレットのカラーイメージを示します。
There is also a requirement to include either the T4Options or the T6Options field in a TIFF-F IFD, depending upon the setting of the Compression field. These fields are defined in the next section on TIFF extensions.
また、圧縮フィールドの設定に応じて、TIFF-F IFDにT4OptionsまたはT6Optionsフィールドのいずれかを含める必要があります。これらのフィールドは、TIFF拡張の次のセクションで定義されています。
These are fields which are extensions beyond the required TIFF-F fields. The following fields have been defined as extensions in [TIFF].
これらは、必須のTIFF-Fフィールドを超える拡張であるフィールドです。以下のフィールドは、[TIFF]で拡張として定義されています。
T4Options (292) (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1). LONG. This field is required if the value for the compression field has been set to 3. The values are set as shown below for TIFF-F. For TIFF-F, uncompressed data is not allowed and EOLs MAY be byte aligned (see section 3.8.3). bit 0 = 0 for 1-Dimensional, 1 for 2-Dimensional (MR) bit 1 = must be 0 (uncompressed data not allowed) bit 2 = 0 for non-byte-aligned EOLs or 1 for byte-aligned EOLs
T4Options（292）（ビット0 = 0または1、ビット1 = 0、ビット2 = 0または1）。長いです。圧縮フィールドの値が3に設定されている場合、このフィールドは必須です。TIFF-Fの場合、値は以下のように設定されます。 TIFF-Fの場合、非圧縮データは許可されず、EOLはバイトアラインされる場合があります（セクション3.8.3を参照）。ビット0 = 1次元の場合は0、2次元（MR）の場合は1ビット1 = 0でなければならない（非圧縮データは許可されません）ビット2 =非バイト境界のEOLの場合は0、バイト境界のEOLの場合は1
This field is made up of a set of 32 flag bits. Unused bits must be set to 0. Bit 0 is the low order bit. Please note that T4Options was known as G3Options in earlier versions of TIFF and TIFF-F. The data in a TIFF-F image encoded using one of the T.4 methods is not terminated with an RTC (see section 3.8.5).
このフィールドは、32個のフラグビットのセットで構成されています。未使用ビットは0に設定する必要があります。ビット0は下位ビットです。 T4Optionsは、TIFFおよびTIFF-Fの以前のバージョンではG3Optionsと呼ばれていたことに注意してください。 T.4メソッドのいずれかを使用してエンコードされたTIFF-F画像のデータは、RTCで終了しません（セクション3.8.5を参照）。
T6Options (293) = (Bit 0 = 0, Bit 1 = 0) LONG.
This field is required for TIFF-F if value of the compression
field has been set to 4. The value for this field is made up of
a set of 32 flag bits. Setting bit 0 to 0 indicates that the
data is compressed using the Modified Modified READ (MMR) two-
dimensional compression method. 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 3.8.6). Uncompressed data is not
applicable for bi-level facsimile images, so that bit 1 must be
set to 0. Unused bits must be set to 0. Bit 0 is the low-order
bit. The default value is 0 (all bits 0).
bit 0 = 0 for 2-Dimensional
bit 1 = must be 0 (uncompressed data not allowed)
In earlier versions of TIFF, this field was named Group4Options. The significance has not changed and the present definition is compatible.
TIFFの以前のバージョンでは、このフィールドはGroup4Optionsという名前でした。重要性は変更されておらず、現在の定義は互換性があります。
In addition, three new fields, defined as TIFF-F extensions, describe page quality. The information contained in these fields is usually obtained from receiving facsimile hardware (if applicable). These fields are optional. They SHOULD NOT be used in writing TIFF-F files for facsimile image data that is error corrected or otherwise guaranteed not to have coding errors.
さらに、TIFF-F拡張として定義された3つの新しいフィールドは、ページ品質を記述します。これらのフィールドに含まれる情報は、通常、ファクシミリハードウェア（該当する場合）の受信から取得されます。これらのフィールドはオプションです。それらは、エラーが修正されているか、コーディングエラーがないことが保証されているファクシミリ画像データのTIFF-Fファイルの書き込みには使用しないでください。
Some implementations 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.
一部の実装では、データのエラー内容を正確に理解する必要があります。たとえば、CADプログラムでは、高精度のドキュメントにインポートする前に、ファイルのエラーレベルが低いことを確認したい場合があります。グループ3のファクシミリデバイスは、必ずしもイメージデータのエラー訂正を実行するわけではないため、受信したページの品質は、デコードされたスキャンラインのピクセル数から推測する必要があります。 「良好な」スキャンラインは、デコード時に正しい数のピクセルを含むラインとして定義されます。逆に、「不良」スキャンラインは、デコード時に不正な数のピクセルを含むラインとして定義されます。
BadFaxLines (326). SHORT or LONG This field reports the number of scan lines with an incorrect number of pixels encountered by the facsimile during reception (but not necessarily in the file).
BadFaxLines（326）。 SHORTまたはLONGこのフィールドは、受信中にファクシミリで検出されたピクセル数が正しくないスキャンラインの数をレポートします（ただし、必ずしもファイル内にある必要はありません）。
Note: PercentBad = (BadFaxLines/ImageLength) * 100
CleanFaxData (327). SHORT N = 0 = Data contains no lines with incorrect pixel counts or regenerated lines (i.e., computer generated) 1 = Lines with an incorrect pixel count were regenerated by receiving device
CleanFaxData（327）。 SHORT N = 0 =ピクセル数が正しくないラインまたは再生成されたライン（つまり、コンピューター生成）がデータに含まれていない1 =ピクセル数が正しくないラインが受信デバイスによって再生成された
2 = Lines with an incorrect pixel count are in the data and were not regenerated by receiving device (i.e. data contains bad scan lines)
2 =ピクセル数が正しくないラインがデータ内にあり、受信デバイスによって再生成されなかった（つまり、データに不良スキャンラインが含まれている）
Many facsimile devices do not actually output bad lines. Instead, the previous good line is repeated in place of a bad line. Although this substitution, known as line regeneration, results in a visual improvement to the image, the data is nevertheless corrupted. The CleanFaxData field describes the error content of the data. That is, when the BadFaxLines and ImageLength fields indicate that the facsimile device encountered lines with an incorrect number of pixels during reception, the CleanFaxData field indicates whether these bad lines are actually still in the data or if the receiving facsimile device replaced them with regenerated lines.
多くのファクシミリデバイスは実際には不良回線を出力しません。その代わり、悪い行の代わりに前の良い行が繰り返されます。ラインの再生と呼ばれるこの置換により、画像が視覚的に改善されますが、データは破損します。 CleanFaxDataフィールドは、データのエラー内容を記述します。つまり、BadFaxLinesおよびImageLengthフィールドが、ファクシミリデバイスが受信中に不正なピクセル数のラインに遭遇したことを示す場合、CleanFaxDataフィールドは、これらの不良ラインが実際にまだデータ内にあるか、または受信ファクシミリデバイスが再生成されたラインに置き換えたかを示します。
ConsecutiveBadFaxLines (328). LONG or SHORT. This field 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).
ConsecutiveBadFaxLines（328）。 LONGまたはSHORT。このフィールドは、ファクシミリデバイスが受信中に検出したピクセル数が正しくない（ただし、必ずしもファイル内にある必要はない）連続する行の最大数を報告します。
The BadFaxLines and ImageLength data indicate only the quantity of such lines. The ConsecutiveBadFaxLines field is an indicator of their distribution and may therefore be a better general indicator of perceived image quality.
BadFaxLinesおよびImageLengthデータは、そのような線の量のみを示します。 ConsecutiveBadFaxLinesフィールドはそれらの分布のインジケーターであり、したがって、知覚される画質のより一般的なインジケーターになる可能性があります。
hese are fields that MAY be used in encoding TIFF-F files, but are ptional in nature and may be ignored by many TIFF readers. These ields are called recommended consistent with historical TIFF-F ractice.
これらはTIFF-Fファイルのエンコードに使用される可能性があるフィールドですが、実際には部分的なものであり、多くのTIFFリーダーによって無視される可能性があります。これらのフィールドは、歴史的なTIFF-Fの慣習に従って一貫して推奨と呼ばれています。
BadFaxLines (326) [defined in section 3.4]
BadFaxLines（326）[セクション3.4で定義]
CleanFaxData (327) [defined in section 3.4]
CleanFaxData（327）[セクション3.4で定義]
ConsecutiveBadFaxLines (328) [defined in section 3.4]
ConsecutiveBadFaxLines（328）[セクション3.4で定義]
DateTime (306). 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.
DateTime（306）。 ASCII。 YYYY：MM：DD HH：MM：SS形式の日付と時刻（24時間形式）。 NULバイトを含む文字列の長さは20バイトです。 DDとHHの間のスペース。
DocumentName (269). ASCII. This is the name of the document from which the document was scanned.
DocumentName（269）。 ASCII。これは、ドキュメントのスキャン元のドキュメントの名前です。
ImageDescription (270). ASCII. This is an ASCII string describing the contents of the image.
ImageDescription（270）。 ASCII。これは画像の内容を説明するASCII文字列です。
Orientation (274). SHORT. This field is designated as "Recommended" for consistency with historical TIFF-F, but is also a Baseline TIFF field with a default value of 1 per [TIFF]. The default value of 1 applies if the field is omitted, but for clarity, TIFF-F writers SHOULD include this field. This field 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] for an explanation of other values.
オリエンテーション（274）。ショート。このフィールドは、過去のTIFF-Fとの一貫性を保つために「推奨」として指定されていますが、[TIFF]ごとに1のデフォルト値を持つベースラインTIFFフィールドでもあります。フィールドが省略された場合、デフォルト値の1が適用されますが、明確にするために、TIFF-Fライターはこのフィールドを含める必要があります（SHOULD）。このフィールドは、画像に関係なく、常に同じ方向を表示したい表示機能に役立ちます。デフォルト値の1は、「0番目の行は画像の上部、0番目の列は画像の左」です。 180度回転は3です。他の値の説明については、[TIFF]を参照してください。
Software (305). ASCII. The optional name and release number of the software package that created the image.
ソフトウェア（305）。 ASCII。イメージを作成したソフトウェアパッケージのオプションの名前とリリース番号。
This section defines the requirements for a minimum subset of TIFF-F fields and values that all TIFF-F readers SHOULD support to maximize interoperability with current and historical TIFF-F implementations. The TIFF-F structure for writing minimum subset files is also defined.
このセクションでは、現在および過去のTIFF-F実装との相互運用性を最大化するためにすべてのTIFF-Fリーダーがサポートする必要があるTIFF-Fフィールドと値の最小サブセットの要件を定義します。最小サブセットファイルを書き込むためのTIFF-F構造も定義されています。
A summary of the minimum subset TIFF-F fields and values is provided in the following table. The required fields for the minimum subset are shown under the column labeled "Field". The values for these fields in the minimum subset are shown under the column labeled "Minimum".
最小サブセットのTIFF-Fフィールドと値の概要を次の表に示します。最小サブセットの必須フィールドは、「フィールド」というラベルの付いた列の下に表示されます。最小サブセットのこれらのフィールドの値は、「最小」というラベルの付いた列の下に表示されます。
Field | Minimum | Comment
------------------|--------------|-------------------------------
BitsPerSample | 1 |one bit per sample
Compression | 3 |3 for T.4 (MH)
FillOrder | 2 |LSB first
ImageWidth | 1728 |
ImageLength | |required
NewSubFileType | Bit 1 = 1 |single page of multipage file
PageNumber | X/X |pg/tot, 0 base, tot in 1st IFD
PhotometricInterp | 0 |0 is white
ResolutionUnit | 2 |inches (default)
RowsPerStrip |=ImageLength |
SamplesPerPixel | 1 |one sample per pixel
StripByteCounts | |required
StripOffsets | |required
T4Options | Bit 0 = 0 |MH
| Bit 1 = 0 |
| Bit 2 = 0,1 |Non-Byte-aligned,
| | Byte-Aligned EOLs
XResolution | 204 |Units is per inch
YResolution | 196,98 |Units is per inch
------------------|--------------|------------------------------
For implementations which need to write minimum subset TIFF-F files, the file structure shown in Figure 3.1 MUST be used:
最小限のサブセットTIFF-Fファイルを書き込む必要がある実装では、図3.1に示すファイル構造を使用する必要があります。
+-----------------------+
| Header |------------+
+-----------------------+ | First IFD
| IFD (page 0) | <----------+ Offset
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 0) |<-+ Offset |
+-----------------------+ | Next IFD
| IFD (page 1) | <----------+ Offset
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 1) |<-+ Offset |
+-----------------------+ | Next IFD
| IFD (page 2) | <----------+ Offset
+-----------------------+
| : |
| : |
Figure 3.1 TIFF-F Minimum Subset File Structure
図3.1 TIFF-Fの最小サブセットファイル構造
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.
図3.1に示すように、各ページのIFDは、そのページの関連する画像データの前にあります。存在する場合、IFDとそのページの画像データの間に長いフィールド値が表示されます。複数ページのドキュメントの場合、すべてのページが定義されるまで、各IFD /イメージペアの直後に、ファイル構造内の論理ページ順に次のIFD /イメージペアが続きます。
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.
TIFFヘッダーの形式は、[TIFF]で定義されています。 TIFF-F最小サブセットファイルを書き込む場合、ヘッダーのバイトオーダーの値はII（0x4949、TIFFファイルのバイトがLSBファースト（リトルエンディアン）オーダーであることを示す）である必要があります（SHOULD）。
This results in a TIFF header whose content is as shown in Figure 3.2.
これにより、図3.2に示す内容のTIFFヘッダーが生成されます。
| 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.2：最小サブセットTIFF-Fファイルの画像ファイルヘッダー
Those new to TIFF may not be familiar with the concept of "strips" embodied in the three fields RowsPerStrip, StripByteCount, StripOffsets.
TIFFの初心者は、RowsPerStrip、StripByteCount、StripOffsetsの3つのフィールドで具体化される「ストリップ」の概念に慣れていない可能性があります。
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.
一般に、TIFFファイルを読み書きするサードパーティの実装では、イメージが「バンド」とも呼ばれる「ストリップ」に分割されることを想定しています。各ストリップには、画像の数行が含まれています。ストリップを使用することで、TIFFリーダーは画像全体をメモリにロードする必要がなくなり、必要に応じて画像の小さなランダムな部分をフェッチして解凍できるようになります。
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.
ストリップの寸法は、RowsPerStripおよびStripByteCountフィールドで記述されます。各ストリップのTIFFファイル内の場所は、StripOffsetsフィールドに含まれています。
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.
TIFF-Fストリップのサイズはアプリケーションによって異なります。マルチページTIFF-F画像の推奨アプローチは、各ページを単一のストリップとして表すことです。
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).
[TIFF]ごとのベースラインTIFFのデフォルトのビット順序は、FillOrder = 1で示され、ビットは格納される前に反転されません。ただし、TIFF-Fは通常、FillOrder = 2の設定を使用します。この場合、バイト内のビット順序は格納前に逆になります（つまり、ビットは最下位ビットが最初に格納されます）。
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.
ファクシミリデータは、CCITT勧告T.4の説明に関連して、ビット逆順で電話回線に表示されます。したがって、ファクシミリの実装の大多数は、この自然な順序でストレージを選択します。それでも、TIFF-Fリーダーは両方のビットオーダーでデータを読み取ることができる必要があります。
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.
多くの既存の実装はすでにTIFF-Fのようなファイルを読み取りますが、マルチページフィールドをサポートしていません。マルチページ形式はFAXアプリケーションソフトウェアでのファイル管理を大幅に簡略化するため、TIFF-Fはマルチページドキュメント（NewSubfileType = 2）を標準ケースとして指定します。
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.
グループ3のファクシミリでは、1994年に標準化され、一般的に使用されている3つの圧縮方法があります。 ITU-T T.4勧告では、Modified Huffman（MH）と呼ばれる1次元の圧縮方法とModified READ（MR）と呼ばれる2次元の方法を定義しています（READはRelative Element Address Designateの略です）。 1984年に、T.6勧告で、Modified Modified READ（MMR）と呼ばれるやや効率的な圧縮方法が定義されました。元々はグループ4ファクシミリで使用するために定義されていたため、この圧縮方法は一般にグループ4圧縮と呼ばれていました。 1991年に、MMR方式はグループ3ファクシミリでの使用が承認され、それ以来広く利用されています。
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.
TIFF-Fでは、3つの異なる圧縮方法を使用できます。最も一般的な方法では、1次元圧縮法（Modified Huffman）が使用されます。これは、圧縮フィールドの値を3に設定し、T4Optionsフィールドのビット0を0に設定することによって指定されます。または、2次元の変更されたREADメソッド（これまでのTIFF-F実装ではあまり使用されていません）を選択できます。ビット0を値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 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.
オプションで、実装要件に応じて、T.6からのより効率的な2次元圧縮方法（つまり、MMRまたは「グループ4圧縮」）を選択できます。この方法を選択するには、圧縮フィールドの値を4に設定し、T6optionsの最初の2ビット（およびすべての未使用ビット）の値を0に設定します。圧縮の選択を行う際に実装者を支援する詳細情報は、実装警告に関する3.8。
Here are examples for writing the CleanFaxData, BadFaxLines, and ConsecutiveBadFaxLines fields:
CleanFaxData、BadFaxLines、およびConsecutiveBadFaxLinesフィールドを書き込む例を以下に示します。
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.
1. ファクシミリハードウェアはページ品質情報を提供しません。ページ品質フィールドを記述してはなりません。 2.ファクシミリハードウェアはページ品質情報を提供しますが、不良行を報告しません。 BadFaxLines = 0のみを書き込みます。3.ファクシミリハードウェアはページ品質情報を提供し、不良回線を報告します。 BadFaxLinesとConsecutiveBadFaxLinesの両方を記述します。また、ハードウェアの再生成機能がわかっている場合は、CleanFaxData = 1または2と書き込みます。 4.ソース画像のデータストリームは、エラーが修正されているか、コンピューター生成ファイルなどのエラーがないことが保証されています。ページ品質のフィールドを書き込まないでください。
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.
TIFF-Fは、ファイル全体のサイズが事前にわかっているストアアンドフォワードメッセージングなどの実装で、これまでFAX画像ファイルの処理に使用されてきました。 TIFF-Fはストリーミングアプリケーションなどの場合のファイル形式としても使用される可能性がありますが、このドキュメントで提供されているものとは異なる前提が必要になる場合があります（たとえば、画像内のページ全体のサイズと数は事前に不明です）。 。その結果、TIFF-Fのストリーミングアプリケーションの定義は、このドキュメントの範囲を超えています。
Fax implementations that do not wish to support TIFF-F as a native format may elect to support it as import/export medium.
TIFF-Fをネイティブ形式としてサポートしたくないFAX実装は、それをインポート/エクスポートメディアとしてサポートすることを選択できます。
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.
実装では、フィールドと値を操作せずに複数ページのTIFF-Fファイルをエクスポートすることをお勧めします。歴史的に、一部のTIFF-Fライターは、エクスポートのために変更されたNewSubFileTypeとPageNumber（1対1）の値を使用して、個別の単一ページTIFF-Fファイルを作成しようとしました。ただし、このような複数の単一ページファイルを論理的な複数ページのドキュメントにリンクする簡単な方法はないため、この方法はお勧めできません。
Import
インポート
A TIFF-F reader MUST be able to handle a TIFF-F file containing multiple pages.
TIFF-Fリーダーは、複数のページを含むTIFF-Fファイルを処理できる必要があります。
3.8.1 Uncompressed data
3.8.1 非圧縮データ
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.
TIFF-Fには、少なくとも1次元のT.4ハフマン（「圧縮」）データを読み書きする機能が必要です。非圧縮データは許可されていません。つまり、T4OptionsまたはT6Optionsの「非圧縮」ビットを0に設定する必要があります。
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).
Group 3の互換性のために2次元エンコーディングは必要ないため、一部の歴史的なTIFF-Fリーダーはそのようなファイルを読み取ることができませんでした。 TIFF-Fの最小サブセットは1次元（Modified Huffman）ファイルをサポートする必要があるため、この選択により移植性が最大化されます。ただし、より高い効率を求める実装者は、TIFF-Fファイルを書き込むときにT.6 MMR圧縮を使用する必要があります（SHOULD）。一部のTIFF-Fリーダーは、2次元の変更されたREADファイルもサポートします。 TIFF-Fファイルの読み取りに最大限の柔軟性を持たせたい実装者は、これらの3つの圧縮方法（MH、MRおよびMMR）をすべてサポートする必要があります（SHOULD）。
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.
解像度の場合、ほとんどすべてのファクシミリ製品は、標準（98 dpi）の垂直解像度と「細かい」（196 dpi）解像度の両方をサポートしています。したがって、細かい解像度のファイルは現実の世界で非常に移植可能です。
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.
1993年に、ITU-Tは、T.30勧告で、ドット/インチベースのユニットで200 x 200、300 x 300、400 x 400を含む、より高い解像度のサポートを追加しました。同時に、次のインチベースの解像度に相当するメトリックディメンションのサポートが追加されました：391v x 204hおよび391v x 408h。したがって、新しい解像度と同等のインチベースのフルセットがTIFF-Fライターでサポートされています。これは、グループ3ファクシミリデバイスから受信した一部の画像データストリームに表示される可能性があるためです。ただし、多くのファクシミリ端末とTIFF-Fリーダーの古いバージョンは、これらのより高い解像度の使用をサポートしていない可能性があります。
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 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.
[T.4]に従い、実装は次のXResolution値を同等として扱うことが許可されています：<204,200>と<400,408>。同様に、次のYResolutionの値も同等として扱うことができます：<98、100>、<196、200>、および<391、400>。これらの同等性は、インチとメートル法ベースのファクシミリ端末の間の変換を許可するために[T.4]によって許可されました。
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.
同様に、一部のレガシーTIFF-F実装で使用されているため、完全性のためにTIFF-Fリーダーでのメトリックベースの解像度（つまり77 x 38.5 cm）のオプションのサポートが含まれていますが、この使用は推奨されません。ライターによるTIFF-Fファイルの作成。
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.
TIFF-Fの歴史的な慣習では、Modified HuffmanまたはModified READデータのすべてのEOLはバイト境界で整列する必要があります。ただし、ベースラインTIFFはデフォルトで非バイト境界のEOLの使用を許可しているため、TIFF-Fリーダー実装の大部分は両方の規則をサポートしています。したがって、このドキュメントで定義されているTIFF-Fの最小サブセットには、バイト境界と非バイト境界の両方のEOLのサポートが含まれています。
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.
EOLは、バイト境界でEOLが終了するようにEOLコードの前に必要に応じてフィルビットが追加され、ゼロニブルが先行する1バイトのEOLシーケンス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).
修正されたハフマンエンコーディングは、バイトではなくビットをエンコードします。これは、行末トークンがバイトの途中で終了する可能性があることを意味します。バイトアライメントでは、EOLに続くデータの最初のビットがバイト境界で始まるように、追加のゼロビット（Fill）が追加されます。実際、バイトアライメントにより、アプリケーションソフトウェアは、走査線を解析してライン指向の画像操作（TIFFファイルの書き込みなど）を行う際に、バイトごとにビットをシフトする負担を軽減します。
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.
Modified READエンコーディングの場合、各ラインはEOLと1ビットのタグビットで終了します。 [T.4]によると、タグビットの値は、次の行に2次元データが含まれている場合は0、次の行が参照行の場合は1です。バイトアラインメントを維持するために、EOL /タグビットシーケンスの前にフィルビットが追加されるので、MRタグビットに続くデータの最初のビットはバイト境界で始まります。
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.
[T.4]の図1 / T.4に示されているように、Modified Huffmanでエンコードされたファクシミリ文書は、EOLで始まります（TIFF-Fではこれをバイト境界で整列させることができます）。画像の最後の行はEOLで終了していません。同様に、Modified READ 2次元エンコーディングでエンコードされた画像は、EOLで始まり、その後にタグビットが続きます。
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.
EOLを除いて、TIFF-Fファイルにはこれまで画像データしか含まれていませんでした。これは、[TIFF]のルールに厳密に準拠し、過去のTIFF-Fとの互換性を維持する必要がある実装に、TIFF-Fファイルの書き込み時にReturn To Controlシーケンス（RTC）（6つの連続したEOLで構成される）を含めないでください。ただし、[T.4]画像データの「透過性」をサポートする必要がある実装は、T4Optionsフィールドのフラグ設定が非バイト境界のMHまたはMR画像データに設定されている場合、TIFF-Fファイルを書き込むときにRTCを含めることができます。 TIFFリーダーの実装者は、MH / MR画像データにRTCシーケンスを含むいくつかの既存のTIFF-F実装があることにも注意する必要があります。したがって、TIFF-FリーダーはRTCを含まないファイルを処理できなければならず、RTCを含むファイルを処理できる必要があります（SHOULD）。
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.
T.6 Modified Modified READ圧縮方式でエンコードされたTIFF-Fページには、各コード化されたストリップの終わりに「ファクシミリブロックの終わり」（EOFB）コードを含める必要があります。 [TIFF]ごとに、EOFBコードの後に、バイト境界に合わせるために必要に応じてパッドビットが続きます。 TIFFリーダーは、EOFBを超えるパッドビット以外のビットを無視する必要があります（SHOULD）。
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.
実装は、アプリケーション要件に応じて、TIFF-Fリーダー、TIFF-Fライター、またはその両方を実装することを選択できます。 TIFF-Fリーダーは通常、コンピューターまたは周辺機器に存在する既存のTIFF-Fファイルを読み取るために使用されます。 TIFF-Fライターは、通常、2値の画像ビットストリームをTIFF-F準拠のファイルに変換するために使用されます。多くのインターネットアプリケーションでは、リーダーのみを実装する必要があります。 TIFF-Fリーダーおよびライターに必要な特定のフィールドサポートを以下にまとめます。
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. The minimum subset of values are also shown. If required fields are omitted in a TIFF-F file, the Baseline TIFF default value will apply. Image data must not have any coding errors. In the table, certain fields have a value that is a sequence of flag bits (e.g. T4Options). An implementation should test the setting of the relevant flag bits individually to allow extensions to the sequence of flag bits to be appropriately ignored.
次の表のフィールドは、TIFF-Fリーダー用に指定されています。必須フィールドと推奨フィールドの値の範囲は次のとおりです。値の最小サブセットも表示されます。 TIFF-Fファイルで必須フィールドが省略されている場合、ベースラインTIFFのデフォルト値が適用されます。画像データにコーディングエラーがあってはなりません。表では、特定のフィールドにフラグビットのシーケンスである値があります（T4Optionsなど）。実装では、フラグビットのシーケンスの拡張を適切に無視できるように、関連するフラグビットの設定を個別にテストする必要があります。
As noted within [TIFF], a TIFF file begins with an 8-byte image file header, of which the first two bytes (0-1) contain the byte order within the file. The permissible values are:
[TIFF]で述べたように、TIFFファイルは8バイトの画像ファイルヘッダーで始まり、その最初の2バイト（0-1）にはファイル内のバイトオーダーが含まれています。許容値は次のとおりです。
II- Byte order from least significant byte to the most significant byte (little-endian) MM - byte order is always from most significant to least significant (big-endian)
II-最下位バイトから最上位バイト（リトルエンディアン）までのバイト順MM-バイト順は常に最上位から最下位（ビッグエンディアン）まで
For a TIFF-F Reader, the legal values are:
TIFF-Fリーダーの場合、有効な値は次のとおりです。
ByteOrder: MM,II (Either byte order is allowed)
ByteOrder：MM、II（どちらのバイト順でも可能です）
Recommended Fields in the table are shown with an asterisk (*).
表の推奨フィールドは、アスタリスク（*）で示されています。
Other fields may be present, but they should be of an informational nature, so that a reader can elect to ignore them.
他のフィールドが存在する場合がありますが、読者がそれらを無視することを選択できるように、それらは情報の性質を持つ必要があります。
Informational fields which are often present in TIFF-F images are: Software, Datetime, BadFaxLines, CleanFaxData and ConsecutiveBadFaxLines.
TIFF-F画像によく存在する情報フィールドは、Software、Datetime、BadFaxLines、CleanFaxData、およびConsecutiveBadFaxLinesです。
Field | Values | Minimum | Comment
------------------|-------------|-------------|----------------------
BitsPerSample | 1 | 1 |one bit per sample
Compression | 3,4 | 3 |3 for T.4 (MH, MR)
| | |4 for T.6 - MMR
FillOrder | 2,1 | 2 |LSB first or MSB first
ImageWidth | 1728, 2048, | 1728 |depends on XResolution
| 2432, 2592, | |
| 3072, 3648, | |
| 3456, 4096, | |
| 4864 | |
ImageLength | >0 | |required
NewSubFileType | Bit 1 = 1 | Bit 1 = 1 |single page of
| | |multipage file
Orientation * | 1 | |1st row=top left,
| | | 1st col=top
PageNumber | X/X | 0/1 |pg/tot, 0 base,
| | | tot in 1st IFD
PhotometricInterp | 0,1 | 0 |0 is white
ResolutionUnit | 2,3 | 2 |inches (default)
RowsPerStrip |=ImageLength |=ImageLength |
| or other | |
SamplesPerPixel | 1 | 1 |one sample per pixel
StripByteCounts | >0 | |required
StripOffsets | >0 | |required
T4Options | Bit 0 = 0,1 | Bit 0 = 0 |MH,MR(incl if not MMR)
| Bit 1 = 0 | Bit 1 = 0 |
| Bit 2 = 0,1 | Bit 2 = 0,1 | Non-Byte-aligned and
| | | Byte-Aligned EOLs
T6Options | 0 | |MMR (incl only if MMR)
XResolution | 204,200,300,| 204 | If unit is per inch
| 400,408, | |
| 77 | | If unit is per cm
YResolution | 196,98,100, | 196,98 | If unit is per inch
| 200,300,391,| |
| 400, | |
| 77,38.5 | | If unit is per cm
------------------|-------------|-------------|----------------------
For the case of writing (creating) a TIFF-F file format from an image data stream or other raster data, implementations SHOULD write files which can be read by a TIFF-F Reader as defined in 3.9.1. It is recommended that all fields from the table in 3.9.1.1 SHOULD be included when writing TIFF-F files in order to minimize dependencies on default values. Image data must not have any coding errors.
画像データストリームまたは他のラスターデータからTIFF-Fファイル形式を書き込む（作成する）場合、実装は3.9.1で定義されているようにTIFF-Fリーダーで読み取ることができるファイルを書き込む必要があります（SHOULD）。デフォルト値への依存性を最小限に抑えるために、TIFF-Fファイルを書き込むときは、3.9.1.1の表のすべてのフィールドを含める必要があります（SHOULD）。画像データにコーディングエラーがあってはなりません。
Other fields may be present, but they should be of an informational nature, so that a Reader may elect to ignore them.
他のフィールドが存在する場合がありますが、読者はそれらを無視することを選択できるように、それらは情報の性質を持つ必要があります。
For the case of writing "minimum subset" TIFF-F files, the rules defined in section 3.6 apply.
「最小サブセット」TIFF-Fファイルを書き込む場合は、セクション3.6で定義された規則が適用されます。
Informational fields that may be useful for TIFF-F files are: Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines
TIFF-Fファイルに役立つ情報フィールドは次のとおりです：ソフトウェア、日時、BadFaxLines、ConsecutiveBadFaxLines
TIFF Writers SHOULD only generate the fields that describe facsimile image quality when the image has been generated from a fax image data stream where error correction (e.g. Group 3 Error Correction Mode) was not used. These fields are: CleanFaxData, BadFaxLines and ConsecutiveBadFaxLines.
TIFFライターは、ファクシミリの画像品質を説明するフィールドのみを生成する必要があります（画像が、エラー訂正（例：グループ3エラー訂正モード）が使用されなかったFAX画像データストリームから生成された場合）。これらのフィールドは、CleanFaxData、BadFaxLines、およびConsecutiveBadFaxLinesです。
[TIFFREG] describes the registration of the MIME content-type image/ tiff to refer to TIFF 6.0 encoded image data. When transported by MIME, the TIFF content defined by this document must be encoded within an image/tiff content type. In addition, an optional "application" parameter is defined for image/tiff to identify a particular application's subset of TIFF and TIFF extensions for the encoded image data, if it is known. Typically, this would be used to assist the recipient in dispatching a suitable rendering package to handle the display or processing of the image file.
[TIFFREG]は、TIFF 6.0エンコードされた画像データを参照するためのMIME content-type image / tiffの登録を記述します。 MIMEで転送する場合、このドキュメントで定義されているTIFFコンテンツは、画像/ tiffコンテンツタイプ内でエンコードする必要があります。さらに、オプションの「アプリケーション」パラメーターがimage / tiffに対して定義され、特定のアプリケーションのTIFFおよび既知の場合は、エンコードされた画像データのTIFF拡張のサブセットを識別します。通常、これは、受信者が適切なレンダリングパッケージをディスパッチして画像ファイルの表示または処理を処理するのを支援するために使用されます。
Since this document defines a facsimile specific profile of TIFF, it is useful to note an appropriate application parameter for the image/tiff MIME content-type.
このドキュメントでは、TIFFのファクシミリ固有のプロファイルを定義しているため、画像/ tiff MIMEコンテンツタイプの適切なアプリケーションパラメータを確認しておくと役立ちます。
The "faxbw" application parameter is defined for black and white facsimile. It is suitable for use by applications that can process one or more TIFF for facsimile profiles or subsets used for the encoding of black and white facsimile data.
「faxbw」アプリケーションパラメータは、白黒ファクシミリ用に定義されています。白黒のファクシミリデータのエンコードに使用されるファクシミリプロファイルまたはサブセットの1つ以上のTIFFを処理できるアプリケーションでの使用に適しています。
Since this document defines a profile of TIFF for facsimile which is suitable for use with black and white facsimile image data, applications which use this profile or its minimum subset should set the value of the application parameter to "faxbw".
このドキュメントはファクシミリ用のTIFFのプロファイルを定義しているため、白黒のファクシミリ画像データでの使用に適しています。このプロファイルまたはその最小サブセットを使用するアプリケーションは、アプリケーションパラメータの値を "faxbw"に設定する必要があります。
An example of the use of the image/tiff MIME Content-type with the application parameter set with the value "faxbw" follows:
値 "faxbw"で設定されたアプリケーションパラメータでのimage / tiff MIME Content-typeの使用例は次のとおりです。
Example:
例：
Content-type: image/tiff; application=faxbw
In this example, use of this parameter value will enable applications to identify the content as being within a profile or subset of TIFF for Facsimile that is suitable for encoding black and white image data, before attempting to process the image data.
この例では、このパラメーター値を使用することで、アプリケーションは、画像データを処理する前に、白黒画像データのエンコードに適したファクシミリのTIFFのプロファイルまたはサブセット内にあるものとしてコンテンツを識別できます。
5.1 Internet Fax Usage
5.1 インターネットFAXの使用
The usage of TIFF-F is envisioned as a component of Internet Fax. It is anticipated that Internet Fax may use both a TIFF-F Reader and TIFF-F Writer. The details of the Internet Fax services and their use of TIFF-F will be specified in other documents.
TIFF-Fの使用は、インターネットFAXのコンポーネントとして想定されています。インターネットFAXはTIFF-FリーダーとTIFF-Fライターの両方を使用することが予想されます。インターネットファックスサービスの詳細とTIFF-Fの使用については、他のドキュメントで説明します。
The Application F of TIFF (i.e. TIFF-F content) is a secondary component of the VPIM Message as defined in [VPIM2]. Voice messaging systems can often handle fax store-and-forward capabilities in addition to traditional voice message store-and- forward functions.
TIFFのアプリケーションF（つまり、TIFF-Fコンテンツ）は、[VPIM2]で定義されているVPIMメッセージのセカンダリコンポーネントです。ボイスメッセージシステムは、多くの場合、従来のボイスメッセージのストアアンドフォワード機能に加えて、ファックスのストアアンドフォワード機能を処理できます。
As a result, TIFF-F fax messages can optionally be sent between compliant VPIM systems, and may be rejected if the recipient system cannot deal with fax.
その結果、TIFF-F FAXメッセージは、準拠するVPIMシステム間でオプションで送信でき、受信側システムがFAXを処理できない場合は拒否される可能性があります。
Refer to the VPIM Specification for proper usage of this content.
このコンテンツの適切な使用方法については、VPIM仕様を参照してください。
This document describes the encoding for TIFF-F, which is a profile of the TIFF encoding for facsimile. As such, it does not create any security issues not already identified in [TIFFREG], in its use of fields as defined in [TIFF]. There are also new TIFF fields defined within this specification, but they are of a purely descriptive nature, so that no new security risks are incurred.
このドキュメントでは、ファクシミリのTIFFエンコーディングのプロファイルであるTIFF-Fのエンコーディングについて説明します。そのため、[TIFF]で定義されているフィールドの使用において、[TIFFREG]でまだ特定されていないセキュリティの問題は発生しません。この仕様内で定義された新しいTIFFフィールドもありますが、それらは純粋に説明的な性質であるため、新しいセキュリティリスクは発生しません。
Further, the encoding specified in this document does not in any way preclude the use of any Internet security protocol to encrypt, authenticate, or non-repudiate TIFF-F encoded facsimile messages.
さらに、このドキュメントで指定されているエンコーディングは、TIFF-Fでエンコードされたファクシミリメッセージの暗号化、認証、または否認防止のためのインターネットセキュリティプロトコルの使用を決して排除するものではありません。
Glenn W. Parsons Northern Telecom P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada Phone: +1-613-763-7582 Fax: +1-613-763-2697 Email: Glenn.Parsons@Nortel.ca
グレンW.パーソンズノーザンテレコムP.O. Box 3511、ステーションCオタワ、オンK1Y 4H7カナダ電話：+ 1-613-763-7582ファックス：+ 1-613-763-2697メール：Glenn.Parsons@Nortel.ca
James Rafferty Human Communications 12 Kevin Drive Danbury, CT 06811-2901 USA Phone: +1-203-746-4367 Fax: +1-203-746-4367 Email: Jrafferty@worldnet.att.net
James Rafferty Human Communications 12 Kevin Drive Danbury、CT 06811-2901 USA電話：+ 1-203-746-4367ファックス：+ 1-203-746-4367メール：Jrafferty@worldnet.att.net
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [MIME4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[MIME1] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。[MIME4] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Four：Registration Procedures」、RFC 2048、1996年11月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[T.30] ITU-T Recommendation T.30 - "Procedures for Document
Facsimile Transmission in the General Switched Telephone
Network", June, 1996
[T.4] ITU-T Recommendation T.4 - "Standardization of Group 3
Facsimile Apparatus for Document Transmission", June, 1996
[T.6] ITU-T Recommendation T.6 - "Facsimile Coding Schemes and
Coding Control Functions for Group 4 Facsimile Apparatus",
March, 1993
[TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 -
Final, June 3, 1992.
[TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File
Format (TIFF) - image/tiff: MIME Sub-type Registration ", RFC
2302, March 1998.
[VPIM2] G. Vaudreuil and G. Parsons, "Voice Profile for Internet
Mail - version 2", Work In Progress, <draft-ema-vpim-06.txt>,
November 1997.
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。