PDFの構造について 1
さて、PDFの構造について日本語でお勉強できる資料というのは少なくて、わたしも過去にAdobeSystemsからリリースされたリファレンスの第２版を読んでいました。ところがですね、あれって、専門用語に関する訳に難がありまして、理解を妨げるような書き方の部分のあったりします。なによりPDF1.3の解説ですから今となってはちょっと古いです。
という事で数年前から片手間にPDF1.7リファレンスの翻訳を行ってるんですが、これ、色々な絡みでそのままお出しできませんです。という事で細切れで解説していきたいと思います。ご存知の通り元となったドキュメントもと～っても分厚い資料ですからどれだけやるかってのはあるのですが、最低でもAcrobatの構造表示を読み解くレベルまでは続けようかと思いますです。
では、１回目としては、そもそもPDFってなに？って所から始まります。
※各見出し付加された数字は原本の章番号になります。諸々の都合により順番が前後しているものもあります。
ページ記述言語（Page Description Languages／2.1.1）
PDFはページ構造を記述するための言語です。アプリケーションプログラムは、次の2段階のプロセスを通じて出力を生成します。
- アプリケーションは、ページ記述言語で出力のデバイスに依存しない記述を生成します。
- 特定の出力デバイスを制御するプログラムがPDFデータを解釈し、そのデバイスに適切な状態にレンダリングします。
2つのステージは、単一のデバイスで実行されるとは限りません。ページ記述言語は、印刷または表示可能な「ドキュメントのコンパクトでデバイスに依存しない送信および保存のための交換標準」として機能します。
※原本に忠実に書くと非常に抽象的でわかりにくくなります。昔々のお話なのですがプリンター出力にはそのプリンターが理解できる形でデータを渡してあげる必要がありました。そしてそのデータ仕様は各社まちまちといったひどい有様でした。そこに現れたのがPostScriptというページ記述言語です。PostScriptの出現によりコンシューマーアプリケーションはどのようなプリンターへの出力を行う場合でもとりあえずはPostScriptでデータを用意すれば良しとなりました。これが１番目の段階となります。そしてプリンタードライバー等を通して出力デバイスの特性を加味したレンダリング結果を用意してプリンターに送るのが２つ目の段階です。PostScriptの出現によりソフトウェアベンダーもプリンターメーカーもPostScriptの前又は後だけを考えて開発することが可能となました。Adobe社はこのコア技術を礎に大きく飛躍していく事となったのは皆さんがご存知の通りです。
※PostScriptというのはページ記述言語ですが、プログラミング言語としての特性も持ち、この点がPDFと大きく異なる部分です。しかし、PDFのオペランド体系などはPostScriptの影響を大きく受けています。
アドビイメージングモデル（Adobe Imaging Model／2.1.2）
アドビイメージングモデルは、グラフィックアートから発展した2次元グラフィックスのシンプルで統一された表示機能です。このモデルでは、各要素は選択した領域のページに配置されます。
- フォントグリフ、パスで構成された図形、線、または写真などのサンプリングされたビットマップデータを扱うことが出来ます。
- 各要素は、カラー、黒・白等任意に着色できます。また、パターンでの塗りつぶし（PDF 1.2）またはスムーズなグラーデーション（PDF 1.3）の形をとることもあります。
- これらの要素は、ページに配置されるときに他の形状によってマスクされる場合があります。ページのコンテンツストリームには、一連のグラフィックスオブジェクトを記述するオペランドと演算子が含まれています。
PDFを取り扱うアプリケーションは、ペイントオペレーターによって作成されたマークをスタックする現在のページを保持します。
最初はカレントページは完全に空白であり、コンテンツストリームで検出されたオブジェクトごとに、アプリケーションは現在のページに要素を配置します。要素は、オーバーレイする可能性のある以前の要素を置き換えるか、組み合わせます。ページが完全に構成されると、スタックされた要素が出力メディアにレンダリングされ、カレントページが再び空白になります。
PDF 1.3以前のバージョンでは、不透明なイメージングモデルを使用しており、ページにペイントされた新しいオブジェクトが配置された場合、それより下に置かれたオブジェクトを完全に覆い隠します（ただし、オーバープリントが設定された場合は新しいオブジェクトのペイント属性は「のせ処理」されます）。PDF 1.4では、ページ上にオブジェクトのペイントに対して透明なイメージングモデルが導入されました。ページ上に配置されたオブジェクトは、ページの既存のコンテンツと合成され、オブジェクトの色とその背景をそれぞれの不透明度の特性に従って組み合わせた結果を生成します。透明イメージングモデルについてはそのうち説明します。
主要なグラフィックスオブジェクトは次のとおりです。
- パスオブジェクトは、接続又は切断された一連のパスポイント、直線や曲線で構成され、シェイプとその位置を記述します。これは、パス構築演算子（c,l等）を順次適用することで構築され、各演算子は、1つ以上の新しい要素を追加します。パスオブジェクトは、パスに沿って線を描くSや、パスの内部を塗りつぶすf等のパスペイント演算子によって終了されます。
- テキストオブジェクトは、テキストの文字を表す1つ以上のグリフ形状で構成されます。テキストのグリフ形状は、フォントと呼ばれる別のデータ構造で記述されます。パスオブジェクトと同様に、テキストオブジェクトはストロークまたは塗りを設定することが出来ます。
- 画像オブジェクトは、長方形を形成する二次元配列であり、配列の各値がそれぞれが長方形内の特定の位置の色を表します。このようなオブジェクトは通常、写真を表すために使用されます
ペイントオペレーターにはさまざまなパラメータが必要となり、明示的に与える必要のあるもの及び既存の値を暗黙的に継承するものがあります。継承されるパラメータには、色、線幅、フォント（書体とサイズ）などがあり、これらのパラメータが共にオブジェクトの状態を構成します。各継承パラメータを設定するペイントオペレーターは呼び出された時点で既存値をオーバーライドし、その値は次にオーバーライドされるまで有効となります。
グラフィックス状態の1つの追加の継承パラメーターは、グラフィックスオブジェクトのペイントの結果を変更します。
カレントクリッピングパスは、オブジェクトを配置できる現在のページ領域の外形を描きます。ペイントオペレータはカレントページのどこにでもオブジェクトを配置しようとしますが、現在のクリッピングパス内にあるマークのみがページに影響し、領域外のオブジェクトはページに影響を与えません。
最初、カレントクリッピングパスは、ページのレンダリング可能な領域全体を含みます。パスまたはテキストオブジェクトによって定義された形状、または複数の形状の交差した領域にに一時的に縮小できます。後続のペイントオペレータによって配置されたオブジェクトは、その領域内に限定されることとなります。
ラスターアウトプットデバイス（2.1.3）
アドビのイメージングモデルの能力の多くは、レーザー、ドットマトリックス、インクジェットプリンター、デジタルイメージセッター、ラスタースキャンディスプレイなどの一般的なラスター出力デバイスを処理する能力に由来します。ラスター出力デバイスのプロファイル定義は、印刷または表示される画像が、個別にアドレス指定できるピクセル（画像要素）と呼ばれるドットの長方形配列またはラスターで構成されていることです。一般的なバイレベル出力デバイスでは、各ピクセルを黒または白にすることができます。一部のデバイスでは、ピクセルを中間のグレーの色合いまたは特定の色に設定できます。
個々のピクセルにより、テキスト、任意のグラフィック形状、およびサンプリングされた画像の複製を含むことができる印刷または表示された出力を生成することが可能になります。
各ベンダーがリリースするラスター出力デバイスの解像度は、2つの直線寸法に沿った単位距離あたりのピクセル数を決定します。多くの場合、解像度は水平方向と垂直方向ともに同じであり、利用される技術とコストパフォーマンス等のバランスにより決定されます。
- コンピューターディスプレイの解像度は比較的低く、通常は1インチあたり72〜110ピクセルです。
- ドットマトリックスプリンタは、通常、1インチあたり100〜250ピクセルの範囲です。
- インクジェットやレーザープリンター等は、1インチあたり300〜1200ピクセルの中レベルの解像度が中心となります。
- 印刷用途に利用される高精細プレート出力機器では1インチあたり2400ピクセル以上の高解像度で運用されます。
解像度が高いほど、出力結果の品質と忠実度が向上しますが、コストが高くなります。しかし、技術的向上とコンピューティングコストの低下によって、出力デバイスはより高い解像度に進化していくでしょう。
スキャンコンバージョン（2.1.4）
抽象グラフィック要素（線、円、文字グリフ、サンプル画像など）は、スキャン変換と呼ばれるプロセスによってラスター出力デバイスにレンダリングされます。グラフィック要素の数学的記述が与えられると、このプロセスは利用可能なデバイス解像度で可能な限り最も忠実な表現を実現するために、調整するピクセルとそれらのピクセルに割り当てる値を決定します。
ページ上のピクセルは、コンピュータメモリ内のピクセル値の2次元配列で表すことができます。印刷用プレート出力機器の様にピクセルが黒または白のみである出力デバイスの場合、各ピクセルを表すには1ビットで十分です。グレーレベルまたはカラーを再現できるデバイスの場合、ピクセルあたり複数のビットが必要です。
注：プリントアウトまたはディスプレイ表示されたページの最終的な表現は、論理的にはピクセルの完全な配列となりますが、表示用メモリ上での実際の表現は、ピクセルごとに1つのメモリアドレスで構成されている必要はありません。一部の実装では、display listsのようなコマンドが利用できます。Adobeイメージングモデルは、ラスターメモリの特定の表現に依存しないように注意深く設計されています。
ページに表示されるグラフィック要素ごとに、スキャンコンバーターは対応するピクセルの値を設定します。ページののレンダリングが完了すると、メモリ内のピクセル値はページの外観を表します。この時点で、ラスター出力プロセスは、この表現を印刷ページまたは表示画面にレンダリング（表示）できます。
長方形や円などのグラフィック形状をスキャン変換するには、どのデバイスピクセルが形状の内側にあるかを判断し、それらの値を適切に設定する必要があります。形状のエッジは必ずしもピクセル間の境界に正確に収まるとは限らないため、エッジに沿ってピクセルを設定する方法を決定するには、いくつかのポリシーが必要です。テキスト文字を表すグリフをスキャン変換することは、概念的には任意のグラフィック形状をスキャン変換することと同じです。ただし、文字グリフは読みやすさの要件にはるかに敏感であり、品質のより厳格な客観的および主観的な測定値を満たす必要があります。バイレベルデバイスでのグレースケール要素のレンダリングは、ハーフトーンと呼ばれる手法によって実現されます。ピクセルの配列は、いくつかのパターン（ハーフトーンスクリーンと呼ばれます）に従って小さなクラスターに分割されます。各クラスター内では、ページ上のその場所で必要なグレーのレベルに応じて、一部のピクセルが黒に設定され、他のピクセルが白に設定されます。十分な距離から見ると、個々のドットは知覚できなくなり、知覚される結果は灰色の陰影となります。これにより、バイレベルラスター出力デバイスでグレーの色合いを再現し、写真などの自然画像を近似することができます。一部のカラーデバイスは、同様の手法を使用しています。
一般的な性質（2.2）
ここでは、イメージングモデル以外のPDFのその他の注目すべき一般的な性質について解説します。
ポータビリティ（2.2.1）
PDFファイルは、8ビットのバイナリバイトのシーケンスとして表され、すべてのプラットフォームとオペレーティングシステム間で移植できるように設計されています。バイナリ表現は、プラットフォームの違いによる文字コードの相違・改行コードやプラットフォーム固有のルール等の相互変換なしで、生成・表示・送受信されることを目的としています。
PDFファイルは、7ビットASCII（情報交換用の米国標準コード）コードのみを使用する形式で表すことも可能ですが、このこの表現は通常のバイナリ表現よりも効率が悪い為に、通常の使用には不適切です。使用する表現にかかわらず、PDFファイルはテキストファイルではなく、バイナリファイルとして取り扱う必要があります。テキストの改行コード変換などの不用意な変更は、ファイルに損傷を与え、ファイルを使用できなくする可能性があります。
ファイルサイズの圧縮（2.2.2）
ファイルサイズを縮小するために、PDFは多くの標準的な圧縮フィルターをサポートしています。
- JPEGおよび（PDF 1.5の）カラーおよびグレースケール画像のJPEG2000圧縮
- CCITT（グループ3またはグループ4）、ランレングス、および（PDF 1.4の場合）モノクロ画像のJBIG2圧縮
- LZW（Lempel-Ziv-Welch）および（PDF 1.2以降）テキスト、グラフィックス、および画像のFlate圧縮
JPEG圧縮を使用の場合、カラー画像とグレースケール画像を10分の１以下の容量に圧縮可能です。モノクロ画像の効果的な圧縮は、使用する圧縮フィルターと画像のプロパティによって異なりますが、2分の1〜8分の１の圧縮容量が一般的となります（ページサイズいっぱいの画像のJBIG2圧縮の場合は20分の1〜50分の1）。
その他のすべてのテキストとグラフィックスを記述するコンテンツストリームに対するLZWまたはFlate圧縮は、約2分の1の圧縮容量となります。これらの圧縮フィルターはすべてバイナリデータを生成し、7ビットのASCII表現が必要な場合は、各種の圧縮フィルターを通したストリームを更にASCII85にエンコーディング処理します。
フォント管理（2.2.3）
フォントの管理は、ドキュメント交換における根本的な課題です。通常、作成した環境以外でドキュメントを開く時、ドキュメントが作成された時に使用されたフォントと同じものが受け取り側に存在する必要があります。異なるフォントに置き換えると、その文字セット、グリフ形状、およびメトリクス情報等が元のフォントのものと異なる場合があり、この置換により、テキスト行が伸びたり、グラフィックと重なったりするなど、予期しない望ましくない体裁崩れが生じる可能性があります。そういった問題を解消するためにPDFは、フォント管理を処理するためのさまざまな手段を提供します。
- 元のフォントプログラムをPDFファイルに埋め込むことができるため、異なる環境においても、作成時の体裁を忠実に再現できることが保証されます。PDFは、Type 1、TrueType、OpenType、CIDキー付きフォントなどのさまざまなフォント形式をサポートしています。
- ファイル容量を抑制するために、ドキュメント上で実際に使用されている文字のグリフのみを含むフォントサブセットを埋め込むことができます。また、Type1・OpenTypeフォントはCFFという特別なコンパクトフォーマットで表現できます。
- PDFは、事前の定義なしで使用できる14の標準フォントのセットを規定しています。これらには、3つのラテン語テキスト書体（Courier、Helvetica*、およびTimes*）のそれぞれ4つのウエイトと、2つのシンボリックフォント（SymbolおよびITCZapfDingbats®）が含まれます。これらのフォント、または同じメトリックを持つ適切な代替フォントは、すべてのPDFを取り扱うアプリケーションで使用可能です。
- PDFファイルは、埋め込まれていないフォントを名前で参照できます。この場合、Acrobat Reader DCのようなPDFを表示するアプリケーションは、その環境で使用可能な場合であれば、それらのフォントを使用可能ですが、フォントのバージョンの差異によるグリフセットの相違やメトリクスの変更の影響を受ける可能性があります。
- PDFファイルには、使用する各フォントのフォント情報が含まれています。この情報にはフォントメトリクスとスタイル情報が含まれているため、PDFを表示するアプリケーションは必要に応じて適切な代替フォントを選択または合成できます。この場合、グリフの形状は意図したものとは異なりますが、各グリフは正確に配置されます。
フォント管理は、主にテキストの正しい外観、つまりグリフの形状と配置を生成することに関連します。ただし、PDFを取り扱うアプリケーションでは、Unicodeなどの標準的なエンコーディングで表されるテキストを抽出する必要がある場合があります。場合によっては、このテキスト情報はPDFファイルのテキスト表示に利用されるエンコーディングから推測できます。それ以外の場合、PDFを生成するアプリケーションは、特別なオブジェクトであるUnicodeに変化する際に利用するCMapを含め、キャラクターマッピングを明示的に指定する必要があります。
ワンパスでのファイル生成（2.2.4）
システム制限や効率の問題でアプリケーションプログラムがシングルパスでPDFファイルを生成することが望ましい場合があります。たとえば、プログラムで使用可能なメモリが限られていたり、一時ファイルを開くことができない場合があります。このため、PDFはファイルのシングルパス生成をサポートします。
一部のPDFオブジェクトはバイト単位で長さを指定する必要がありますが、長さがPDFファイル内のオブジェクトに追従できるメカニズムが提供されています。さらに、すべてのページが生成された後、ドキュメントのページ数などのinSECTION構成をファイルに書き込むことが可能です。
シングルパスで生成されたPDFファイルは、最適化が適用されない為フラグメンテーションが大きくなる傾向があり、特にネットワークを介してファイルのコンテンツにアクセスする場合等で、全体をダウンロードしなければページレンダリングが完了できない場合もあります。
繰り返し表示することを目的としたPDFファイルを生成する場合は、最適化を実行することをお勧めします。この処置はPDF構造をシリアライズ化する他、重複したグラフィクスオブジェクトを検出し共有シーケンスに統合するといった機能もあります。
ランダムアクセス（2.2.5）
PDFファイルは、オブジェクトの出現順序には重要な問題ではありません。任意の方法で相互に参照できるオブジェクトのコレクションで構成されるデータ構造のフラット化された表現と考えることもできます。一般に、PDFを表示するアプリケーションは、オブジェクトを順番に処理するのではなく、オブジェクトからオブジェクトへの参照をたどる事によってPDFファイルを処理します。これは、インタラクティブなドキュメント表示や、PDFファイル内のページやその他のオブジェクトに順不同でランダムにアクセスするアプリケーションにとって特に重要な事です。
個々のオブジェクトへのランダムアクセスをサポートするために、すべてのPDFファイルには、ファイル内のページやその他の重要なオブジェクトを見つけて直接アクセスするために使用できるクロスリファレンステーブルが含まれます。クロスリファレンステーブルは多くの場合ファイルの最後に保存されるため、ワンパスでPDFファイルを生成するアプリケーションにおいても容易に保存可能で、PDFファイルを読み取るアプリケーションは容易にに見つけることができます。クロスリファレンステーブルを使用することにより、ページまたは他のオブジェクトを見つけるために必要な時間はドキュメントの長さにほとんど依存せず、数百〜数千のページを含むPDFドキュメントにおいても効率的に意図したページにアクセス可能です。
セキュリティ（2.2.6）
PDFには、任意のドキュメントで個別にまたは一緒に使用できる2つのセキュリティ機能があります。
- ドキュメントは暗号化可能で、許可されたユーザーのみがアクセスできます。
- ドキュメントの所有者と他のすべてのユーザーには個別の承認があります。ユーザーのアクセスを選択的に制限して、表示、印刷、編集などの特定の操作のみを許可することが可能です。
- ドキュメントは、その信頼性を証明するためにデジタル署名することが可能です。署名には、公開鍵/秘密鍵で暗号化されたドキュメントダイジェスト、指紋などの生体認証署名など、さまざまな形式があります。署名されたPDFファイルに対する変更は、署名を無効にします。
インクリメンタルアップデート（2.2.7）
Acrobat Pro DC等のアプリケーションではPDFドキュメントを編集可能です。ユーザーは、ドキュメントへの変更が保存されるたびに、多数のページを含むファイル全体が更新されるのを待つ必要はありません。PDFは元のデータをそのままに変更部分をファイルに追加できます。ファイルが編集作業によって更新されるときに追加されるデータ領域は実際に追加または変更されたオブジェクトのみが追記され、その部分に該当するクロスリファレンステーブルが追加・更新されます。インクリメンタルアップデートを使用すると、編集アプリケーションは、ファイルのサイズではなく、変更のサイズに比例した時間でPDFドキュメントへの変更を保存可能です。
さらに、変更前の内容がファイルに残るため、変更領域を削除することで、保存された変更を元に戻すことができます。元のドキュメントの正確な内容を復元する機能は、デジタル署名が適用され、後で検証する必要がある場合に重要となります。
拡張性（2.2.8）
PDFは柔軟な拡張性を念頭に設計されています。新しい機能を追加できるだけでなく、以前のバージョンのPDFに基づくアプリケーションは、サポート不可能な新しい機能に遭遇したときに合理的に動作可能です。さらに、PDFは生成元アプリケーションが独自のデータ構造をPDFファイルに保存するための手段を提供します。この情報は、生成元アプリケーションによってインポートされたときに利用可能ですが、他のアプリケーションでは無視されます。例えば、Adobe IllustratorはPDFを書き出す際にネイティブの編集データであるPGFデータをPDFをに含めることが出来ます。そういったファイルは再度Adobe IllustratorがそのPDFを開く際に利用されますが、他のアプリケーションではその部分は無視され、PDFとして処理されます。このような特定のアプリケーション固有のデータは、PDFコンテンツストリーム内のグラフィックスオブジェクトに注釈を付けるマーク付きコンテンツとして、またはPDFコンテンツに接続されていない完全に別個のオブジェクトとして保存できます。
今回はここまでです。リファレンスに記述されているPDFの特徴などを中心に紹介しました。特に2.2に記述された特徴はPDFの構造や編集の際に何が起きているのかに関わる部分です。こういった情報が頭の片隅にのこっていればトラブルシューティングの際の一助になるかと思います。
