JP5772079B2 - 自動生成された変換を使う印刷システムにおける改善されたｊｄｆチケット処理の方法および構造 - Google Patents

Description

本発明は、概括的には、ジョブ定義フォーマット（JDF: Job Definition Format）ジョブ・チケットの処理のための印刷システムにおける処理を簡単にするための、印刷環境における、マッピング・ファイルからおよびプリンタ記述ファイルから生成されるデバイス・ポストスクリプト（PostScript）・テーブルの生成および使用を通じた、JDFジョブ・チケットの処理に関する。

プリントショップ（大小の印刷業者）、プロダクション印刷およびさらに小規模なワークグループ環境を含む多くの印刷環境において、特定の印刷ジョブを印刷するために必要とされる処理を記述するJDF情報を生成することが一般に知られている。JDFは、印刷プロセスの一般的なタスクのために使用されるべきキーワードおよびファイル構造の組、特に、ジョブ・チケットおよびデバイス機能ファイルの構成を定義する国際規格である。JDFは典型的には、オフィスや家庭での印刷に比べ印刷ジョブがより複雑であり要求が厳しいプロダクション印刷の分野で使用される。ジョブ・チケットは、印刷ジョブの処理のために必要なすべてのパラメータを含む。デバイス機能ファイルは、特定の装置上で利用可能な機能を記述し、テンプレートの役割もする。そのテンプレートから、実行可能であることが保証されたジョブ・チケットがその装置について生成できるのである（たとえば、コンピュータ・システムのプリンタ・ドライバまたは他の好適なコンテンツ生成プログラムによって生成される）。JDFジョブ・チケットおよびデバイス機能ファイルのフォーマットは、CIP4という機関（Cooperation for the Integration of Processes in Prepress, Press, and Postpress［印刷前・印刷・印刷後工程の統合のための協力］）によって文書「JDF仕様、リリース1.4」において記述されている。この規格は当業者にはよく知られており、規格に関する情報はwww.cip4.orgにて入手できる。

JDF規格とは対照的に、デジタル・プリンタ製造業者は一般に、その装置の機能および任意的な設定を記述するためにキーワードの組を使う。これらのキーワードはしばしば、JDF規格で機能を定義するために使われる名称および値とは異なっている。さらに、印刷システムの機能および設定を記述する選択されたキーワードはしばしば、異なる製造業者の間で変異があり、時には同じ製造業者によって生産される印刷システム・モデルの間でさえ変異がある。ポストスクリプト・プリンタの場合、特定のプリンタに固有の情報はポストスクリプト・プリンタ記述（PPD: PostScript Printer Description）ファイルとして製造業者によって公表される。PPDファイルは、アドビ・システムズ社（Adobe Systems, Inc.）による文書「ポストスクリプト・プリンタ記述ファイル・フォーマット仕様（PostScript Printer Description File Format Specification）」において記述される標準的な統辞法〔シンタックス〕および文法〔グラマー〕を有する。PPDの統辞法および文法は当業者にはよく知られており、PPDの統辞法および文法に関する背景情報はwww.adobe.comにて入手できる。

そのような製造業者が供給するPPDファイルにおける機能名は、JDF規格に基づく機能名とは直接一致しないことがありうる。よって、JDF機能とプリンタ機能との間の変換プロセスが必要とされる。現行の解決策は、JDFと製造業者の機能および設定値の間の乖離を、印刷システム外部のホスト・ベースのコントローラにおいてジョブ・チケットおよびコンテンツ・ファイルを処理することによって埋めている。この処理は、どのデバイス制御関数が、与えられたJDFジョブ・チケットによって必要とされているかを判定し、次いでそれらのデバイス制御関数についての対応するコマンド・シーケンスをコンテンツ・ファイルと組み合わせて一時印刷ファイルを生成する。この一時印刷ファイルは次いで印刷システムに送られ、もとのジョブ・チケットおよびコンテンツ・ファイルによって指定される出力が生成される。適切なコマンド・シーケンスを決定し、それらを印刷されるべきコンテンツと正しく組み合わせる工程は、オンザフライでPPDファイルを読むか、PPDデータがハード的に組み込まれている（hard-coded）ホスト・ベースのアプリケーションによって実装されうる。そのようなアプリケーションは、コンテンツ内の適切な点にコマンド・シーケンスを挿入するため必要に応じてコンテンツ・ファイルを書き換える自由をももつ。

いくつかの印刷システムは、JDFジョブ・チケットおよび対応するコンテンツ・ファイルを直接受け取る処理機能を含んでいてもよく、印刷システム自身の処理機能内でジョブ・チケットを処理してもよい。そのような場合、中間的なコントローラはなく、一時印刷ファイルも生成されない。ジョブ・チケットの構文解析〔パース〕および適切なデバイス・コマンド・シーケンスの決定は、印刷システムによって（すなわち、印刷システムのプリンタ・コントローラによって）実行されねばならない。

JDFジョブ・チケットを直接処理するそのような印刷システムでは問題が生じることがある。

ジョブ・チケットは、クライアント（たとえば、ドライバおよび／またはアプリケーション・プログラム）によって生成されねばならない。これはチケットを、印刷システム上で利用可能な機能のJDF等価物に制限する。さらに、クライアントは、印刷システムによって処理されるべきジョブ・チケット中の機能の組み合わせに対するいかなる制約も守るよう注意を払うべきである。機能および／または設定のある種の組み合わせは、特定の印刷システムにとっては処理できないことがありうる。ジョブ・チケットを生成するホスト・ベースのクライアント・アプリケーションと該チケットを処理するプリンタ・ベースのJDFインタープリタとでは、アプリケーション・ユーザーが信頼できる形で期待した印刷出力を得るために使うJDF要素および属性のデバイス機能へのマッピングが同じでないことがありうる。さらに、クライアントおよび印刷システムは、デバイス・コマンドによって実装されない機能について一致しないことがありうる。たとえば、ページ・コンテンツ・スケーリングおよび変換は、いくつかの印刷システムではポストスクリプト手順によって実装されることがあるが、他の印刷システムではそうでないこともある。

JDFジョブ・チケットは、文書の異なるセクションについて異なる属性を指定することがある。そのようなセクション固有のJDF属性（特徴）がデバイス・コマンドおよびポストスクリプト手順に変換されるとき、その文書の印刷の間に印刷システム上で実行される必要があるデバイス・コマンドが二組以上あることがある。さらにまた、文書の特定のセクションに対応する特定のコマンドの組がいつ実行されるべきかを決定するために、入力ページ記述および出力の印刷されたシートの適正なアカウンティング〔追跡〕が必要である。

印刷ジョブ内の同じ点において複数のコマンドが必要とされるとき、それらのコマンドが印刷システム上で実行されるべき順序が決定的に重要なことがある。そのような順序付け情報は、典型的には、印刷システムのコントローラには一般にアクセスできないPPDファイル内の情報から決定される。

ジョブ・チケットは、デバイスが特定の構成にあること、あるいは任意的なアクセサリーがインストールされていることを要求することがある。デバイス構成は典型的には、本解決策では、印刷システムに適用されPPDファイル――またもや印刷システムにとっては一般に利用可能でない――において提供される問い合わせコードを使うことによって検査される。

ジョブ・チケットの属性は、JDF規格によればかちあわなくてもデバイス・コマンドに変換されると印刷システムによって禁止されているコマンドの組み合わせを生じることがありうる。そのような禁止は、典型的にはPPDファイル内――またもや印刷システムにとっては一般に利用可能でない――の制約文によって定義されている。

印刷システム内でJDFジョブ・チケットを処理することは、上記およびその他の問題を呈するものの、多様な理由により、そうすることはやはり望ましい。パフォーマンス上の理由により、印刷システムがポストスクリプト・コンテンツをオリジナルの形で受け入れることが望ましいことがよくある。これは、ホスト・ベースのクライアント・アプリケーションから、コンテンツ・ファイルによってはきわめて大きなものとなることがある一時印刷ファイルを書く必要を軽減する。こうして、ジョブを印刷システム内で処理することによって、クライアント・アプリケーションは制御を素速くユーザーに返したり、あるいはすぐにプリンタ状態のモニタリングを開始したりすることができる。他のパフォーマンス上の理由により、印刷システムがコンテンツ・ファイルを受け取るとき、コンテンツを、印刷システムに結合されたディスク・ドライブ上の一時ファイルに書き出すのではなく、入力チャネルからの直接のコンテンツを処理することが好ましい。この型の処理が達成できるのは、コンテンツ・ファイルに含まれるページを並べ替える必要がない場合のみである。そのような並べ替えは、印刷システムがジョブ・チケット特徴に基づいて実行されるべき完全なジョブの知識を持つことに基づく。

よって、印刷ジョブの印刷の際のジョブ・チケット処理の柔軟性および忠実性を維持しつつ上記の最適化を実現する印刷システムを提供することは、いまだ未解決の課題である。より一般には、印刷システム内でJDFジョブ・チケットおよび関連する印刷ジョブ・データを堅牢かつ効率的に処理することは、いまだ未解決の課題である。

本発明は、印刷システム内でのJDFジョブ・チケットの処理を改善するためにデバイス機能ファイルおよびデバイス・ポストスクリプト・テーブルを生成および利用するための方法および関連する構造を提供することによって、上記およびその他の問題を解決し、それにより有用な現状技術を進歩させる。本発明の特徴および側面は、デバイスについてのPPDファイル内の情報からおよびマッピング・ファイルからデバイス機能ファイルおよびデバイス・ポストスクリプト・テーブルを生成する。デバイス機能ファイル〔デバイス能力ファイル〕（device capability file）は、JDFジョブ・チケットを生成するために使用されうる。デバイス・ポストスクリプト・テーブル（device PostScript table）は印刷システムにおいて、JDFジョブ・チケット内の要素を対応するデバイス・コマンド・ストリングに変換するためのルックアップ・テーブルとして使われる。本発明の任意的な特徴および側面は、プリンタ記述ファイル（printer description file）からおよびマッピング・ファイル（mapping file）から制約情報を生成する。制約情報（constraint information）は、ジョブ・チケットを生成するコンピューティング・システムにおいて、および／または印刷システムにおいて、JDFジョブ・チケットを有効確認する（validate）ために使われてもよい。ある例示的な実施形態では、デバイス・ポストスクリプト・テーブルおよび制約情報は、ポストスクリプト辞書としてポストスクリプト印刷システムにおいて生成され、JDFジョブ・チケットの処理はポストスクリプト・プログラムとして実装されてもよい。

本発明の一つの側面は、印刷システム上で印刷ジョブを印刷する方法を提供する。本方法は、印刷システムについてのプリンタ記述ファイルを提供することを含む。プリンタ記述ファイルは複数のエントリーを含み、各エントリーはデバイス機能名〔デバイス・フィーチャー名称〕（device feature name）およびデバイス機能設定名〔デバイス・フィーチャー設定名称〕（device feature setting name）と対応するデバイス・コマンド・ストリングとを関連付ける。本方法はさらに、複数のエントリーをもつマッピング・ファイルを提供することを含み、各エントリーは、一つまたは複数のジョブ定義フォーマット（JDF）機能名を一つまたは複数のデバイス機能名に、および一つまたは複数のデバイス機能設定名にマッピングし、コンピューティング・システムにおいてプリンタ記述ファイルおよびマッピング・ファイルに基づいてデバイス機能ファイルを生成することを含む。デバイス機能ファイルは、複数のジョブ定義フォーマット（JDF）機能名のそれぞれを、対応する一つまたは複数のデバイス機能設定名に関連付ける。本方法はまた、プリンタ記述ファイルおよびマッピング・ファイルに基づいてデバイス・ポストスクリプト・テーブルを生成することも含む。デバイス・ポストスクリプト・テーブルは、一つまたは複数のJDF機能名を一つまたは複数のデバイス機能設定名と、および前記一つまたは複数のデバイス機能設定名に対応する一つまたは複数のデバイス・コマンド・ストリングと関連付ける。本方法はさらに、コンピューティング・システムにおいて、デバイス機能ファイルに基づいて印刷ジョブについてのJDFジョブ・チケットを生成し、該JDFジョブ・チケットおよび印刷ジョブに関連する印刷ジョブ・データを、コンピューティング・システムから印刷システムに送信することを含む。本方法はまた、印刷システム内で、デバイス・ポストスクリプト・テーブル内のエントリーに基づいて、JDFジョブ・チケットのエントリーを、対応するデバイス・コマンド・ストリングに変換し、印刷システム内で、前記対応するデバイス・コマンド・ストリングおよび前記印刷ジョブ・データを実行して当該印刷ジョブについての印刷された出力を生成することも含む。

本発明のもう一つの側面は、印刷ジョブに関連付けられたジョブ定義フォーマット（JDF）ジョブ・チケットを処理するためのポストスクリプト印刷システム・コントローラにおいて動作可能な方法を提供する。本方法は、ポストスクリプト印刷システム・コントローラ内に記憶されているデバイス・ポストスクリプト・テーブルを提供することを含む。デバイス・ポストスクリプト・テーブルは複数のエントリーをもち、各エントリーは一つまたは複数のJDF機能名およびJDF設定名を、所望のJDF機能を呼び出すために印刷システム・コントローラによって実行されるべきデバイス・コマンド・ストリングにマッピングする。本方法はさらに、JDFジョブ・チケットおよび関連する印刷ジョブ・データを受け取ることを含む。ここで、JDFジョブ・チケットは一つまたは複数のJDF要素を有し、それぞれが所望されるJDF機能名および所望されるJDF機能設定名を指定し、一つまたは複数の所望されるJDF機能名および一つまたは複数の所望されるJDF機能設定名に基づいてデバイス・ポストスクリプト・テーブル内にエントリーを位置特定する。本方法はさらに、位置特定されたエントリーの値フィールドを処理して一つまたは複数のデバイス・コマンド・ストリングを生成し、前記一つまたは複数の生成されたデバイス・コマンド・ストリングおよび印刷ジョブ・データを処理して印刷された出力を生成することを含む。

本発明のさらにもう一つの側面は、コンピューティング・システムを有するシステムを提供する。コンピューティング・システムはさらに、複数のエントリーをもつマッピング・ファイルを有し、各エントリーは、一つまたは複数のジョブ定義フォーマット（JDF）機能名を一つまたは複数のデバイス機能名に、および一つまたは複数のデバイス機能設定名にマッピングする。コンピューティング・システムはさらに、対応する印刷システムの利用可能なデバイス機能名およびデバイス機能設定名に関する情報を含むプリンタ記述ファイルと、前記プリンタ記述ファイルを受け取るよう結合された印刷システム初期化コンポーネントとを有する。印刷システム初期化コンポーネントは、プリンタ記述ファイルおよびマッピング・ファイルに基づいてデバイス機能ファイルを生成するよう適応されている。デバイス機能ファイルは、一つまたは複数の利用可能なデバイス機能設定名を一つまたは複数の対応するJDF機能名と関連付けるエントリーを有する。印刷システム初期化コンポーネントはさらに、プリンタ記述ファイルおよびマッピング・ファイルに基づいてデバイス・ポストスクリプト・テーブルを生成するよう適応されている。デバイス・ポストスクリプト・テーブルは、一つまたは複数のデバイス機能設定名および一つまたは複数の対応するJDF機能名を、印刷システムによって実行されたときにデバイス機能設定名を呼び出す一つまたは複数のデバイス・コマンド・ストリングと関連付けるエントリーを有する。初期化コンポーネントはさらに、デバイス・ポストスクリプト・テーブルを印刷システムに送信するよう適応されている。コンピューティング・システムはさらに、デバイス機能ファイルを受け取るよう結合されたジョブ生成器コンポーネントを有する。ジョブ生成器コンポーネントは、ユーザー入力に基づいて、かつデバイス機能ファイル中の情報に基づいて、JDFジョブ・チケットを生成するよう適応されている。ジョブ生成器コンポーネントはさらに、生成されたJDFジョブ・チケットおよび関連する印刷ジョブ・データを対応する印刷システムに送信するよう適応されている。デバイス・ポストスクリプト・テーブルに従って印刷された出力を生成するためである。

すべての図面において同じ参照符号は同じ要素または同じ型の要素を表す。

本願の特徴および側面に基づいて向上された、JDFジョブ・チケットの改善された処理のためにデバイス・ポストスクリプト・テーブルおよび任意的な制約情報を利用する例示的なシステムのブロック図である。 本願の特徴および側面に基づいて向上された、JDFジョブ・チケットの改善された処理のためにデバイス機能ファイル、デバイス・ポストスクリプト・テーブルおよび任意的な制約情報を生成および利用するために与えられたプリンタ記述ファイルおよびマッピング・ファイルを利用する、もう一つの例示的なシステムのブロック図である。 本願の特徴および側面に基づく、JDFジョブ・チケットの改善された処理のためにデバイス機能ファイル、デバイス・ポストスクリプト・テーブルおよび任意的な制約情報を生成および利用するために与えられたプリンタ記述ファイルおよび与えられたマッピング・ファイルを利用する、例示的な方法を描いたフローチャートである。 図１ないし図３の方法およびシステムにおいて使用されるマッピング・ファイルの例示的な構造を記述するブロック図である。 本願の特徴および側面に基づく、JDFジョブ・チケットの改善された処理のためにデバイス機能ファイル、デバイス・ポストスクリプト・テーブルおよび任意的な制約情報を生成および利用するために与えられたプリンタ記述ファイルおよび与えられたマッピング・ファイルを利用する、もう一つの例示的な方法を描いたフローチャートである。

図１ないし図５および以下の記述は、当業者に本発明をいかにして作成・使用するかを教示するために本発明の個別的な例示的実施形態を記載する。本教示の目的のため、本発明のいくつかの通常の側面は単純化または省略している。当業者は、本発明の範囲内にはいるこれらの実施形態からの変形を認識するであろう。当業者は、以下に記述される特徴をさまざまな仕方で組み合わせて本発明の多数の変形を形成できることを認識するであろう。よって、本発明は、以下に記述される個別的な実施形態に限定されるものではなく、請求項およびその等価物によってのみ限定される。

図１は、本願の特徴および側面に基づいて向上された、印刷システム内でのJDFジョブ・チケットの変換のための改善された処理を提供し、任意的にジョブ・チケットの有効確認を提供する、例示的なシステム１００のブロック図である。システム１００は、コンピューティング・システム１５０および印刷システム１０６を含む。コンピューティング・システム１５０は、JDFジョブ・チケット１０２および関連する印刷ジョブ・データ１０４を含む印刷ジョブを生成するよう適応されている。コンピューティング・システム１５０は、印刷ジョブを、処理してもらうために印刷システム１０６に送信する。その結果、印刷ジョブ出力１１８（たとえば、所望の印刷可能媒体基質に適用されたフォーマットされた印刷ジョブ・データ）が生じる。

