-
マーク(
)は，特に版1.0で取り扱う部分を示す。
通常は，その後の版で置き換えられた機能を含む。
-
マーク(
)は，特に版1.1での新しい機能を取り扱う部分を示す。
-
マーク(
)は，特に版1.2での新しい機能を取り扱う部分を示す。
-
マーク(
)は，特に版1.3での新しい機能を取り扱う部分を示す。
-
マーク(
)は，附属書Gに，互換性の備考及び実装上の備考がある
ことを示す。
この標準情報(TR)は，1999年3月にAdobe Systems Incorporatedから公表された Portable Document Format Reference Manual, Version 1.3 を翻訳し，技術的内容を変更することなく作成した標準情報(TR)である。 1.及び2.については，原規定の同項目を全文翻訳し， 3.以降に ついては，それぞれ原規定の同項目の内容を引用するものとした。
この標準情報(TR)は，Adobeが開発したフォーマット済み文書の交換フォーマットである ポータブル文書フォーマット(PDF 1.3)を規定する。 PDFの目標は，フォーマット済み電子文書を, それが生成された環境とは独立に， 容易にかつ信頼性をもって交換し閲覧することを可能にすることとする。 PDFは，テキスト及び図形を装置非依存及び分解能非依存な方法で記述するために， PostScript®言語の可視化モデルに依存する。 対話的な閲覧の性能を向上させるために，PDFは，多くのPostScript言語プログラムが用いる フォーマットよりも更に構造化されたフォーマットを定義する。 PDFは，ページ部分それ自体ではないが，対話的閲覧に便利な， 注記，ハイパテキストリンクなどのオブジェクトも含む。
PDFファイルは，PostScript言語で用いられるオブジェクトに類似した 番号付きオブジェクトの列で構成される。ページの内容を形成するテキスト， 図形及び画像は，PostScript言語の演算子に基づく演算子, 及びAdobe Illustrator® 3.0のページ記述演算子に厳密に従う 演算子を用いて表現される。
PDFファイルは，PostScript言語プログラムではなく，PostScriptインタプリタが それを直接解釈することはできない。しかし，PDFファイルのページ記述は， PostScript言語プログラムに変換できる。
この標準情報(TR)は, PDFファイルフォーマットを規定する共に， 効率的なPDFファイルを生成するための方策を示す。 主として，直接PDFファイルを生成しようとするアプリケーション開発者を対象とする。 この標準情報(TR)は，PDFファイルを読み修正するアプリケーションを， 開発者が書くことを可能にするために充分な情報も含む。 PDFはどんな特定のアプリケーションにも依存しない。ただし， 特定のアプリケーションがファイルの中のPDF機能に出会うときに, そのアプリケーションがとる動作によって，そのPDF機能が最適に説明されることはある。 同様に, 附属書Dでは, Acrobatのビュアアプリケーションにおける実装上の制約を示す。 ただし，それらの制約は，ファイルフォーマットそれ自体の一部をなすものではない。
PDF規定は，PDF 生成系 (PDFファイルを生成するアプリケーション)又は PDF 利用系 (PDFファイルを読みその内容を解釈するアプリケーション) のどのような特定の実装にも依存しない。しかし，実装者に指針を与えるために， 規定に附属した 実装に関する備考 及び附属書Gが， この規定で文書化された変更に際してのAcrobatビュアの振る舞いを示す。
この標準情報(TR)は，二つの章から成る。第1章でファイルフォーマットを規定し， 第2章で効率的なPDFファイルを生成するための技法を示す。さらに附属書は， ファイル例，幾つかのあらかじめ定義されたフォント符号化の詳細規定， PDFページマーク付け演算子及びその他の情報を示す。
この規定を読むには，PostScript Language Reference Manual, Third Edition [1]に記述された PostScript言語の知識をもっていることを前提とする。 さらに，Adobe Type 1 Font Format [5] に記述されたフォントの理解が役に立つ。
この標準情報(TR)の第1章，ポータブル文書フォーマットは，2.〜7.を含み， PDFファイルフォーマットを規定する。
2.は，PDFファイルフォーマットを生成する動機を示し，その体系の概要を示す。 PDFを，PostScript言語と比較する。
3.は，PDFファイルで用いる座標系及び座標変換を示す。PDFで使う座標系は， PostScript言語で用いる座標系に極めて類似しているので， PostScript言語の充分な背景をもつユーザは，この3.を単なる復習として読んで差し支えない。
4.は，PDFファイルにおいて文書を構成するために用いるオブジェクトの型を規定する。 これらの型は，PostScript言語において使われるものに類似している。 PostScript言語にあるオブジェクトの型をよく知っている者は， この4.を心覚えとして読んで差し支えない。
5.は，PDFファイルのフォーマットの記述を示す。 つまり，PDFファイルをディスク上に構成する方法，及びPDFファイルに更新を付加できる機構を示す。
6.は，4.に示すオブジェクト型を用いて，PDFファイルで文書を表現する方法を規定する。
7.は，PDFファイルで用いる資源，すなわち，フォント，色空間，画像などを定義する。
8.は，PDFファイルで用いる演算子を示す。この演算子は，ページ上に実際のマーク付けを行う。 その多くは，一つ以上のPostScript言語の演算子に類似している。 PostScript言語の経験のある者は，この類似性にすぐ気付くであろう。
この標準情報(TR)の第2章 PDFファイルの最適化は，9.〜14.を含み， 効率的PDFファイルを生成するための技術を規定する。そこに示される技術の多くは， PostScript言語でも利用できる。その技術は，四つの分野，すなわち，テキスト，画像， 図形及び一般の各技術に細分化される。
9.は，線形化されたPDFファイルを規定する。線形化されたファイルは， ネットワーク環境での効率的動作のために構成された。
10.は，PDFファイルの様々な状況で利用できる一般的な最適化を示す。
11.は，テキストの最適化を示す。
12.は，図形の最適化を示す。
13.は，サンプル画像に利用できる最適化を示す。
最後に14.において，描画が行われる領域を制限するためのクリッピングパスの利用技術 及び効率的な混成を行うための画像の利用技術を示す。
備考 混成の章は，この標準情報(TR)の原規定の第4版では削除された。
この標準情報(TR)の原規定の第2版は， Portable Document Format Reference Manual の1993年の版である。 この版は，PDFの版1.1(以降PDF 1.1)を規定する。
参考 実装においては，PDF 1.1は，Adobe Acrobat 2.0製品群の固有ファイルフォーマットである。
PDF 1.0規定と同様に，PDF 1.1規定は，最小限のレベルの対話的機能を定義する。 PDFは，拡張可能なフォーマットである。これは，PDFファイルには， この規定が定義しないオブジェクトが含まれてもよいことを意味する。 この規定の利用者は，PDF 1.1が規定するオブジェクトのセマンティクスを正しく実装し， 利用者が理解しないオブジェクトを，可能な限り無いものとして無視するのがよい。 附属書Gに，利用者が理解しないオブジェクトを処理する方法の指針を示す。
参考 実装では，Acrobat 2.0及びその後継の製品の中には， プラグインをサポートするインタフェースを提供するものがある。 このプラグインは，PDFファイル内の非公開のデータオブジェクトを使ったり， それらオブジェクトをファイル内に置いたりできる。 附属書Gでは，使用可能な非公開データの種類を示し，附属書Fでは， このデータに対するレジストリを定義する。 レジストリは，互いに関係しないプラグインからのデータを識別する際の (名前の)衝突を避けるために使用できる。
PDF 1.1で導入された新しい機能は，次を含む。
備考 PDF 1.1では，辞書検索キーの名前は，ファイルの中に空きを多くするために 一つ又は二つの字とすることが多い。これら検索キーを以降で示す場合には， 検索キーに続けて，より説明的な文字列を括弧で囲み示す。 しかし，実際には，1字又は2字の名前だけをPDFファイルの中で使用してよい。
この標準情報(TR)の原規定の第3版は， Portable Document Format Reference Manual の1996年3月1日の版である。 これは，PDFの版1.2(以降PDF 1.2)を規定する。
参考 実装においては，PDF 1.2は，Adobe Acrobat 3.0製品群の固有ファイルフォーマットである。
PDF 1.2で導入された新しい機能は，次を含む。
参考 PDFは，発展段階にある言語である。 この規定の新しい版は，その変化を文書化するために， 発展途上の基盤に基づいて提供されることになる。 この標準情報(TR)の原規定の最新の版は， Adobeのウェブサイト(http://www.adobe.com) で入手可能である。
この規定を印刷して使用する者は多いだろうが，オンラインで参照する者もいる。 これを考慮して，画面上で読むことを多少でも容易とするために， フォントの選択及びサイズなどのフォーマットに対して多くの変更を行った。
この標準情報(TR)の原規定の第4版は， 1996年10月3日のPortable Document Format Reference Manual第1.2版である。 これは，Portable Document Formatの版1.3を規定する。
参考 実装においては，PDF 1.3は，Adobe Acrobat 4.0製品群の固有ファイルフォーマット である。
PDF 1.3は，PostScript 3で定義したとおりのAdobe作画モデルの新しい機能， 及びそれ以外の機能に対するサポートを追加する。これらは，次を含む。
テキストのスタイルは，様々な演算子，キーワード，用語及び オブジェクトを識別するために使用される。この規定では，次に示すスタイルを使用する (1)。
注1 ただし，カラーは，この標準情報(TR)の紙による出版物では表示されないことに注意。
辞書キーに含まれるテーブルは，通常，最初に Type 及び Subtype の キーをおき，辞書に要求される何か他のキー，何らかのオプションキーと続けて構成する。
備考 Type キーは，ほとんどの場合，文脈から推測できる。例えば， Tf 演算子のオペランドは，Fontオブジェクトでなければならない。そこで，Font辞書の Type キーは，主として，文書化として，及びエラー検査の情報として， 利用される。PDF1.3以降では， Type キーが表にない場合， もはやそのキーは要求されない。しかし，表にある場合には， それは正しい値をもたなければならない。でなければならない。 さらに，あらゆる辞書の Type キーの値は，それが"私的データ"だとしても， この規定で定義されている名前又は"登録された名前"のどちらでなければならない。 詳細は，附属書Fを参照すること。
表において太文字で示されるキーの名前は，S(Subtype)などとして， 括弧で囲まれた用語を続けることがある。表の中ではキーの名前だけが使われる。 すなわち，記述されている用語は，同意語でも代替のキーでもない。
この標準情報(TR)の原規定の以前の版に対する重要な変更及び訂正は，原規定の左余白にある 垂直の変更バーでマーク付けしてある。変更の大部分は，PDFの版の間の違いに関係している。 これらは，原規定の右余白にあるアイコンでマーク付けしてある。
)は，特に版1.0で取り扱う部分を示す。
通常は，その後の版で置き換えられた機能を含む。
)は，特に版1.1での新しい機能を取り扱う部分を示す。
)は，特に版1.2での新しい機能を取り扱う部分を示す。
)は，特に版1.3での新しい機能を取り扱う部分を示す。
)は，附属書Gに，互換性の備考及び実装上の備考がある
ことを示す。
一般に，新しい機能及び属性は，古いビュアでは無視される。 版のアイコンで示される属性は，その版で新しいものか， 又はその版で実質的に再定義されたものであってよい。
この規定を通して，次に示すように構文を記述するために， 拡張BNF(Extended Backus Naur Form，EBNF)記法を使用する。
<xyz> ::= abc <def> ghi | <k> j
"<"と">"とで囲まれたトークンは，文書構成要素のクラスに名前を付ける。 一方，通常のテキストは，文字通りそのまま，又はいくつかの明確な置換えをして表示される。 文法規則は，二つの部分をもつ。クラス名は，定義記号(::＝)の左にある。この例では， クラスは xyz である。定義記号の右には，そのクラス要素が文書の中で取るであろう 一つ以上の代替の形式の集合が存在する。垂直バー( | )は，代替の形式を分離する。
定義の右側は，複数行になっていてもよい。多少の例外はあるが，これらの行は， ファイルの中の行とは対応しない。
記法 [...] は，括弧で囲まれた項目をオプションとすることを意味する。 アステリスク(*)が項目の後に続く場合，その項目は，0回 以上繰り返してもよい。 正符号(+)が項目の後に場合，その項目は，1回 以上繰り返さなければならない。 波括弧 {...} は，項目をグループ化するために使われる。
演算子がEBNFの規定に現れる場合，それは，オペランドを伴った演算子の簡略形とする。 例えば，演算子mがEBNFの規定の中に現れる場合，それは x y m を意味する。ただし，x 及び y は数とする。
PDFは，大文字・小文字を区別する。
最終形式文書のための交換フォーマットを利用する一般的な考えは，パブリックドメインにある。 最終形式文書のための交換フォーマットを定義する自分自身の 一意なコマンド集合及びデータ構造を案出することは, 誰にも自由である。 Adobeは，ポータブル文書フォーマット(Portable Document Format)という 特定な交換フォーマットに関するデータ構造，演算子及び規定書における著作権を所有する。 これらの要素は，Adobeの許可なしに複製してはならない。
Adobeは，その著作権を強く主張する。Adobeの意図は，ポータブル文書フォーマットの 規定としての完全性を維持することにある。これによって，誰もが, ポータブル文書フォーマットと他の最終形式文書の交換フォーマットとを 区別することを可能にする。
しかしAdobeは，多様な製品及びアプリケーションの中で， 情報交換のためにポータブル文書フォーマットの利用を促進することを希望する。 そこでAdobeは, 次に示す誰に対しても著作権許可を与える。
これらの著作権許諾の条件は，著作権で保護された 演算子及びデータ構造のリストをこの方法で使用する誰もが， 適切な著作権表示を行わなければならないことだけとする。
著作権で保護された演算子及びデータ構造のリストを使用するためのこの限定付き権利は, ポータブル文書フォーマット参照マニュアル，Adobeの他の著作権で保護されたもの， 又はポータブル文書フォーマットを使用するどのようなAdobeの製品のソフトウェア を複写する権利も含まず，総括的にも部分的にも，どのようなAdobeの特許を使う権利も含まない。
PDFファイルの詳細な構造を吟味する前に，PDFとは何か， PostScript言語とどのように関係しているかを理解することが重要になる。 2.では，PDF及びPDFのPostScript言語との関係について示す。
3.では，PDFファイルの様々な構成要素を記述するために使用する座標系について規定する。 4.及び5.では，PDFがサポートするオブジェクトの基本型 及びPDFファイルの構造について規定する。 6.，7.及び8.では，PDF文書の構造，並びにテキスト，グラフィクス及び画像の描画に 使用される演算子について規定する。
PDFは，文書の作成に使用するアプリケーションソフトウェア，ハードウェア及び オペレーティングシステムに依存せずに文書を表現するファイルフォーマットとする。 PDFファイル は，PDF文書 及びその他の補助的なデータを含む。
PDF文書は，1ページ以上(のデータ)を含む。 文書中のそれぞれのページは，装置及び解像度に依存しないフォーマットで， テキスト，グラフィクス及び画像の任意の組合せを含んでよい。 これを ページ記述 という。PDF文書は，ハイパテキストのリンク，音， 動画などの電子的表現でだけ可能な情報を含んでもよい。
PDFファイルは，文書に加えて，そのファイルで使用されているPDF規定の版， 及びファイル中にある重要な構造の位置に関する情報を含む。
PDFを理解するには，PDF文書がどのように生成され， 使われるのかを理解することが重要になる。 PDF文書及びPDFファイルを読むアプリケーションは普及してきているので， PDFファイル作成及び使用の新しい方法が考え出されていくであろう。 このことは，この規定の目的の一つになっている。 すなわち，ファイルフォーマットが入手可能となることで，アプリケーション開発者は， PDF及びそれをサポートする初期のアプリケーションの背後にある着想を拡張することができる。
現在，PDFファイルは，アプリケーションから直接に，又は PostScriptページ記述を含むファイルから生成される。
多くのアプリケーションは，PDFファイルを直接に生成できる。 Apple® Macintosh®コンピュータ及び Microsoft® Windows®環境が動作するコンピュータ で使用可能なPDF Writerは，プリンタドライバとして動作する。 プリンタドライバは，通常，オペレーティングシステムのグラフィクス及びテキストの命令 (Macintoshに対してはQuickDrawTM及びWindowsに対してはGDI) をプリンタで処理できる命令に変換する。ドライバは，これらの命令を プリンタに送るページを印刷する命令のストリームに組み込む。 図2.1に示すとおり，PDF Writerは，これらの命令をプリンタに送る代りに， PDF演算子に変換し，PDFファイルに組み込む。
生成されたPDFファイルは，動作環境に依存しない。Macintosh又はWindows のコンピュータ上のどちらで生成されたかに関わらず， サポートされるいかなる動作環境においても，PDF閲覧アプリケーションによって閲覧できる。
アプリケーションの中には，QuickDraw又はGDIの作画モデルにおける制限のために， 又はシステムレベルのプリンタドライバが存在しないDOS又はUNIX® のコンピュータ上で実行されるために，PostScriptページ記述を直接に生成するものもある。 PostScriptページ記述は，図2.2に示すとおり，Acrobat Distiller® アプリケーションを使用して，PDFファイルに変換できる。Distillerアプリケーションは， プログラムで作成されたか手入力されたかに関わらず，いかなるPostScriptページ記述も 受け付ける。幾つかのアプリケーションプログラムに対しては，Distillerアプリケーションが， PDF Writerよりも，効果的なPDFファイルを生成する。
図2.3に示すとおり，一度PDFファイルが作成された場合は， ファイルに含まれている文書を閲覧及び印刷するために， Acrobatビュアを使用することができる。利用者は，サムネール画像， ハイパリンク及びしおりを使用して，文書中をたどることができる。 文書中のテキストは，他のアプリケーションによって検索及び抽出されてもよい。 さらに，Acrobat利用者は，テキスト注記，ハイパリンク， 各々のページのサムネール画像，及び特定のページを直接表示するしおりを， 作成することによって，PDF文書を変更してもよい。
PDFの目的及び意図する利用を可能とするために，その設計には， 幾つかの注目すべき特性がある。2.3では，これらの特性について示す。
PDFでは，Adobe作画モデルを使って，テキスト及びグラフィクスを表現する。 これは，PostScript言語で使用される作画モデルと同じものとする。PostScript 言語プログラムと同様に，PDFのページ記述は，選択された領域に， "ペイント(paint)"を配置することによって，ページを描画する。
PDFページマーク付け演算子は，PostScript言語のマーク付け演算子と類似している。 PDFマーク付け演算子がPostScript言語と異なる主たる理由は， PDFはプログラミング言語ではなく，手続き処理，変数又は制御構造をもたないことにある。 PDFは，柔軟性に劣るが，その代わりに効率性を改善している。 典型的なPostScript言語プログラムは，PostScript言語のマーク付け演算子を使って， 高水準な演算子の集合を定義する。PDFは，大部分のページを記述するのに十分な 高水準演算子の独自の集合を定義する。これらの演算子は， PostScript言語コードではなく機械語で直接に実装されているので， PDFページ記述は，よりすばやく描画できる。PDFでは， 任意のプログラム要素は許されないので，アプリケーションは， より効率的により信頼性が高く，PDF文書でのテキスト列の配置が可能となる。
PDFファイルは，バイナリファイルとする。すなわち，文字の8ビット範囲全体を使用する。
不幸なことに，アプリケーションの中には，7ビットのASCIIコードの印字可能な部分集合 及び空白文字だけを"テキスト"として使用するファイルを処理し， その内容に対して理解しがたい勝手な扱いをするものがある。例えば， メール転送システムは，7ビット文字のあるものをそのまま確保せず， 改行を変更することがある。 これによって，PDFファイルに損傷が発生することがある。
そこで， PDFファイルに"binary"というラベルをつけることが可能な場合は， それを行うことを推奨する。このような扱いを促す一つの方法には， たとえファイルの残りがASCII文字だったとしても， 幾つかのバイナリ文字(127より大きい文字コード) をファイルの最初近くの注釈に含ませるものがある。 この方法は，5.12で示す。 これによって，PDFファイルは，可能な場合はバイナリとして扱われ， 非バイナリの通信路を損傷無しに転送可能にもなる。
参考 実装においては，Acrobatアプリケーションは，バイナリ文字の注釈をもつ PDFファイルを生成する。
備考 PDF1.0ファイルはASCII ファイルなので，この中のすべてのバイナリデータは， ASCIIフィルタ又は文字列中のエスケープ文字の手段を使って， 7ビットASCIIで表現されなければならない。PDF1.0ファイルの中の行は， 255文字を超えてはならない。
ファイルの大きさを減らすために，PDFは， 多くの業界標準の圧縮フィルタをサポートする。
JPEG圧縮を使って，カラー及びグレースケールの画像を10倍以上圧縮できる。 モノクローム画像の効率的な圧縮は，使用する圧縮フィルタ及び画像の特性に依存するが， 通常は，2:1〜8:1に圧縮される。文書のバランスが取られた， テキスト及びグラフィクスのLZW又はFlateの圧縮は，およそ2:1の圧縮率となる。 これらの圧縮フィルタはすべてバイナリデータを生成するが， 可搬性を維持するために，ASCII base-85符号化方式で符号化してよい。
フォントの管理は，文書の相互交換における基本的な課題である。 一般に，文書の受信側は，送信側が文書を作成するために使用したフォントと 同じフォントをもっていなければならない。そうでない場合には， デフォルトのフォントが代わりに使用されるが，デフォルトフォントは， 意図するフォントとは異なる文字メトリクス(文字幅)をもっているので， 予想外の望ましくない効果を生じてしまう。フォント幅の違いによって， 行が余白に食い込んだり，グラフィクスに重なったりするかもしれない。
送信側が，文書とともにフォントを含めることもできるが，これによって容易に， 短い文書でさえも非常に大きなファイルとなってしまう。例えば， 四つのフォントを使用した普通の2ページのメモが，10KBから250KB へと巨大化するかもしれない。送信側が，文書の各ページをファクスなどの 固定解像度の画像に変換するという，他の送信方法も可能である。しかし， 圧縮したとしても，たった1ページの画像が，非常に大きくなる可能性がある。 例えば，200dpiで取り込むと45KB〜60KBとなる。 さらに, 受信側が文書からテキストを探したり抽出したりができなくなるなど， ファイルに必要情報(intelligence)が残らなくなる。
PDFは，文書を作成するために使用したフォントとはその文書を独立にする 新しい解決法を提供する。PDFファイルは，文書も中で使用されている 各フォントに対して フォント記述子 を含む。このフォント記述子は， フォント名，文字メトリクス及びスタイル情報を含む。 これは，失われたフォントを模擬するために必要な情報であって，通常は， フォントごとに1KB〜2KBだけですむ。
文書の中で使用されているフォントが，そのドキュメントを表示するコンピュータ上で 利用可能な場合，そのフォントを使用する。利用できない場合は， 多重マスタフォントを使用し，一文字ごとに元のフォントの濃淡及び幅を模擬し， 文書の全体の"カラー"及びフォーマット化を維持する。 この解決法は，Adobe Type 1フォントとApple Computerが開発した TrueTypeTMフォーマット[32]との両方に適用される。
シンボリックフォントは，特別な方法で扱わなければならない。 シンボリックフォントとは，標準ISOLatin1文字集合を使わないフォントのこととする。 Carta®，Adobe CaslonTM，Swash Italic， Minion® Ornaments，Lucida® Math などのフォントは，この分類に入る。シンボリックフォントを効果的に模擬することは 可能ではない。
シンボリックフォントに対しては, (メトリクス及びスタイル情報を含む) フォント記述子は十分ではない。文書の正確な表示及び印刷のためには， 実際の文字の形状(又はグリフ)が要求される。Symbol及びITC Zapf Dingbats ®以外のすべてのシンボリックフォントのために， そのフォント用のType 1フォントプログラムの圧縮版が，PDFファイルに含まれている。 最も広く使用されているシンボリックフォントであるSymbol及びITC Zapf Dingbatsは， Acrobatといっしょに出荷されており，PDFファイルに含まれる必要はない。
システムの制限及び効率性への配慮から，PDFを生成するプログラムの実装は， 単パスでPDFファイルを作成することが望ましい。場合によっては必要となる。 これは，例えば，アプリケーションが限定されたメモリにアクセスするとか， 一時ファイルを開くことができないとかのためである。 そこで，PDFは，ファイルの単パス生成をサポートする。 PDFは，あるオブジェクトにその長さをバイト単位で示す数値を含めることを要求する一方で， オブジェクトに対応するファイルにその長さを置くことが可能な機構を提供する。 さらに, すべてのページをファイルに書き込んだ後で， 文書中のページ数などの情報をそのファイルに書きこむことができる。
PostScript言語プログラムから選択されたページを抽出し表示するツールは， そのプログラムを，最初から希望のページが見つかるまで順に検索しなければならない。 平均的に，ページを見るために必要な時間は，ページの複雑さに依存するだけでなく， 文書中の全ページ数にも依存する。このことは，対話的な文書閲覧では問題となる。 この場合，ページを見るのに必要な時間が文書の総ページ数に依存しないことが重要となる。
すべてのPDFファイルは，ファイルの中のページ及び他の重要なオブジェクトの位置を確定し， 直接にアクセスするために使用可能な相互参照表をもつ。 相互参照表の位置情報は，ファイルの最後に格納する。 こうすることで，単パスでPDFファイルを生成するアプリケーションは 容易に相互参照表を格納でき，PDFファイルを読むアプリケーションは 容易に相互参照表の位置を確定できる。 相互参照表を使用することで，PDFファイルの中のページを見るために必要な時間は， 文書中の全ページ数と殆ど独立とすることができる。
アプリケーションは，何百ページも含むPDF文書を利用者が修正できるようにしてもよい。 利用者は，文書への修正を保存するたびに， ファイル全体を書き換えるのを待つ必要がないようにすることが望ましい。 PDFは，修正をファイルに付加することが可能で，元データに手を付けずに残しておくことができる。 ファイルが追記によって更新される場合に付加されるものは， 修正された又は追加されたオブジェクトだけとする。ただし，相互参照表への更新も行われる。 追記による更新のサポートによって，アプリケーションは， ファイルの大きさの代わりに修正の大きさに比例する時間でPDFファイルへの修正を保存できる。 さらに, ファイルの元の内容がファイルの中に依然として存在しているので， 付加されたものを削除することによって保存された変更を取り消すことができる。
PDFは拡張可能に設計されている。PDFにまだ実装されていない又は考えられていない機能を， 開発者が追加したいと思うのは疑いがない。
PDFの設計は，新しい機能の追加できるだけではなく， 以前の版のフォーマットを理解するアプリケーションが， 実装していない機能に出会っても文書を完全には壊さないものとなっている。 Appendix G "互換性及び実装上の注意"では， PDFビュアが予期していた仕様に適合しないファイルを読み込んだ場合に， どのように振る舞うことが望ましいかを規定する。
2.3は，PDFとPostScript言語との違いについて幾つかの点を示した。 2.4は，これらの差を要約し，PDFファイルをPostScript言語プログラムへと変換する処理を示す。
PDF及びPostScript言語は，同じ作画モデルをもつ一方で，幾つかの重要な差がある。
これらの差のために，PDFファイルは，印刷の際にPostScriptプリンタへ直接にはダウンロードできない。 PDFファイルをPostScriptプリンタへ送って印刷するアプリケーションは， 次の手順を踏まなければならない。
| a) | procsetを挿入する。 ここでprocsetとは，PDFページ記述演算子を実装をするPostScript言語手続き定義の集合とする。 |
| b) | 各ページに対して内容を抽出する。 ページは，PDFファイルでは必ずしも順番に保存されてはいない。 各ページ記述は，本質的には，movetoに対して"m"，linetoに対して"l"などの 非常に特殊な手続きを使用する従来のPostScript言語プログラムの重要なスクリプト部分とする。 |
| c) | 圧縮されたテキスト，グラフィクス及びイメージデータを復号する。 これによって，Flateフィルタで符号化されたデータ以外は， PostScript言語ファイルで圧縮されたデータを受け付けることができる PostScriptレベル2プリンタを必す(須)とはしないようになる。 |
| d) | フォントなどのあらゆる資源をPostScript言語ファイルに挿入する。 PDFファイルのフォントメトリクスに基づき，必要に応じて，代替フォントを定義し挿入する。 |
| e) | 情報を正しい順番にする。その結果が，文書の視覚的側面を完全に表現する従来の PostScript言語プログラムとなる。ただし，これには，ハイパテキストリンク，注記， しおりなどのPDF要素はもはや含まれない。 |
| f) | PostScript言語プログラムをプリンタに送る。 |
PDFをよく理解するためには，PDFを図2.4に示す四つの部分で考えるとよい。
最初の構成要素は，オブジェクトを表現するためにPDFが使用する基本オブジェクト型の集合とする。 これらの型は，少数の例外を除き，PostScript言語で使用するデータ型に対応する。 4.で，これらオブジェクト型について示す。
第2の構成要素は，PDFファイル構造とする。 ファイル構造は，PDFファイルでオブジェクトが格納される方法，アクセスされる方法 及び更新される方法を決定する。この構造は，オブジェクトのセマンティクスとは独立とする。 5.で，ファイル構造を示す。
第3の構成要素は，PDF文書構造とする。 文書構造は，ページ，注記，ハイパテキストリンク，フォントなどの PDF文書の構成要素を表現するために，基本オブジェクト型が使用される方法を規定する。 6.で，PDF文書構造を示す。
第4の最後の構成要素は，PDFページ記述とする。 PDFページ記述は，PDFページオブジェクトの一部だが，他の構成要素とは独立に示すことができる。 PDFページ記述は，PDF文書の他の部分とは限られた相互作用だけをもつ。 これによって，PostScript言語への変換が単純化される。8.で，PDFページ記述を示す。
Portable Document Format (PDF) Version 1.3の Chapter 3: Coordinate Systems による。
Portable Document Format (PDF) Version 1.3の Chapter 4: Objects による。
Portable Document Format (PDF) Version 1.3の Chapter 5: File Structure による。
Portable Document Format (PDF) Version 1.3の Chapter 6: Document Structure による。
Portable Document Format (PDF) Version 1.3の Chapter 7: Common Data Structures による。
Portable Document Format (PDF) Version 1.3の Chapter 8: Page Descriptions による。
Portable Document Format (PDF) Version 1.3の Chapter 9: Linearized PDF による。
Portable Document Format (PDF) Version 1.3の Chapter 10: General Techniques for Optimizing PDF Files による。
Portable Document Format (PDF) Version 1.3の Chapter 11: Optimizing Text による。
Portable Document Format (PDF) Version 1.3の Chapter 12: Optimizing Graphics による。
Portable Document Format (PDF) Version 1.3の Chapter 13: Optimizing Images による。
Portable Document Format (PDF) Version 1.3の Chapter 14: Clipping による。