以下の文章を読んで、GDIについて1つだけ書いておくのも悪くないと思いした。
あまりに多くの常識が置き去りにされている時代なので。
念のために補足すると、ここで書くことは上記の文章からすれば全く筋違いの話です。単に私が書いておきたいと思っただけのことを書き留めるものです。ついでに言えば、一般のXMLデータを読みやすい書式にフォーマットする場合、現在のところPDFは最も有効なフォーマットだと認識していて、上記の文章を含むブログ「PDF 千夜一夜」が存在することは、とても良いことだと思います。
以上、補足終わり。
以下、上記文章の本筋と関係ない本文を書きます。
お断り §
何せ、昔の知識をろくに検証もしないで書いているので、間違っている可能性は大いにあります。まずあり得ないと思いますが、万一この知識を活用したいと思う場合は、きちんと裏付けを取ってください。
ちなみに、対象は主に16bit時代のWindows 2.1～3.0のGDI.EXE(GDI.DLL)とします。
(Windows 2.xまで、DLLの拡張子はEXEでした。念のため)
何が問題なのか §
上記の文章では、WindowsでPDFを作成する手段として、PostScriptプリンタドライバとGDI型PDFプリンタドライバが存在することが示されています。そして、GDI型PDFプリンタドライバでは、線の細さの情報が維持されない(同じ太さになってしまう)ケースがあることが示されています。この原因は、GDIを経由した時点で太さの情報が飛んでしまっているから……ということになります。おそらく、このような認識は間違っていないと思います。
しかし、GDI的にはアンフェアである §
上記のような問題は、GDIの立場からすれば、明らかなGDIの誤用によって発生したものだと言えます。それについて書きます。
GDIの役割 §
GDIの役割はいくつもありますが、極めて乱暴に短く要約すると、以下のようになります。
つまり、GDIとは物理的なディスプレイやプリンタの詳細から独立した描画モデルを提供するためのモジュールです。
ですから、以下のような形でデータが流れます。
アプリ→(論理描画データ)→GDI→(物理描画データ)→ディスプレイドライバやプリンタドライバ
論理描画データとは何か? §
さて、論理描画データの座標系は、デフォルトではMM_TEXT(値1が1ピクセルに対応する)となっていますが、実はサポートされている座標系でピクセル基準であるのはこれ1つしかありません。あとは全て論理的な座標系です。おそらく、MM_TEXT以外で最も多く使われると思われるのはMM_TWIPSだろうと推測しますが、これは値1が1/1440インチに相当する座標系です。つまり、1440dpiのデバイスに出力した際に値1が1ピクセルに相当する計算になる単位です。たとえ、最終的に出力するデバイスが、72dpiに過ぎず、これほど小さな値を扱えないとしても、論理描画データとしてはこれだけ小さな値を指定することができ、それは有効です。
物理描画データとは何か? §
物理デバイスのページサイズやピクセルの大きさなどにピッタリと適合する形に変換された描画データです。ここでの座標系は、ピクセルが主役となります。ピクセルとピクセルの中間に対する描画要求のように曖昧なものは含まれません。
つまり、72dpiのデバイスに出力するための物理描画データは、1/72インチより小さな値の相違は全て消失します。なぜ消失するかと言えば、デバイスが表現できない曖昧な情報を除去しているからです。
論理描画データを保存するメタファイル §
論理描画データは、通常はGDIのAPI呼び出しによってGDIに伝達されます。
しかし、一連のAPI呼び出しの内容を、実際に描画することなく、メタファイルと呼ばれるデータに記録することができます。
メタファイルは、論理描画データを保存を保存するデータ形式となります。
つまり、出力するデバイスに全く依存しない論理的な描画データの集合体を作成することができ、これはファイルに保存することも、通信で送ることもでき、全く見ず知らずのシステム上で、そのシステムで可能な最善の品質で表示、印刷することができます。つまり、メタファイルを作成したシステムに72dpiのデバイスしか接続されていないとしても、メタファイルを300dpiのデバイスが接続されたシステムでプレイバックすれば、それは300dpiで表示、印刷されるということです。
GDI型PDFプリンタドライバはどこで足を踏み外したのか §
GDI型PDFプリンタドライバは、ドライバの一種ですから、当然GDIから送られる物理描画データを受け取ります。このとき、GDI型PDFプリンタドライバがGDIに対して自己申告した解像度よりも小さな値は全てGDIによって取り除かれてしまいます。つまり、申告した解像度よりも細い線の太さの差は全て消失します。このような動作は、自己申告した解像度が実際のデバイスの解像度と同じであれば、非常にリーズナブルです。
さて、GDI型PDFプリンタドライバが上手く機能しない理由はもう明らかでしょう。特定の解像度に合わせた描画データを生成するモジュールの出力を受け取って、解像度の概念が存在しない論理的なデータであるPDFデータを生成しようと言う発想そのものが最初から間違っているのです。
GDI型PDFプリンタドライバとは、お手軽に便利に使えるから存在する代用品でしかなく、それに過大な期待をしてはいけないことになります。
実は、部分的にPDFと役割がかぶるメタファイル §
メタファイルとは初期のWindowsからサポートされた非常に基本的な機能ですが、あまり利用されている例に出会いません。(無いとは言わないが、BMPファイルなどと比較すると圧倒的に出会う頻度がひくい)
しかし、デバイスに依存しない論理的な描画データという意味では、PDFと似通った役割を持つ存在だと言えます。(機能は大幅に劣りますが)
今から考えると、なぜメタファイルが流行らなかったのかが何となく分かります。LANすらろくに普及していない時代、今画面に見えているものが即座にプリントアウトできることが乗り越えるべきハードルだったわけです。このような時代には、デバイスに依存しない描画データはアプリとGDIの間でほんの一瞬だけ存在すればよく、それをファイルに保存したり交換する必要性はほとんど発生しません。しかし、ネットワークが普及した今、不特定の相手に文書を送ろうと思ったら、相手がどのようなデバイスで見るか分からない以上、デバイスに依存しない描画データに強い存在意義が発生しています。
それを考えると、メタファイルは生まれるのが早すぎたPDFの原型のようなものと言えるのかもしれません。
(というのは、実は綺麗すぎるまとめ方で、実は歴史的にPostScriptや他のPDLなどと絡めて考えると、いろいろ深い話になりますが、それはここではナシ!)