印刷システム１０６は、マーキング・エンジン１１６を含んでいてもよい。マーキング・エンジン１１６は、電子写真式マーキング・エンジン、インクジェット・マーキング・エンジンまたは一連のページ・イメージを紙などの印刷可能な媒体上に印するよう適応された他の任意の装置であってもよい。印刷システム１０６は印刷ジョブ（チケット１０２およびデータ１０４）をコンピューティング・システム１５０から受信し、印刷ジョブを処理してマーキング・エンジン１１６に加えられるページ・イメージを生成する。次いでマーキング・エンジン１１６が生成されたページ・イメージを所望される印刷可能媒体上に印して出力１１８を生成する。

印刷システム１０６はプリンタ・コントローラ１０８を含む。コントローラ１０８は、受け取った印刷ジョブを処理するよう適応された任意のコンピューティング・デバイスであってよく、典型的には処理装置（たとえば図示しないCPU）およびメモリ１１２を含む。メモリ１１２はいかなる好適なメモリ・デバイスであってもよく、たとえば磁気または光ディスク・ドライブ、DRAM、SDRAM、静的RAM、フラッシュ・メモリまたは印刷ジョブの処理において使用される情報を記憶するのに好適な他の任意のメモリ・デバイスを含みうる。ある例示的な実施形態では、印刷システム１０６は、ポストスクリプト印刷システムであり、プリンタ・コントローラ１０８はポストスクリプト・コマンド・ストリングを解釈するよう適応されたポストスクリプト・プリンタ・コントローラである。

プリンタ・コントローラ１０８は、コンピューティング・システム１５０からJDFジョブ・チケット１０２を受け取るよう適応され、JDFジョブ・チケットの属性／要素（たとえば、JDF機能および機能設定）を解釈して対応するデバイス・コマンド・ストリングを生成するよう適応されたJDFジョブ・チケット処理コンポーネント１１０を含んでいてもよい。上記で一般的に論じたように、JDFジョブ・チケット内の要素または機能は、機能名と、名付けられた機能についての設定についての設定名とを含む。さまざまな利用可能な設定の一つが、ジョブ・チケットの各要素についての所望されるデバイス機能設定名として選択されてもよい。一般に、JDFジョブ・チケット処理コンポーネント１１０は、受け取ったJDFジョブ・チケット１０２から各要素を取得し、そのJDF要素を、メモリ１１２に記憶されているデバイス・ポストスクリプト・テーブル１２０の内容に基づいて、対応するデバイス・コマンド・ストリング（たとえば「デバイス制御ストリング」）に変換するよう適応されている。後述するある例示的な実施形態では、デバイス・ポストスクリプト・テーブル１２０はポストスクリプト辞書として実装される。そのような実施形態では、「変換」は、ポストスクリプト辞書において特徴名を表すキー値を見つけ出すことによって実行される。そのように位置特定された辞書エントリーは、そのエントリーに関連付けられたデバイス制御ストリング（単数または複数）を提供する（たとえば位置特定されたエントリーの値から導出される）。変換によってそのように生成された（たとえば、ポストスクリプト辞書検索によって同定された）デバイス・コマンド・ストリングは次いで、印刷ジョブ・データ１０４において具現されているデバイス・コマンド・ストリング（たとえば「ページ・イメージ・データ」）とともに、印刷コントローラ１０８内の印刷ジョブ処理コンポーネント１１４に加えられる。印刷ジョブ処理コンポーネント１１４は、そのようなすべてのデバイス・コマンド・ストリング（たとえば、デバイス制御ストリングおよびページ・イメージ・データ）を処理して、マーキング・エンジン１１６への印加のために所望されるページ・イメージを生成する。さらに、印刷ジョブ処理コンポーネント１１４は、デバイス・コマンド・ストリングの互いに対する、また印刷ジョブ・データ１０４に対する適正な順序付け／シーケンスを保証して、ジョブ・チケット１０２および印刷ジョブ・データ１０４によって定義される適正な出力を生成するよう適応される。

ある例示的な実施形態では、プリンタ・コントローラ１０８は、メモリ１１２に記憶された制約情報１２２をも含む。JDFジョブ・チケット処理コンポーネント１１０はさらに、制約情報１２２を利用して、ジョブ・チケット１０２内のJDF要素の何らかの特定の組み合わせが、JDF要素のそのような組み合わせが印刷システム１０６上で呼び出すことができないという衝突につながるかどうかを判定する。よって、制約情報１２２は、JDFジョブ・チケット処理コンポーネント１１０によって、JDFジョブ・チケット１０２の要素を有効確認するために使用されうる。JDFジョブ・チケット処理コンポーネント１１０の有効確認処理がJDFジョブ・チケット１０２の特定のJDF要素における衝突を検出する場合、与えられた印刷ジョブがうまく処理できない理由を示すエラー信号が生成されてもよい。そのようなエラー信号は、たとえばコンピューティング・システム１５０にエラー・メッセージを返すこと、あるいはたとえば遭遇したエラー／衝突の性質を記述するエラー・インジケータ・ページを生成および印刷することを含んでいてもよい。後述するある例示的な実施形態では、制約情報は、ポストスクリプト辞書として実装される（デバイス・ポストスクリプト・テーブル１２０の一部として、あるいは別個の辞書データ構造として）。そのような実施形態では、機能名および／または機能設定名を表す一つまたは複数のキー値は、機能および設定名に関係する制約を指定する辞書のエントリーを位置特定するために使用される。位置特定された制約情報エントリーは次いで、印刷システム１０６についての衝突を生じるジョブ・チケット内に指定されている他の機能または設定名を判別するために使用される。より一般には、制約情報１１２は、JDF機能名およびJDF機能設定名の互いに相容れない〔両立できない〕グループを同定する。

プリンタ・コントローラ１０８がポストスクリプト・プリンタ・コントローラである例示的な実施形態では、JDFジョブ・チケット処理コンポーネント１１０および印刷ジョブ処理コンポーネント１１４は、ポストスクリプト・プリンタ・コントローラ１０８のポストスクリプト・インタープリタ（図示せず）の解釈によって実行されるポストスクリプト・プログラムとして実装されてもよい。そのような実施形態では、メモリ１１２は、デバイス・ポストスクリプト・テーブル１２０および任意的な制約情報１２２を記憶するための、かつポストスクリプト・プログラム・コマンド・ストリングと、JDFジョブ・チケット処理コンポーネント１１０および印刷ジョブ処理コンポーネント１１４の実行によって利用および生成される中間データとを記憶するための、ポストスクリプト・インタープリタによって利用および管理されるポストスクリプト・ダイナミック・メモリであってもよい。印刷システム１０６がポストスクリプト印刷システムではない他の例示的な実施形態では、プリンタ・コントローラ１０８内で動作可能なJDFジョブ・チケット処理コンポーネント１１０および印刷ジョブ処理コンポーネント１１４は、その特定のプリンタ・コントローラ１０８の機能に従って好適にプログラムされた命令として実装されてもよい。同様にして、メモリ１１２内のデバイス・ポストスクリプト・テーブル１２０および任意的な制約情報１２２（そのような非ポストスクリプト実施形態での）は、当業者には一般に既知の任意の好適なルックアップ・テーブルまたは配列データ構造として実装されてもよい。

ある例示的な実施形態では、デバイス・ポストスクリプト・テーブル１２０および任意的な制約情報１２２は、コンピューティング・システム１５０によって生成され、コンピューティング・システム１５０から印刷システム１０６に、プリンタ・コントローラ１０８による使用のために送信されてもよい。後述するように、デバイス・ポストスクリプト・テーブル１２０および任意的な制約情報１２２は、プリンタ記述ファイルおよびマッピング・ファイル（図１には示さず）内の情報に基づいて生成される。

当業者は、システム１００および印刷システム１０６における数多くの追加的なおよび等価な要素を容易に認識するであろう。そのような追加的なおよび等価な要素は、議論の簡明のため、ここでは省略する。

図２は、印刷システム１０６への送信のためのファイルを生成するよう適応されたコンピューティング・システム１５０の例示的な追加的詳細を与えるブロック図である。印刷システム初期化コンポーネント２５０は、与えられたプリンタ記述ファイル２００（たとえば、ポストスクリプト印刷システムのコンテキストではPPDファイル）から情報を取得する。プリンタ記述ファイル２００内の情報は一般に、対応する印刷システム１０６および関連するデバイス・コマンド・ストリングにおいて利用可能な可能なオプション設定のそれぞれについてデバイス機能設定名を含む。たとえば、ポストスクリプト印刷システムのコンテキストにおいて、PPDファイルは、両面印刷オンまたはオフ、給紙トレイ・オプション設定、排紙トレイ・オプション設定などといったさまざまなオプションを示してもよい。PPDファイル２００内の各デバイス機能設定名について、対応するデバイス・コマンド・ストリングがそれに関連付けられており、印刷ジョブについての関連付けられた所望されるオプションを与えるために印刷システム１０６によって実行されるべき特定のデバイス・コマンドを与える。

さらに、プリンタ記述ファイル２００は、対応する印刷システム１０６上で印刷ジョブを処理する際に一緒に呼び出せないデバイス設定機能名の特定の組み合わせを指定する制約情報を含んでいてもよい。たとえば、両面印刷機能は、印刷のために給紙トレイから封筒が選択されることを指定する他の機能とは両立しない。そのような場合、プリンタ記述ファイル２００は、そのような機能の組み合わせが、印刷システム１０６に送られるべき有効な印刷ジョブにおいては一緒に呼び出せないことを示す制約指定を含んでいてもよい。

印刷システム１５０はマッピング・ファイル２０４をも含む。マッピング・ファイル２０４は、JDFの機能および設定の名付け規約と、製造業者のPPDファイル２００における機能および設定名との間の変換を支援するために、PPDファイル２００との関連で使用される。マッピング・ファイル構造およびその使用の詳細は後述する。

プリンタ記述ファイル２００およびマッピング・ファイル２０４内の情報に基づいて、印刷システム初期化コンポーネント２５０は、JDFで定義された規格に基づくデバイス機能ファイル２０２を生成してもよい。デバイス機能ファイル（device capability file）２０２は一般に、所望される印刷ジョブを生成するためにユーザーに呈示されるべき印刷システム１０６のための利用可能なデバイス機能設定名のリストを与える。プリンタ記述ファイル２００から導出されるそれぞれの利用可能なデバイス機能設定名は、デバイス機能ファイル２０２内の適切なフォーマットに変換されてもよい。印刷ジョブ生成器２５２が、特定の印刷ジョブに適用されるべき特定のオプションを定義するために、ユーザーと対話するために使用するためである。ある例示的な実施形態では、印刷システム初期化コンポーネント２５０は、デバイス機能ファイル２０２中の情報を生成する。その情報とは、印刷記述ファイル２００内に位置される一つまたは複数のデバイス機能設定名を、一つまたは複数の対応するJDF機能名と関連付けて、それにより印刷ジョブ生成器２５２が、対応する印刷ジョブ・データ１０４を印刷するときに適用されるべき特定の機能設定を指定するJDFジョブ・チケット１０２を生成できるようにする情報である。生成されたデバイス機能ファイルの例については後述する。印刷ジョブ生成器２５２は次いで、ユーザー・インターフェースにおいて、印刷システム１０６の利用可能な特徴／機能のみを呈示して、ユーザーが所望のオプションを選択できるようにしてもよい。印刷ジョブ生成器２５２は次いで、関連する印刷ジョブ・データ１０４の印刷のためのJDFジョブ・チケット１０２中に適切なJDF要素を生成する。

ある例示的な実施形態では、印刷システム初期化コンポーネント２５０はまた、一緒に利用できないJDF機能の組み合わせを指定する、デバイス機能ファイル２０２内の制約情報２０６をも生成してもよい。制約情報２０６の例示的な追加的詳細については後述する。

ある例示的な実施形態では、印刷システム初期化コンポーネント２５０は、プリンタ記述ファイル２００およびマッピング・ファイル２０４中の情報を利用して、デバイス・ポストスクリプト・テーブル１２０を生成してもよい。デバイス・ポストスクリプト・テーブル１２０は、印刷ジョブ生成器２５２によって生成されるJDFジョブ・チケット１０２において与えられうる各機能についてのエントリーを含んでいてもよい。それらのエントリーは、次いで、印刷システムにおいて、JDF機能設定を対応するデバイス・コマンド・ストリングに変換するために使用されてもよい。

もう一つの例示的な実施形態では、印刷システム初期化コンポーネント２５０はまた、プリンタ記述ファイル２００およびマッピング・ファイル２０４中で与えられる制約情報に基づいて、制約情報１２２を生成してもよい。制約情報１２２の例示的な追加的詳細については後述する。

印刷システム初期化コンポーネント２５０によってそのようにして生成されたデバイス・ポストスクリプト・テーブル１２０および任意的な制約情報１２２は次いで印刷システム１０６に送信されてもよい。

図１を参照して上記したように、印刷システム１０６は、コンピューティング・システム１５０内の印刷ジョブ生成器２５２によって生成されたJDFジョブ・チケット１０２および印刷ジョブ・データ１０４を受け取り、デバイス・ポストスクリプト・テーブル１２０に従って、また任意的には制約情報１２２に従って、関連する印刷ジョブを処理する。

当業者は、コンピューティング・システム１５０内の数多くの追加的および等価な要素を容易に認識するであろう。そのような追加的なおよび等価な要素は、議論の簡明のため、ここでは省略する。

図３は、印刷システム内でのJDFジョブ・チケットの処理を改善するための本願の特徴および側面に基づく例示的な方法のフローチャートである。図３の方法は、図１および図２において記載されているようなシステムのコンポーネントにおいて実行できてもよい。後述するように、図３の処理の一部が印刷システムと結合されたコンピューティング・システム内で実行されてもよく、図３の他の処理は印刷システム内で実行されてもよい。

ステップ３００ないし３０６は、デバイス機能ファイルおよびデバイス・ポストスクリプト・テーブル（それぞれ任意的に制約情報を含む）を生成するための初期化処理を表す。ステップ３００は、特定の印刷システムに対応するプリンタ記述ファイル（printer description file）（たとえばPPDファイル）およびマッピング・ファイルを与える。上記のように、PPDファイルは一般に、デバイス機能設定名と、対応するデバイス機能設定名を呼び出すために印刷システムによって実行されるべき対応するデバイス・コマンド・ストリングとを与える。さらに、上記のように、PPDファイルはまた、特定の印刷ジョブの処理において印刷システムによって一緒に呼び出せないデバイス機能設定名の組み合わせを示す制約情報を含んでいてもよい。与えられるマッピング・ファイルは、JDF機能および設定名と、対応するPPD機能および設定との間のマッピング／変換を支援する。マッピング・ファイルの構造および使用のさらなる詳細については後述する。

ステップ３０２は、与えられたプリンタ記述ファイルおよびマッピング・ファイル内の情報に基づいてデバイス機能ファイルを生成する。デバイス機能ファイル（device capability file）の生成されたエントリーは、一つまたは複数のJDF機能名を、プリンタ記述ファイル内に位置される利用可能なデバイス機能設定名の一つまたは複数と、マッピング・ファイル内の情報に基づいて、関連付ける。ある例示的な実施形態では、生成されたデバイス機能ファイルは、生成されたJDFジョブ・チケットを有効確認するために使用される制約情報を含んでいてもよい。デバイス機能ファイル中の制約情報は、マッピング・ファイル中の情報に従ってマッピングされる／変換されるPPDファイル中の対応する制約情報から導出される。

ステップ３０４は、与えられたプリンタ記述ファイルおよびマッピング・ファイル内の情報に基づいて、デバイス・ポストスクリプト・テーブルを生成する。デバイス・ポストスクリプト・テーブル内の生成されたエントリーは、JDF機能名および対応する機能設定名を、対応するJDF機能を実装するために印刷システムによって実行されるべき一つまたは複数のデバイス・コマンド・ストリングにマッピングする。テーブル・エントリーは、PPDファイルおよびマッピング・ファイル内の情報に基づいて定義される。ある例示的な実施形態では、生成されたデバイス・ポストスクリプト・テーブルは、印刷システムにおいて受領される生成されたJDFジョブ・チケットを有効確認するために印刷システムにおいて使用される制約情報を含んでいてもよい。制約情報は、マッピング・ファイル中の情報に従ってマッピングされる／変換されるPPDファイル中の対応する制約情報から導出される。

ステップ３０６は、生成されたデバイス・ポストスクリプト・テーブルを印刷システムに送信する。印刷システムにおいて受け取ったJDFジョブ・チケットを有効確認および／または実行するために使うためである。デバイス・ポストスクリプト・テーブルは、印刷システム（すなわち、印刷システム・コントローラ）によって、受け取られたJDFジョブ・チケット中のJDF要素を対応するデバイス・コマンド・ストリングに変換するパフォーマンスを改善するために利用される。たとえば、デバイス・ポストスクリプト・テーブルがポストスクリプト辞書データ構造として与えられる場合、印刷システム内のデバイス・ポストスクリプト・テーブルを利用しての一つまたは複数のテーブル／辞書探索工程が、JDF機能名を位置特定し、それによりJDFジョブ・チケット中の所望されるJDF機能を、対応する一つまたは複数のデバイス・コマンド・ストリングに変換する。

ステップ３００ないし３０６は、図１および図２を参照して上記したシステム１５０のような印刷システムに結合されたコンピューティング・システム上で実行される。

ステップ３２０ないし３２４は、印刷ジョブ・データおよび関連するJDFジョブ・チケットを含む印刷ジョブを生成し、生成された印刷ジョブ（チケットおよび関連データ）を印刷システムに実行のために転送する、印刷システムと結合されたコンピューティング・システム内での処理を表す。デバイス機能ファイルにおいて任意的な制約情報が与えられている場合には、生成されたJDFジョブ・チケットは、印刷システムによって実行されうることを保証するために、コンピューティング・システムによって有効確認されてもよい。

ステップ３２０は、生成されたデバイス機能ファイルから所望されるオプションを選択するユーザー入力の受領に基づいて所望される印刷ジョブのためのJDFジョブ・チケットをコンピューティング・システムにおいて生成する。コンピューティング・システムは、デバイス機能ファイルのエントリーに基づいてユーザーに利用可能な機能を呈示してもよく、印刷ジョブを印刷するときに呼び出されるべき所望される機能の組を選択するユーザー入力を受け取ってもよい。デバイス機能ファイルの一部として制約情報が与えられる例示的な実施形態では、ステップ３２０は、JDFジョブ・チケットを、ステップ３２０の処理によって生成されるときに有効確認してもよい。デバイス機能ファイル内の制約情報は、印刷システムによって実行される単一の印刷ジョブにおいて組み合わせることのできないJDF機能および設定の組み合わせを示す。よって、ステップ３２０は、制約情報を使用して、生成されたJDFジョブ・チケットが印刷システムの何らかの可能な構成およびそのさまざまな任意的な構成によって実行されうることを検証できる。

