PostScript 言語は、強力なグラフィックス機能を兼ね備えたインタープリタ型のプログラミング言語なのである。すんなり読んでしまうところではあるが、PostScript はなんと「Basic の様なインタープリタ型のプログラム言語」なのである。PostScript 言語は FORTH とよく似ており、オペレータの前にオペランドを置く逆ポーランド記法を採用している。これがまた理解を難解なものにしている。
PostScript には、オペレータと呼ばれる組み込みの「コマンド」がビルトインされており、PostScript インタープリタはオペランドスタックに積まれたオペレータを順次ポップし消費していく。オペレータは、必要に応じ必要な数のオペランドをオペランドスタックから取り出し処理する。通常処理結果はオペランドスタックにプッシュされる。オペレータの中には、算術オペレータもあれば、if や for などの制御オペレータ、そして PDL として必須となる描画オペレータなど、実に様々なオペレータが存在する。これらのオペレターを駆使することにより、再帰を使った PostScript プログラムを書くことさえ可能であり、小さなプログラムで、面白い幾何学模様を作ることさえ出来る。
このように、プログラマーにはとても興味をそそる機能を持つ PostScript 言語ではあるが、OS に搭載される PostScript プリンタドライバの出力する PostScript プログラムには、あまり複雑なものは無い。プリンタドライバの生成する PostScript ファイルは、通常プロローグとスクリプトに分かれており、プロローグ部分では、PostScript の辞書機能を使い、Windwos GDI が使用する機能とのインターフェイスが取りやすいように、便利な手続きを独自の名前で登録する。実際のページ記述は、スクリプト部分で記載されているが、プロローグで登録した独自手続きの名前を多用しており、さらに手続きの中でその他の手続きを参照するなど、実に読みづらい。PostScript エラーの解析では、この解析に多くの時間がとられる。したがって、プリンタドライバが生成する PostScript ストリングスは、複雑ではないが実に難解だ。
このように、PostScript 言語で記載された印刷ジョブは、頭のプロローグの部分を処理しないと、ページ部分の記述を処理することが出来ない。またプロローグの定義は、その後のページ記述で置き換えることも可能であり、特定のページだけを処理するには、少なくともそれ以前のページを総て適正に消費することが必要となる。
1980 年代初頭に初代 PostScript が開発され、その後レベル 2 とレベル 3 という 2 つのメジャーな改訂が行われました。 Adobe Systems 社 (以降 Adobe) の尊敬すべき点は、いずれのバージョンにおいてもリファレンス・マニュアルを本で提供たことである(日本語版もある)。最初の PostScript リファレンス・マニュアルは、表紙が赤であった為、レッド・ブックという愛称でも呼ばれた。最新の PostScript リファレンスマニュアル第3版は背表紙が黒を基調としているのは、私的にはとても残念だ。Adobe は、初代 PostScript リファレンス・マニュアルと共に、チュートリアル&クックブック(ブルー・ブック)というイグザンプルを多く含んだ解説書と、PostScript プログラム・デザイン(グリーン・ブック)というプログラミングのテクニックを纏めた本、さらには、Adobe Type 1 Font Format Version 1.1 (ブラック・ブック(またはホワイト・ブック))という Type 1 フォント形式について解説した姉妹本を発行した。
PostScript Level 2 は、初代 PostScript のカラー拡張やコンポジットフォント拡張(OCF フォント)を取り込み、更に拡張したものである。CIE ベースのデバイス非依存カラースペースの対応も含まれている。PostScript 3 は、スムーズなシェーディング、CID フォントへの正式対応 (PostScript v2014 以前のものは、CSL (CID Support Library) を組み込むことにより対応可能)など、とても斬新な機能に対応し、多くの PostScript クローンベンダーを駆逐した。 しかしながら、PostScript は、現時点に至っても透過をサポートしていない。
PDF と PostScript は、同じ Adobe 社のイメージングモデルをベースにしているようである。PDF は PostScript 言語の大きな特徴でもあるプログラム能力は取り外された。 PostScript との大きな違いは、ページ毎に独立してアクセスできることである。ただし、PDF はページへのリンク情報が PDF の最後についており、基本的には PDF を一旦ファイルシステムに取り込んでから、RIP 処理を行うことになる。この点は、PostScript はファイルを受けながら処理(消費)ができるのに、残念だ。Adobe は、長い間 RIP 内部で PDF 形式を PostScript 形式に一度変換し、PostScript を処理していた。
PDF の機能は改訂を重ねるにつれ、次第に複雑なものとなり、PDF 1.4 で透過にも対応した。この時点で、上記変換プロセス(PostScript を中間ファイル形式とする)では透過に対応できないという大きな問題が露見した。しかしながら、長い間この問題は放置されてきた。 Adobe は、この問題に対処する為に、Adobe PDF Engine というものを開発し、PDF をネイティブに処理することにしたようだ。これにより、透過部分を分割・統合することなく処理が可能となった。この PDF のネイティブ対応は、これは何も画期的な機能ではなく、Harlequin RIP や Jaws RIP では初期の段階からネイティブに処理しており、むしろこの制約は Adobe の欠点とも言われていた。
現在、Adobe は、PDF 1.7 のフル仕様で、AIIM を通して ISO の標準化を進めている。国際標準なることは、PDF を生成するソフトウエアと PDF を処理するデバイス間での相互運用にとって好ましいことだ。 PDF にとっては、Acroabt Reader で開けるかどうかが唯一の、互換性の証明であり、実は仕様的におかしな、PDF も多く流通している。電子ドキュメントの形式は、囲い込みの時代からオープンな時代へと替わりつつあるようだ。
PostScript インタープリタは、言語仕様的にとても複雑で、私の知る限り天才的なプログラマーが開発している。また、その複雑さの為に、品質の高い PostScript プログラムを書き出すプリンタドライバの開発が難しく、また問題発生時に調査を行うのもひときわ困難なものであった。
※ 商標について
PostScript はAdobe Systems Incorporated の商標で、特定の法域で登録されている場合があります。
その他のブランド名および製品名は、各所有者の登録商標または商標です。