(57)【要約】【課題】  ページ独立性を欠く印刷ジョブを複数の所定のジョブ部分に分割する方法であって、これらのジョブ部分が、複数の処理ノードにおいて、プリンタによる印刷のためのプリンタ依存フォーマットへと独立に処理され得るようにする方法を提供する。【解決手段】  印刷ジョブを独立に処理されるようになっている複数の所定のジョブ部分に分割すべき場合の独立処理時にエラーを通常生成することが知られている所定のトークン／イディオムに関して、印刷ジョブがサーチされる。このサーチにおいて発見された所定のトークンはセーブされる。印刷ジョブは、その後、複数の所定の部分に分割され、トークンは、その後、複数の処理ノードによる処理中の処理独立性を保証するために、分割されたジョブ部分に関連付けられる。【選択図】          図１
2004310762.tif 000002
【特許請求の範囲】
【請求項１】
ページ独立性を欠く印刷ジョブを複数の所定のチャンクに分割する方法であって、前記チャンクは、プリンタによる印刷のためのプリンタ依存のフォーマットへと独立に処理され得る、前記方法において、
前記印刷ジョブを前記複数の所定のチャンクに分割すべき場合の独立処理時にエラーを通常生成することが知られている所定のトークンに関して前記印刷ジョブをサーチし、
前記サーチで発見された前記所定のトークンをセーブし、
前記印刷ジョブを前記複数の所定のチャンクに分割し、
前記サーチで発見された前記所定のトークンを前記複数の所定のチャンクの少なくとも１つに関連づけて該１つの所定のチャンクの処理独立性を保障する、
ことを特徴とする方法。
【請求項２】
前記複数の所定のチャンクをプリンタ依存のフォームへ処理することを更に備える請求項１記載の方法。
【請求項３】
前記処理は複数の処理ノードを使用する請求項２記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷システム、更に言えば、複数の分離部分にジョブを分割して独立した複数部分の独立処理を助長する印刷ジョブのための処理ステップに関する。
【背景技術】
【０００２】
印刷システムによって印刷される印刷準備ドキュメントの生成には、所望の文書を見、処理し、出力するために必要とされる全ての情報（内容、グラフィック、製造仕様等）を印刷エンジンによって理解可能な電子フォームで獲得することが必要である。このようなシステムは、パーソナルコンピュータシステムの消費者ユーザによく知られている簡易で妥当な価格のものから、フルカラーで毎分何百ページも生成できる商業的印刷システムにまで及ぶことがある。しかしながら、あらゆるシステムは印刷をより高速に実行することを目標として高くかかげている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
故に、印刷システムの効率とスピードの改善という絶え間ない欲求の下において、単なるジョブ若しくはページ並列処理に限るのでなく、印刷システムに対する印刷ジョブの制御とデータフローを助長する一方で、独立に且つ並列に処理され得る複数の印刷ジョブ部分に印刷ジョブを分割することができるシステムが必要である。どのようにして印刷ジョブをよりよく分割し、その一方でページ若しくはチャンク並列処理を確実ならしめるのかが本発明の主題である。
【０００４】
並列な処理に加えて、ページ独立性が有用な他の様々な理由が存在する。文書マネジャーは、ページに上向きに印刷するプリンタにおいて印刷前にドキュメントのページの順番を逆転することを求められるかもしれない。ユーザは、元々の印刷プロセスにおける若しくはその後の処理におけるエラーの可能性故に、長いドキュメントの一部のみを再印刷することを望むかもしれない。この場合、文書マネジャーは、印刷準備フォームへ変換される前に、所望のページを含むサブドキュメントをドキュメント全体から抽出することを求められるだろう。これらのいずれの場合にあっても、文書マネジャーは、印刷準備フォームへ変換されたときは、ドキュメント全体が物理的に印刷されて、その後に、機械的に逆転されたもの（第１の場合）若しくはより多くの（物理的な）ページのセットから抽出された所望のページのいずれかと、同じページのセットを生成するような有効なドキュメントを構築しなければならない。所定のページの内容が従前のページの内容に依存するとき、従来技術を使用することは不可能である。この場合、ページ独立性は犯されてしまっている。いずれかの所定のページの内容が、いずれにしても処理された従前のページに依存しないとき、ドキュメントはページ独立である。
【０００５】
適合（準拠）すべき（conformant）ポストスクリプトマスターのため、Ａｄｏｂｅ開発支援ウェブから利用できるＡｄｏｂｅ’報告＃５００１，ポストスクリプト言語ドキュメント構造化規約（ＤＳＣ）仕様によって特定される文法にそれは従わなければならない。多くのポストスクリプトマスターがこれらのルールに違反してはいるが、いまだにかなりの量の適合ドキュメントが存在する。これには幾つかの理由が存在する。先ず、これらの規約が現在１０才に近づきつつあり、それらのソフトウェアを改変するには所定のアプリケーションとドライバ書き手の時間が必要なこと、以前のＤＳＣソフトウェアについては使用できなくなっていることである。第２に、問題のポストスクリプトマスターは、複数のアプリケーションの小さなセット（若しくは、他のアプリケーションによって呼び出されるより限定されたドライバのセット）によって全て自動的に生成されることである。これらのアプリケーションでさえ適合ドキュメントの生成に失敗した場合、それは非常に限定された方法である。経験がこの点をものがたっている。大部分のアプリケーションは適合ポストスクリプトを生成するようにみえるが、その一方で、例外的なものは予測可能な方法で違反しているようにみえる。
【０００６】
ドキュメント管理システムは、しばしば、ジョブサブ設定やページ再順序付け（一般にはページ逆転）といったタスクの実行を求められる。そのようなシステムの必要性はスプリッター（分割装置）についてもまったく同様である。このスプリッターは、ジョブを複数の独立したページ若しくはグループに分割する。ここで、分割された各グループは、印刷時には、それら各グループが生み出されたジョブの環境から取り除かれてしまっているにもかかわらず正確に印刷しなければならない。
【０００７】
故に、完全な適合ドキュメントでページを操作することに制限されず、適合に近い（類似する）ルールを予測可能な方法で違反するようなドキュメントを取り扱うことができるシステムが必要である。そのようなシステムが本発明の主題である。
【０００８】
規約は、特別にフォーマットされたコメントに含まれる材料（データ）を記述する。このことは、ポストスクリプトドキュメントは、正確に印刷するために適合させる必要がないことを意味する。ＤＳＣ適合ドキュメントは、”％！ＰＳ−Ａｄｏｂｅ−3．0＜ｔｙｐｅ＞opt”で始まる。ここでタイプは、それが定型ファイルか、エンカプセルド（カプセル化された）ポストスクリプトファイル（ＥＰＳＦ）か、若しくは、キュエリー（質問）、イグジットサーバ、若しくはリソースタイプかを示す。本発明において問題となるのは、主に、タイプが与えられていない定型ファイルと、定型ファイルのサブドキュメントとして出現するＥＰＳＦである。ドキュメントマネジャー（スプリッターであってよい）は、このコメントで開始した場合は文書は適合していると仮定するものと予想される。バージョン２．１を有するファイルも等しくページ独立であることが経験から分かっている。
【０００９】
規約は、文書をプロローグとスクリプトを含むものとして記述する。プロローグは、ドキュメントが分割されるときに全てのサブドキュメントの最初にコピーされなければならない材料を含み、スクリプトは、独立ページ材料の後にこれまたコピーされなければならない少量を含む。それは、”％％ＢｅｇｉｎＳｅｔｕｐ:”コメントで始まり、”％％ＥｎｄＳｅｔｕｐ:”コメントで終わるものであって、最初の”％％Ｐａｇｅ:＜ｌａｂｅｌ＞#”コメントのすぐ後に続くべきものである。
【００１０】
ページの内容は通常は”％％Ｐａｇｅ: ”コメントで始まり、”％％ＰａｇｅＴｒａｉｌｅｒ:”コメントで終わるが、”％％ＰａｇｅＴｒａｉｌｅｒ:”コメントは任意である。
【００１１】
規約仕様は、ドキュメントには％％ＥＯＦは１つしか現れるべきでないこと、及び、ドキュメントマネジャーは最初の出現をファイルの終了を示すものととらえるべきであること、を明確に示している。しかしながら、ＰａｇｅＭａｋｅｒTMは、（％％ＥＯＦを含めた）多数のドキュメントを１つのファイルへとアペンディングする（後尾に追加する）ことによってそれらを結合することが知られている。これは、適合におけるエラーの、容易に認識されるお決まりの一例である。
【００１２】
コメント構造化規約に加えて、クリエーターは、”％％ＰａｇｅＯｒｄｅｒ: Ｓｐｅｃｉａｌ”コメントを用いてクリエーターが知らせることを許された予告記載とともに、全てのページに必要とされる全てのポストスクリプト材料を最初の”％％Ｐａｇｅ: ”コメントの前に置かなければならない。ドキュメントマネジャーがこのコメントをみた場合、ドキュメントマネジャーはそのドキュメントはページ独立ではないと仮定するものと通常は予想される。しかしながら、少なくとも１つのアプリケーションは、常に、そのシーケンスを使用して、ページ独立性を必要とするいずれかのドキュメント管理特性を効果的に無効化してしまう。不正確な出力を生成することなくドキュメントマネジャーが”％％ＰａｇｅＯｒｄｅｒ: Ｓｐｅｃｉａｌ”（既知のアプリケーションについてのもの）を無視できるようにすることが本発明の目標である。
【００１３】
故に、印刷ジョブの所定部分の独立した取扱を邪魔することが知られている予め選択されたトークン若しくはイディオム（慣用語）を識別するシステム若しくは方法が必要である。印刷ジョブはその後、印刷ジョブ自体の調整は最小としてその分割を助長するように調整される必要がある。本発明はこれらの必要を満たし、上に特定した問題を他の問題と同様に克服するものである。
【課題を解決するための手段】
【００１４】
現代のアプリケーションやドライバによって一般に生成されるような、ほぼページ独立のドキュメント印刷ジョブでは、クリエーターを識別するために、印刷ジョブのファイルのヘッダ材料に十分な情報が存在する。ある所定のイディオム若しくはトークンを含めることによって不正確なファイルやページ独立適合ではないファイルを生成してしまうことが知られているそれらのクリエーターに対しては、複数の分離されたページに分割されたときにファイルの処理を失敗させてしまうようなそれらファイル内のイディオムに対してサーチが実行される。ファイルを複数のページ若しくはチャンクに分割している間に矯正動作が実施され、それらのファイルは、安全に記録され、解釈され、及び／又は、ページ若しくはチャンク独立性を必要とする他のいずれかの方法で取り扱われ、並列に印刷され、サブセットされ得る。本発明を実施することにより、多数のプリンタにおけるページ並列印刷や、ＲＩＰ前のページ逆転、サブセットＲＩＰや印刷に加えて、ページ並列なＲＩＰ（ラスタライジング（rasterizing）画像処理）が助長される。
【００１５】
本発明は、満足のいく定義語を発見できない並列処理をユニークに実施するものであり、したがって、本願出願人自身の辞書編集（法）として機能するものであり、本願出願人は、この概念を「チャンク」並列処理と呼ぶことにしている。チャンク並列処理は、ジョブ並列処理とページ並列処理の中間レベルの並列処理である。チャンクは、少なくとも１つのページと１つ以下のジョブから成るラスタライズドデータ（rasterized data）の集合である。チャンクは、ジョブ全体よりも少ない整数ページであってもよいが、ページベース毎とは対称的にチャンクベースで出現するラスタライジングオーバヘッドを有する。
【００１６】
本発明の印刷システムは、プリンタと、印刷ジョブの一部をプリンタ依存のフォーマットへ処理するために各々が設けられているような複数の処理ノードと、独立処理のため複数の処理ノードによってプリンタ依存のフォーマットへ印刷ジョブを複数の分離部分に分割するような処理マネジャーとを備える。処理マネジャーは、独立処理のための印刷ジョブの複数部分への分割を邪魔することが知られている印刷ジョブ内の所定のイディオムを識別する手段を有する。処理マネジャーは、分割中に、分離部分に対し、印刷ジョブを操作するイディオムに関連付けられた印刷ジョブの所定の識別イディオム若しくは部分を付加し、処理を成功させる。これらのイディオムは印刷ジョブのヘッダに付けられ、各分離部分の前に付される。
【発明を実施するための最良の形態】
【００１７】
本発明は、より高速の印刷システム、特に、全てのページがカラーで且つ異なっていてもよいシステムに加えて、取り分けジョブの所定部分が特別の処理を必要とするような印刷ジョブをより良く扱うといった絶え間ない欲求に向けられている。このシステムは、並列処理を活用して、そのスピードと、更には、ジョブ並列処理やページ並列処理に制限されていた従来の印刷システムでは知られてない並列処理の実施を助長するものである。本発明は、ここでは「チャンク」並列処理として定義した中間レベルの並列処理を活用することができる。印刷ジョブデータのチャンクは、少なくとも１つのページと１つ以下のジョブから成るラスタライズ可能なデータの集合を備えるようになっている。ジョブ並列処理は、ジョブが最小のチャンクサイズよりも小さいときに出現し、ページ並列処理は、チャンクサイズが０（バイト／ページ）のときに出現する。本発明は、ジョブ、ページ、若しくはチャンク並列処理のいずれに対しても、印刷ジョブを複数の部分に分割するのに有用である。
【００１８】
本発明は、大まかには、ジョブを複数チャンクのセット（これらは結合されて文書の全体を形成する）に分割するといった流れで記載されている。しかしながら、他のアプリケーションが存在する。スプリッターは、ページ逆転の問題に容易に適合する。最も簡単な実施では、複数の単一ページチャンクが生成され、その後、それらのページチャンクが逆の順番で集められて、逆転させたドキュメントを形成する。この逆転ドキュメントは、これにより、シリアル若しくはパラレルシステムを用いて印刷され得る。幾分ではあるが、より効率的なアプローチは、ヘッダに存在すべきであるが存在しなかった材料を発見するような文書を通じた単一パス（通過）を行い、それをヘッダにアペンディングし、その後、そのヘッダを１回だけ逆順の全てのページに続いて出力するというものである。
【００１９】
他のアプリケーションは、ドキュメントの特定のサブセットを必要とするようなジョブサブ設定である。スプリッターは印刷すべき最初のページに達するまで何らの出力をも生成せずに進行してもよい。その後、それは要求された全てのページ（それらは隣接するものであってもなくてもよい）を含む単一のチャンクを形成する。チャンクは、この時点で、所望のサブセットを含む。このチャンクは、この時点で、シリアル若しくはパラレルシステムを用いて印刷され得る。並列ケースにおける、より効率的なアプローチは、印刷すべきではないページはスプリッターに抑制させるが、あたかもサブ設定しているかのように多数のチャンクを同じ方法で生成するというものである。
【００２０】
本願の従来技術の欄に述べた要件に加え、適合には他の多くの要件がある。それらのほとんどは以下の記載に現れる。パーサ（構文解析系）／スプリッター（本発明の１つの実施形態を実施するようになっている）は、一部においてはドキュメントの適合（故に分割可能性）における信頼レベルを向上させるため、また、一部においては何らかの既知のエラーが（クリエーターに基づいて）求められるかどうかを判断するため、多くの要件をチェックする。
【００２１】
グラフィック印刷を発生するのに特に有用な２つのよく知られたシステム、即ち、Ｑｕａｒｋ（登録商標）とＰａｇｅｍａｋｅｒ（登録商標）は、ＤＳＣ適合であるにもかかわらず、ページ独立性の違反を含むことが知られている。Ｑｕａｒｋ（登録商標）とＰａｇｅｍａｋｅｒ（登録商標）は共に、しばしば、それが最初に使用される直前に（つまり、最初のページの開始後に）フォントを定義し（それらはフォントを発見し、それに変形を加えて、汎用辞書に格納するように見える）、後続のページにおいては、再定義することなくそれを使用する。それらは共に、この方法で定義したフォントが、” ”（６つのアンダースコア（下線）文字）で始まる名前を汎用辞書に有する。これら２つのクリエーターによって生成されたマスターを固定するため、ドキュメントマネジャーは、最初の”％％Ｐａｇｅ: ”コメントの後の６−アンダースコアイディオムをチェックする。これは、トークン’ ’を含めるために辞書分析器が発見するトークンのリストを増強することによって、第一に、”＜ｅｏｌ＞％”と”％％”のためのフラグを既に含むテーブルへ’ ’を付加することによって、第二に、ダブル（二重）アンダースコアが発見されたときは付加的なアンダースコアの正しい数をチェックすることによって、実行される。（ドキュメントマネジャーは、ファイルを一度に２バイトスキャンし、テーブルルックアップを使用して２バイトシーケンスがコメントの開始かどうかを判断することを思い出してほしい）。これは、このイディオマティックな（慣用的な）エラーを含まないＱｕａｒｋ（登録商標）やＰａｇｅｍａｋｅｒ（登録商標）ファイルに対してはオーバヘッドをほとんど生じさせることはなく、他のタイプのファイルに対してもオーバヘッドをほとんど生じさせない。
【００２２】
一旦、６−アンダースコアトークンが発見されると、別個のクリエーター依存のルーチンが呼び出されて、そのトークンの前後の正しいラインのセットを正確に捕獲し、これらは、全ての後続ページ（しかし、現在のものに対してではない）の前に付される（接頭辞として付けられる）ようにして、既に捕獲されたヘッダセクションのテキストの終りに付けられる。
【００２３】
以下の例は、ドキュメントにページ独立性を喪失させるようなポストスクリプトコードの一部を示す。これは単なる一例であり、ＱｕａｒｋＸＰｒｅｓｓファイルで見つかるイディオムの典型である。
【００２４】
【数１】
2004310762.tif 000003
【００２５】
このポストスクリプトフラグメントは、フォントを突き止め、それに変形を加え、それを”ＱｕａｒｋＸＰｒｅｓｓ 4．04”と名づけられた汎用辞書の記号”| 55−Ｈｅｌｖｅｔｉｃａ−Ｒｏｍａｎ”を用いて記憶する。それは、多数のパラメータ（数字と名前）を特定し、従前に定義されたプロシージャ（”ｘｐｂｕ”と”ｘｐｂｎ”ような）を呼び出すことによってこれを実行する。この全てが、ページ１の一部であるべきであってドキュメントヘッダの一部ではないドキュメントの部分で実行される（その後に最初の”％％Ｐａｇｅ: ”コメントが続く）。ドキュメントマネジャーがドキュメントをそのヘッダ材料へ分割し、その後、その部分だけをページの各々に対して前付加する場合（つまり、"%%Page: "で始まり、次の”％％Ｐａｇｅ: ”の直前若しくはファイルの終りで終了する部分）、ドキュメントは印刷に失敗するだろう。なぜなら、後のページは記号”| 55−Ｈｅｌｖｅｔｉｃａ−Ｒｏｍａｎ”を参照するからである。
【００２６】
特に図１、図２を参照する。本発明のシステムアーキテクチャ、データフローの制御、及び処理ステップは、プリンタ１０や印刷管理にジョブを提供する責任がある処理ノード１２によって管理されるような印刷エンジン１０を備える。印刷ジョブが印刷システムに提供されると、入力スプーリングシステム１４は、その内容をメモリ内かディスク上にセーブする。ジョブを提供したノードはまた、印刷ジョブの到来をファシリティー（機能）オブジェクトマネジャー１４にアドバイスする。ファシリティーオブジェクトマネジャー１４は、印刷ジョブ言語、ジョブサイズ、どのように／どこでメモリシステム内の印刷ジョブデータを発見するかを識別するような、必要な監督機能を引き起こす処理マネジャーセンブリとして機能する。データのロケーションを伝達するため、分散システムのためのネットワークファイル名や中央化システムのためのメモリアドレスを含む幾つかの既知のメカニズムのいずれを用いることもできる。処理マネジャーノード１４はまた、印刷ジョブを複数の部分に分割するスプリッターを含む。これら複数の部分は、複数の独立のオペレーティング処理ノード（ＲＩＰ）から成る共通（一般的な）デコンポーザ（分解）ファシリティー１６で独立に処理され得る。この共通デコンポーザファシリティーは、その入力フォームの印刷ジョブからプリンタ１０へ提供するためのプリンタ依存準備フォームへの翻訳を行う。
【００２７】
本発明は、より詳細には、ファシリティーオペレータ１４は、どのようにして、複数のＲＩＰにおける独立処理のための保証された独立性である複数のジョブチャンクにジョブを分割するのかに関する。第１のステップは、印刷ジョブをサーチして、印刷ジョブを複数の独立部分に分割すべき場合の独立処理時にエラーを通常生成することが知られているイディオム若しくはトークンが存在するかどうかを検証すること２０を備える。言い換えれば、ある所定のイディオム（例えば、フォント操作を伴うことが知られているが、生成される独立ページ並列処理のための複数ページへのジョブの分割を邪魔するような印刷ジョブ内のロケーションに配置されているイディオム）が識別され得るということである。イディオム若しくはトークンは、フォント操作や他のタイプのジョブ内容操作のように何らかのそのような操作を引き起こす印刷ジョブの部分を意味する。そのようなイディオムの含有が検証された後、そのイディオムに関連付けられた印刷ジョブの部分がセーブされ２２、ページ独立性を保障する印刷ジョブの異なるロケーションへの移動や付加を助長する。ファシリティーオブジェクトマネジャーは、ＲＩＰ処理に最も適したいかなる部分、つまりページ若しくはチャンクへも、印刷ジョブを分割することができる２４。イディオムに関連付けられたセーブ部分は、その後、複数の分割チャンクへ前付加され（つまり、その前に付加され）２６、これにより、チャンクの独立性を保証して共通デコンポーザファシリティーにおける処理を成功させる１６。これらのチャンクはその後、ファシリティー１６で処理される２８。
【００２８】
最初の”％！ＰＳ−Ａｄｏｂｅ−3．0”コメントの後は、残り全てのＤＳＣコメントで、新たなライン若しくはキャリッジリターン文字（ＡＳＣＩＩ１３及び１０）や２つの”％”で始まる文字が先行する。こうして、それらは、ファイル２バイト（１つのショートワード）を一度にスキャンし、ショートワード毎に単一のテーブルルックアップを用いることによって、実行中のポストスクリプトで発見され得る。ファイルの最初の部分はコメントのみを含み、この部分に対してはバイト整列サーチを使用するのがより有効である。最初の非コメントラインで、パーサはショート整列サーチへ切り替わる。フライ上にルックアップテーブルを構築することによってパーサはバイトオーダ依存性からも守られる。
【００２９】
このようなイディオムを発見して必要な部分をセーブし、それを後続ページに前付加するアルゴリズムは以下の通りである。
１．          ＱｕａｒｋＸｐｒｅｓｓ，１によって創り出されたことが知られているフ
ァイル内で”％％Ｐａｇｅ: ”コメントを発見した後ｆｏｕｎｄ＝「誤」
を設定
２．          次のラインの終りに進む
３．          ＳｔａｒｔｉｎｇＰｏｓｉｔｉｏｎ１を現在のラインの開始の位置に設定
４．          ＳｔａｒｔｉｎｇＰｏｓｉｔｉｏｎ２を０に設定
５．          最大２８ラインに対して
５．１．      現在のラインが”％％ＱＲＫＳｅｑｕｅｎｔｉａｌＰａｇｅ: ”で始まる
場合
５．１．１．  ｆｏｕｎｄを値「真」に設定し、このループに残る（ステップ６へ）
５．２．      現在のラインが”ｉｎｉｔｉａｌｉｚｅｐａｇｅ”で始まる場合
５．２．１．  ｅｎｄｉｎｇｐｏｓｉｔｉｏｎ１をラインの従前の終りのロケーションに
設定
５．２．２．  ｓｔａｒｔｉｎｇｐｏｓｉｔｉｏｎ２を現在のラインの従前の終りのロケ
ーションに設定
５．３．      次のラインへ進む
６．          ｆｏｕｎｄが「誤」の場合、停止（イディオムは発見されなかった）
７．          ｆｏｕｎｄ＝「誤」を設定
８．          次のラインに進む
９．          現在のラインが”ＱｕａｒｋＸＰｒｅｓｓ”で始まらない場合、停止（イ
ディオムは発見されなかった）
１０．        ｍｏｒｅ＝「誤」を設定
１１．        最大３０ラインに対して
１１．１．        現在のラインが６つのアンダースコアを含む場合
１１．１．１．    ｆｏｕｎｄ＝「真」を設定
１１．１．２．    ｍｏｒｅ＝「真」を設定
１１．１．３．    このループに残る（ステップ１２へ進む）
１１．２．        次のラインへ進む
１２．            ｆｏｕｎｄが「誤」の場合、停止（イディオムは発見されなかった）
１３．            ｍｏｒｅが「真」の場合
１３．１          最大４ラインに対して
１３．１．１．    現在のラインが”ｘｐｂｎ”で始まる場合
１３．１．１．１．  このループを出る（ステップ１４へ進む）
１３．１．２．    次のラインへ進む
１３．２．        ｅｎｄｉｎｇＰｏｓｉｔｉｏｎ２を現在のラインの終りに設定
１３．３．        ステップ１０へ進む
１４．            ｓｔａｒｔＰｏｓｉｔｉｏｎ１からｅｎｄｉｎｇＰｏｓｉｔｉｏｎ１
に、且つ、ｓｔａｒｔＰｏｓｉｔｉｏｎ２からｅｎｄｉｎｇＰｏｓｉ
ｔｉｏｎ２へ、位置をセーブ
【００３０】
累積したセーブ部分はその後、ヘッダ部分のテキストへアペンディングされる。その後、単一のラインである
ｅｎｄ
が続き、ＱｕａｒｋＸＰｒｅｓｓ−４．０４ｂｅｇｉｎによって開かれた辞書を閉じる。
【００３１】
この全シーケンスは単なるヘッダ部分のテキストの代わりに使用され、ページ並列印刷若しくはバック−トゥー−フロント（後から前）印刷の場合は全てのページに先行し、また、サブセット印刷の場合は全ての独立のページのブロックに先行する。
【００３２】
上の方法が実行するのは、
・イディオムがファイルで使用されることを検証すること
・フォント操作を実行する部分をセーブして、初期ページ（initializepage）を省くこと
・セーブされた部分で開始／終了対を整合させること、である。
【００３３】
この方法では、フォント定義がヘッダセクションに配置されることを確実ならしめることによって、後続ページは従前のページと独立とされ得る。
【００３４】
幾つかのファイルは、”％％ＩｎｃｌｕｄｅＲｅｓｏｕｒｃｅ: ”コメントを、上とほぼ同じ方法でフォントを定義する前に含み、そのトークンがファイルレベルで発生したときは（閉鎖ドキュメント（enclosed documents）においてではなく）、同様の処理が続く。
【００３５】
１つの他のエラーモードが、ＰａｇｅＭａｋｅｒで発見された。ＰａｇｅＭａｋｅｒは、ユーザに、複数の独立ファイルからドキュメントを構築することを許す。ユーザがそうするとき、発行されたポストスクリプトマスターは、複数の適合ドキュメントを互いに結びつけるものとなり、これによって標準に違反して複数の”％％ＥＯＦ”コメントを含む。これらのマスターのため、ドキュメントマネジャーはファイルの終りの後にチェックを行い、それが本当に物理的なファイルの終りにあるかどうかを調べ、その後、ループバックして、新たなドキュメントのパーズ（解析）を試みる。
【００３６】
まとめると、本発明の本質は、ほぼページ独立のＰＤＬファイルの複数部分を自動的に編集してそれらをページ独立とし、その後、ページ独立を要求する、ページ逆転、ページ並列印刷、若しくは、サブセット印刷のような、いずれかの動作を用いて続けることである。この方法は、「あるパターンは、それらがページ独立性に違反する何かを行っているときを除いてファイルに決して現れることはない」という事実に依った、また、それらのファイルは簡単な編集動作によって容易に固定されることに依った、イディオム認識技術を用いる。
【図面の簡単な説明】
【００３７】
【図１】本発明によって形成された印刷システムの制御及びデータフローのためにアーキテクチャを示すブロック図である。
【図２】本発明による印刷ジョブを処理するための方法を要約したフローチャートである。
【図１】
2004310762.tif 000004
【図２】
2004310762.tif 000005