さまざまな理由のいずれかにより、生成されたジョブ・チケットによって表される印刷ジョブは、印刷システムに後で提出するために待ち行列に入れておくことができる。たとえば、生成された印刷ジョブは単に、待ち行列に入れられたジョブの長いリストの末尾に置かれることもできる。あるいは、たとえば、新たに生成された印刷ジョブは、何らかの将来の時刻に実行を開始するよう指定されることもできる。こうして、印刷システムの構成は、ジョブ・チケットが最初に生成された時と印刷システムが実際に印刷ジョブの実行を開始する準備ができた時とで変化することがある。そこで、ステップ３２２は、生成された印刷ジョブ・チケットを印刷システムに送る直前に生成されたジョブ・チケットを再び有効確認するための任意的な処理を表す。次いで、ステップ３２４は生成されたJDFジョブ・チケットおよび関連する印刷ジョブ・データを印刷システムに送信する。それにより、JDFジョブ・チケット要素に従って印刷システムによって定義された印刷ジョブが印されることができる。

当業者は、ジョブ・チケットを生成する際に（たとえばステップ３２０において）実行される有効確認は単に、生成されるジョブ・チケットが印刷システムの何らかの可能な構成で処理できることを検証するのでよいことに気づくであろう。これに対し、ステップ３２２によって実行されるチケット有効確認は、生成されたジョブ・チケットが印刷システムの現在の構成で実行できることを検証しうる。したがって、デバイス機能ファイル中の制約情報は、生成された印刷ジョブ・チケットを印刷システムに送る直前の印刷システムの現在の構成を判別するために印刷システムによって実行されるべき問い合わせ動作を含んでいてもよい。

次いで、ステップ３３０ないし３３４が、印刷ジョブの受領（すなわち、印刷ジョブ・チケットおよび関連する印刷データの受領）に応答して印刷システムによって実行される。ステップ３３０は、受領したジョブ・チケットを再び有効確認して、ジョブ・チケットにおいて指定されている機能／設定が印刷システムによってその現在の構成およびその現在の動作状態において実行されうることを確認してもよい。もしそうであれば、ステップ３３２は、JDFジョブ・チケットの要素を対応するデバイス・コマンド・ストリングに、印刷システムに記憶されているデバイス・ポストスクリプト・テーブルのエントリーに基づいて、変換する。JDFジョブ・チケット内の各要素について、ステップ３３０は、JDFジョブ・チケットにおいて与えられている機能名を処理して、デバイス・ポストスクリプト・テーブルの一つまたは複数の対応するエントリーを位置特定する。次いでステップ３３４は、デバイス・ポストスクリプト・テーブルを使ってJDFジョブ・チケット変換から導出されたデバイス・コマンド・ストリング（たとえば「デバイス制御ストリング」）と、受領した印刷ジョブ・データ中のデバイス・コマンド・ストリング（たとえば、ページ・イメージ・データ）を実行して、印刷されるべきページ・イメージを生成する。

JDFジョブ・チケット変換工程から導出されたデバイス・コマンド・ストリングは、デバイス・コマンド・ストリングを実行する適正な時を、ジョブ・チケットと一緒に供給された印刷データに対して、また受領したジョブ・チケットの処理によって生成された他のデバイス・コマンド・ストリングに対して決定するために印刷システムによって使用される、順序付け／シーケンシング情報を含んでいてもよい。一般に、実施形態によっては、デバイス・ポストスクリプト・テーブルからの位置特定されたデバイス・コマンド・ストリング（すなわち、ステップ３３２の）は、デバイス・ポストスクリプト・テーブルから抽出され（たとえばポストスクリプト辞書探索に基づいて）、印刷ジョブ・データおよびジョブ・チケット処理から生成された他のデバイス・コマンド・ストリングとの関連で適正なシーケンスにおいてのちに処理するために保存されるという意味で、並進されてもよい。他の実施形態では、JDF機能‐設定値は、保存され、のちに（すなわちステップ３３４で）、ページ・イメージをレンダリングするために印刷ジョブが処理される際に実行されるべき対応するデバイス・コマンド・ストリングを処理する（たとえば位置特定するまたは変換する）ために使用されてもよい。

デバイス・ポストスクリプト・テーブル中の制約情報に基づいて印刷システムにおいて実行される有効確認工程は、そのような制約情報の簡単な例によってより十全に理解されうる。プリンタ記述ファイル（たとえばPPDファイル）は、デバイス機能名およびデバイス機能設定名のうち、デバイス機能名とデバイス機能設定名の別の組み合わせとは組み合わせられないものについてのエントリーを含みうる。たとえば、プリンタ記述ファイルは、
*UI制約: *機能A 設定B*機能C 設定D
*UI制約: *機能A 設定B*機能E 設定F
のような二つの例示的なエントリーを含むことがありうる。

これらのエントリーは、デバイス機能設定名「設定B」に設定されているときのデバイス機能名「機能A」は、設定名「設定D」に設定されているときの機能名「機能C」をもつ、あるいは設定名「設定F」に設定されているときの機能名「機能E」をもつ印刷ジョブにおいて組み合わせることができないことを示している。この情報は、次いで、上で論じたように、またのちに詳述するように、デバイス・ポストスクリプト・テーブルの一部として印刷システムに送られるべき制約情報を生成するために、使用されうる。ある例示的な実施形態において記されるように、制約情報は、デバイス・ポストスクリプト・テーブルにおいて、ポストスクリプト辞書（たとえば、キー‐値テーブル構造の例）として実装されてもよい。プリンタ記述ファイルにおいて遭遇される衝突する機能‐設定値の各対について、制約情報において対応するエントリーが生成または更新される。たとえば、エントリーは、第一の機能‐設定値をキー・フィールドとして含み、第一の（キー 値）機能‐設定組み合わせと衝突する他のすべての機能‐設定値の配列である値フィールドを含んでいてもよい。いくつかの実施形態では、第二の機能‐設定値がキー・フィールドとして使用され、対応する値フィールドが衝突する他のすべての機能‐設定値の配列を含む追加的なエントリー（たとえば、最初に前記第一の機能‐設定値、すなわち、最初に生成されたエントリーの逆）が生成されてもよい。そのような「逆」エントリーの使用は、チケットにおいて機能および設定が与えられる順序に依存して、無効なジョブ・チケットの認識における処理を高速化できる。よって、上記の例示的なプリンタ記述ファイル制約エントリーは、
/機能A_設定B[機能C_設定D 機能E_設定F]
/機能C_設定D[機能A_設定B]
/機能E_設定F[機能A_設定B]
のような例示的なポストスクリプト辞書エントリーに変換されうる。

上記の例示的な辞書エントリーは、抽象的な形での単純な制約を示している。より一般には、印刷システム内で使用される制約情報は、JDF機能名およびJDF機能設定名の互いに相容れないグループを同定する。

下記の抜粋は、典型的なプリンタ記述ファイル（たとえばPPDファイル）に記憶される情報のさらなる例を与える。これは、任意的な制約情報におけるエントリーを生成するために使用されうるものである。

［*UI制約: *給紙スロット マルチ手差しトレイ *両面 両面長辺綴じ
*UI制約: *給紙スロット マルチ手差しトレイ *両面 両面短辺綴じ
*UI制約: *両面 両面長辺綴じ *給紙スロット マルチ手差しトレイ
*UI制約: *両面 両面短辺綴じ *給紙スロット マルチ手差しトレイ
*UI制約: *両面 両面長辺綴じ *ページ・サイズ A6
*UI制約: *両面 両面長辺綴じ *ページ・サイズ B6
*UI制約: *両面 両面長辺綴じ *ページサイズ ハーフレター
*UI制約: *両面 両面長辺綴じ *ページ・サイズ 12×18
*UI制約: *両面 両面長辺綴じ *ページ・サイズ 封筒１０（Env10）
*UI制約: *両面 両面長辺綴じ *ページ・サイズ 封筒モナーク（EnvMonarch）
*UI制約: *両面 両面長辺綴じ *ページ・サイズ 封筒５（Env5）
*UI制約: *両面 両面長辺綴じ *ページ・サイズ 封筒６（Env6）
*UI制約: *両面 両面長辺綴じ *ページ・サイズ DL封筒（DLEnv）
*UI制約: *両面 両面長辺綴じ *給紙スロット マルチ手差しトレイ
*UI制約: *両面 両面長辺綴じ *用紙種類 ラベル
*UI制約: *両面 両面長辺綴じ *用紙種類 OHP
*UI制約: *両面 両面長辺綴じ *用紙種類 厚紙２
*UI制約: *両面 両面長辺綴じ *用紙種類 厚紙３
*UI制約: *両面 両面長辺綴じ *用紙種類 薄紙
*UI制約: *両面 両面長辺綴じ *ページ領域 A6
*UI制約: *両面 両面長辺綴じ *ページ領域 B6
*UI制約: *両面 両面長辺綴じ *ページ領域 ハーフレター
*UI制約: *両面 両面長辺綴じ *ページ領域 12×18］
下記の抜粋は、上記の例示的なプリンタ記述ファイルの諸部分からポストスクリプト辞書データ構造として生成される例示的な制約情報の諸部分を示す。

上記のように、デバイス・ポストスクリプト・テーブルは、ジョブ・チケットの変換によって生成されたデバイス・コマンド・ストリングの実行の適正なシーケンシングを保証するための順序付け情報を含んでいてもよい。ジョブ・チケットにおける機能‐設定の組み合わせは、対応するデバイス・コマンド・ストリングの実行の適正なシーケンシングを保証するために並べ替えられてもよい。これは、のちに実行されるデバイス・コマンド・ストリング（不適切な順序で実行される）が先に実行されたデバイス・コマンド・ストリング（前記不適切な順序で実行される）のオプションをオーバーライドするために、デバイス・コマンド・ストリングの実行が所望されるオプションを不適切に打ち負かしてしまうことがないことを保証する助けとなる。

ある例示的な実施形態では、順序付け情報は、プリンタ定義ファイルにおいて提供されてもよい。この順序付け情報は、たとえば、記述ファイルによって指定される利用可能なデバイス機能名についての処理の、要求される順序を表していてもよい。たとえば、プリンタ記述ファイルは

のようなエントリーを含んでいてもよい。

プリンタ記述ファイルにおけるそのようなエントリーは、JDFジョブ・チケットのプリンタの処理において使用するための別のテーブル（たとえばポストスクリプト辞書）を生成するために使用されてもよい。印刷システム内の印刷ジョブ・プロセッサは、ひとたびジョブ・チケットのJDF要素を処理することによって連結された機能‐設定名のリストを構築したら、機能‐設定名がデバイス・ポストスクリプト・テーブルから呼び出されるべき順序を決定するために、単に機能名を使ってこのテーブルを参照することになる。プリンタ記述ファイルの上記の例示的なエントリーから生成される例示的なテーブル構造（たとえばポストスクリプト辞書）は次のようになる。

当業者は、図３に例示されている方法において存在しうる多様な追加的なおよび等価な方法ステップを容易に認識するであろう。そのような追加的なおよび等価なステップは、議論の簡明のため、ここでは省略する。さらに、当業者は、図３の方法が、（設計上の選択の問題として）たとえば図１および図２のシステムのコンポーネント内の汎用または特殊目的のプロセッサによって実行される好適にプログラムされた命令として実装されてもよく、あるいは指定された機能を提供するための好適に設計されたカスタム回路として実装されてもよいことを認識するであろう。

マッピング・ファイル
マッピング・ファイル（図２の２０４）は図３の方法のステップの機能にとって重要である。図４は、マッピング・ファイルの構造を概括的に記述するブロック図である。マッピング・ファイル２０４は好ましくはXMLフォーマットを使って実装される。これは、JDF規格もXMLフォーマットを使っており、XML処理のために利用可能な多くのツールやプログラミング言語設備があるので、便利である。当業者は、マッピング・ファイルについての他のフォーマットが可能であることをすぐ認識するであろう。同じ理由で、まずPPDファイルを、マッピング・ファイルとの関連で、処理する前に、等価なXMLフォーマットに構文解析することが便利である。こうして、図３のプロセスへの二つの入力はいずれもXMLファイルである。

図４のマッピング・ファイル２０４はPDFジョブ・チケットに対して、ある程度の類似性をもつ構造をもつ。マッピング・ファイルの最上位のタグ（エレメント）はJDF ４００であり、次のような五つのサブエレメント（子要素）を含んでいてもよい：
・ProcessPool〔プロセスプール〕４０２――印刷システムによってサポートされるべきJDFプロセスをリストし、各JDFプロセスによってどの機能が必要とされるかを示す；デバイス・ポストスクリプト・テーブルを生成するために使用される。
・MacroPool〔マクロプール〕４０６――デフォルトのデバイス独立なマクロを含み、PPDが処理されるときにデバイス依存マクロによって補足される。
・AuditPool〔監査プール〕４１０――作業フローを追跡するためにジョブ・チケット中にコピーされるデータ構造。
・ResourcePool〔資源プール〕４０４――JDFResourcePoolの構造をPPD機能〔フィーチャー〕にマッピングする。
・ResourceLinkPool〔資源リンクプール〕４０８――JDFResourceLinkPoolの構造をPPD機能にマッピングする。

ResourcePool ４０４およびResourceLinkPool ４０８は、JDFジョブ・チケット中と同じ名をもつ子要素を有していてもよいが、JDFジョブ・チケット中のエレメントの属性はその代わりにマッピング・ファイル中のサブエレメントとして表現されてもよい。JDF属性に対応するこれらのサブエレメントは、それ自身、「PPDFeature」または「JDFFeature」と名付けられた一つまたは複数のサブエレメントを含んでいてもよい。ProcessPool ４０２内のサブエレメント４２２はやはりPPDFeatureおよびJDFFeatureエレメントを含んでいてもよく、これらはResourcePool（サブエレメント４２４）またはResourceLinkPool（サブエレメント４２８）における対応するPPDFeatureおよびJDFFeatureエレメントを指す。

（サブエレメント４２２、４２４または４２８中の）PPDFeatureエレメントは、PPDファイル中で生起しうるデバイス固有機能（feature）を記述する。PPDFeatureエレメント（サブエレメント）は二つの属性「名前（Name）」および「OEM」を有する。名前属性はPPDファイル中で生起するPPD機能の名前である。OEMはデバイスの製造業者（元の装置製造業者［Original Equipment Manufacturer］）を指し、名前空間宣言として機能する。このOEM属性指示は、一般的なデバイス機能についてPPDファイルにおいて使用される名前が製造業者の間で、あるいは単一の製造業者からのデバイス・モデルのセット（または世代）の間で異なりうるが一般に名付け規約のファミリーにはいる場合に有用となることがある。PPDFeatureエレメントのOEM属性は、このPPDFeatureが属する名前のファミリーを示す。よって、複数のPPDFeature要素を各位置に含めることによって、マッピング・ファイルは、PPD名の複数のファミリーについて、PPDからJDFへのマッピングを記述できる。

PPDFeatureエレメントは、「PPD」、「JDF」と名付けられた属性をもつ「設定（Setting）」と名付けられた子要素を有していてもよい。これらの「設定」エレメントは、JDF値を一つまたは複数のPPDデバイス設定に、または必要に応じてポストスクリプト手順にマッピングする。

図５は、印刷システム内でのJDFジョブ・チケットの処理を改善するための本願の特徴および側面に基づくもう一つの例示的な方法を描くフローチャートである。図５の方法は、図４で上に論じたマッピング・ファイル構造の諸部分に関係する、いくつかのステップを記述する。図５の方法は、図１および図２に記載されたようなシステムのコンポーネントにおいて動作可能であってもよい。本稿でさらに後述するように、図５の処理の一部は、印刷システムと結合されたコンピューティング・システム内で実行されてもよく、図５の他の処理は印刷システム内で実行されてもよい。

ステップ５００は、XMLフォーマットにされたマッピング・ファイルとの関連でのPPDの処理を容易にするために、与えられたPPDファイルをXMLフォーマットに変換して、XMLフォーマットのデバイス機能ファイルを生成する。ある例示的な実施形態では、変換されたPPDファイルは、XML木構造としてメモリ内で表現されてもよい。ステップ５０２は、PPDファイル（たとえば、メモリ内XML木構造に変換されている）においてOEMがもしあればどのOEMが指定されているかを判別する。OEM識別子は、使用されるべき特定の印刷システムのための適切なデバイス機能ファイルおよびデバイス・ポストスクリプト・テーブルの生成において使用するためにマッピング・ファイルのさまざまなエントリーの間で選択するために使われてもよい。次いでステップ５０４は同定された印刷システムのための新しいデバイス機能ファイルを生成する。

ステップ５０６ないし５１０は、マッピング・ファイルの対応する諸セクションにおける情報を処理する。具体的には、ステップ５０６はAuditPool（図４のエレメント４１０）を処理し、ステップ５０８はResourcePool（図４のエレメント４０４）を処理し、ステップ５１０はResourceLinkPool（図４のエレメント４０８）を処理する。ステップ５１２はPPDファイルおよびマッピング・ファイルを処理してデバイス機能ファイル中のTestPool〔試験プール〕（後述）を生成する。ステップ５１４はPPDファイルおよびマッピング・ファイルを処理してデバイス機能ファイル中のMacroPool（後述）を生成する。ステップ５１６はPPDファイルおよびマッピング・ファイルを処理してデバイス機能ファイル中のModulePool〔モジュールプール〕（後述）を生成する。

ステップ５１８は、生成されたデバイス・ポストスクリプト・テーブルを記憶するための出力ファイルを生成する。ステップ５２０は、マッピング・ファイルのProcessPool（図４のエレメント４０２）中の各エレメントのために出力ファイル中の新しいポストスクリプト辞書データ構造を開始する。次いでステップ５２２は、マッピング・ファイルのProcessPoolにおいて参照される各PPD機能またはJDF機能のための辞書木構造を追加する。（一つまたは複数のポストスクリプト辞書のような）生成されたデバイス・ポストスクリプト・テーブルを含む生成された出力ファイルは、印刷システムに送られる。印刷システムにおいてJDFジョブ・チケットの処理のために使われるためである。

ステップ５２４は、ユーザーによって入力されたマクロ選択に基づいてデバイス機能ファイルのエントリーを調整する。

