PDFの構造について 2
前回の投稿の核心部分というのは2.1.2の「アドビイメージングモデル」というところです。「グラフィックアートから発展した2次元グラフィックスのシンプルで統一された表示機能です。」この部分なんですが「シンプルで統一された表示機能」という部分に集約されています。PDFにおいて一番大切なのはこの「表示」であり、どの端末においても確実に意図した表示にするための実装が最優先されます。各オブジェクトは表示の再現のために配置され、本来持っていた文書構造は担保されません。この事はPDFというフォーマットへの変換は不可逆である事を意味します。近年Acrobat等がOffice関連フォーマットへの変換機能を強力にプッシュしていますが、その機能自体もPDFの見た目から文字列の塊を段落として罫線が交差している部分は表だと認識して、それらの位置情報をもとにデータを再度作成しているのです。やってることは人間と一緒なのですが、レイアウトへの理解の深さという点では人間の判断には及ばない部分があるために複雑な構造のPDFを変換しても意図通りには変換してくれないのも当然な結果なのです。こういった特性に対して予備知識がないと使い物にならないといった印象になってしまうのも理解できます。あくまでもベストエフォートな機能であり、使い所をユーザーが適切に判断して利用するべきものなのです。
端から話がそれていますがファイルフォーマットに対する理解の深化というのは副次的にこういったセールストークに対する懐疑的な部分を確信に昇華してくれるものです。
ファイルフォーマットに限った話ではありませんが、正しい知識は物事を判断する重要な基準となります。また、対象が常に変化する場合において情報は「生鮮物」としての性質も持ちえます。わたし自身もしっかりと学び続けたいと思います。
ということで、続きに入ります。今回は２章の残りの部分についてです。
PDFの生成（2.3）
PDFファイルの生成は、アプリケーションプログラムによって直接作成される場合と、他のファイル形式またはイメージングモデルからの変換によって間接的に作成される場合があります。
PDFが規格化され一般化される過程で多くのアプリケーションがPDFを書き出しをサポートしました。多くのアプリケーションにおいてPDFファイルを直接生成可能で、一部のアプリケーションにおいてはそれらをインポートすることも可能となっています。
この直接的なアプローチは、イメージングモデル、インタラクティブ機能、ドキュメント交換機能など、PDFの全機能へのアクセスをアプリケーションに提供するため、望ましい方法です。PDFを直接生成しないアプリケーションにおいてもPDFプリンター等を利用することでPDF出力を間接的に生成できます。2つの主要な間接的な方法があります。
- アプリケーションは、Microsoft®Windows®のGDIやApple Mac OSのQuick-Drawなどのアプリケーションプログラミングインターフェイス（API）を呼び出すことにより、印刷可能な出力を記述します。プリンタドライバと呼ばれるソフトウェアコンポーネントがこれらの呼び出しを受け取り、解釈してPDF形式の出力を生成します。
- アプリケーションは、PostScript、PCL、HPGL、DVIなどの他のファイル形式で直接印刷可能な出力を生成します。これらはDistillerやdvi2pdfのような別の変換プログラムを通してPDFに変換されます。
これらの間接的な処理は多くの場合、既存のアプリケーションからPDF出力を取得する最も簡単な方法となります。しかし、API上の制限やテンポラリに展開されたデータの品質に依存する影響で、この手法では高レベルのAdobeイメージングモデルを最大限に活用できない場合があります。
WindowsおよびMacOSプラットフォームで利用可能なAdobePDFプリンターは、プリンタードライバーとして機能しオペレーティングシステムのAPIを介して実行中のアプリケーションプログラムによって生成されたグラフィックスやテキストを変換します。
AdobePDFプリンターではドキュメントをプリンターコマンドに変換して直接プリンターに送信する代わりに、PDFコマンドに変換し、PDFファイルに埋め込みます。その結果、プラットフォームに依存しないファイルが作成され、AcrobatなどのPDFビューアアプリケーションを利用することで、ファイルが作成された環境とは異なるデバイス上においても正しく表示および印刷が可能となります。
QuickDrawやGDIイメージングモデルの制限を受けるアプリケーションや、DOSやシステムレベルのプリンタドライバが存在しないUNIX®といった環境上で動作するアプリケーションの一部はAPI呼び出しを介して印刷可能な出力を記述する代わりに、PostScriptファイルを生成し、それをAcrobatDistiller®を使用してPDFファイルに変換できます
PostScriptとPDFは同じAdobeイメージングモデルを共有しているため、DistillerはPDFへの変換でPostScriptファイル上のグラフィックコンテンツを正確に変換可能です。さらに、Distillerはpdfmarkと呼ばれるPostScript言語拡張をサポートしており、作成アプリケーションは、ハイパーテキストリンク、論理構造、およびPDFの他のインタラクティブなドキュメントのインターエクスチェンジ機能を作成するための命令をPostScriptファイルに埋め込むことができます。
PDFとPostScript言語（2.4）
グラフィックスの状態を設定し、グラフィックスオブジェクトをペイントするためのPDFコマンドは、PostScript言語の対応するコマンドに似ています。しかし、PDFは効率と予測可能性を向上させるために柔軟性を捨てた為、PostScriptとは異なりプログラミング言語とは呼べなくなりました。PDFは以下の点でPostScriptとは異なります。
- PDFはアプリケーションが任意の順序でドキュメントの一部にアクセスできるランダムアクセス性を高めるための厳密に定義されたファイル構造を採用しました。
- コンテンツストリームの処理を簡素化するために、PDFには、プロシージャ、変数、制御構造などの一般的なプログラミング言語機能は含まれていません。
- PDFファイルには表示を忠実に再現するためのフォントメトクスなどの情報が含まれています。
- PDFファイルには、インタラクティブな表示用のハイパーテキストリンクやドキュメントインターエクスチェンジ用の論理構造情報など、イメージングモデルに直接関連しないメタ情報が含まれている場合があります。
この様な違いのため、通常PDFファイルをPostScript出力デバイスに直接送信して印刷することはできません。
PDFドキュメントをPostScriptデバイスに印刷するアプリケーションは、次の手順に従う必要があります。
- PostScriptプロシージャ定義を含むプロシージャセットを挿入して、PDFコマンドを実装します。
- 各ページのコンテンツを抽出します。各コンテンツストリームは、基本的に、movetoの場合はm、linetoの場合はlなど、非常に特殊な手順を使用する従来のPostScriptプログラムのスクリプト部分です。
- 必要に応じて、圧縮されたテキスト、グラフィックス、および画像データをデコードします。PDFで使用される圧縮フィルターは、PostScriptで使用される圧縮フィルターと互換性がありますが、出力デバイスがサポートするPostScript LanguageLevelによってサポートされる範囲は異なります。
- フォントなどの必要なリソースをPostScriptファイルに挿入します。これらは、PDFファイルのフォントメトリクスに基づいて、元のフォントまたは適切な代替フォントのいずれかを埋め込みます。フォントは、タイプ1やタイプ42など、PostScriptインタープリターが認識できる形式に変換する必要がある場合があります。
- データ構造を正しい順序に並べます。その結果、ドキュメントの視覚的表現を完全に表す従来のPostScriptプログラムが生成されますが、ハイパーテキストリンク、注釈、ブックマークなどのPDF要素は削除されます。
- PostScriptプログラムを出力デバイスに送信します。
以上で２章はおわりです。
PDF変換の際にどのような手順が行われているのかが解説されています。PDFのコマンドとい体系というのはPostScriptをベースにしていますから処理としては共通する部分が多くあります。これはターゲットとするイメージングモデルが共通である事も関係します。冒頭で書いたように双方ともページ記述に特化したものであり、文書を効率よく取り扱うよりはプリンター用紙またはディスプレイの平面上に正確に配置・表示する事に重きを置いて開発されたものです。
※この部分の記述も実は少し古臭くって、最近のプリンターはPDFネイティブだったりします。色々と注意は必要ですが基本的な部分と捉えて把握して頂ければ良いでしょう。