RFC2306 日本語訳
2306 Tag Image File Format (TIFF) - F Profile for Facsimile. G.Parsons, J. Rafferty. March 1998. (Format: TXT=59358 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Parsons
Request for Comments: 2306 Northern Telecom
Category: Informational J. Rafferty
Human Communications
March 1998
教区牧師がコメントのために要求するワーキンググループG.をネットワークでつないでください: 2306年のノーザン・テレコムカテゴリ: 1998年の情報のJ.Rafferty人間のコミュニケーション行進
Tag Image File Format (TIFF) - F Profile for Facsimile
タグ画像ファイル形式(いさかい)--ファクシミリのためのFプロフィール
Status of this Memo
この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)インターネット協会(1998)。 All rights reserved。
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
インターネットファックスワーキンググループ
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インターネットファックス作業部会の製品です。 このドキュメントのすべてのコメントをメール発送先リスト at <ietf-fax@imc.org に送るべきである、gt。
1. Abstract
1. 要約
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-F)のためにファクシミリイメージのストレージと置き換えに使用されるかもしれないファイル形式とTIFFのFプロフィールを定義するためにTag Image File Format(TIFF)に参照をつけます。
2. TIFF Definition
2. いさかい定義
TIFF (Tag Image File Format) Revision 6.0 is defined in detail within [TIFF].
TIFF(タグ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]に指示されます。
Parsons & Rafferty Informational [Page 1] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[1ページ]のRFCプロフィール行進
2.1 Baseline TIFF and Applications
2.1 基線いさかいとアプリケーション
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開発者が彼らの製品の中にサポートするべきである基礎)のコアであるとしてBaseline TIFFを特徴付けます。 TIFFのアプリケーションは、Baseline TIFFからいかなる他の違いも指定することと同様に特定の「アプリケーション」に使用されるTIFFとBaseline TIFFを使用することによって出発点と定義されて、次に、「拡大」を定義することです。
3. TIFF-F Definition
3. いさかいF定義
3.1 Introduction
3.1 序論
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ドキュメントは元々、ジョー・キャンベルによって導かれたファックスの専門家の小さいグループによって作成されました。 TIFF-Fの存在は[TIFF]に述べられますが、それは定義されません。 このドキュメントは[TIFF]のFアプリケーションを定義します。 参照する場合に便利なようにTIFF-Fが「ファクシミリのためのいさかいのFプロフィール」に速記としてこのドキュメント中で使用される用語。 TIFF-Fファイルは「アプリケーション」パラメタのサポートを含んでいるイメージ/いさかいMIMEメディアcontent typeがある使用のために意図します(例えばアプリケーションはfaxbwと等しいです)。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[REQ]で説明されるように本書では解釈されることであるべきですか?
3.1.1 TIFF-F Historical Background
3.1.1 いさかいF歴史的背景
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.
TIFF6.0まで、TIFFはTIFFの様々なアプリケーションの使用を定義した様々な「クラス」をサポートしました。 クラスは特定のアプリケーションをサポートするのに使用されました、そして、この精神では、TIFF-Fは「いさかいのクラス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
TIFF6.0[TIFF]現在、TIFF Class概念はBaseline TIFFの概念を支持して排除されました。 したがって、このドキュメントはファクシミリのためにTIFFのFプロフィールとしてTIFF-Fの定義をアップデートします、[TIFF]で出発点と定義されて、次に、TIFF-Fに申し込むBaseline TIFFから違いを定義するとしてBaseline TIFFを使用することによって。 ほとんどすべての場合、それらと一致したTIFF-F分野と値の残りの結果として起こる定義はTIFF Class F.Whereの以前の定義にいくつかを歴史的に使用しました。
Parsons & Rafferty Informational [Page 2] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[2ページ]のRFCプロフィール行進
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.
分野への値では、アップデートして、ITU-T[T.4]と[T.30]ファックス推薦をより正確な順応に提供してください、これらの違いに注意します。
3.1.2 Overview
3.1.2 概要
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) 大部分のサポートを提供する伝統的なTIFF-F分野への、より広い範囲の値は広くファクシミリ圧縮、ページ・サイズ、および解決を使用しました、ITU-T[T.4]と[T.30]推薦と一致しています。
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定義の構造は以下の通りになるでしょう。 .4にマルチページTIFF-Fファイルの書くことと読書のためのTIFFファイルと実際的なガイドラインの構造の寸評をセクション3.1.3と3.1に提供します。
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で使用されるBaseline 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の読者とWriterを紹介します。 必要でTIFF-F読者にとってのお勧めの分野のテーブルを提供します、受入れられたセットの値に関する詳細と共に。
3.1.3 Structure of TIFF Files
3.1.3 いさかいファイルの構造
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で定義されます。
Parsons & Rafferty Informational [Page 3] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[3ページ]のRFCプロフィール行進
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ファイルはファイル(セクション3.9.1を見る)の中で使用されたバイトオーダーを定義して、内容がTIFFファイルであると認識するマジックナンバー系列を入れて、次に最初のImage Fileディレクトリ(IFD)を示すのにオフセットを使用する8バイトのイメージ・ファイルヘッダーと共に始まります。 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ファイルの中の1IFDを使用することで表されるかもしれません。 各IFDはタイプがNewSubfileType分野で与えられている「副-ファイル」を定義します。 TIFF-Fファイルに置かれるファクシミリデータに関するケースのために、マルチページドキュメントのそれぞれのファクシミリページにはそれ自身のIFDがあります。 2レベルのファクシミリファイルに関しては、複数のIFDsが繋がっているリストとして組織化されます、各IFDにおける最後のエントリーが次のIFDを示していて(最後のIFDの指針は0です)。 (また、木として複数のIFDsを組織化するための別のテクニックがありますが、それはSubIFDs分野を使用しますが、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構造を発生させることができます。 これは特にファクシミリ端末などの環境における実装のために複雑なファイル構造がサポートするのが難しいところにあります。
3.1.4 Practical Guidelines for Writing/Reading Multi-Page TIFF-F Files
3.1.4 マルチページいさかいFファイルを書くか、または読むための実際的なガイドライン
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読者SHOULD。しかしながら、構造が[TIFF]と一致しているファイルをTIFFに読み込むように用意してください、ここでお勧めであるよりフレキシブルなファイル構造を支えるどれ。
Parsons & Rafferty Informational [Page 4] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[4ページ]のRFCプロフィール行進
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ファイルのための構造はドキュメントのページあたり1IFDを含むでしょう。 したがって、各IFDは1ページのために属性を定義するでしょう。 簡単さのために、TIFF Fの作家はページの実際の系列として同次でSHOULDの現在のIFDsをファイルします。 ページは、0ページで始まりながら最初のページとしてTIFF-Fの中で付番されて、次に、昇っています(すなわち、0、1、2)。(しかしながら、セクション3.1.3で注意されるように、4バイト以上のどんな分野値も別々にページオーダーに示されますが、扱うことができる読者SHOULDがIFDsを予想するIFD. TIFF-F例外から保存されるでしょう。
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ファイルの書くことのための仮定を簡素化する1秒はマルチページドキュメントSHOULDの各ページイメージデータが1片(すなわち、ファックスページあたり1イメージ片)の中に含まれていると指定することです。 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 SHOULDがIFDが説明するイメージに先行するポイントにTIFF-Fファイル構造に置かれるということです。 何かロング・フィールド値がそうならその時、これらのSHOULDを寄贈してください(セクション3.1.3を見ます)。それらの参照箇所IFDの後とそれらが説明するイメージデータの前に置かれてください。
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ファイル構造の中の物理的なオーダーにおける実画像データが注文される場所にはTIFF-F作家と読者のための4番目の簡素化仮定があります。 実際には、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作家は5番目の簡素化仮定をするかもしれません。((それでは、次のイメージIFDに先行します)IFDにはオフセットがあるIFD、値のデータ、およびイメージデータ)。 これらの要素は最小のセットTIFF-Fファイルで次のイメージIFDに先行しなければなりません(セクション3.6.2を見てください)。 しかしながら、この原則は、過去の習慣を反映するためにTIFF-Fの場合でリラックスしました。
Parsons & Rafferty Informational [Page 5] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[5ページ]のRFCプロフィール行進
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ファイルは順番に、それぞれ、また、イメージデータのページがTIFF-Fファイル構造の中に論理的なページ順番に置かれる1ページのイメージデータ(1ページあたり1片)を示すページオーダーを昇る際に寄贈されたIFDsの繋がっているリストで本質的には構成されるでしょう。 (イメージデータのページがそうするかもしれない、自分たち、作成者の選択のときに隣接の方法で保存されてください、)
3.2 Baseline TIFF Required Fields for BiLevel Images
3.2 二階建ての家イメージズのための基線いさかい必須項目
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、圧縮、PhotometricInterpretation、StripOffsets、RowsPerStrip、StripByteCounts、XResolution、YResolution、およびResolutionUnit。 TIFF-Fは、Baseline TIFFよりこれらの分野のすべてを使用しますが、いくつかの場合、異なった範囲の許容値を指定します。 [TIFF]に従って、分野が省略されると、Baseline 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
Fieldname(タグ番号)は値と等しいです(適切であるなら)。 タイプ
A brief summary of the Baseline TIFF fields and their use in TIFF-F follows:
Baseline 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:
1728、2048、2432、2592、3072、3648、3456、4096、ImageWidth(256)=4864。 短いか、または長いです。 これらは画素の固定ページ幅です。 許容値は[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
--------------------------------------------|------------------
XResolution x Yresolution| ImageWidth--------------------------------------------|------------------ 204×98、204×196、204×391、200×100、200×200| 1728、2048、2432、300×300| 2592 3072 3648 408×391、400×400| 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
歴史的なTIFF-Fは、より高い解像度に関連する以下の幅のサポートを含んでいませんでした: 2592、3072、3648、3456、4096、および4864。 また、歴史的なTIFF-FドキュメントはA5に関連する以下の値とA6幅を含んでいました: 816と1216。 [T.4]の最新のバージョンあたり、A5とA6ドキュメントはノーです。
Parsons & Rafferty Informational [Page 6] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[6ページ]のRFCプロフィール行進
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.
より長い間、Group3ファクシミリで支持されていて、したがって、関連する幅の値は現在、時代遅れです。 インチ/のメートル法のequivalenciesと他の実現の詳細の詳しい情報に関してセクション3.8.2を見てください。
ImageLength (257). SHORT or LONG. LONG recommended.
The total number of scan lines in the image.
ImageLength(257)。 短いか、または長いです。 推薦された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です。 1Baseline TIFFあたりのデフォルト値は1(解凍される)ですが、ファクシミリイメージに、この値は無効です。 また、基線TIFFは値2(変更されたハフマン符号化)の使用を可能にしますが、データはEOLsを含まないフォームに提示されます。 代わりに、TIFF-Fは一次元T.4 Modifiedハフマンか2次元のModified READデータをコード化するのに値3を指定します。 T.4がデータを暗号化したので、適用される詳細な設定はT4Options分野を使用することで指定されます。 また、TIFF-Fが値4のデータが[T.6]圧縮方法を使用することでコード化されるのを示す圧縮分野の使用を可能にする、(i.e、Modified Modified READの二次元方法) 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の中で使用されたイメージとコンベンションのコード化に関する詳しい情報についてT4Optionsの定義とセクション3.3、およびセクション3.8のT6Options野原を参照してください。
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)。 短いか、または長いです。 各片、その片のオフセットのために。 オフセットはファイルの始まりから測定されます。 1ページが大きい1つの片として言い表されるなら、そのようなエントリーの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)。 短いか、または長いです。 推薦されたLONG。 片単位でスキャンの数は立ち並んでいます。 1ページが大きい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。 各片、その片の中のバイト数のために。 1ページが大きい1つの片として言い表されるなら、これは圧縮の後のページのバイトの総数です。 LONGかSHORTの選択を片のサイズに依存することに注意してください。
Parsons & Rafferty Informational [Page 7] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[7ページ]のRFCプロフィール行進
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イメージの水平な解像度。 200と408の値は一貫性のために[T.30]と共に歴史的なTIFF-F値に加えられます。 また、いくつかの既存のTIFF-F実現が77(cm)の値を支持するかもしれません。 インチ/のメートル法のequivalenciesと他の実現の詳細の詳しい情報に関してセクション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イメージの垂直解像度。 100の値であり、200、および391は一貫性のために[T.30]と共に歴史的なTIFF-F値に加えられます。 また、いくつかの既存のTIFF-F実現が77、38.5(cm)の値を支持するかもしれません。 インチ/のメートル法のequivalenciesと他の実現の詳細の詳しい情報に関してセクション3.8.2を見てください。
3.3 TIFF-F Required Fields
3.3 いさかいF必須項目
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:
Baseline 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。 短い。 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。 短い。 TIFF F読者は両方の噛み付いている命令でデータを読むことができなければなりませんが、かなりの大多数のファクシミリ製品は最初にデータLSBを格納します、ちょうど電話回線の上に現れるように。 1は最初に、ほとんどのSignificant Bitと等しいです。 2は最初に、最少のSignificant Bitと等しいです。
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
NewSubFileType(254)は(ビット1 = 1)と等しいです。 長い。 この分野は32フラグビットで作られます。 未使用のビットは0であると予想されます、そして、ビット0は下位のビットです。 ビット0はTIFF-Fのために0に設定されます。 マルチページイメージの1ページを示して、ビット1はTIFF-Fのためにいつも1に設定されます。 同じビット
Parsons & Rafferty Informational [Page 8] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[8ページ]のRFCプロフィール行進
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.
TIFF-Fが1ページのファックスイメージに使用されるとき、設定は使用されています。 セクション3.1.1とマルチページTIFF-Fイメージの構造に関するその他の詳細のための.2がファイルする3.1を見てください。
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.
PageNumber(297)。 短いか、または短いです。 この分野はファックスドキュメントのページ番号を指定します。 分野は2つのSHORT値を包括します: 最初の値がページ番号である、2番目はページの総数です。 したがって、1ページドキュメントは0000/0001十六進法を使用します。 2番目の値が0であるなら、ドキュメントのページの総数は有効ではありません。
SamplesPerPixel (277) = 1. SHORT.
The value of 1 denotes a bi-level, grayscale, or palette color
image.
SamplesPerPixel(277)=1。 短い。 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.
また、T4OptionsかT6Options分野のどちらかを含んでいるという要件がTIFF-F IFDにあります、Compression分野の設定によって。 これらの分野はTIFF拡張子のときに次のセクションで定義されます。
3.4 TIFF-F Extensions
3.4 いさかいF拡大
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に設定されたなら、この分野が必要です。 値は1次元です、2次元の(MR)のための1が0(許容されなかったデータを解凍する)が非バイトが並んでいるEOLsのためのビット2 = 0であったなら1=必須に噛み付いたか、またはバイト1がEOLsを並べたので以下にTIFF F.For TIFF-Fに関して、解凍されたデータが許容されていなくて、EOLsがバイトであるかもしれないことが示されるセットが. ビット0 = 0を並べたという(セクション3.8.3を見ます)ことです。
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はG3OptionsとしてTIFFとTIFF-Fの以前のバージョンで知られていました。 T.4方法の1つを使用することでコード化された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-
T6Options(293)は長い間、(ビット0 = 0、ビット1 = 0)と等しいです。 圧縮分野の値が4に設定されたなら、この分野がTIFF-Fに必要です。 この分野への値は32フラグビットのセットで作られます。 0〜0にビットを設定するのは、データがModified Modified READ(MMR)twoを使用することで圧縮されるのを示します。
Parsons & Rafferty Informational [Page 9] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[9ページ]のRFCプロフィール行進
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)
次元圧縮方法。 そして、MMR、圧縮されたDataが2歳である、次元、EOLsを使用しません。 各MMRはイメージをコード化しました。それぞれのコード化された片(セクション3.8.6を見る)の端ときに「ファクシミリブロックの端」(EOFB)コードを含まなければなりません。 両性愛者のレベルファクシミリイメージには、解凍されたデータが適切でないので、ビット1を0に設定しなければなりません。 未使用のビットを0に設定しなければなりません。 ビット0は下位のビットです。 デフォルト値は0(すべてのビット0)です。2次元のビット1=のためのビット0 = 0は0であるに違いありません。(許容されなかった解凍されたデータ)
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つの新しい分野がページ品質について説明します。 これらの分野に保管されていた情報は、通常、ファクシミリハードウェアを受け止めるのから得て(適切。)です。 これらの分野は任意です。 SHOULD NOTは、修正された誤りであるファクシミリイメージデータに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プログラムは、高い精度ドキュメントにそれを輸入する前に、ファイルには低誤りレベルがあることを確かめたがっているかもしれません。 Group3ファクシミリ装置が必ずイメージデータにエラー修正を実行するというわけではないので、解読されたスキャン線の画素数から容認されたページの品質を推論しなければなりません。 「良い」スキャン線は解読されると画素の適度の数を含む線と定義されます。 逆に、「悪い」スキャン線は解読されると不正確な数の画素を包括する線と定義されます。
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 Thisがファクシミリで不正確な数の画素があるスキャン線の数がレセプション(しかし、必ずいずれのファイルでもそうするというわけではない)の間に遭遇したレポートをさばきます。
Note: PercentBad = (BadFaxLines/ImageLength) * 100
以下に注意してください。 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)。 0つの=SHORT N=データは不正確な画素数がある1=線が作り直された不正確な画素数か作り直された線(すなわち、発生するコンピュータ)がある装置を受ける線を全く含んでいません。
Parsons & Rafferty Informational [Page 10] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[10ページ]のRFCプロフィール行進
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)。 長いか、または短いです。 この分野はレセプション(しかし、必ずいずれのファイルでもそうするというわけではない)の間にファクシミリ装置で遭遇する不正確な数の画素を含む連続した線の最大数を報告します。
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分野は、彼らの分配のインディケータであり、したがって、知覚された画質の、より良い一般的なインディケータであるかもしれません。
3.5 Recommended Fields
3.5 お勧めの分野
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.
heseはTIFF-Fファイルをコード化する際に使用されるかもしれない分野です、現実にptionalであり、多くのTIFF読者によって無視されるかもしれないのを除いて。 これらのieldsは歴史的なTIFF-F racticeと一致していた状態でお勧めであると呼ばれます。
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。 これはドキュメントがスキャンされたドキュメントの名前です。
Parsons & Rafferty Informational [Page 11] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[11ページ]のRFCプロフィール行進
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のデフォルト値があるBaseline 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。 イメージを作成したソフトウェアパッケージの任意の名前とリリース番号。
3.6 Requirements for TIFF-F Minimum Subset
3.6 いさかいF最小の部分集合のための要件
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読者SHOULDが支持する値の最小の部分集合のための要件を定義します。 また、最小の部分集合ファイルを書くためのTIFF-F構造は定義されます。
3.6.1 Summary of Minimum Subset Fields and Values
3.6.1 最小の部分集合分野と値の概要
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
分野| 最小限| コメント------------------|--------------|------------------------------- BitsPerSample| 1 |サンプルCompressionあたり1ビット| 3 |3 T.4(MH)FillOrderのために| 2 |LSB最初のImageWidth| 1728 | ImageLength| |必要なNewSubFileType| ビット1 = 1|「マルチ-ページ」ファイルPageNumberの1ページ| X/X|pg/幼児、0ベースは最初のIFD PhotometricInterpで合計にされます。| 0 |0は白いResolutionUnitです。| 2 |インチ(デフォルト)RowsPerStrip|=ImageLength| SamplesPerPixel| 1 |1画素あたり1個のサンプル
Parsons & Rafferty Informational [Page 12] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[12ページ]のRFCプロフィール行進
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
------------------|--------------|------------------------------
StripByteCounts| |必要なStripOffsets| |必要なT4Options| ビット0 = 0|MH| ビット1 = 0| | ビット2 = 0、1|非バイトは並びました。| | バイトで並べられたEOLs XResolution| 204 |ユニットがインチYResolution単位であります。| 196,98 |ユニットが1インチ単位であります。------------------|--------------|------------------------------
3.6.2 TIFF-F Minimum Subset File Structure
3.6.2 いさかいF最小の部分集合ファイル構造
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
+-----------------------+
| : |
| : |
+-----------------------+ | ヘッダー|------------+ +-----------------------+ | 最初に、IFD| IFD(0ページ)| <、-、-、-、-、-、-、-、-、--+ オフセット+---| |------------+ | | |--+ | 値| +-----------------------+ | | オフセット+-->| 長い値| | | +-----------------------| | 片| | イメージデータ(0ページ)| <、-+ オフセット| +-----------------------+ | 次のIFD| IFD(1ページ)| <、-、-、-、-、-、-、-、-、--+ オフセット+---| |------------+ | | |--+ | 値| +-----------------------+ | | オフセット+-->| 長い値| | | +-----------------------| | 片| | イメージデータ(1ページ)| <、-+ オフセット| +-----------------------+ | 次のIFD| IFD(2ページ)| <、-、-、-、-、-、-、-、-、--+ オフセット+-----------------------+ | : | | : |
Figure 3.1 TIFF-F Minimum Subset File Structure
図3.1 いさかい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はそのページ関連するImage Dataに先行します。 存在しているなら、どんなロング・フィールド値もそのページIFDとイメージデータの間に現れます。 複数のページドキュメントに関しては、それぞれのIFD/イメージ組はすぐにファイル構造の中の論理的なページ順番で次のIFD/イメージ組によってついて来られています、すべてのページが定義されるまで。
Parsons & Rafferty Informational [Page 13] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[13ページ]のRFCプロフィール行進
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 Headerのための形式が[TIFF]で定義されるようにあります。 バイトオーダーのために最小の部分集合ファイル、値をTIFF-Fに書くときにはHeader SHOULDでは、IIになってください。(0×4949、中にTIFFファイルのバイトがあるのを指示して、LSBは最初に、注文します(リトルエンディアン)。
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 | +--------+-------------------+--------+--------------------+
| 相殺してください。| 記述| タイプ| 値| +--------+-------------------+--------+--------------------+ | 0 | バイトオーダー| 短い| 0×4949 (II)| +--------+-------------------+--------+--------------------+ | 2 | バージョン| 短い| 42 | +--------+-------------------+--------+--------------------+ | 4 | 第0IFDのオフセット| 長い| 0x0000 0008| +--------+-------------------+--------+--------------------+
Figure 3.2: Image File Header for Minimum Subset TIFF-F Files
図3.2: 最小の部分集合いさかいFファイルのためのイメージ・ファイルヘッダー
3.7 Technical Implementation Issues
3.7 技術的実装問題
3.7.1 Strips
3.7.1 片
Those new to TIFF may not be familiar with the concept of "strips" embodied in the three fields RowsPerStrip, StripByteCount, StripOffsets.
TIFFに新しいそれらは3つの分野に具体化している「片」RowsPerStripの概念になじみ深くないかもしれません、StripByteCount、StripOffsets。
In general, third-party implementations that read and write TIFF files expect the image to be divided into "strips," also known as "bands." Each strip contains a few lines of the image. By using strips, a TIFF reader need not load the entire image into memory, thus enabling it to fetch and decompress small random portions of the image as necessary.
一般に、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イメージのためのお勧めのアプローチは各ページ単位で1片を表すことです。
Parsons & Rafferty Informational [Page 14] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[14ページ]のRFCプロフィール行進
3.7.2 Bit Order
3.7.2 ビットオーダー
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]あたりのBaseline TIFFのデフォルトビットオーダーはFillOrder=1によって示されます。そこでは、保存される前にビットが逆にされません。 しかしながら、TIFF-FはFillOrder=2の設定を通常利用します。(そこでは、バイトの中の噛み付いているオーダーがストレージの前に逆にされます(すなわち、ビットが最初に、Least Significant Bitと共に保存されます))。
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 Recommendation T.4の記述に比例して現れます。 したがって、ファクシミリ実装の広い大部分がストレージのためのこの自然界の秩序を選びます。 それにもかかわらず、TIFF-F読者は両方の噛み付いている命令でデータを読むことができなければなりません。
3.7.3 Multi-Page
3.7.3 マルチページ
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が既に読まれた多くの実装は、ファイルが好きですが、マルチページ分野をサポートしません。 マルチページ形式がファックスアプリケーション・ソフトでファイル管理を大いに簡素化するので、TIFF-Fは一般的なケースとしてマルチページドキュメント(NewSubfileType=2)を指定します。
3.7.4 Compression
3.7.4 圧縮
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.
Group3ファクシミリには、3つの1994年の時点で、標準化された、共用の圧縮方法があります。 ITU-T T.4推薦はModifiedハフマンとして知られている一次元圧縮方法(MH)とModified READとして知られている二次元メソッド(さん)を定義します(Relative Element Address Designateに、READは短いです)。 1984年に、Modified Modified READ(MMR)として知られているいくらか効率的な圧縮方法はT.6推薦で定義されました。 それは元々使用のためにGroup4ファクシミリで定義されました、この圧縮方法が一般的にGroup4圧縮と呼ばれたように。 1991年に、MMRメソッドは、Group3ファクシミリにおける使用のために承認されて、以来、広く利用されています。
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つの異なった圧縮方法を可能にします。 実際には、最も通例の一次元圧縮方法(変更されたハフマン)は使用されています。 これは、Compression分野の値を3に設定して、次に、T4Options分野のビット0を0に設定することによって、指定されます。 あるいはまた、二次元Modified READメソッド(まして、歴史的なTIFF-F実装に頻繁に使用される)は、1の値にビット0を設定することによって、選択されるかもしれません。
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
実装要件によって、任意に、T.6(すなわち、MMRか「グループ4圧縮」)からの、より効率的な二次元圧縮方法は選択されるかもしれません。 このメソッドは選択されます。
Parsons & Rafferty Informational [Page 15] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[15ページ]のRFCプロフィール行進
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.
Compression分野の値を4に設定して、次に、T6optionsの最初の2ビット(すべての未使用のビット)の価値を0に設定します。 圧縮選択をする際にimplementerを支援する詳しい情報はImplementation Warningsの上のセクション3.8に含まれています。
3.7.5 Example Use of Page-quality Fields
3.7.5 ページ品質分野の例の使用
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. ソースイメージデータ・ストリームは、誤りで直るか別の方法でコンピュータなどのようにエラーのないのがファイルを生成したのが保証されています: SHOULD NOTはページ品質分野を書きます。
3.7.6 Use of TIFF-F for Streaming Applications
3.7.6 いさかいFのストリーミング・アプリケーションの使用
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は、ファイルの全体のサイズがあらかじめ知られているところで通信しながら店などの実装に前方にファックスイメージ・ファイルを扱うのに歴史的に使用されました。 また、TIFF-Fがストリーミング・アプリケーションなどのケースにことによるとファイル形式として使用されているかもしれない間、本書では提供されたものと異なった仮定が必要であるかもしれません(例えばイメージの中の全体のサイズとページ数はあらかじめ、知られていません)。 その結果、TIFF-Fのストリーミング・アプリケーションのための定義はこのドキュメントの範囲を超えています。
3.7.7 TIFF-F Export and Import
3.7.7 いさかい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をサポートしたがっていない実装を送ってください。
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つページ)値で個々の1ページTIFF-Fファイルを作り出すのを試みました。 しかしながら、そのような複数の1ページファイルを論理的な倍数ページドキュメントに結びつけるどんな簡単な方法もありません、この習慣が推薦されないように。
Parsons & Rafferty Informational [Page 16] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[16ページ]のRFCプロフィール行進
Import
輸入
A TIFF-F reader MUST be able to handle a TIFF-F file containing multiple pages.
TIFF-F読者は複数のページを含むTIFF-Fファイルを扱うことができなければなりません。
3.8 Implementation Warnings
3.8 実装警告
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に設定しなければならないことを意味します。
3.8.2 Encoding and Resolution
3.8.2 コード化と解決
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).
以来、二次元コード化はGroup3の互換性に必要でなく、何人かの歴史的なTIFF-F読者はそのようなファイルを読むことができませんでした。 1個の次元(ハフマンを変更する)のファイルのTIFF-F REQUIRESサポートの最小の部分集合であり、したがって、この選択は移植性を最大にします。 しかしながら、TIFF-Fファイルを書くとき、より大きい効率SHOULDを探すimplementersがT.6 MMR圧縮を使用します。 また、何人かのTIFF-F読者が二次元Modified READファイルをサポートするでしょう。 読書TIFF-FファイルSHOULDに最大の柔軟性を持ちたがっているImplementersがこれらのすべての3つの圧縮方法(MH、MR、およびMMR)をサポートします。
For the case of resolution, almost all facsimile products support both standard (98 dpi) vertical resolution and "fine" (196 dpi) resolution. Therefore, fine-resolution files are quite portable in the real world.
解決に関するケースのために、ほとんどすべてのファクシミリ製品が、両方が標準(98dpi)の垂直解像度と「すばらしい」(196dpi)解決であるとサポートします。 したがって、緻密な解像力ファイルは本当の世界でかなり携帯用です。
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は、1インチあたりのドットに200x200、300x300、400x400を含むT.30推薦における、より高い解像度のサポートがユニットを基礎づけたと言い足しました。 同時に、サポートは同等物が解決を以下のインチまで基礎づけたということであるメートル法の寸法のために加えられました: 391v x204hと391v x408h。 したがって、新しい解決のインチベースの同等物のフルセットはTIFF-F作家でサポートされます、Group3ファクシミリデバイスから受けられたイメージデータ・ストリームに現れるかもしれないので。 しかしながら、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
[T.4]に従って、実装が以下のXResolution値を同等であるとして扱うのは、許されています: <20万4200>と<40万408>。 同様の敬意、以下のYResolution値で
Parsons & Rafferty Informational [Page 17] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[17ページ]のRFCプロフィール行進
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.
また、同等であるとして扱われるかもしれません: <98、100の>、<196、200>、および<391、400>。 [T.4]はこれらのequivalenciesをインチとメートル法のベースのファクシミリ端末の間の変換を可能にさせられました。
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ファイルの作成のために作家によって推薦されないので、TIFF-F読者(すなわち、77x38.5cm)でのメートル法のベースの解決の任意のサポートは完全性のために含まれています。
3.8.3 EOL byte-aligned
3.8.3 EOLはバイト並びました。
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ハフマンかModified READデータのすべてのEOLsがバイトで並べなければならないということです。 しかしながら、Baseline TIFFはデフォルトで非バイトが並んでいるEOLsの使用を可能にしました、大きい百分率のTIFF-F読者実装が両方のコンベンションをサポートするように。 したがって、定義されるとしてのTIFF-Fの最小の部分集合は本書ではバイトで並べられて、かつ非バイトが並んでいるEOLsのサポートを含んでいます。
An EOL is said to be byte-aligned when Fill bits have been added as necessary before EOL codes such that EOL always ends on a byte boundary, thus ensuring an EOL-sequence of a one byte preceded by a zero nibble: xxxx0000 00000001.
EOLはEOLがEOLがバイト境界でいつも終わるようなものをコード化する前にFillビットが必要に応じて加えられたとき、バイトによって並べられると言われています、その結果、ゼロで先行された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).
変更されたハフマン符号化はバイトではなく、ビットをコード化します。 これは、行末トークンが1バイトの中央に終わるかもしれないことを意味します。 バイト整列では、付加的なゼロ・ビット(いっぱいにしている)が加えられるので、EOLに続くデータの最初のビットはバイト境界で始まります。 事実上、バイト整列はバイト毎に系列指向の映像操作(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ビットのタグビットによって終えられます。 次の系列が次の系列が基準線であるなら二次元データと1を含んでいるなら、[T.4]あたりタグビットの価値は0です。 EOL/タグが系列に噛み付く前にバイト整列を維持するために、中詰めビットは加えられます、MRタグビットに続くデータの最初のビットがバイト境界で始まるように。
3.8.4 EOL
3.8.4 EOL
As illustrated in FIGURE 1/T.4 in [T.4], facsimile documents encoded with Modified Huffman begin with an EOL (which in TIFF-F may be byte-aligned). The last line of the image is not terminated by an EOL. In a similar respect, images encoded with Modified READ two dimensional encoding begin with an EOL, followed by a tag bit.
[T.4]の図1/T.4で例証されるように、Modifiedハフマンと共にコード化されたファクシミリドキュメントはEOL(TIFF-Fでバイトによって並べられるかもしれない)と共に始まります。 イメージの最終ラインはEOLによって終えられません。 同様の点で、Modified READが二次元であることの形でコード化しながらコード化されたイメージはタグビットが支えたEOLと共に始まります。
Parsons & Rafferty Informational [Page 18] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[18ページ]のRFCプロフィール行進
3.8.5 RTC Exclusion
3.8.5 RTC除外
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.
EOLsは別として、TIFF-Fファイルはイメージデータを歴史的に含むだけでした。 TIFF Fファイルを書くとき、これは、規則が[TIFF]にある厳しい順応と歴史的なTIFF-Fとの互換性を維持したがっている実装であり、SHOULD NOTがReturn To Control系列を含んでいることを意味します(RTC)(6連続したEOLsから成ります)。 しかしながら、T4Options分野の旗の設定が非バイトの並べられたMHかMRイメージデータに設定されるならTIFF-Fファイルを書くとき、[T.4]イメージデータの「透明」をサポートする必要がある実装はRTCを含むかもしれません。 また、TIFF読者の作成者もMH/MRイメージデータにRTC系列を含んでいるいくつかの既存のTIFF-F実装があるのを意識しているべきです。 したがって、TIFF-F読者はRTCとSHOULDを含んでいないファイルを処理できなければなりません。RTCを含んでいるファイルは処理できてください。
3.8.6 Use of EOFB for T.6 Compressed Images
3.8.6 EOFBのT.6圧縮画像の使用
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読者SHOULDはEOFBを超えたパッドビット以外のどんなビットも無視します。
3.9 TIFF-F Fields Summary
3.9 いさかいF分野概要
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 Writerまたは両方を実装するのを選ぶかもしれません。 TIFF F読者は、コンピュータか周辺機の上にある既存のTIFF-Fファイルを読むのに通常使用されます。 TIFF-F WriterはTIFF-F対応することのファイルに両性愛者のレベルイメージビットストリームを変換するのにおいて通常使用されています。 多くのインターネットアプリケーションのために、読者だけが、実装される必要があります。 特定の分野サポートがTIFF-F読者に必要であり、Writersは以下へまとめられます。
3.9.1 TIFF Reader
3.9.1 いさかい読者
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ファイルで省略されて、Baseline TIFFデフォルト値は適用されるでしょう。 イメージデータには、少しのコード化誤りもあってはいけません。 テーブルでは、ある一定の分野はフラグビット(例えば、T4Options)の系列である値を持っています。 実装は、フラグビットの系列への拡大が適切に無視されるのを許容するために個別に関連フラグビットの設定をテストするべきです。
Parsons & Rafferty Informational [Page 19] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[19ページ]のRFCプロフィール行進
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)
最も重要でないバイトから最も重要なバイト(リトルエンディアン)MMまでのIIバイトオーダー--いつも最も重要であるのから最も重要にならないまでバイトオーダーがあります。(ビッグエンディアン)
For a TIFF-F Reader, the legal values are:
TIFF-F読者にとって、正当な値は以下の通りです。
ByteOrder: MM,II (Either byte order is allowed)
ByteOrder: mm、II(どちらのバイトオーダーも許容されています)
3.9.1.1 Fields for TIFF-F Reader
3.9.1.1 いさかいF読者のための分野
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イメージでしばしば存在している情報の分野は以下の通りです。 ソフトウェア、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
分野| 値| 最小限| コメント------------------|-------------|-------------|---------------------- BitsPerSample| 1 | 1 |サンプルCompressionあたり1ビット| 3,4 | 3 |3 T.4(MH、MR)のために| | |T.6のための4--MMR FillOrder| 2,1 | 2 |LSB1番目の、または、MSB最初のImageWidth| 1728, 2048, | 1728 |XResolutionによります。| 2432, 2592, | | | 3072, 3648, | | | 3456, 4096, | | | 4864 | | ImageLength| >0| |必要なNewSubFileType| ビット1 = 1| ビット1 = 1|1ページ| | |「マルチ-ページ」ファイルOrientation*| 1 | |最初の行は左上と等しいです。| | | 最初のあん部=の先端PageNumber| X/X| 0/1 |pg/幼児、0ベース| | | 最初のIFD PhotometricInterpで合計になってください。| 0,1 | 0 |0は白いResolutionUnitです。| 2,3 | 2 |インチ(デフォルト)RowsPerStrip|=ImageLength|=ImageLength| | 何らかの| | SamplesPerPixel| 1 | 1 |画素StripByteCountsあたり1個のサンプル| >0| |必要です。
Parsons & Rafferty Informational [Page 20] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[20ページ]のRFCプロフィール行進
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
------------------|-------------|-------------|----------------------
StripOffsets| >0| |必要なT4Options| ビット0 = 0、1| ビット0 = 0|MH、MR(inclかMMR)| ビット1 = 0| ビット1 = 0| | ビット2 = 0、1| ビット2 = 0、1| そして非バイトが並べた。| | | バイトで並べられたEOLs T6Options| 0 | |MMR(MMRである場合にだけ、inclする)XResolution| 204,200,300,| 204 | ユニットが1インチ単位であるなら| 400,408, | | | 77 | | ユニットがcm YResolution単位であるなら| 196,98,100, | 196,98 | ユニットが1インチ単位であるなら| 200,300,391,| | | 400, | | | 77,38.5 | | ユニットが1cm単位であるなら------------------|-------------|-------------|----------------------
3.9.2 TIFF-F Writer
3.9.2 いさかいF作家
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ファイル形式を書く(作成します)ケースのために、実装SHOULDがTIFF-F読者が中で定義されるように読むことができるファイルを書く、3.9、.1 すべてがテーブルから3.9で.1をさばくのが、お勧めである、.1SHOULD、デフォルト値で依存を最小にするためにTIFF-Fファイルを書くときには、含められてください。 イメージデータには、少しのコード化誤りもあってはいけません。
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ファイルの役に立つかもしれない情報の分野は以下の通りです。 ソフトウェア、Datetime、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 Writers SHOULDはイメージがファックスイメージデータ・ストリームのためにエラー修正(例えば、Group3Error Correction Mode)が使用されなかったところで発生しているときファクシミリ画質について説明する分野を生成するだけです。 これらの分野は以下の通りです。 CleanFaxData、BadFaxLines、およびConsecutiveBadFaxLines。
4. MIME sub-type image/tiff
4. MIMEサブタイプイメージ/いさかい
[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
[TIFFREG]は、TIFF6.0のコード化されたイメージデータを示すためにMIME content typeイメージ/いさかいの登録について説明します。 MIMEによって輸送されると、イメージ/いさかいcontent typeの中でこのドキュメントによって定義されたTIFF内容をコード化しなければなりません。 さらに、任意の「アプリケーション」パラメタはa特定用途のTIFFとTIFF拡張子の部分集合を特定するイメージ/いさかいのために定義されます。
Parsons & Rafferty Informational [Page 21] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[21ページ]のRFCプロフィール行進
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.
それが知られているなら、イメージデータをコード化しました。 通常、これは、イメージ・ファイルのディスプレイか処理を扱うために適当なレンダリングパッケージを派遣するのに受取人を助けるのに使用されるでしょう。
4.1 Refinement of MIME sub-type image/tiff for Application F
4.1 Application FのためのMIMEサブタイプイメージ/いさかいの気品
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のファクシミリの特定のプロフィールを定義するので、イメージ/いさかいMIME content typeのための適切なアプリケーションパラメタに注意するのは役に立ちます。
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"アプリケーションパラメタは白黒のファクシミリのために定義されます。 それはファクシミリプロフィールのための1TIFFを処理できるアプリケーションか白黒のファクシミリデータのコード化に使用される部分集合で使用に適しています。
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"で設定されたアプリケーションパラメタがあるイメージ/いさかいMIME文書内容の使用に関する例は従います:
Example:
例:
Content-type: image/tiff; application=faxbw
文書内容: イメージ/いさかい。 アプリケーションは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.
この例では、このパラメタ価値の使用は、アプリケーションが、白黒のイメージデータをコード化するのに適当なFacsimileのためにTIFFのプロフィールか部分集合の中に内容があることであると認識するのを可能にするでしょう、イメージデータを処理するのを試みる前に。
5. Implementation Usage
5. 実装用法
5.1 Internet Fax Usage
5.1 インターネットファックス用法
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の用法はインターネットファックスのコンポーネントとして思い描かれます。 インターネットファックスがTIFF-F読者とTIFF-F Writerの両方を使用するかもしれないと予期されます。 インターネットファックスサービスの詳細と彼らのTIFF-Fの使用は他のドキュメントで指定されるでしょう。
5.2 VPIM Usage
5.2 VPIM用法
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(すなわち、TIFF-F内容)のApplication Fは[VPIM2]で定義されるようにVPIM Messageの伴星です。 そして、声のメッセージシステムがしばしば伝統的な音声メールに加えた店とフォワード能力が保存するファックスを扱うことができる、-、-機能を進めてください。
Parsons & Rafferty Informational [Page 22] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[22ページ]のRFCプロフィール行進
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ファックス通信は、任意に対応するVPIMシステムの間に送ることができて、受取人システムがファックスに対処できないなら、拒絶されるかもしれません。
Refer to the VPIM Specification for proper usage of this content.
この内容の適切な用法についてVPIM Specificationを参照してください。
6. Security Considerations
6. セキュリティ問題
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-Fのためのコード化について説明します。(FはファクシミリのためのTIFFコード化のプロフィールです)。 そういうものとして、それは問題が[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はファクシミリメッセージをコード化しました。
7. Authors' Addresses
7. 作者のアドレス
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.パーソンズノーザン・テレコム私書箱3511、K1Y 4H7カナダの駅のCオタワは以下に電話をします。 +1-613-763-7582 Fax: +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
ダンベリー、コネチカット06811-2901米国が電話をするジェームスRaffertyの人間のコミュニケーション12ケビンドライブ: +1-203-746-4367 Fax: +1-203-746-4367 メールしてください: Jrafferty@worldnet.att.net
8. References
8. 参照
[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]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。 解放された[MIME4]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、1996年11月。
Parsons & Rafferty Informational [Page 23] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[23ページ]のRFCプロフィール行進
[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.
[REQ] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。 [T.30]ITU-T推薦T.30--「司令官におけるドキュメントファクシミリ伝送のための手順は電話網を切り換えました」、1996[T.4]年6月のITU-T推薦T.4から「ドキュメントトランスミッションのためのグループ3ファクシミリ装置の規格化」、6月まで、1996[T.6]ITU-T推薦T.6--「グループ4ファクシミリ装置のためにコード構成とコード化コントロール機能を電送してください」、3月、1993年の[いさかい]Adobe開発者協会、いさかい(TM)改正6.0--決勝、1992年6月3日。 [TIFFREG] パーソンズ、G.、Rafferty、J.、およびS.Zilles、「Image File Format(TIFF)にタグ付けをしてください--/いさかいに像を描いてください」 「MIMEサブタイプ登録」、RFC2302、1998年3月。 [VPIM2] G.ボードルイとG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2インチ、Work In Progress、ema-vpim-06.txt>、11月を作成している<1997。」
Parsons & Rafferty Informational [Page 24] RFC 2306 TIFF-F Profile March 1998
パーソンズと1998年の2306いさかいFのRaffertyの情報[24ページ]のRFCプロフィール行進
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Parsons & Rafferty Informational [Page 25]
パーソンズとRafferty情報です。[25ページ]
一覧
スポンサーリンク