こうして印刷システムに送られるデバイス機能ファイルおよびデバイス・ポストスクリプト・テーブルを生成したところで、ステップ５２６は、生成されたデバイス機能ファイルを使った印刷ジョブのためのジョブ・チケットを生成するための、ユーザー／アプリケーションによる処理を表す。生成されたJDFジョブ・チケットおよび関連付けられた印刷ジョブ・データは次いでステップ５２８での処理のために組み合わされ、ステップ５３０で印刷システムに送られる。次いで、ステップ５３２はJDFジョブ・チケットおよび関連付けられた印刷ジョブ・データを処理して所望の印刷出力を生成するための印刷システム内の処理を表す。

デバイス機能ファイルおよびデバイス・ポストスクリプト・テーブルを生成するためのマッピング・ファイルおよびPPDファイルのエレメントおよび使用は、マッピング・ファイルのエントリーの例および関連する例示的なPPDおよびJDFジョブ・チケット・エントリーを参照しても理解されうる。下記は、「OEM2」製造業者印刷システムにおける丁合（collate）機能のための例示的なPPDファイルからの抜粋である。

下記のXMLは、「OEM2」丁合機能および別の例示的なOEM（たとえば「OEM1」）のものを含む丁合機能のためのマッピング・ファイルの例示的な部分を表す。各OEMのPPD機能についての「設定（Setting）」属性は、対応する丁合機能のためのポストスクリプト・コマンド・ストリング（「PS」属性）を指定する。

例示的なJDFジョブ・チケットは、下記のJDジョブ・チケット抜粋におけるような丁合機能の使用を指定しうる。

（図３の方法によって使用されるとき）上記の例示的なPPD抜粋と関連して上記に与えた例示的なマッピング・ファイル抜粋は、次いで、「OEM2」プリンタによって実行されるべき下記のポストスクリプト・コードを生成する。

デバイス機能を呼び出す上記の例示的な生成されたポストスクリプト・コードは、「OEM2」デバイスのためのPPDFeatureの「PS」属性からのコードと組み合わされていることを注意しておく。「PS」属性におけるデバイス独立コードは、典型的には、ページ・レイアウトに影響する設定をレイアウト・エンジンに知らせ、それによりレイアウト・エンジンを、設定を判別するためにプリンタ・ハードウェアにデバイス固有問い合わせをする必要から解放するために使われる。これは、すべてのデバイスについて展開されるべき、デバイス独立なレイアウト・エンジンを許容する。

いくつかのPPD機能は、JDF機能と一対一にマッピングしない。場合によっては、複数のPPD機能オプションが単一のJDF属性値にマッピングされる。場合によっては、複数のJDF属性値が同じPPD機能オプションにマッピングされる。マッピング・ファイルは、「設定」エレメントの「PPD」属性が複数のPPD機能オプション名を含むことを許容し、マッピング・ファイル中の複数の位置における「PPDFeature」エレメントが同じPPD機能を参照することを許容することによって、そのための備えをする。下記の例は、ResourcePool中の三つのJDF属性およびResourceLinkPool中の一つのJDF属性が「OEM1」プリンタの「StapleLocation〔ステープル位置〕」機能にマッピングする様子を示している。

正しいデバイス設定を判別するために、ジョブ・チケット・プロセッサは、ジョブ・チケット中の四つすべての属性を調べねばならない。マッピング・ファイルは、特定のジョブ・チケットのための単一のステープル設定を判別するために、相互排除を許容する情報を含む。たとえば、StitchType＝"Corner"〔綴じ型＝隅〕、Angle＝"90"〔角度＝90〕、NumberOfStitches＝"1"〔綴じ数＝1〕、Orientation＝"Rotate0"〔配向＝回転０〕の場合、PPD機能「StapleLocation〔ステープル位置〕」に対する適切なオプションは「UpperLeft〔左上〕」である。

PPDFeatureエレメントがいかなるSetting〔設定〕子要素も含まない場合、これは、許容されるJDF機能設定のリストがPPDファイルにおいて指定されている機能設定のリストから、同じ名前および値型をもって、直接生成されるべきであることを示す。マッピング・ファイルの解釈におけるこの規約は、PPDに固有の名前のセットが自動的に特定のJDF属性にマッピングされることを許容する。たとえば、PPDからの「MediaType〔メディア型〕」エントリーを（下記のマッピング・ファイル抜粋で例示されるところでは）JDFノード/JDF/ResourcePool/Mediaの「MediaTypeDetails〔メディア型詳細〕」にマッピングするために使うことができる。

このマッピング・ファイル構造は、メディア型の名前のような、プリンタ・モデルの間で大きく変動があり、JDF規格がすべての場合における同等物を定義していない大きなオプション・セットのために有用である。JDF規格は特に、カスタム属性値のそのようなセットを許容し、よってマッピング・ファイルは上記の例示的な構造をもってこれを受け入れる。

PPDFeatureエレメントは、マッピング・ファイルのProcessPool中にも生起しうる。この場合、これらのエレメントはマッピング・ファイルによってサポートされる各プロセスのためにどのPPD機能が呼び出されねばならないかを示す。次のマッピング例抜粋は、「ColorSpaceConversion〔色空間変換〕」プロセスが「OEM1」プリンタについてはPPD機能「ColorModel〔色モデル〕」を呼び出し、「OEM2」プリンタについてはPPD機能「EFColorMode〔EF色モード〕」を呼び出すことを指定している。

JDFFeatureエレメント（サブエレメント）は、PPDファイルにリストされていないがその代わりポストスクリプト手順によって実装されるデバイス独立な機能を記述する。これは、その機能のためのデバイス・コマンドを補足するものであるPPDFeatureエレメントの「PS」属性に含まれるポストスクリプトとは異なる。

マッピング・ファイル内のResourcePoolまたはResourceLinkPool中に現れるJDFFeatureエレメントは、ジョブ・チケット内の等価な位置に現れるJDF機能に対応する。これらのJDFFeatureエレメントは、「JDF」属性および任意的に「PS」属性を有する「Setting」子要素を含んでいてもよい。「JDF」属性は、JDF機能についての許容される設定値を示し、任意的な「PS」属性は二つの要素をもつポストスクリプト配列〔アレイ〕を含んでいてもよい。二つの要素とは、整数およびその機能を実装する手順である。整数は、コマンド順序番号であり、PPD機能のためのコマンド順序番号と同じように機能する。整数順序番号は、ポストスクリプト手順が他のコマンドおよび手順に対していつ実行されるべきかを示す。次の例示的なマッピング・ファイル抜粋では、順序番号は「SetSizePolicy〔サイズ設定ポリシー〕」手順について1000である。

「JDFFeature」エレメントの「JDF」属性の値が「INTEGER〔整数〕」である場合、それは、ジョブ・チケットに見出される値が、ポストスクリプト・スタック上のパラメータとして配列中の手順に渡されねばならない単一の整数であろうことを示す。「JDF」属性の値が「XYPAIR〔XY対〕」である場合、それはジョブ・チケット中に見出される値が、パラメータとして配列中のポストスクリプト手順に渡されねばならない実数の対であることを示す。「JDF」属性の値が「STRING〔文字列〕」である場合、それはジョブ・チケットからのストリング値がポストスクリプト手順に渡されることを示す。次の例示的なマッピング・ファイル抜粋は、コピーの数が整数属性値を用いてどのように設定されるかを示す。

「JDFFeature」エレメントが「PS」属性をもたない場合、このことは、印刷時に実行されるべき手順がないことを示す。しかしながら、「JDF」属性の値は、システム中の別のモジュールによって使用されてもよい。次の例示的なマッピング・ファイル抜粋では、「ComponentType〔コンポーネント型〕」属性がジョブ・チケット・プロセッサによっては必要とされないが、印刷システム中の、ジョブ・スケジューラのような別のモジュールによって参照されうる。

JDFFeatureエレメントは、マッピング・ファイルのProcessPool中にも現れることがある。この場合、それらの要素は「Setting」という子はもたず、ただ一つの属性、つまりジョブ・チケット中の対応する属性を同定するJDFパス名の値をもつ「Path〔パス〕」属性をもつ。これは、チケット・プロセッサに、そのJDFFeatureエレメントが現れたProcessPoolのプロセス子要素に対応するプロセスを実行するときにその属性が参照されねばならないことを通知する。次の例示的なマッピング・ファイル抜粋は、マッピング・ファイルが、「DigitalPrinting〔デジタル印刷〕」プロセスの一部として「SetNumCopies〔部数を設定〕」手順（上に例示したような）が呼び出されねばならないことを示す様子を示している。

デバイス機能ファイル
JDF文書において規定されているデバイス機能記述フォーマット（DevCaps）はいくつかの目的の役に立つことができる。DevCapsファイルは、デバイス上で利用可能な機能のセットを、APIとして、クライアントのために呈示することができ、これらの機能をJDFジョブ・チケット中の構造体（constructs）にマッピングするための論理を含むことができる（MacroPool）。さらに、衝突があるかどうか機能設定を検査するための試験のセットを含んでいてもよい（TestPool）。さらに、DevCapsファイルは、どの機能が利用可能であり（ModulePool）最終的かに影響するデバイスの任意的な構成の記述を含んでいてもよい。さらに、ジョブ・チケット生成のためのテンプレートの役を果たすこともできる（CurrentValue〔現在値〕属性の使用を通じて）。ここに記載されるマッピング・ファイルは、デバイス機能ファイルを生成するためのこれらの使用事例すべてをサポートする。

PPD機能は、一般に、ジョブ・チケットのResourcePoolにおける要素にマッピングされる。そのような要素は、属性「Context〔コンテキスト〕」を値「Resource〔資源〕」に設定して、DevCaps要素によってDevCapsファイルにおいてモデル化される。ResourceLinkPoolエレメントは、Contextを「Link〔リンク〕」に設定してDevCaps要素によってモデル化される。これら二つの要素のセットは、PPDファイルおよびマッピング・ファイルを入力として使うソフトウェア・モジュールによって生成できる。これらのモジュールのアルゴリズム論理は以下に述べる。PPDファイルの特性を調べることによって、あるいは構成ファイル〔コンフィギュレーション・ファイル〕（これものちに論じるアルゴリズムへの入力として使われる）中の値を直接設定することによって、OEMがすでに判別されていると想定する。

CIP4デバイス機能ファイルは、「DeviceInfo〔デバイス情報〕」ルート・ノードで始まる。このルート・ノードは「Device〔デバイス〕」エレメントを子としてもち、このエレメントは「DeviceCap」子要素をもち、これは一つまたは複数の「DevCaps」エレメントを含む。各「DevCaps」エレメントは「DevCap」子要素をもち、これはジョブ・チケット中の属性を表す一つまたは複数の子要素（EnumerationState〔列挙状態〕またはIntegerState〔整数状態〕のような）をもつ。

ResourcePoolのためのDevCaps
次の例の抜粋は、「Media〔メディア〕」エレメントについての単一のDevCapsエレメントと、その「Location〔位置〕」属性についてのその子DevCapエレメントを示している。このようにして、JDFジョブ・チケットはデバイス上で使用されるべき入力トレイを指示する。

上記のDevCapsの例の抜粋は、次のマッピング・ファイルの例示的な抜粋によってマッピングされる。（これがDevCap中に実際に現れるよりも多くの入力トレイ名を指定していることに注意。）

上記のように、マッピング・ファイルにおけるトレイ名のすべてがデバイス機能ファイルに現れるわけではなく、例示的なPPDファイル抜粋における対応する機能において見出された名前に一致するものだけが示されている。

上記の例示的な抜粋は、デバイス機能ファイルが、マッピング・ファイルに従ってPPDファイルからマッピングおよびフィルタリング情報を使ってどのように構築されるかを示す。次のアルゴリズムは、マッピング・ファイルおよびPPDファイルを使ってResourcePoolエレメントについてデバイス機能ファイル中の要素を生成するための方法をより十全に記述する。
１．マッピング・ファイル・ノード"/JDF/ResourcePool"の子ノードすべてについて反復
２．各子ノードについて、出力XMLファイル中でDevCapsエレメントを開始
３．Name属性を子の名前に設定し、Context属性を"Resource"に設定
４．IDおよびStatus属性を、所望に応じてデフォルト設定に設定
５．DevCapsエレメントの"DevCap"子ノードを同じ名前属性をもって開始
６．マッピング・ファイルからの子ノードを渡し、出力ファイルを再帰的機能へのパラメータとして渡す。再帰的機能は：
ａ．渡されたノード・パラメータのすべての子ノードについて、反復
ｂ．子ノードがPPDFeatureエレメントであれば、"Name"属性の値を使ってPPDファイル中のその機能を見出し、PPDがその機能について何のオプションももたない場合にはアボートする
ｃ．PPDFeatureマップ・ノードの最初の子要素（Setting）を得、みつかったら：
ｉ．SettingエレメントのJDF属性を調べ、それが
１．単一の整数であれば、DevCapの"IntegerState"子を開始し、"List"に設定された属性"ListType"を追加し、
２．スペースによって区切られた二つの整数であれば、"XYPairState"子を開始し、
３．名前であれば、"EnumerationState"子を開始
ｉｉ．その機能についてのデフォルト・オプションがあるかどうかPPDファイルを調べ、みつかったら：
１．マッピング・ファイル中の対応するJDF名を判別し、
２．それをStateエレメントのDefaultValue〔デフォルト値〕属性として出力
ｉｉｉ．EnumerationStateであれば、マップ中のPPDFeatureエレメントの各Setting子要素の"PPD"属性におけるPPDファイルから各機能オプションの名前を探し、関連付けられた"JDF"属性の値をリストに追加することによって、出力中にStateエレメントの"AllowedValues〔許容される値〕"属性のリストを生成
ｉｖ．出力中のStateエレメントを終了
ｄ．PPDFeatureエレメントが子をもたなければ、PPDオプションからの出力を生成：
ｉ．出力中にEnumerationStateエレメントを開始
ｉｉ．その機能についてのPPDファイル中にリストされているオプションから直接にAllowedValues属性についてのリストを生成
ｉｉｉ．PPDファイル中でデフォルト・オプションが指定されていれば、DefaultValue属性を追加
ｉｖ．出力中のStateエレメントを終了
ｅ．渡されたノードの子が（PPDFeatureでなく）JDFFeatureであれば、子Settingエレメントおよび可能性としてはDefaultエレメントを反復
ｉ．第一のSetting子において、型を判別するためにJDF属性の値を調べ、出力中の新しいエレメントを開始：適宜IntegerState、XYPairStateまたはEnumerationState
ｉｉ．EnumerationStateであれば、マップ中のJDFFeatureエレメントのSetting子のJDF属性からAllowedValues属性についてのリストを構築
ｉｉｉ．SettingエレメントのDefaultエレメント兄弟に遭遇したら、その値をStateエレメントのDefaultValue属性として出力
ｉｖ．出力中のStateエレメントを終了
ｆ．渡されたノードの子がJDFFeatureでもPPDFeatureでもない場合、それは中間ノードであり、よって現在の関数への再帰的な呼び出しをする。再帰は、PPDFeatureまたはJDFFeatureエレメントが見出されるまで続けられる
７．DevCapエレメントを終了
８．DevCapsエレメントを終了。

ResourceLinkPoolのためのDevCaps
ジョブ・チケットのResourceLinkPool中のエレメントをモデル化するDevCapsエレメントは、マッピング・ファイルのResourceLinkPoolから直接に、そしてマッピング・ファイルのResourcePoolから間接的にという二通りの仕方で導出できる。

DevCaps要素は、マッピング・ファイル中のノード"/JDF/ResourceLinkPool"のすべての子を通じて、名前"PPDFeature"または"JDFFeature"のいずれかをもつ子孫ノードがみつかるまで再帰的に反復することによって、マッピング・ファイルのResourceLinkPoolから直接導出される。次のアルゴリズムは、マッピング・ファイルおよびPPDファイルを使って、ResourceLinkPoolエレメントのためのデバイス機能ファイル中の要素を生成するための方法をより十全に記述する。
１．最初の再帰（すなわち/JDF/ResourceLinkPoolの直接の子）であれば：
ａ．出力DevCapsファイルにおいて新しいDevCapsエレメントを開始し、マップ・ノードからName属性をコピーし、Context属性を"Link"に設定
ｂ．新しいDevCapエレメント（DevCapsの子）を開始し、同じName属性を設定
２．PPDFeatureエレメントに遭遇した場合：
ａ．Name属性を取得し、それがPPDファイル中の機能に現れなければアボート
ｂ．このPPDFeatureのSetting子がなければ、スキップ
ｃ．第一のSetting子要素からデータ型を判別し、ResourcePool処理についてアウトライン・ポイント６ｃで上記したように出力において新しいStateエレメントを開始
ｄ．Setting子要素を通じて反復、JDF属性値をリスト中に集める
ｅ．集められたリストをStateエレメントのAllowedValuesList属性として出力
ｆ．Stateエレメントを終了
３．JDFFeatureエレメントに遭遇した場合：
ａ．このJDFFeatureの子がなければ、スキップ
ｂ．上記のように、第一のSettingまたはDefault子要素からデータ型を判別
ｃ．このJDFFeatureのすべてのSetting子（および可能性としては単一のDefault子）を通じて反復、JDF属性値をリスト中に集める
ｄ．集められたリストをStateエレメントのAllowedValuesList属性として出力
ｅ．JDFFeatureのDefault子に遭遇した場合には、そのJDF属性の値をStateエレメントのDefaultValue属性として出力
ｆ．Stateエレメントを終了
４．すべての再帰の完了後、DevCapエレメントを終了
５．DevCapsエレメントを終了。

MacroPool
"MacroPool"は生成されるデバイス機能ファイルにおいてDeviceCapエレメントの子要素であり、ResourcePoolおよびResourceLinkPoolエレメントの兄弟要素である。MacroPoolは一つまたは複数の「macro」子要素を含み、そのそれぞれが"choice"要素を含み、これは一つまたは複数の"when"要素を含む。"when"要素は、"IntegerEvaluation"または"EnumerationEvaluation"のような評価要素と、一つまたは複数の"set〔設定〕"要素を含み、そのそれぞれがジョブ・チケット中でのエレメントの属性を指し、その属性が設定されるべき値を指定する。評価要素は、マクロに渡されたパラメータを処理し、適切な設定要素を選択するはたらきをする。典型的には、設定要素は、ジョブ・チケット中でターゲット要素をモデル化するDevCapsにおける"CurrentValue"属性を設定する。ジョブ・チケットについての値を選択するためにDevCaps要素におけるCurrentValue属性の値が使われるので、これは、ジョブ・チケットの生成を容易にする。

下記のマクロの例の抜粋は、ジョブ・チケット中のResourcePoolの子であるLayoutPreparationParams〔レイアウト準備パラメータ〕エレメントのRotate〔回転〕属性に格納されている、印刷ジョブについてのポートレート〔縦置き〕（portrait）またはランドスケープ〔横置き〕（landscape）の配向を選択する。

