PDF出力を考える

PDFの直接出力

DTPの世界で、データのプリンタ出力を行うということは、とりもなおさずPostScriptのお世話になるということを意味します。PostScriptというのはプリンタ出力において印字内容を指示する命令（ページ記述言語と言う）です。データの制作現場で使われるプリンタから印刷機で使うプレートを出力するためのCTPにいたるまで、あらゆる出力機がPostScriptをサポートすることで、どんな環境でも同じ出力結果を得ることができる、というのがPostScriptの最大のメリットです。

アドビ社が開発したPostScriptが発表されたのは1984年、実際のデバイスに搭載されたのはその翌年で、Apple LaserWriterというプリンタでサポートされたのが最初です。当時、日本語にも対応していなかったPostScriptですが、その後Level 2でコンポジットフォントに対応、In-RIPセパレーション（RIP内部で分版する機能）をサポートするなど機能を強化、1997年に発表されたPostScript 3ではPostScript言語だけでなく、PDFデータのサポートも行われています。

PostScriptがPDFをサポートしたことで、出力環境にも大きな変化がもたらされることになりました。これまでの出力は、DTPデータをパソコンで開き、マシン上でPostScript言語に書き出してプリンタに送ると、プリンタ側はPostScript言語を解釈してデータ通りの印字を行うというものでした。

PDFは、PostScript技術を使って作られたデータフォーマットですが、プリンタ出力専用のデータではなく、画面表示が可能な文書データです。アドビがPDFとPostScript 3を開発したことで、ユーザーは、汎用文書ファイルであるPDFをパソコンで開いて閲覧することも、プリンタに直接送って出力することも可能になったのです。もちろん、この場合、画面での表示とプリンタの出力は完全に一致するというのがアドビの売り文句です。

PDFをプリンタに直接送って出力できるというメリットは、一般のDTPユーザーにはあまりピンとこないものかもしれません。データを出力するだけであればInDesign（インデザイン）などのアプリケーションから印刷コマンドを使って行うのが普通ですし、PDFを出力するにしてもAcrobatなどで開いてから出力すればいいからです。

ただし、高解像度出力を行う出力環境ではPDFの直接出力が活用されるようになってきました。たとえば、PrinergyやApogeeといった、「ワークフローRIP」と呼ばれる新しいRIPではPostScriptデータをいったんPDFにしてから出力するという方法が一般的になっています。

PostScript 3対応RIPでは、PostScriptデータを処理して出力することももちろん可能ですが、PDFを利用することでデータのチェックやRIP内での面付け処理などさまざまな機能を使うことができます。巨大なPostScriptデータをRIPに送り、そこで処理するよりも、データの軽いPDFで処理したほうが効率的ですし、柔軟な処理が可能なのです。

PDF入稿の可能性

PDFの直接出力に対応したシステムが普及してきたことで、出力現場へのデータ入稿のあり方も変わってきました。

これまでは、アプリケーションのデータがそのまま入稿され、それを出力オペレーターが同じアプリケーションで開いて印刷指示をかけるというのが一般的でした。しかし、RIP内でPDFが使われるのであれば、PDFを入稿してもかまわないわけです。

PDFには、ネットワーク入稿が容易になり、フォントの不一致などのトラブルを回避できるなどのメリットがあります。ただし、PDFになれば全てが解決するというわけではありません。

出力工程ではさまざまなトラブルが起きる可能性があります。アプリケーションのデータに比べると安全とされるPDFですが、それでも出力のトラブルが皆無になるという保証はないのです。

仮にPDFが入稿され、それを出力する際にトラブルが生じた場合、データのどこに問題があるのかを調べ、それを回避する処置を行うのは簡単ではありません。画像やフォントなどデータを構成する各部品が明確に分かれているDTPのアプリケーションデータと違い、フォントや画像を含めて全てのデータが一つにまとめられているPDFは、データの修正ひとつとっても制約があるのです。

最新のAcrobatやPitStop（Enfocus社が開発したAcrobatのPDF編集プラグイン）などを使えば、PDFのデータ検証や編集も可能ですが、それでも普通のアプリケーションデータと同じようにできるというわけではありません。

高度な安全性が求められる出力現場では、PDF入稿はなかなか受け入れられませんでした。出力に適さないデータが送られてきた場合に対応できる範囲が狭いからです。今でも、PDF入稿でありながらInDesignデータも合わせて入稿するというケースは少なからずあります。結局のところ、出力トラブルに対する責任が明確にならない限り、出力サイドとしてはPDFを100％信用するというわけにはいかないのかもしれません。

とはいえ、現実にPDFでの入稿は着実に増えています。トラブル発生時の対処に不安があるとはいえ、データの軽さや簡便さなどPDFのメリットは誰の目にも明らかなほど大きいのです。

PDF入稿が普及すればするほど、データを作る側も、できるだけ安全なPDFを作るためのノウハウを蓄積し、トラブルを最小限にする（完全にトラブルを排除することはいかなるシステムでも不可能と思われるが）対策を考えておく必要があるのではないでしょうか。

（田村　2007.2.26初出）

（田村　2016.11.4更新）