DTPでPDFを利用するメリットは、フォント埋め込みにあるが、なかなか信用されていないようで、最近は印刷会社の内部は1bit-TIFFが主流になりつつあるらしい。社内で出力ワークフローを組むときは、PDFではなく1bit-TIFFを選択するケースが多いようである。
　もちろん、これは印刷会社の内部的なフォーマットで、データを入稿したあとも社内で処理するときのものである。1bit-TIFFを利用すれば、その後データが変形するおそれがなく安心して利用できるというのが、大きな理由だろうか。
　もうすこし意地悪くいえば、1bit-TIFFでトラブッても、担当者の責任にはならないからだ。逆にいうと、そのくらい1bit-TIFFには安心感があるということだろう。

　むかしあるセミナーで「DTPでは20万字に1文字くらい文字化けの可能性がある」と聞いたことがあるが、おそらくそんなことはないだろう。もしそんな率で文字化けしていれば、DTPはとうに捨てられていたかもしれない。
　データをメディアからあるいはネットワークを通じてコピーするとき、データが劣化するおそれはある。送信受信時の不具合というより、書き込んだストレージが損傷していればデータも不良になるからだ。昔ほど、MOやCD、ハードディスクが壊れやすいわけではないので、そういう可能性は現在ではきわめて小さいといえる。
　出力データが不良化する可能性は、ほとんどないといえるが、PDFは基本的にテキストデータなので、データの一部が損傷すると文字化けのおそれがないわけではない。
　1bit-TIFFであれば、網点情報の一部が壊れるだけなので、実際に劣化は目立たない可能性が大きい。PDFを含めてドキュメントのネイティブデータの場合は、ファイルが開かないこともあるので、「どちらが安全か」ということになると、1bit-TIFFに分があるのは確かだろう。
　ただ私はとしては、1bit-TIFFは枯れきってしまったともいえるフォーマットなので、全くといっていいほど面白みを感じないのだ。そのうち、網点をスキャンして完璧なオリジナルデータに戻せるようになるかもしれないが、それももう少し時間がかかりそうである。
　いずれにしても、データを作る側からいうと、自分の都合のいいデータ形式で入稿したあとどのようなフォーマットで処理しようと、結果さえ付いてくればそれでいいのである。

　さて、印刷会社の内部フォーマットが1bit-TIFFになっても、印刷会社へのデータの入稿はジワジワとであっても、PDFが主流になるだろう。一度PDFに移行すると、元に戻ることはないからだ。PDFになれると、これほど便利なものはない。そのティッピング・ポイントはどこか、ということは私にはわからないが、それほど遠くないことも確かだろう。
　PDFを使うというのは、プリンタフォントがいらないということもあるが、出力時に複数のファイルフォーマットを考慮する必要がないことが、出力ワークフローでの生産性を高めるはずである。
　Illustratorの古いバージョンとQuarkXPress 3.3Jのみを使い続けるというのであれば、それはそれでもよいが、新しいアプリケーションと新しいバージョンにスムーズな対応していくためには、PDFというファイルフォーマットをクッションにする方が、結果としてはラクなはずである。その場合は、PDFの出力方法がわかっていれば、アプリケーションが変わろうとバージョンが新しくなろうと、ほとんどどのようなデータの出力にも対応できるからである。

　PDFのメリットは「フォントのダウンロード」だといったものの、それではこの「フォントのダウンロード」とはどのようなものだろうか。Mac OS Xのプリントセンターでは1バイトフォントを作成してしまうようだが、本当はどのようなことを指すのだろうか。
　そういえば、「フォントのダウンロード」についての詳しい技術的な解説を読んだことがなかったことを思い出した。いやあったかもしれないが、私の記憶にはないのである。
　Mac OS Xのプリントセンターで行うフォントのダウンロードと、AcrobatなどのAdobeのアプリケーションが行うフォントのダウンロードは同じものだろうか、それとも異なるものなのだろうか。やはり気になるところである。
　理屈しては、サブセット字形を1バイトフォントにしてPostScriptファイルに添付するというのはわかりやすいやり方だろう。今では1バイトフォントは、PostScript Type 1フォントもTrueTypeフォントも、プリンタにフォントを丸ごと転送して、あたかもプリンタフォントのように出力できるわけだから、それと同じ仕組みでプリントすることもできる。
　ただし、プリントセンターからPostScriptファイルを書き出してDistillerでPDFにすると、そうしてサブセット化されたと思われるフォトンファイル名がリストされてしまう。Adobe PSなどでPostScriptファイル化したときと明らかにフォントの扱いが異なるのである。Adobe PSなどでPostScriptファイルを作成する場合は、普通に使用しているフォント名がリストされるのである。

　Adobeの「フォントのダウンロード」はどうなっているのか、というのがやはり気になるところである。ということになると、それを調べるにはリファレンスを繰ってみるしかない。
　PostScriptオペレータが太字になっているこのPostScriptリファレンスマニュアルは、やはり手元になくてはならないものだ。ではあるが、私は技術者ではないので、斜め読みするのがやっとである。まあ書いてあることの半分も理解できないのだが、少しくらいは解答に近づけてくれるはずだ。
　そうして斜め読みすると、どうやら「フォントのダウンロード」というのは、フォント辞書をダウンロードすることらしい。フォント辞書ってなんだけっけと思い出しつつ、昔書いた本を広げてみた。「フォント攻略編」という本でフォント辞書のことを書いたことを思い出したのである。
　PostScriptのフォントの出力というのは、まず、フォントの情報をPostScriptファイルに書き込む。次にそれをRIPがフォント辞書に作り替えるのであった。フォント辞書はFontType、Encoding、FontMatrix、FontBBoxとフォントを展開していく。そして最後にビットマップイメージを作成するのである。FontTypeとEncoding情報からフォントファイルにアクセスして、字形データを取り出すわけで、このときにフォントファイルがプリンタに必要となるわけである。
　Acrobatの「フォントのダウンロード」というのは、本来RIPのインタープリタ（懐かしい言葉ですな、今では死語か）がするべきフォント辞書の作成を先に行ってしまい、RIPにダイレクトにフォント辞書を送りつけるのである。
　このとき、フォントから取り出す字形データも抱き合わせるわけである。つまり、字形データをもったフォント辞書があるので、プリンタフォントがなくても出力できるということのようだ。

　ちなみにIllustrator 9.0でフォントを含めたダウンロードしたPostScriptファイルと、含めないで作成したPostScriptファイルを比較すると、含めた方には「GlyphDirectory」というフォントをサブセット化し増分定義するオペレータが含まれており、その下にグリフデータとおぼしき文字列があるのだ。
　文字列の最初には正数の数字があり、これのCID値をみると、ちゃんとIllustratorで使用していた文字のグリフIDであった。
　Illustrator 9.0のPostScriptファイルの中身を見たとき、使用している日本語はシフトJISで表記されているようで、日本語で記述されているが、おそらくCMapでシフトJISからCIDに変換して字形にアクセスしているのだろう。
　なるほどなぁ、PDFはリッピングされたデータだというが、フォントの扱いもある程度RIPでの処理を肩代わりしていたわけである。
　ということは、フォントの埋め込みというのは、フォントファイルの埋め込みではなく、フォント辞書の埋め込みだったのである。
　それでは、TrueTypeの埋め込みはどうなっているのだろうか。それはみなさんが調べてみてはいかがだろうか。CMapで変換して利用していることは確かだと思うけどね。