上記の例におけるマクロは、指定されているページ回転はいかなるポストスクリプト対応プリンタ上でもポストスクリプト・コマンドによって実装できるので、デバイス独立である。したがって、このマクロは、マッピング・ファイルのMacroPool中に含めることができ、これは、（PPDファイルからの案内の必要なしに）マッピング・ファイルから生成されるすべてのデバイス機能ファイル中にコピーされる。

デバイス依存のPPD機能のためのマクロはPPDおよびマッピング・ファイルから導出される。これは、デバイス機能記述がPPD機能のインターフェースをクライアントに呈示し、次いでユーザーの選択を反映するJDFジョブ・チケットを生成することができる一次機構である。次のマクロの例の抜粋は、マッピング・ファイルによってステープル機能について生成される単純なマクロ（選択肢（choice）が一つのみ）を示している。

こうして、デバイス独立およびデバイス依存という二つ（以上）のクラスのマクロがありうる。デバイス独立なマクロはマッピング・ファイルによって指定され、生成されるデバイス機能ファイル中に直接コピーされる。デバイス依存マクロはPPD機能を実装し、PPDおよびマッピング・ファイル中の情報から生成される。MacroPoolエレメントが出力デバイス機能ファイルにおいて開始されているとすると、これは次のアルゴリズムによって達成されうる：
１．すべてのPPDFeatureエレメントを見出すために、マッピング・ファイル中のResourcePoolおよびResourceLinkPoolエレメントのすべての子孫を通じて再帰的に反復
２．PPDFeatureエレメントのName属性すべての値を集める。これは生成されるべきマクロの名前のリストをなす
３．ステップ２で生成されたリスト中のそれぞれの名前について：
ａ．出力中で新しい"macro"エレメント（MacroPoolの子）を開始
ｂ．ID属性を、リストから逐次反復されている名前に設定
ｃ．出力中で新しい"choice"エレメント（macroの子）を開始
ｄ．リストされる各オプションについて、PPDファイル中で当該機能を位置特定：
ｉ．出力中で"when"エレメントを開始
ｉｉ．出力中で"EnumerationEvaluation"エレメントを追加
ｉｉｉ．PPDファイル中でのオプションの名前に等しい値をもつ"ValueList"属性を追加。これはEnumerationEvaluationエレメントを終了する
ｉｖ．PPD機能名に等しい"Name"属性をもつすべてのPPDFeatureエレメント（そのようなエレメントは複数あることがありうる）を見出すために、マッピング・ファイル中のResourcePoolおよびResourceLinkPoolエレメントのすべての子孫を通じて再帰的に反復。みつかった一つ一つについて：
１．PPDFeatureの"Setting"子要素を通じて反復。PPDファイルからのオプションの名前との一致を探してPPDFeatureの"PPD"属性中の一つまたは複数の名前を探索。一致がみつかったら：
ａ．出力中で"set"エレメントを開始
ｂ．マッピング・ファイル中のPPDFeatureの位置に対応するJDFパスの値をもつ"rRef"属性を追加。たとえばJDF.StitchingParams.StitchType
ｃ．出力中で"FeatureAttribute"エレメントを開始
ｄ．反復中の"Setting"エレメントの"JDF"属性の値をもつ"CurrentValue"属性を追加
ｅ．"FeatureAttribute"エレメントを終了
ｆ．"set"エレメントを終了
ｖ．"when"エレメントを終了
ｅ．"choice"エレメントを終了
ｆ．"macro"エレメントを終了。

マクロ・プロセッサ
マクロ処理は、本特許出願において論じられるマッピング・ファイルに直接依存しないものの、その概念についてここで手短に説明しておく。CIP4文書が、マクロ選択がジョブ・チケット生成のためのプロセスにどのように提出されるかについて明確でないからである。

印刷ジョブについてのマクロ設定を決定するために、クライアント・アプリケーションはユーザーに、デバイス機能ファイル中のMacroPoolに基づいて選択肢のセットを呈示してもよいし、あるいは自分自身の内部論理を使ってもよい。いずれにせよ、なされた選択は、生成されるデバイス機能ファイルにおける値を設定するマクロ・プロセッサに渡される必要がある。すると設定値はその後、チケット生成器によって、実際のジョブ・チケットを出力するために使用できる。選択肢は"Setting"エレメントを含むXML構造によって簡単に記述できる。各"Setting"エレメントは、マクロの"ID"属性に等しい"MacroRef"属性と、所望される設定を指定する"set"エレメントを含む"when"エレメントの"EnumerationEvaluation"子要素の"ValueList"属性に等しい"MacroChoice"属性とを有する。次は、九つのパラメータの選択を表す例示的なマクロの抜粋である。

ユーザーの選択を指定するXMLは、デバイス機能ファイルと一緒にマクロ処理機能に提出される。マクロ処理機能は次のアルゴリズムを実行する：
１．"MacroSettings"エレメントのそれぞれの"Setting"子要素について：
ａ．反復中の"Setting"エレメントの"MacroRef"属性に一致する"ID"属性をもつマクロがみつかるまで、デバイス機能ファイルのMacroPool中の"macro"エレメントを通じて反復
ｂ．マクロの"choice"子要素を取得
ｃ．"choice"エレメントの"when"子を反復。それぞれについて：
ｉ．"EnumarationEvaluation"子要素を取得し、"ValueList"属性の値を（ステップ１．ａにおいて）反復中の"Setting"エレメントの"MacroChoice"属性と比較し、一致があれば：
１．ステップ１．ｃ．ｉにおいて同定された"when"エレメントの"set"子要素の"rRef"属性中のJDFチケット位置に対応するデバイス機能ファイル中のエレメントまでナビゲート
２．デバイス機能エレメントの"CurrentValue"属性を追加（存在しない場合）または設定（存在する場合）して、ステップ１．ｃ．ｉにおいて同定されたMacroPool中の"set"子要素の"FeatureAttribute"子要素の"CurrentValue"属性の値にする。

TestPool
PPDファイルは、互いに相容れない機能およびオプション名の二つの対をリストする"UIConstraint"という名称の構造体（construct）を含んでいてもよい。換言すれば、第一の機能名が第一のオプション名に設定されると、第二の機能名は第二のオプション名に設定されないよう制約される。これは、ポストスクリプト・プリンタ・ドライバが印刷ジョブについての設定における衝突を回避できる一次的な機構である。次は11×17の用紙（「レジャー（ledger）」サイズ）が用紙トレイ＃１にロードされるのを禁止する（たとえば物理的に収まらないので禁止）例示的なPPDの抜粋である。

制約を表すCIP4の方法は、一つまたは複数の"Test"〔試験〕エレメントを含む"TestPool"と呼ばれるXMLデータ構造の使用によるものである。各Testエレメントは、EnumerationEvaluationのような、"ValueList"および"rRef"という名称の属性をもつ単一の評価エレメントを含んでいてもよい。第一の"ValueList"は値であり、第二の"rRef"はJDFジョブ・チケット中の位置である。名指しされた位置における属性が名指しされた値をもつ場合、Testエレメントは真であると評価され、そうでなければ偽であると評価される。あるいはまた、Testエレメントは複数の評価エレメントを含んでいてもよい。それらの評価エレメントが"and"エレメントのもとにグループ化されていれば、その評価子要素のすべてが真であると評価される場合にかつその場合にのみ真であると評価される（それ以外の場合には偽）。あるいは、それらの評価エレメントが"or"エレメントのもとにグループ化されていれば、その評価子要素のうちのいずれかが真であると評価されれば真であると評価される。上記の例示的なPPD制約抜粋のCIP4等価物は次のようになろう。

Test ID属性として使われるテキスト・ストリングについて標準的な規約はないが、ここに記載される諸方法はIDを機能およびオプション名から構築し、次いでその機能が名指しされたオプションに設定されている場合に禁止される設定を記述する他のTestsへの一つまたは複数の参照をリストする。これらの方法はTestPoolデータ構造におけるスペースを節約する。

マッピング・ファイルは、PPD制約条件において指定される機能およびオプションのJDF等価物を導出するために使われる。この方法において、TestPoolは、二つの部分をもって生成されうる：第一の部分は機能‐設定の組み合わせについての試験のセットを定義し、第二の部分は第一のセクションにおける試験を参照する禁止のセットを定義する。第一の部分における試験は、"AND"エレメントのもとにグループ化された複数の評価エレメントを含んでいてもよい。これは、いくつかの場合において、単一のデバイス設定がJDFジョブ・チケットにおける複数の設定にマッピングされるからである。たとえば、この複数マッピングは、デジタル・プリンタ上のステープル仕上げ器〔フィニッシャー〕のための設定の場合に当てはまる。この場合、個々の各設定は、JDFジョブ・チケット中で設定されねばならない四つの異なる値にマッピングされる。よって、特定のステープラー設定に関係するPPD制約をCIP4規格を使って表すためには、まず、四つの異なる評価エレメントを含む"AND"エレメントからなる、そのステープラー設定についての試験を記述することが必要である。次いで、制約条件は、そのステープラー設定試験への参照および禁止される条件を表す他の任意の試験を含む試験として構築できる。これらの試験参照は、そのいずれも許容されないので、"OR"エレメントのもとにグループ化されることになる。よって、それらのいずれか一つが真であると評価されれば、親試験は真であると評価され、これは、衝突がみつかり、そのジョブ・チケットは無効であるということである。第二のグループにおけるこれらの試験は「排除（exclusions）」と称される。第一のグループからリストされる試験によって表される条件のいずれをも排除するからである。

PPDファイル中のUIConstraint文のいくつかは、JDF等価物にマッピングできる機能設定を参照しない。むしろ、PPDファイルの"InstallableOptions"〔インストール可能オプション〕グループにおいて指定されているポストスクリプト問い合わせの結果を参照する。そのような制約はTestPoolの第二の部分において参照されることになるが、TestPoolの第一の部分には定義をもたない。むしろ、これらの制約についての機能名はModulePool（後述）に現れる。これは、デバイス・ポストスクリプト・ファイルが機能名によって参照される問い合わせをもつことを示す。そのような場合には、ホスト・ベースのクライアントはプリンタにその問い合わせを実行して結果をホストに返すよう依頼し、該結果において返される名前が機能名と結合（たとえば名前の間にアンダースコアをセパレータとしてもつようにして連結）できるようにする。次いで、TestPoolの処理は、この機能‐設定名が真であると評価されたTestPoolの第一の部分における試験の名前であったかのように、続くことができる。

次の例は、第一の部分において定義されている三つの試験および第二の部分において定義されている四つの排除試験をもつ二部からなるTestPoolを示している。第二の部分における名前の一つ"Finisher_None"〔仕上げ器＿なし〕は、インストール可能なオプションがあるかどうかの問い合わせの結果なので、第一の部分には定義されていない。

次のアルゴリズムは、デバイス機能ファイル出力におけるTestPoolを生成するための処理を記述する。
１．出力デバイス機能ファイル中の"TestPool"エレメントを、"DeviceCap"エレメントの子（DevCapsエレメントの兄弟）として開始する。
２．PPDファイル中の各"UIConstraint"文におけるそれぞれの一意的な機能／オプション対について：
ａ．マッピング・ファイルのResourcePoolおよびResourceLinkPool中で、"Name"属性の値としての機能名と、PPDFeatureエレメントの"Setting"子のいずれかのPPD属性に含まれるオプション名とをもつPPDFeatureエレメントがいくつあるかを数えるために再帰関数を呼び出す。

ｂ．PPDFeatureの計数値が0より大きければ、出力デバイス機能ファイルにおいて新しい"Test"エレメントを開始（すなわち、マッピングされない機能についての試験は出力されない）
ｉ．"Test"エレメントの"ID"属性を、アンダースコアを用いて結び合わされた機能およびオプションの名前に設定
ｉｉ．PPDFeatureの計数値が1より大きければ、出力中で新しい"and"エレメントを開始
ｉｉｉ．ステップ２．ａで関連するPPDFeatureエレメントを計数するのに使われたのと同様の再帰関数を呼び出すが、今回は、探索される機能／オプション対との一致を含むPPDFeatureエレメントの"Name"属性および"Setting"子要素の"PPD"属性のそれぞれについて、"Setting"エレメントからの"JDF"属性の値に設定された"ValueList"属性とマッピング・ファイル中のPPDFeatureの位置のパス名に設定された"rRef"属性とをもつ評価エレメントを出力
ｉｖ．ステップ２．ｂ．ｉにおけるPPDFeatureの計数値が1より大きかった場合、出力における"and"エレメントを終了
ｖ．出力中で"Test"エレメントを終了
３．PPDファイル中の各"UIConstraint"文におけるそれぞれの一意的な機能／オプション対について：
ａ．出力中で"Test"エレメントを開始
ｉ．試験エレメントの"ID"属性を、アンダースコアを用いて結び合わされた機能およびオプションの名前に設定し、末尾に"_Exclusions"をアペンド
ｉｉ．この機能／オプション対を禁止する他のすべてのUIConstraint文のリストを構築
ｉｉｉ．リスト中の項目数が1より大きければ、出力中で"or"エレメントを開始
ｉｖ．リスト中の各UIConstraint文について、同じUIConstraintについてステップ２．ｂ．ｉで生成された"ID"属性に一致するよう、アンダースコアを用いてUIConstraintからの機能およびオプションの名前を結び合わせることによって形成されたストリングに設定された"rRef"属性をもつ"TestRef"エレメントを出力
ｖ．ステップ３．ａ．ｉｉｉにおいて"or"エレメントが開始された場合には、その"or"エレメントを終了
ｖｉ． "Test"エレメントを終了
４．"TestPool"エレメントを終了。

ModulePool
CIP4デバイス機能ファイルにおけるモジュール・エレメントは、インストールされている特定のハードウェアまたはソフトウェア機能に依存する機能を指定する。デジタル・プリンタの場合、これはたとえば、ステープル、パンチ、折りといった機能を提供する仕上げ器を含みうる。モジュールの利用可能性（現在インストールされているか否か）は、デバイス機能記述において、モジュールそのものとは異なる位置に記述される。モジュール・エレメントは"Device"エレメントの子であり、"DeviceCap"エレメントの兄弟である。各モジュールの利用可能性は"ModuleCap"エレメントによって記述される。"ModuleCap"エレメントは"ModulePool"エレメントの子であり、"ModulePool"エレメントは"DeviceCap"エレメントの子である。次は、デバイス機能ファイルにおいて生成されるModuleエレメントの例示的な抜粋である。

"Module"、"ModulePool"および"ModuleCap"エレメントの構築はマッピング・ファイルを必要としないが、ModuleIDはUIConstraint文によって参照され、このUIConstraint文はステープルおよびパンチ機能といったマッピングされる機能をも参照しうる。

モジュールは、まずPPDファイル内で"InstallableOptions"というグループを位置特定し、PPDファイル中に見出された各インストール可能オプションについて出力デバイス機能ファイルに"Module"エレメントを追加することによって生成される。PPDにリストされている任意的な構成それぞれについて子"Module"エレメントがある。親"Module"エレメントの"ModuleID"属性はPPD中の機能名の値をもち、子"Module"エレメントの"ModuleID"属性はPPDファイル中に与えられた個々のオプション名の値をもつ。

"ModulePool"エレメントは、第一ステップにおいて生成されたそれぞれの最上位の"Module"エレメントについて、必要に応じて同じ"ModuleID"属性および"Availability〔利用可能性〕"属性が設定された（利用可能性がデジタル問い合わせまたは手動のユーザー介入によってのちに判定される場合には"Unavailable"〔利用不能〕に設定される）"ModuleCap"子要素を生成することによって生成される。

AuditPool
AuditPoolは、MacroPool、ResourcePoolおよびResourceLinkPoolと同じレベルのJDFジョブ・チケット中のXMLデータ・エレメントである。これは、ジョブ・チケットが生成、修正および実行された日時のようなプロダクション・データを記録するために使われる。これはPPDファイルからマッピングされる要素は含まないが、AuditPoolについてのテンプレートが、MacroPoolのデバイス独立マクロと同じ仕方で（すなわちResourcePool、ResourceLinkPoolおよびProcessPoolの兄弟として）、マッピング・ファイルに含められる。

デバイス機能生成器
上記の諸セクションは、デバイス機能ファイルを生成するために必要な機能のすべてを記述している。デバイス機能ファイルを生成するために、諸方法は、"/DeviceInfo/Device/DeviceCap"というXMLルートで始まり、次いでResourcePoolおよびResourceLinkPoolについてのDevCapsエレメントをDeviceCapの子として追加し、エレメントMacroPool、TestPool、ModulePoolおよびAuditPoolをDeviceの子（そしてDeviceCapの兄弟）として追加する。

チケット生成器
デバイス機能ファイルは、デバイス機能XMLをメモリにロードし、次いでMacrosまたは直接編集を使ってジョブ・チケット中の要素をモデル化するデバイス機能エレメントについて所望されるように"CurrentValue"属性を設定することによって、ジョブ・チケット生成のためのテンプレートのはたらきをするよう用意されてもよい。"Context"属性が"Element"に設定されたデバイス機能エレメントは、"JDF"ルート・エレメントの直接の子であるジョブ・チケット・エレメントにつながる。"Context"属性が"Resource"に設定されたデバイス機能エレメントは、ジョブ・チケット中のResourcePoolの子要素を生成し、"Context"属性が"Link"に設定されたデバイス機能エレメントは、ジョブ・チケット中のResourceLinkPoolの子を生成する。

生成されたデバイス機能ファイルに基づくジョブ・チケットの生成のための例示的なアルゴリズムは次のようになる：
１．デバイス機能ファイル中の"DeviceCap"エレメントの各"DevCaps"子について：
ａ．"Context"属性が"Element"であれば、出力ジョブ・チケットにおいてノード"/JDF"に移動し；そうでなければ、もし"Context"属性が"Resource"であれば、出力中のノード"/JDF/ResourcePool"に移動し；そうでなければ、もし"Context"属性が"Link"であればノード"/JDF/ResourceLinkPool"に移動
ｂ．"DevCaps"エレメントの"DevCap"子を取得し、以下を行う再帰関数を呼び出す：
ｉ．"DevCap"エレメントの"Name"属性の値に等しい名前をもつ、出力ジョブ・チケット中の新しいエレメントを開始
ｉｉ．"DevCap"エレメントの各子エレメントについて：
１．それがもう一つの"DevCap"エレメントであれば、再帰
２．そうでなければ、それがStringState、EnumerationState、IntegerState、DateTimeStateまたはXYPairStateであれば、
ａ．デバイス機能記述中の状態エレメントの名前をもつ、出力ジョブ・チケット中の現在のエレメントの属性を開始
ｂ．ジョブ・チケット中のその属性の値を、状態エレメントの"CurrentValue"属性の値に設定；そうでなければ
ｉ．状態エレメント中に"CurrentValue"属性がなければ、"DefaultValue"属性を使用；そうでなければ
１．状態エレメント中に"DefaultValue"属性がなければ、状態エレメント中の"AllowedValueList"属性において見出された最初の値を使用；そうでなければ
ａ．値が一つも決定できなければエラーにする
ｃ．出力ジョブ・チケットにおいてその属性を終了
ｉｉｉ．１．ｂ．ｉで開始した出力ジョブ・チケット中のエレメントを終了
２．ジョブ・チケットを終了。

チケット有効確認（validation）
ジョブ・チケットが有効確認されうる印刷ジョブ・プロダクションの種々のフェーズがあり、検査されうる有効確認の種々のレベルがある。プロダクションのフェーズは、ジョブ・チケット生成、ジョブ待ち行列提出およびジョブ実行を含む。チケット生成時の印刷ジョブ・チケット有効確認は、ホスト・ベースのクライアント・アプリケーションによって実行される可能性が高く、一方、実行時の有効確認はホスト・クライアントによって実行されうる。印刷ジョブ・チケット生成の時点でのこの有効確認は、上で論じたような生成されたデバイス機能ファイルのTestPoolおよびModulePoolを使用しうる。ジョブ・チケット生成の時点での有効確認は、生成されたジョブ・チケットが、同定された印刷デバイスによって実行されうる印刷ジョブについての有効な印刷ジョブ・チケットを表すことを検証しうる。換言すれば、同定された印刷システムは、現在構成設定されているか否かによらず、生成された印刷ジョブ・チケット中の機能を実行する能力をもつ。

さらに、いくつかの理由により、ホスト・システムは、後刻印刷されるべきジョブについての印刷ジョブ・チケットを生成することがある。たとえば、生成される印刷ジョブ・チケットは、のちの何らかの時点で印刷システムに送信するために待ち行列から出される（スプール解除される）よう待ち行列（たとえばスプール）に入れられてもよい。あるいは、たとえば、ユーザーは、何らかの指定された時刻にまたは指定された時刻より後に印刷システムに送られるべきであることを示す印刷ジョブ・チケットを生成してもよい。あるいは、さらなる例として、印刷ショップの運営者は、何らかの共通の仕上げ器コンポーネント構成設定をみな必要とする複数の印刷ジョブの実行を保留することがある。そのようなすべてのジョブが、運営者〔オペレーター〕がその特定の仕上げオプションを組み込むよう印刷システムを構成し直すつもりの後刻に「バッチ実行」されうるようにするためである。そのような場合、クライアント・ソフトウェア（たとえば印刷待ち行列／スプール管理モジュール）は、その生成後、二度目に、生成されたジョブ・チケットを有効確認してもよい。生成されたジョブ・チケットの二度目の有効確認は、生成されたジョブ・チケットによって表されるジョブが、その印刷ジョブの実行のために印刷システムに送られる直前に実行されてもよい。この第二のジョブ・チケット有効確認において、有効確認プロセスは、印刷システムの現在の構成を判別するために、印刷システムに問い合わせをしてもよい。こうして、生成されたジョブ・チケットの第二の有効確認は、印刷システムが、生成されたジョブ・チケットによって表される印刷ジョブの実行を許容するよう、現在構成されていることを検証する。

印刷システム内で、ジョブ・チケットが有効確認されるもう一つの機会がある。印刷システムはジョブ・チケットを受領し、処理するので、ジョブ・チケットは、印刷システム内でのその受領および／または実行と関連して三度目に有効確認されてもよい。この第三の可能な有効確認において、デバイス・ポストスクリプト・ファイルは、ジョブ・チケットにおいて指定されているJDF機能が現在の動作状態にある印刷システムの現在の構成について適切であることを検証するために使用されうる。制約情報もデバイス・ポストスクリプト・ファイル内にエンコードされうる。機能の組み合わせが、印刷システムによって、その現在の構成およびその現在の動作状態において実行されることができることを検証するためである。

こうして、ジョブ・チケット有効確認のさまざまなレベルは、製造業者によってサポートされる印刷装置のあらゆる可能な構成を含んでいてもよいし、あるいは現場で利用可能なオプションのアクセサリーおよび用紙種別の特定のセットで可能な構成のサブセットのみを含んでいてもよいし、あるいは現在構成されており現在動作的な印刷装置の現在デバイス構成のみを含んでいてもよい。

現在デバイス構成に対するジョブ・チケット有効確認は、次のようにしてホスト・ベースのクライアント・アプリケーションによって実行できる：
１．（PPDファイルから生成されたDevCapsファイルのModulePool中で定義されるような）インストール可能なオプションについてデバイス問い合わせストリングをプリンタに送る。インストール可能なオプションの名前についての値として応答を記録するよう注意を払い、それらが制約文によって参照されうるようにする（たとえば、返答が期待される「なし」「はい」「いいえ」「真」「偽」などとして記録されることを保証する）
２．"_Exclusions"で終わる名前をもつTestPool内のすべての"Test"エレメントを処理。いずれかの試験が真の値を返す場合、それは衝突がみつかったことを意味する
３．衝突がみつかったら、衝突が解決できるよう衝突の記述を呼び出し者に渡す
４．衝突がみつからなかったら、チケットが有効であることを示す結果を呼び出し者に返す。

現在の構成だけよりも幅広い範囲の構成について検査するために、上記のアルゴリズムのステップ１は、現時点においてデバイスに問い合わせを送信することによって得られる単一の応答だけではなく、DevCapsファイル中にリストされている可能な問い合わせ応答の二つ以上に対して制約が検査されることを許容するよう修正されてもよい。

プリンタ常駐JDFインタープリタによるデバイス上で実行されるジョブ・チケット有効確認は、次節で、デバイス・ポストスクリプト・ファイルの側面として記述される。

デバイス・ポストスクリプト・ファイル（Device PostScript File）
PPDファイルおよびマッピング・ファイルから導出されたデバイス機能ファイルから生成されたジョブ・チケットのプリンタ・ベースの処理は、チケット・プロセッサとデバイス機能生成器との間での、JDFエレメントおよび属性がPPDファイルにおいて指定されるデバイス機能にどのようにマッピングされるかについての合意を必要とする。これは、PPDおよびマッピング・ファイルを使って、チケット・プロセッサ（すなわち印刷システム）が、同じPPDによって記述されるデバイスについて生成されたいかなるジョブ・チケットについても適切なデバイス・コマンド・シーケンスを曖昧さなく決定するために必要な情報すべてを含むデバイス・ポストスクリプト・テーブルを生成することによって最も容易に達成される。PPDからの他の情報もデバイス・ポストスクリプト・ファイルに書き込まれてもよい。それには、たとえば：デバイス・コマンド順序および機能設定制約が含まれる。これは、「デバイス・ポストスクリプト・テーブル（device PostScript table）」（あるいは等価に「デバイス・ポストスクリプト・ファイル」）と呼ばれる。

ポストスクリプト・デバイス上でジョブ・チケットを処理するために必要な印刷プロダクション機能は二つの範疇にはいりうる：デバイス・コマンドによって実装されるもの（両面を設定するコマンドなど）とポストスクリプト回転コマンドのようなデバイス独立なポストスクリプト・コマンドによって実装されるものである。デバイス・コマンドはPPDファイルによって指定される。デバイス独立なポストスクリプト・コマンドは、マッピング・ファイルにおいて一般的な形で指定されることができる。

PPDファイルにおいて指定される各デバイス・コマンドには、コマンドが他のコマンドに対していつ実行されるべきかを（整数によって）指示する"OrderDependency"〔順序依存性〕文が伴う。いくつかのデバイス・コマンドは、それが制御するパラメータをそのデフォルト値に戻すことによって以前のコマンドを無効にすることがあるので、これは有用である。たとえば、新しいページ・サイズの設定は、両面モードを片面（すなわち両面オフ）にリセットすることがある。そのような場合、ページ・サイズ設定コマンドを両面設定コマンドより前に実行することが有用であろう。そのようなデバイスについてのPPDファイルでは、ページ・サイズのための順序値は、両面のための順序値よりも小さな数でありうる。それは、ページ・サイズが両面より前に設定されるべきであることを示す（逆に、大きな番号のコマンドが小さな番号のコマンドより前に実行されることもできる）。デバイス独立コマンドも、特定の順序で実行されることができるよう、順序値を割り当てられることができる。コマンド順序値は、デバイス・ポストスクリプト・テーブルにコピーされ、コマンド順序値はジョブ・チケット・プロセッサ（すなわち印刷システム）によって、ジョブ・チケット中のあるパーティションを出力文書のあるセクションについて（適正な順序で）実行されるべきデバイス・コマンドのセットに変換した後、そのデバイス・ポストスクリプト・テーブルから使用されることができる。デバイス・コマンドについてのコマンド順情報はPPDからデバイス・ポストスクリプト・テーブルに直接コピーされることができる。デバイス独立なポストスクリプト・コマンドについてのコマンド順情報は、マッピング・ファイルによって供給されてもよい。

PPD中の制約情報（たとえば、どの機能設定対が互いに両立できないかを示す制約情報）は、ジョブ・チケット有効確認における使用のためにデバイス・ポストスクリプト・ファイルに直接コピーされることはできない。ジョブ・チケット中で使われるJDF名ではなくPPD名を参照するからである。制約を表すデバイス・ポストスクリプト・ファイル中の結果として得られるデータ構造がジョブ・チケットを有効確認するためにジョブ・チケット・プロセッサによって使用できるよう、PPD名をJDF名にマッピングするためにマッピング・ファイルが使用されねばならない。JDFジョブ・チケットを有効確認するためのデバイス・ポストスクリプト・ファイル中の制約および他の情報の構造および使用に関するさらなる情報について以下に呈示する。

JDFプロセスは常に必要とするリソースと同じ名前をもつわけではない（たとえばプロセスColorSpaceConversion〔色空間変換〕はリソースColorantControl〔着色剤制御〕を使う）。チケット・プロセッサはパーティション分割されたリソース（これは出力文書の異なる諸部分を表す）を認識するべきなので、パーティション分割可能なリソースの名前の指示をもつことも助けになる。JDFジョブ・チケットでは、パーティション分割可能なリソースは、リソース自身と同じ名前をもちうる。このリソース／パーティション名は、マッピング・ファイルから供給されて、チケット・プロセッサによる使用のためにデバイス・ポストスクリプト・ファイル中にコピーされてもよい。チケット・プロセッサは次いで、出力中のさまざまなセクションについてのデバイス設定を示す、JDFリソース中のさまざまなパーティションを解釈する。

ProcessPoolに基づくデバイス・ポストスクリプト
マッピング・ファイル中のProcessPoolエレメントは、デバイス・ポストスクリプト・ファイルの構成について適切な構造を提供する。JDF規格が印刷ジョブをチケット・プロセッサによって実行されるべき一連のプロセスとして記述するからである。特定のジョブについてのプロセスのリストは、ジョブ・チケットにおいて、最上位の「JDF」ノードの"Types"属性のストリング値として、供給されてもよい。チケット・プロセッサに有用なデバイス・ポストスクリプト・テーブルは、PPDおよびマッピング・ファイルの組み合わせによって決定されるところのプロセス・リストに現れうるあらゆる名前についての項目をもつポストスクリプト辞書を有していてもよい（すべてのプロセスがすべてのデバイス上で利用可能でなくてもよい、たとえば綴じ）。各プロセス項目の値は、そのプロセスを実行するのに必要な情報を含んでいてもよい。この情報は、JDFジョブ・チケット中の特定の属性へのパス名、各属性についての特定の値をデバイス・コマンドおよびデバイス独立手順に関連付けるサブ辞書ならびにコマンド順序付け情報ならびに出力文書を異なる設定をもつ異なるセクションにどのようにして分割するかを指示する潜在的なパーティションの名前を含んでいてもよい。また、属性パス名情報は、JDFジョブ・チケットにおいて現れるリソース参照についての何らかの規約をサポートしてもよい。たとえば、"DigitalPrintingParams"エレメントの子である"MediaRef"エレメントの"rRef"属性など。

そのようなプロセス辞書はチケット・プロセッサによって、ジョブ・チケットの最上位の"JDF"ノードの"Types"属性におけるプロセスのリストを通じて逐次反復する際に使われてもよい。リストされる各プロセスの名前は、プロセス辞書において見出すことができ、位置特定された項目の値はそのプロセスを駆動するために必要な情報を含むサブ辞書であってもよい。このサブ辞書情報は、このプロセスについてのパーティション分割可能なリソースの名前を含むストリング値をもつ"PartitionName"のようなキーと、一つまたは複数のさらなるサブ辞書とを含みうる。さらなるサブ辞書のそれぞれは、一つまたは複数のJDF属性からデバイス・コマンド、デバイス独立ポストスクリプト手順または両者の組み合わせとそれに加えてコマンド順番号とを含む「コマンド・アレイ」へのマッピングを記述する。マッピングは、単一のコマンド・アレイにマッピングされるJDF属性の数の２倍に等しいノード深さをもつ階層的木構造によって記述できる：各属性のパス名を含む単一のノードと、属性の許容される値についての子ノードのサブレベルである。JDF属性がマッピングされる最後のものである場合、その子ノードはそれぞれ、適切なコマンド・アレイを含む子ノードをもつことになる。実際のジョブ・チケットにおいて当該属性が設定されうる値をもつ属性子ノードを選択することによって、チケット・プロセッサは処理されるべきコマンドを同定できる。JDF属性がマッピングされる最後のものでない場合、その子ノードはそれぞれ、マッピングされるべき次の属性を含む子ノードをもつことになる。多くの場合、次の単純化された例示的なデバイス・ポストスクリプト・テーブル項目に示される丁合（collate）機能のように、マッピングされる一つの属性しかない：

チケット・プロセッサは、次のアルゴリズムに従って上記の例を使用しうる：
１．ジョブ・チケットがDigitalPrintingプロセスを指定する場合、
ａ．/JDF/ResourcePool/DigitalPrintingParamsまでナビゲート
ｂ．現在のページまたはシートに一致するDigitalPrintingParamsパーティションをみつける
ｃ．一致したDigitalPrintingParamsノードから"Collate"属性の値をロード
ｄ．「None〔なし〕」の場合、
ｉ．200未満の順序番号をもつすべてのコマンドの実行後、
ｉｉ．200を超える順序番号をもつ何らかのコマンドを実行する前に、
ｉｉｉ．手順{<</Collate false>>setpagedevice}を実行
ｅ．「Sheet〔シート〕」の場合、
ｉ．200未満の順序番号をもつすべてのコマンドの実行後、
ｉｉ．200を超える順序番号をもつ何らかのコマンドを実行する前に、
ｉｉｉ．手順{<</Collate true /CollateDetails
<</Type 6 /AlignSet false>>
>>setpagedevice}を実行。

そのようなプロセス辞書は、チケット・プロセッサを実装するのを比較的容易にする。すべてのプロセスについてすべての機能を完了したとき、辞書は、特定のデバイス上でジョブ・チケットを解釈および実行するために必要なすべてのJDFおよびPPD情報を含む。

このプロセス辞書は、ページ・レイアウトおよびXML構文解析のようなタスクのためのデバイス独立な手順定義をも含むデバイス・ポストスクリプト・ファイルの一部であってもよい。このプロセス辞書は、PPDおよびマッピング・ファイルから直接生成できる。プロセス辞書中の属性パス名および許容される値は、同じPPDおよびマッピング・ファイルから生成されるデバイス機能ファイル中のパス名および許容される値に一致する。パス名および許容される値は、DevCapsエレメントおよびMacroPool中のマクロの両方によってデバイス機能ファイル中で参照される。こうして、マッピング・ファイルは、いかなる印刷デバイス上でも該印刷デバイスについてのPPDファイルが存在すれば完全なJDF作業フロー・システムの自動化された生成をサポートする。

PPDおよびマッピング・ファイルから生成された情報は、ジョブ・パーティション、リソース参照、複数製造業者およびカスタマイズ可能な機能性をもサポートしうる。下記の例示的なマッピング・ファイル抜粋は単一のプロセスおよびそれが必要とするリソースを記述する：

下記の例は、「OEM1」プリンタについてのマッピング・ファイルおよびPPDファイルの組み合わせから生成されたデバイス・ポストスクリプト・テーブル中のポストスクリプト辞書木構造である。このポストスクリプト辞書は、ジョブ・チケットのプロセス・ベースの解釈をサポートするよう設計される。ここで、最上位の"JDF"ノードの"Types"属性にリストされているプロセスが順番通りに逐次実行され、各プロセスによって必要とされるリソースはポストスクリプト辞書によって指定される。この例において記述されている単一のプロセスはColorSpaceConversionであり、上記のマッピング・ファイルの例と同じである。木構造の二つの葉がキー／値の対であることを注意しておく。ここで、キーはJDF設定の名前であり、値は順序番号および関連するデバイス・コマンドを含む手順を含むアレイである。

ポストスクリプト辞書木構造は、PPDコマンドがJDFジョブ・チケット中の複数の位置にマッピングされるときはより複雑になる。Stitchingプロセスについての下記の例示的な辞書項目は、ステープルのためのデバイス・コマンドの１０通りの異なる変形がそれぞれ、四つの異なるJDF属性値（三つはResourcePool中、一つはResourceLinkPool中）の一意的な組み合わせにマッピングされる様子を示している：

先の例におけるデバイス・ポストスクリプトは、印刷システム・チケット・プロセッサによって、次の例示的なアルゴリズムに従ってジョブ・チケットからデバイス・ステープル設定を確立するために使用されてもよい：
１．出力される文書の現在のセクションに適用されるジョブ・チケット中の"StitchingParams"パーティションを判別
２．このパーティションにおいて、属性/JDF/ResourcePool/StitchingParams/StitchTypeの値を取得
３．この属性の値（Corner〔隅〕、Side〔横〕またはSaddle〔中綴じ〕）を使ってマッピング・ファイル構造において一レベル下にナビゲート
４．ジョブ・チケットから属性/JDF/ResourcePool/StitchingParams/Angleの値を取得
５．この属性の値（0、45または90）を使ってマッピング・ファイルにおいて一レベル下にナビゲート
６．属性/JDF/ResourcePool/StitchingParams/NumberOfStitchesの値を取得
７．この属性の値（1または2）を使ってマッピング・ファイルにおいて一レベル下にナビゲート
８．属性/JDF/ResourceLinkPool/ComponentLink/Orientationの値を取得
９．この属性の値（Rotate0〔回転０〕、Rotate90〔回転９０〕、Rotate180〔回転１８０〕）を使ってアレイを選択し、次いで
ａ．50未満の順序番号をもつすべてのコマンドの実行後、
ｂ．50を超える順序番号をもつ何らかのコマンドを実行する前に、
ｃ．アレイに含まれる手順を実行。

こうして、デバイス・ポストスクリプト・テーブルは、ジョブ・チケット中の属性値から、印刷ジョブ中の各プロセスについて実行されるべきデバイス依存コマンドおよびデバイス独立手順の両方へのマッピングを指定する。

上記の諸例のポストスクリプト・コードのすべては、次の例示的なアルゴリズムを使ってPPDファイルおよびマッピング・ファイルから生成できる：
１．新しい出力ファイル中で新しいポストスクリプト辞書"JDFProcessDict"を開始
２．マッピング・ファイルのProcessPool中の各プロセスについて：
ａ．プロセスと同じ名前をもって出力ファイル中の新しい辞書を開始
ｂ．ProcessPool中のプロセス・エレメントの"Partition"子要素の"Name"属性の値をもってキー"PartitionName"を出力
ｃ．プロセス・エレメントの子孫であるすべての"JDFFeature"エレメントのすべての"Path"属性の値を集めるために再帰関数を呼び出す
ｄ．集められた各"Path"属性値について：
ｉ．そのパス値をポストスクリプト名に変換してそれを出力において開始された新しい辞書の名前として出力
１．パスがパーティション名を含まない場合、そのパスはパーティションから参照されねばならないので、ポストスクリプト名に変換する前に、パス中のトップ・リソース名の前にパーティション名に"/"を加えたもの挿入し、パス中のトップ・リソース名の終わりに"Ref/rRef"を加える
ｉｉ．マッピング・ファイルにおいてパスの位置までナビゲートし、そこに"JDFFeature"エレメントを見出し、このエレメントの各"Setting"子について：
１．ポストスクリプト・キーが"Setting"エレメントの"JDF"属性の値に等しく、ポストスクリプト値が"Setting"エレメントの"PS"属性の値に等しいポストスクリプト・キー／値対を出力
ｉｉｉ．２．ｄ．ｉで開始されたポストスクリプト辞書を終了
ｅ．マッピング・ファイルにおけるプロセス・エレメントの子孫であり、PPDファイルによって記述されるデバイスの製造業者の名前に等しい"OEM"属性をもつすべての"PPDFeature"エレメントを集めるために再帰関数を呼び出す
ｆ．集められたプロセス・エレメントの子孫である各"PPDFeature"について：
ｉ．マッピング・ファイルのResourcePoolおよびResourceLinkPoolにおける同じ"Name"および"OEM"属性をもつすべての"PPDFeature"エレメントを見出し、これらのPPDFeatureエレメントのXMLパスを集めるために再帰関数を呼び出す
ｉｉ．六つのパラメータをもつ別の再帰関数を呼び出す。六つのパラメータは：PPD機能の名前、前のステップで集められたXMLパスのリスト、リスト中のパスの数、リスト中の最初のパスに対応するマッピング・ファイル・ノード、0に初期化された現在の再帰レベルを示す整数、空のリストに初期化されたPPDオプションのリストである。この関数の各再帰について：
１．PPDファイル中にリストされているこの機能についてのすべてのオプションを集める
２．PPDからこの機能についてのOrderDependency数を得る
３．見出されたPPD機能が"Setting"子要素をもたない場合：
ａ．XMLパス名に等しい名前をもって出力中の新しいPS辞書を開始（PSシンタックスのためにスラッシュは別の文字で置き換える必要がある場合がある）
ｂ．この機能についてのPPDファイル中にリストされたすべてのオプションについて：
ｉ．オプション名をキーとしてもつ出力中のキー／値対を開始し、出力中の値としてアレイを開始
ｉｉ．アレイの第一の要素としてOrderDependency数を出力
ｉｉｉ．呼び出し値からPSコードを取得し、それをカーリー・ブレース〔中括弧{ }〕に入れて（それをPS手順にする）アレイの第二の要素として出力
ｉｖ．アレイを終了
ｃ．２．ｆ．ｉｉ．１で開始されたPS辞書を終了
４．そうでない場合、"PPDFeature"が"Setting"子要素をもつ場合、
ａ．各"Setting"エレメントについて：
ｉ．新しいリストを開始
ｉｉ．"Setting"エレメントの"PPD"属性からオプション名のリストを取得
ｉｉｉ．見出された各オプション名について、現在の再帰レベル・パラメータが0であれば、あるいはそのオプション名がPPDオプション・パラメータのリスト中に現れれば、それを新しいリストに追加
ｉｖ．新しいリストが空でなければ、
１．これがステップ２．ｆ．ｉｉ．４で逐次反復される最初の"Setting"エレメントである場合、現在の再帰レベル数によってインデックスされるXMLパス・パラメータ中のXMLパス名から形成される名前をもって出力中の新しい辞書を開始し、
ａ．そのパスがパーティション名を含まない場合、パーティションから参照されねばならず、よってポストスクリプト名に変換する前に、パーティション名に"/"を加えたものをパス中のトップ・リソース名の前に挿入し、パス中のトップ・リソース名の終わりに"Ref/rRef"を追加
２．現在の再帰レベルがXMLパス・パラメータ中のパスの数より1小さいものより小さい場合、
ａ．"Setting"エレメントの"JDF"属性の値から形成された名前をもって出力中の新しい辞書を開始
ｂ．ステップ２．ｆ．ｉｉ．４．ａ．ｉで開始された新しいリストが空でなければ：
ｉ．六つのパラメータをもつステップ２．ｆ．ｉｉにおける関数への再帰呼び出しをする。六つのパラメータは：PPD機能の名前、XMLパスのリスト、リスト中のパスの数、リスト中の現在の再帰レベルによってインデックスされるパスに対応するマッピング・ファイル・ノード、現在の再帰レベルを示す整数、２．ｆ．ｉｉ．４．ａ．ｉで開始された新しいリストである
ｃ．辞書を終了
３．そうでない場合、最後の再帰レベルに到達しており、ステップ２．ｆ．ｉｉ．４．ａ．ｉで開始された新しいリストが空でなければ、
ａ．リストが二つ以上の名前をもてば、エラー条件を生じさせて関数を抜ける
ｂ．そうでなければ、PPDファイル中の機能を探索して、リスト中のオプション名を探す
ｉ．"Setting"エレメントの"JDF"属性の値をキーとしてもつキー／値の対を出力し、値として出力中のアレイを開始
ｉｉ．アレイ中の第一の項目としてOrderDependency数を出力
ｉｉｉ．出力中の新しい手順を開始する"{"を出力
ｉｖ．ステップ２．ｆ．ｉｉ．４．ａ．ｉｖ．３．ｂにおいて同定されたPPD中のオプションの呼び出し値（invocation value）からPSコードを出力
ｖ．"Setting"エレメントが"PS"属性をもてば、その値に含まれているPSコードを出力
ｖｉ．手順およびアレイを終了する"}]"を出力
４．ステップ２．ｆ．ｉｉ．４．ａ．ｉｖ．１で開始された辞書を終了
ｇ．ステップ２．ａで開始された辞書を終了
３．ステップ１で開始された辞書を終了。

制約、インストール可能オプションおよびプリンタ・ベースのジョブ・チケット有効確認
プリンタ・ベースのJDFインタープリタは、相互に両立できない機能設定およびインストールされていない必須ハードウェア・オプションによって引き起こされるジョブ・チケット中のエラーに対する最終防衛ラインである。PPDファイルにおける"*UIConstraints"で始まるテキスト行は、両立できない機能設定の対をリストする。そのいくつかは"*OpenGroup: Installable Options"のもとにリストされるオプションのハードウェアを参照しうる。

PPD制約データを表すデバイス・ポストスクリプト・ファイル中のデータ構造は、制約中で名指しされている単一のPPD機能に複数のJDF機能がマッピングされうるという事実を考慮しなければならない。一つの例示的な実施形態は、二つのポストスクリプト辞書を設ける。第一の辞書は、PPD機能設定が一つまたは複数のJDF機能設定と関連付けられることを許容し、第二の辞書はPPD機能設定がそれと両立できない一つまたは複数の他のPPD機能設定と関連付けられることを許容する。第一の辞書を生成するためにはマッピング・ファイルが使用されねばならない。第二の辞書はPPDファイルから直接生成されうる。インストール可能なオプションを表す第三のポストスクリプト辞書がPPDファイルから直接生成されてもよい。

次は、アンダースコアを用いて機能および設定の名前を結び合わせて単一の名前を形成する技術を使って、デバイス・ポストスクリプト・ファイル中に生成されるべき三つの辞書の例である。

上の例において、三つのPPD機能設定名の対が与えられている。機能‐設定名は、辞書"OEM1ConstraintNames"におけるJDF機能設定名と、辞書"OEM1Installables"において定義される"Finisher"についてのデバイス問い合わせとを用いて定義される。

ポストスクリプトにおいて実装されるチケット・プロセッサは、デバイス・ポストスクリプト・ファイル中のこの情報を使って、次のアルゴリズムに従ってジョブ・チケットを有効確認する：
１．辞書OEM1Constraintsにおける各キー値対について
ａ．キーが辞書OEM1ConstraintNames内に存在する場合、その辞書を取得し
ｉ．辞書中の各キー値対について、キーによって同定されるJDFジョブ・チケット位置を探して、値によって同定される設定をもつかどうかを検査する；JDF位置のすべてが示された設定をもつ場合には、制約は検査されねばならない。そうでなく、辞書にリストされるJDF位置のいずれかが示される設定をもたない場合には、制約は検査される必要がない
ｂ．そうでない場合、（アンダースコアの前の）キーの第一の部分が辞書OEM1Installables内に存在する場合、値であるポストスクリプト手順を取得し、
ｉ．それを実行する。結果として得られるスタック上の名前ストリングがキー中のアンダースコアに続く名前と同じであれば、制約は検査されねばならない。そうでなければ、制約は検査される必要がない
２．ステップ１における試験が制約が検査されねばならないと決定する場合、OEM1Constraints辞書におけるキーに関連付けられた値である名前のアレイを取得しアレイ中の各名前について：
ａ．ステップ１におけるようにOEM1ConstraintNamesまたはOEMInstallablesのいずれかにおいてその名前を検索し、ステップ１ａまたは１ｂによって設定一致（setting match）が見出される場合には、衝突が同定されたことになり、ジョブ・チケットは有効ではない；逐次的評価プロセスを停止して逐次反復されたOEM1Constraints中のキーと衝突を同定したアレイ中の名前との両方をもつエラーを返す。

ｂ．そうでない場合、前のステップにおいて評価されたアレイ中の名前のいずれもジョブ・チケットの機能設定の一つに一致する機能設定につながらない場合には、制約は破られておらず、衝突は同定されていない。よって、辞書OEM1Constraints中のキー値対についての逐次反復を続ける。

上記のポストスクリプト辞書OEM1Installablesは、次のようにして、マッピング・ファイルを使うことなく、PPDファイルから直接生成できる：
１．出力デバイス・ポストスクリプト・ファイル中の"OEM1Installables"と名付けられた新しいポストスクリプト辞書を開始
２．PPDファイル中の"*OpenGroup: InstallableOptions"文と"*CloseGroup: InstallableOptions"文の間の各"*OpenUI"文について：
ａ．"*OpenUI"文と"*CloseUI"文との間に"*?"で始まる文である問い合わせがあれば、OEM1Installables辞書にキー値対を追加する。ここで、キーは"*OpenUI"キーワードに続く名前で先頭のアステリスクを除去したものであり、値はストリング"*?"のシーケンスに続くポストスクリプト問い合わせコードの引用されたストリングにキーワードを加えコロン文字を加えたものを含むポストスクリプト手順である
３．ステップ１で開始された辞書を終了。

二つのポストスクリプト辞書OEM1ConstraintNamesおよびOEM1Constraintsは、DevCapsファイル中の二つの部分からなるTestPoolデータ構造と同様の構造および内容をもち、同様の仕方でPPDおよびマッピング・ファイルから生成できる：
１．出力デバイス・ポストスクリプト・ファイル中の"OEM1ConstraintNames"と名付けられた新しい辞書を開始
２．PPDファイル中の各"UIConstraint"文における一意的な機能／オプション対それぞれについて：
ａ．マッピング・ファイルのResourcePoolおよびResourceLinkPool中のPPDFeatureエレメントのいくつが、"Name"属性の値としての機能名と、そのPPDFeatureエレメントの"Setting"子のいずれかのPPD属性に含まれるオプション名とを有するかを計数するための再帰関数を呼び出す
ｂ．PPDFeatureの計数値が0より大きければ、機能および設定の名前をアンダースコア文字によって結び合わせたものをキーとして出力辞書OEM1ConstraintNames中の新しいキー‐値の対を開始し、値として新しいサブ辞書を開始（すなわち、マッピングされない機能についてのキー‐対は出力されない）
ｃ．ステップ２．ａで関連するPPDFeatureエレメントを計数するのに使われたのと同様の再帰関数を呼び出すが、今回は、探索される機能／オプション対との一致を含むPPDFeatureエレメントの"Name"属性および"Setting"子要素の"PPD"属性のそれぞれについて、現在のサブ辞書中のキー‐値の対を出力。キーはマッピング・ファイル中のPPDFeatureの位置のパス名から形成され、値は"Setting"エレメントの"JDF"属性の値と同じ内容をもつストリングである
ｄ．ステップ２ｂにおいて開始されたサブ辞書を終了
３．ステップ１で開始された辞書"OEM1ConstraintNames"を終了
４．出力デバイス・ポストスクリプト・ファイル中の"OEM1Constraints"と名付けられた新しい辞書を開始
５．ステップ２でキー‐値の対が出力された、または機能名に等しいキーをもつキー‐値の対がOEM1Installables辞書中に存在する、PPDファイル中の各"UIConstraint"文における一意的な機能／オプション対それぞれについて：
ａ．機能および設定の名前をアンダースコア文字によって結び合わせたものをキーとして出力のOEM1Constraints辞書中の新しいキー‐値の対を開始し、値として新しいアレイを開始
ｂ．この機能／オプション対を禁止する他のすべてのUIConstraint文のリストを構築
ｃ．リスト中の各文について、禁止する機能および設定の名前をアンダースコアを用いて結び合わせることによって名前を生成
ｄ．リストから形成された各名前について、それがOEM1ConstraintNames辞書に存在するかどうか、あるいはその名前の最初の部分（禁止する機能名）がOEM1Installables辞書に存在するかどうかを検査
ｅ．ステップ５ｄにおけるいずれかの存在検査が「真」という結果になれば、形成された複合名を出力アレイに追加
ｆ．ステップ５ａで開始されたアレイを終了
６．ステップ４で開始されたOEM1Constraints辞書を終了。

OEM（「OEM1」「OEM2」および「OEM3」）について三つの値をサポートする完全なマッピング・ファイルの例が付録Aとして収録されている。

図８は、デバイス機能ファイルおよびデバイス・ポストスクリプト・テーブルを生成および利用する、本願の特徴および側面に基づくもう一つの例示的な方法を記述するフローチャートである。ステップ８００ないし８１６は、与えられたPPDファイルおよびマッピング・ファイルからデバイス機能ファイルを生成するよう、図１および図２に関して論じたようなコンピューティング・システム上で機能できてもよい。ステップ８００はまず、構文解析および処理を単純にするために、与えられたPPDファイルをXMLフォーマット木構造に変換する。上で論じたように、マッピング・ファイルは好ましくはすでにXMLフォーマットで記されており、よって処理を単純にするためにやはりXML木データ構造中に読み込まれてもよい。次いでステップ８０２は、マッピング・ファイル中のさまざまなオプションのうちで選択するべきOEM識別子を決定する。OEMは、与えられたPPDファイルにおいて指定されてもよいし、あるいは管理ユーザーによって手動で入力されてもよい。次いでステップ８０４は新しい装置機能出力ファイルを開始する。ステップ８０６はマッピング・ファイル中のAuditPool情報を対応するDevCapsフォーマットに変換し、変換された情報を新たに開始されたデバイス機能出力ファイルに追加する。ステップ８０８および８１０はそれぞれResourcePoolおよびResourceLinkPoolというマッピング・ファイル中の情報から、PPDファイル情報（XMLフォーマットに変換されたもの）と関連させて、対応するDevCaps項目を生成する。ステップ８１２は、PPDファイル情報と関連させてマッピング・ファイル中のTestPool情報に基づいてデバイス機能ファイル中の制約情報を生成する。ステップ８１４は、マッピング・ファイルおよびPPDファイルの情報に基づいてデバイス機能ファイル中に入れるMacroPool情報を生成する。ステップ８１６は、印刷システムのインストール可能なオプションに関し、マッピング・ファイル情報およびPPDファイル情報に基づいてデバイス機能ファイル中に入れるModulePool情報を生成する。

ステップ８１８ないし８２２は、マッピング・ファイルおよびPPDファイル中の情報に基づいてデバイス・ポストスクリプト・テーブルを生成するよう、（たとえば図１および図２の）コンピューティング・システム上で機能できてもよい。ステップ８１８は、生成デバイス・ポストスクリプト・テーブル情報を含むための新しい出力ファイルを生成する。気づかれるように、デバイス・ポストスクリプト・テーブルは、ポストスクリプト辞書構造として、あるいは印刷システムに送信され、印刷システムによって処理されるべき他の好適なデータ構造としてエンコードされうる。こうして、コンピューティング・システムによって生成されたファイルは、印刷システムに送られるべきデバイス・ポストスクリプト・ファイルを含むことになる。ステップ８２０は、マッピング・ファイルのProcessPool中の各要素について新しいポストスクリプト辞書構造を開始する。次いでステップ８２２はマッピング・ファイルのProcessPool項目によってマッピングされる各PPD機能またはJDF機能について辞書木を追加する。完成したデバイス・ポストスクリプト・テーブルを含むファイルは次いで記憶および利用のために印刷システムに送信される。

次いでステップ８２４は生成されたデバイス機能ファイルを、特定の印刷システムの適正な動作のための選択肢を手動で選択するためにユーザーによって提出されるマクロ選択に従って修正する。

次いでステップ８２６ないし８３２は、生成されたデバイス・ポストスクリプト・テーブルに従って印刷システムによって実行されるべき、生成されたデバイス機能ファイルに基づく印刷ジョブを生成するための処理を表す。ステップ８２６は、生成されたデバイス機能ファイルに基づいて、ユーザーにより供給されたオプションからJDFジョブ・チケットを生成する。次いでステップ８２８は生成されたジョブ・チケットを任意の必要とされるコンテンツ（印刷データ）ファイルと組み合わせ、ステップ８３０は組み合わされたジョブ・チケットおよび印刷ジョブ・データ（コンテンツ・ファイル）を印刷システムに送信する。

するとステップ８３２は、受信されたJDFジョブ・チケット中の選択されたパーティションおよびプロセスに基づいて、かつデバイス・ポストスクリプト・テーブル中に見出されるデバイス・コマンド・ストリングに従って、ジョブを処理するための印刷システムにおける処理を表す。

本稿では個別的な実施形態について記述したが、本発明の範囲はそうした個別的な実施形態に限定されるものではない。本発明の範囲は、付属の請求項およびその任意の等価物によって定義される。

付録
OEMについての３つの値：「OEM1」、「OEM2」および「OEM3」をサポートする完全なマッピング・ファイルの例。

１０２ JDFジョブ・チケット
１０４ 印刷ジョブ・データ
１０６ 印刷システム
１０８ プリンタ・コントローラ（たとえばポストスクリプト・コントローラ）
１１０ JDFジョブ・チケット処理コンポーネント
１１２ メモリ
１１４ 印刷ジョブ処理コンポーネント
１１６ マーキング・エンジン
１１８ 印刷ジョブ出力
１２０ デバイス・ポストスクリプト・テーブル
１２２ 任意的な制約情報
１５０ コンピューティング・システム
２００ プリンタ記述ファイル（たとえばPPD）
２０２ デバイス機能ファイル
２０４ マッピング・ファイル
２０６ 任意的な制約情報
２５０ 印刷システム初期化コンポーネント
２５２ 印刷ジョブ生成器コンポーネント
３００ 印刷システムのためにプリンタ記述ファイル（たとえばPPDファイル）およびマッピング・ファイルを提供
３０２ プリンタ記述ファイルおよびマッピング・ファイルから、JDF機能名をデバイス機能設定名と（任意的には制約情報と）関連付けることによって、デバイス機能ファイルを生成
３０４ プリンタ記述ファイルおよびマッピング・ファイルから、JDF機能名をデバイス機能設定名およびデバイス・コマンド・ストリングと（任意的には制約情報と）関連付けることによって、デバイス・ポストスクリプト・テーブルを生成
３０６ 生成されたデバイス・ポストスクリプト・テーブルを印刷システムに使用のために送信
３２０ ユーザー入力およびデバイス機能ファイルに基づいて印刷ジョブのためのJDFジョブ・チケットを生成（任意的に、デバイス機能ファイル制約情報に基づいて生成されるチケットを有効確認）
３２２ 任意的に、デバイス機能ファイル制約情報および現在の印刷システム構成に基づいてジョブ・チケットを有効確認
３２４ 生成されたJDFジョブ・チケットおよび関連付けられた印刷ジョブ・データを印刷システムに送信
３３０ 任意的に、デバイス・ポストスクリプト・テーブル制約情報および現在の印刷システム構成に基づいてジョブ・チケットを有効確認
３３２ デバイス・ポストスクリプト・テーブルに基づいて、JDFジョブ・チケット要素を変換してJDFジョブ・チケット機能についてのデバイス・コマンド・ストリングを生成
３３４ 生成されたデバイス・コマンド・ストリングおよび印刷ジョブ・データを実行して印刷出力を生成
４００ JDF
４０２ ProcessPool
４０４ ResourcePool
４０６ MacroPool
４０８ ResourceLinkPool
４１０ AuditPool
４２２ サブエレメント
４２４ サブエレメント
４２８ サブエレメント
５００ 入力PPDをXMLフォーマットに変換
５０２ PPDのOEMを判別
５０４ 新しいデバイス機能ファイルを開始
５０６ AuditPoolをDevCapsの形に変換し、デバイス機能ファイルに追加
５０８ マッピング・ファイルによって指令されるようにPPDデータを用いてResourcePoolについてのDevCapsを生成
５１０ マッピング・ファイルによって指令されるようにPPDデータを用いてResourceLinkPoolについてのDevCapsを生成
５１２ マッピング・ファイルによって指令されるようにPPD制約データを用いてTestPoolを生成
５１４ マッピング・ファイルによって指令されるようにPPDデータを用いてMacroPoolを生成
５１６ PPDファイルからのインストール可能なオプションを用いてModulePoolを生成
５１８ 新たなデバイス・ポストスクリプト・テーブルを開始
５２０ マッピング・ファイルのProcessPool中の各エレメントについて新たなポストスクリプト辞書を開始
５２２ ProcessPoolによってマッピングされる各PPD機能またはJDF機能について辞書木を追加
５２４ クライアントによって提出されるマクロ選択を処理し、デバイス機能ファイルをマークアップ
５２６ マークアップされたデバイス機能ファイルからジョブ・チケットを生成
５２８ ジョブ・チケットをコンテンツ・ファイルおよびデバイス・ポストスクリプト・テーブルと組み合わせる
５３０ 組み合わされた印刷ファイルをプリンタに送信
５３２ ジョブ・チケット中の各パーティションについて、ジョブ・チケット中にリストされる各プロセスについて、ジョブ・チケット設定によってマッピングされるところのデバイス・ポストスクリプト・テーブル中のコマンドを呼び出す

Claims (20)

1. 印刷システム上で印刷ジョブを印刷する方法であって：
   前記印刷システムについての、複数のエントリーを含むプリンタ記述ファイルであって、各エントリーはデバイス機能名およびデバイス機能設定名ならびに対応するデバイス・コマンド・ストリングを関連付ける、プリンタ記述ファイルを提供する段階と；
   複数のエントリーをもつマッピング・ファイルであって、各エントリーは一つまたは複数のジョブ定義フォーマット（JDF）機能名を一つまたは複数のデバイス機能名に、および一つまたは複数のデバイス機能設定名にマッピングするマッピング・ファイルを提供する段階と；
   コンピューティング・システムにおいて前記プリンタ記述ファイルおよび前記マッピング・ファイルに基づいて、デバイス機能ファイルを生成する段階であって、前記デバイス機能ファイルは複数のジョブ定義フォーマット（JDF）機能名のそれぞれを、対応する一つまたは複数のデバイス機能設定名に関連付ける、段階と；
   前記プリンタ記述ファイルおよび前記マッピング・ファイルに基づいて、デバイス・ポストスクリプト・テーブルを生成する段階であって、前記デバイス・ポストスクリプト・テーブルは、一つまたは複数のJDF機能名を一つまたは複数のデバイス機能設定名と、および前記一つまたは複数のデバイス機能設定名に対応する一つまたは複数のデバイス・コマンド・ストリングと関連付ける、段階と；
   前記コンピューティング・システムにおいて、前記デバイス機能ファイルに基づいて、印刷ジョブについてのJDFジョブ・チケットを生成する段階と；
   前記JDFジョブ・チケットと前記印刷ジョブに関連する印刷ジョブ・データとを、前記コンピューティング・システムから前記印刷システムに送信する段階と；
   前記印刷システム内で、前記デバイス・ポストスクリプト・テーブル内のエントリーに基づいて、前記JDFジョブ・チケットのエントリーを、対応するデバイス・コマンド・ストリングに変換する段階と；
   前記印刷システム内で、前記対応するデバイス・コマンド・ストリングおよび前記印刷ジョブ・データを実行して前記印刷ジョブについての印刷された出力を生成する段階とを含む、
   方法。
2. 請求項１記載の方法であって、
   前記デバイス機能ファイルを生成する段階がさらに：
   前記コンピューティング・システムにおいて、前記の生成されたJDFジョブ・チケットを有効確認するための制約情報を含む前記デバイス機能ファイルを生成することを含み、
   前記JDFジョブ・チケットを生成する段階がさらに：
   前記制約情報に基づいて前記の生成されたJDFジョブ・チケットを有効確認して、前記の生成されたJDFジョブ・チケットによって同定される印刷ジョブが前記印刷システムの何らかの可能な構成で実行されうることを確認する段階を含む、
3. 請求項１記載の方法であって、
   前記デバイス機能ファイルを生成する段階がさらに：
   前記コンピューティング・システムにおいて、前記の生成されたJDFジョブ・チケットを有効確認するための制約情報を含む前記デバイス機能ファイルを生成することを含み、前記制約情報は前記印刷システムの現在の構成を判別するためのデバイス問い合わせを含み、
   前記JDFジョブ・チケットを生成する段階がさらに：
   前記デバイス問い合わせの実行に対する応答に基づいて前記印刷システムの現在の構成を判別する段階と；
   前記制約情報および前記現在の構成に基づいて前記の生成されたJDFジョブ・チケットを有効確認して、前記の生成されたJDFジョブ・チケットによって同定される印刷ジョブが前記印刷システムの前記現在の構成で実行されうることを確認する段階を含む、
   方法。
4. 請求項１記載の方法であって、
   前記デバイス機能ファイルを生成する段階がさらに：
   前記コンピューティング・システムにおいて、前記の生成されたJDFジョブ・チケットを有効確認するための制約情報を含む前記デバイス機能ファイルを生成することを含み、前記制約情報は前記印刷システムの現在の構成を判別するためのデバイス問い合わせを含み、
   前記JDFジョブ・チケットを送信する段階がさらに：
   前記デバイス問い合わせの実行に対する応答に基づいて前記印刷システムの現在の構成を判別する段階と；
   前記制約情報および前記現在の構成に基づいて前記の生成されたJDFジョブ・チケットを有効確認して、前記の生成されたJDFジョブ・チケットによって同定される印刷ジョブが前記印刷システムの前記現在の構成で実行されうることを確認する段階を含む、
   方法。
5. 請求項１記載の方法であって、
   前記デバイス・ポストスクリプト・テーブルを生成する段階がさらに：
   前記コンピューティング・システムから受領されるJDFジョブ・チケットを有効確認するための制約情報を含む前記デバイス・ポストスクリプト・テーブルを生成することを含み、
   当該方法はさらに：
   前記印刷システムにおいて、前記制約情報に基づいて前記の生成されたJDFジョブ・チケットを有効確認して、前記の受領されたJDFジョブ・チケットによって同定される印刷ジョブが前記印刷システム上で実行されうることを確認する段階を含む、
   方法。
6. 請求項１記載の方法であって、
   前記印刷システムがポストスクリプト印刷システムであり、
   前記プリンタ記述ファイルを提供する段階がさらに：
   前記ポストスクリプト印刷システムのためのポストスクリプト・プリンタ記述（PPD）ファイルを提供することを含む、
   方法。
7. 請求項６記載の方法であって、さらに：
   前記デバイス・ポストスクリプト・テーブルが、前記ポストスクリプト印刷システムにおけるポストスクリプト辞書データ構造を含む、
   方法。
8. 請求項６記載の方法であって、さらに：
   前記デバイス・ポストスクリプト・テーブルが、前記ポストスクリプト印刷システムにおけるポストスクリプト・アレイ・データ構造を含む、
   方法。
9. 印刷ジョブに関連付けられたジョブ定義フォーマット（JDF）ジョブ・チケットを処理するためのポストスクリプト印刷システム・コントローラにおいて機能できる方法であって：
   前記ポストスクリプト印刷システム・コントローラ内に記憶されている、複数のエントリーをもつデバイス・ポストスクリプト・テーブルであって、各エントリーは一つまたは複数のJDF機能名およびJDF設定名を、所望のJDF機能を呼び出すために前記印刷システム・コントローラによって実行されるべきデバイス・コマンド・ストリングにマッピングする、デバイス・ポストスクリプト・テーブルを提供する段階と；
   JDFジョブ・チケットおよび関連する印刷ジョブ・データを受領する段階であって、前記JDFジョブ・チケットは一つまたは複数のJDF要素を有し、各JDF要素が所望されるJDF機能名および所望されるJDF機能設定名を指定する、段階と；
   一つまたは複数の所望されるJDF機能名および一つまたは複数の所望されるJDF機能設定名に基づいて前記デバイス・ポストスクリプト・テーブル内でエントリーを位置特定する段階と；
   位置特定されたエントリーの値フィールドを処理して一つまたは複数のデバイス・コマンド・ストリングを生成する段階と；
   前記一つまたは複数の生成されたデバイス・コマンド・ストリングおよび前記印刷ジョブ・データを処理して印刷された出力を生成する段階とを含む、
   方法。
10. 請求項９記載の方法であって、さらに：
    前記ポストスクリプト印刷システム・コントローラ内に記憶されている前記デバイス・ポストスクリプト・テーブルにおいて制約情報を提供する段階を含み、前記制約情報はJDF機能名およびJDF機能設定名の互いに相容れないグループを特定する、方法。
11. 請求項１０記載の方法であって、さらに：
    前記ポストスクリプト印刷システム・コントローラ内で、前記制約情報に基づいて、前記の受領されたJDFジョブ・チケットを有効確認する段階を含む、
    方法。
12. 請求項１０記載の方法であって、
    前記制約情報がさらに、ポストスクリプト印刷システムの現在の構成を判別するためのデバイス問い合わせコマンドを含み、
    当該方法がさらに：
    前記JDFジョブ・チケットが前記ポストスクリプト印刷システムによってその現在の構成において実行されうることを検証する段階を含む、
    方法。
13. 請求項９記載の方法であって、
    前記デバイス・ポストスクリプト・テーブルが、前記生成されたデバイス・コマンド・ストリングの処理の順序を定義する順序付け情報を含み、
    前記一つまたは複数の生成されたデバイス・コマンド・ストリングおよび前記印刷ジョブ・データを処理して印刷された出力を生成する前記段階が、前記デバイス・ポストスクリプト・テーブル内の前記順序付け情報によって定義される順序で実行される、
    方法。
14. コンピューティング・システムを有するシステムであって、前記コンピューティング・システムはさらに：
    複数のエントリーをもつマッピング・ファイルであって、各エントリーは、一つまたは複数のジョブ定義フォーマット（JDF）機能名を一つまたは複数のデバイス機能名に、および一つまたは複数のデバイス機能設定名にマッピングするマッピング・ファイルと；
    対応する印刷システムの利用可能なデバイス機能名およびデバイス機能設定名に関する情報を含むプリンタ記述ファイルと；
    前記プリンタ記述ファイルを受領するよう結合された印刷システム初期化コンポーネントとを有しており、
    前記印刷システム初期化コンポーネントは、前記プリンタ記述ファイルおよび前記マッピング・ファイルに基づいてデバイス機能ファイルを生成するよう適応されており、前記デバイス機能ファイルは、一つまたは複数の利用可能なデバイス機能設定名を一つまたは複数の対応するJDF機能名と関連付けるエントリーを有し；
    前記印刷システム初期化コンポーネントはさらに、前記プリンタ記述ファイルおよび前記マッピング・ファイルに基づいてデバイス・ポストスクリプト・テーブルを生成するよう適応されており、前記デバイス・ポストスクリプト・テーブルは、一つまたは複数のデバイス機能設定名および一つまたは複数の対応するJDF機能名を、印刷システムによって実行されたときに前記デバイス機能設定名を呼び出す一つまたは複数のデバイス・コマンド・ストリングと関連付けるエントリーを有し、前記初期化コンポーネントはさらに、前記デバイス・ポストスクリプト・テーブルを前記印刷システムに送信するよう適応されており；
    前記コンピューティング・システムはさらに：
    前記デバイス機能ファイルを受領するよう結合されたジョブ生成器コンポーネントを有しており、
    前記ジョブ生成器コンポーネントは、ユーザー入力に基づいて、かつ前記デバイス機能ファイル中の情報に基づいて、JDFジョブ・チケットを生成するよう適応されており、
    前記ジョブ生成器コンポーネントはさらに、前記デバイス・ポストスクリプト・テーブルに従って印刷された出力を生成するために、生成されたJDFジョブ・チケットおよび関連する印刷ジョブ・データを対応する印刷システムに送信するよう適応されている、
    システム。
15. 請求項１４記載のシステムであって、さらに：
    前記デバイス・ポストスクリプト・テーブルおよび前記JDFジョブ・チケットおよび前記関連する印刷ジョブ・データを受領するよう前記コンピューティング・システムと結合された印刷システムを有し、前記印刷システムがさらに：
    前記JDFジョブ・チケットの要素を前記デバイス・ポストスクリプト・テーブルに基づいてデバイス・コマンド・ストリングに変換することによって前記JDFジョブ・チケットを処理するよう適応されたJDFジョブ・チケット処理コンポーネントと；
    前記デバイス・コマンド・ストリングおよび前記関連する印刷ジョブ・データに基づいて前記の印刷された出力を生成するよう適応された印刷ジョブ処理コンポーネントとを有する、
    システム。
16. 請求項１５記載のシステムであって、
    前記印刷システム初期化コンポーネントがさらに、前記プリンタ記述ファイルおよび前記マッピング・ファイルに基づいて制約情報を生成するよう適応されており、
    前記印刷システム初期化コンポーネントがさらに、前記制約情報を前記対応する印刷システムに送信するよう適応されており、
    前記JDFジョブ・チケット処理コンポーネントがさらに、前記制約情報に基づいて、前記JDFジョブ・チケットを有効確認するよう適応されており、
    前記JDFジョブ・チケット処理コンポーネントがさらに、前記JDFジョブ・チケットが無効であると判定することに応答してエラーを信号伝達するよう適応されている、
    システム。
17. 請求項１６記載のシステムであって、
    前記制約情報が前記デバイス・ポストスクリプト・テーブルと統合されている、システム。
18. 請求項１４記載のシステムであって、
    前記印刷システム初期化コンポーネントがさらに、前記プリンタ記述ファイルおよび前記マッピング・ファイルに基づいて前記デバイス機能ファイル内の制約情報を生成するよう適応されており、
    前記ジョブ生成器コンポーネントがさらに、前記制約情報に基づいて前記JDFジョブ・チケットを有効確認するよう適応されている、
    システム。
19. 請求項１８記載のシステムであって、
    前記制約情報が、前記印刷システムの現在の構成を判別するためのデバイス問い合わせを含み、
    前記ジョブ生成器コンポーネントがさらに、前記デバイス問い合わせの実行に対する応答に基づいて、前記印刷システムの現在の構成を判別するよう適応されており、
    前記ジョブ生成器コンポーネントがさらに、前記JDFジョブ・チケットを生成する際に、前記制約情報および前記現在の構成に基づいて、前記JDFジョブ・チケットを有効確認するよう適応されている、
    システム。
20. 請求項１８記載のシステムであって、
    前記制約情報が、前記印刷システムの現在の構成を判別するためのデバイス問い合わせを含み、
    前記ジョブ生成器コンポーネントがさらに、前記デバイス問い合わせの実行に対する応答に基づいて、前記印刷システムの現在の構成を判別するよう適応されており、
    前記ジョブ生成器コンポーネントがさらに、前記JDFジョブ・チケットを送信するのに先立って、前記制約情報および前記現在の構成に基づいて、前記JDFジョブ・チケットを有効確認するよう適応されている、
    システム。
    

Images