(57)【要約】  ページ記述言語（ＰＤＬ）で記述されておりページ間非依存性に欠けるデータストリームを効率的に処理可能な方法及び装置を提案する。本方法及び装置では、ＰＤＬジョブを単一パスでパーシングし、クリエータスニファ（８３）を用いそのジョブのプロデューサを検出し、リソーススニファ（８５）を用いそのジョブから共有リソースを検出し、ページ情報スニファ（８４）を用いそのジョブからページ境界を検出し、そしてデータ及びリソースの順序が変わらないようそのジョブの整然化表現（６３）を生成する。このシステムでは、そのストリームの順序変更無しでＰＤＬデータストリームが効率的に且つページ、データ又はリソース単位で整頓される。その整然化データは複数個のＰＤＬプロセッサ（６５）へと効率的に提供できる。
2012517635.tif 000002
【特許請求の範囲】
【請求項１】
ページ記述言語（ＰＤＬ）で記述されページ間非依存性に欠けている印刷ジョブを、ページ間非依存性が不要で且つ複数個のプロセッサで効率的に分割処理可能な表現へと整頓する方法であって、
上記印刷ジョブを単一パスでパーシングするステップと、
上記印刷ジョブのプロデューサを検出するステップと、
上記印刷ジョブから共有リソースを検出してマーキングするステップと、
ページ特性部を検出、マーキング及び抽出するステップと、
上記印刷ジョブからページ境界を検出してマーキングするステップと、
上記諸ステップでの検出結果に従い且つデータ及びリソースの順序が変わらないよう上記印刷ジョブの整然化表現を生成するステップと、
を有する方法。
【請求項２】
請求項１記載の方法であって、上記ページ特性部をＰｏｓｔＳｃｒｉｐｔ（登録商標）インタプリタで解釈し上記印刷ジョブに係るページプロパティを求める方法。
【請求項３】
請求項１記載の方法であって、上記印刷ジョブがＰｏｓｔＳｃｒｉｐｔ（登録商標）ジョブである方法。
【請求項４】
請求項１記載の方法であって、マーキングを上記印刷ジョブ内で実行する方法。
【請求項５】
請求項１記載の方法であって、上記整然化表現から上記印刷ジョブの一部分を指し示す形態でマーキングを実行する方法。
【請求項６】
請求項１記載の方法であって、上記整然化表現が小規模な表現である方法。
【請求項７】
ページ記述言語（ＰＤＬ）で記述されておりページ間非依存性に欠ける印刷ジョブを整頓する装置であって、
上記印刷ジョブを単一パスでパーシングする手段と、
上記印刷ジョブのプロデューサを検出する手段と、
上記印刷ジョブから共有リソースを検出してマーキングする手段と、
ページ特性部を検出、マーキング及び抽出する手段と、
上記印刷ジョブからページ境界を検出してマーキングする手段と、
各ページのグラフィクス状態を定めるコマンドを検出する手段と、
上記諸手段での検出結果に従い且つデータ及びリソースの順序が変わらないよう上記印刷ジョブの整然化表現を生成する手段と、
上記リソースを実行する手段と、
グラフィクス状態を指定するコマンドを各ページの冒頭に付加する手段と、
そのページを送信する手段と、
を備える装置。
【請求項８】
請求項７記載の装置であって、上記ページ特性部をＰｏｓｔＳｃｒｉｐｔ（登録商標）インタプリタで解釈し上記印刷ジョブに係るページプロパティを求める装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷システム、表示システム、ＰＤＬ解析システム、ＰＤＬ変換フレームワーク等からの求めに応じ、ＰＤＬ（ページ記述言語）データからページプロパティを効率的に抽出する方法及び装置に関する。
【背景技術】
【０００２】
ＰｏｓｔＳｃｒｉｐｔ（登録商標；以下「ＰＳ」と略し注記省略）は本件技術分野で習熟を積まれた方々（いわゆる当業者）にとり周知で、印刷ジョブ内ページ記述に使用可能なコマンドに富むＰＤＬである。ＰＳは他種ＰＤＬ、例えばＩＰＤＳ、ＰＤＦ、ＰＣＬ、ＰＰＭＬ（いずれも登録商標；以下注記省略）等と大きく違い、それ自体がプログラミング言語となっている。そのため、ページ内コンテンツを豊富且つ柔軟に表現することができるが、その柔軟性が仇となり、ＰＳ言語でジョブを記述するとページ解釈(interpret)が面倒になることが多い。ＰＳジョブに対するページ解釈を正確化し、有意なＰＳジョブ変換を実現するには、ＰＳ用のインタプリタが必要となる。そうしたＰＳインタプリタの例としては、ＰＳジョブを処理してビットマップを生成するＡｄｏｂｅ（登録商標；以下注記省略）ＣＰＳＩ(Configurable PostScript Interpreter)（商品名）、ＰＳジョブを処理してビットマップではなくＰＤＦファイルを生成するＡｄｏｂｅＤｉｓｔｉｌｌｅｒ（商品名：以下注記省略）等がある。
【０００３】
１９８４年の発表以来、ＰＳ言語には幾つかの限界、例えば
ａ）ＰＳジョブをプリンタ定格動作速度で処理することができないという速度限界
ｂ）ＰＳジョブを１ページ毎に分割できず、従って複数個のＣＰＵ(central processing unit)を使用し複数枚のページを並列的に処理することができない、という分割不可能性
ｃ）指定されたページを効率的に印刷することができず、従ってページ範囲を指定しての再印刷を効率的に行えない、というページ印刷不効率性
があることが判明し、世界中の技術者達がその克服のため様々な技術を開発してきた。
【０００４】
性能問題の子細、経験的事実の概要、ひいては後述する発明を理解するには、ここで、一般的なＰＳインタプリタについて説明しておいた方がよいだろう。まず、ＰＳジョブを処理する際には、多少重複もあるが解釈段階と出力段階の二段階が実行される。
【０００５】
・解釈段階では、同じくインタプリタ言語であるＰｅｒｌ、Ｊａｖａ（いずれも登録商標）等と同様に、ＰＳジョブをパーシング（構文解析）してジョブ内構造を導出する。例えば、高次乃至低次グラフィカルオブジェクトについてのリンクリスト乃至樹状構造、複雑なジョブ内ページ記述等、固有の表現形式をとるジョブ内構造を導出する。
【０００６】
・出力段階では、そのジョブ内構造を処理して必要な出力を生成する。印刷システムなら個々のページをレンダリング（描画）し、得られたラスタデータ（生ビットマップ等）をプリンタ等に送信する。ＡｄｏｂｅＤｉｓｔｉｌｌｅｒならＰＤＦファイルを生成する。他の形式の出力、例えばＡＦＰ（登録商標；以下注記省略）／ＩＰＤＳでの出力も同じ要領で生成することができる。
【０００７】
往時には、その段階からもたらされる情報量に従い解釈段階が軽い段階、出力段階が重い段階であるとされていた。テキスト及びグラフィクスを含む典型的なＰＳジョブ内ページの原情報量が１００ＫＢ程度であるところ、そのレンダリングで得られる６００×６００ｄｐｉ（ドット／インチ；１インチ＝約０．０２５ｍ）ＣＭＹＫ画像の生ビットマップは１００ＭＢ程度と、原情報量の１０００倍にも上っていたからである。
【０００８】
そのため、ＰＳ言語の発表当初から、「対架空装置書込」によるレンダリング飛ばしが技術者達の手で導入され、非特許文献１の全バージョンで引き継がれてきた。架空装置(null-device)を設定してレンダリングを飛ばした後、実在装置を再定義してレンダリングを再開させる、という手法である。この手法を用いページを飛ばす場合、解釈したページのレンダリングが飛ばされることになる。こうしたページ飛ばし機構を使用するページ単位並列処理方式としては、図１に示すものがいわゆる当業者の手で実現されている。
【０００９】
図１に示す方式では、４個あるプロセッサそれぞれに丸ごとのＰＳジョブ１１を供給し、個々のプロセッサで一部のページだけを飛ばさせ、残りのページを処理させている。例えば、１個目のプロセッサ１２は第１、５、９、…ページを、２個目のプロセッサ１３は第２、６、１０、…ページを、３個目のプロセッサ１４は第３、７、１１、…ページを、そして４個目のプロセッサ１５は第４、８、１２、…ページを処理している。自明な通り、プロセッサ現在負荷、ページ難度等の特性を踏まえるより秀逸な負荷バランスアルゴリズムを使用することもできる。後述する諸構成にも同様の負荷バランス思想を適用することができる。
【００１０】
この方式の長所は容易に理解することができる。例えば、あるジョブを１個のＣＰＵで処理したとき１００秒かかったとする。また、無難に考え、解釈速度がレンダリング速度の４倍であるとする。これらの仮定の下では、解釈に２０秒、レンダリングに８０秒が費やされているはずである。その点、図１に示した方式であれば、各プロセッサが別々にジョブ全体を解釈するため解釈に２０秒かかるものの、プロセッサ毎のレンダリング所要ページ数が全ページ数の１／４に留まるためレンダリングには２０秒しかかからない。即ちジョブ全体の処理が４０秒で済む。これは１００／４０＝２．５倍の性能向上である。
【００１１】
図２に示すように８個のプロセッサを用い、処理を解釈段階と出力段階に分け別々のプロセッサに実行させてもよい。インタプリタ（解釈用プロセッサ）２２でＰＳデータストリームを解釈してレンダラ（レンダリング用プロセッサ）２６に送るパイプライン処理が、前述のページ単位並列処理に加え実行されることとなる。このように、８個のプロセッサを用い解釈段・レンダリング段間パイプラインを並列稼働させると、前掲の例ならジョブ全体が約２０秒で処理されることとなる。これは１００／２０＝５倍の性能向上である。
【００１２】
図２に示した方式が完全に不都合無しに稼働するのは、解釈所要時間がレンダリング所要時間に比べ十分に短い場合である。これが成り立っていたのは以前のことであり、解釈・レンダリング間バランスには１９８４年当時から見て大きな変化が生じている。例えば
ａ）速度性能向上のため、非常に効率的なレンダリングシステム及び専用ハードウェアを用いるレンダリング技術に企業が巨費を投じたこと
ｂ）マルチＣＰＵシステムの安価化が進み、メインストリームＣＰＵ技術における最近のトレンドが個々別々のＣＰＵとして振る舞うプロセッサコアを複数個有する汎用ＣＰＵとなり、近未来に８コア、１６コア、３２コア等のＣＰＵが実現される展望が生じたこと
ｃ）非常に複雑なグラフィクス及び大きな画像を含み、解釈段階で重い処理が必要になるジョブが、非常に多くなったこと
ｄ）印刷速度が劇的に高まり、１００ｐｐｍ（ページ／分）、更には１０００ｐｐｍ超にも達したこと
による変化である。
【００１３】
こうした変化が生じた結果、個々のプロセッサで丸ごとのＰＳジョブを解釈する対架空装置書込では、処理速度を向上させることができなくなった。寧ろ、本質的にシーケンシャルな処理である解釈が、印刷上のボトルネックになるに至った。個々のインタプリタにおけるジョブ解釈に同じ時間（２０秒）が費やされるため、例えば図２の構成にプロセッサを追加しても性能は向上しない。
【００１４】
図２中のインタプリタそれぞれに同じジョブが重複供給されていることに鑑みれば、図３に示すように、解釈段階をまとめて単一のプロセッサに担わせるのが一策となりうる。同図に示す集中解釈方式では、集中インタプリタ３２がＰＳジョブ１１を解釈し、個別のページ３３を含むジョブ内構造（表示リスト）を幾つか導出し、その表示リストを個別のレンダラ３４に供給している。図２に示した方式に対するこの方式の主たる長所は、同等の性能を僅か５個のＣＰＵで実現できることである。更に、インタプリタ３２として強力なＣＰＵを使用することで、解釈のボトルネック化を幾分であれ緩和することができる。
【００１５】
この方式の難点は複雑性、即ちＰＳジョブ用プロセッサを集中インタプリタと個別ノード用レンダラとに分けるのが面倒なことである。その実現には大規模なコード変換及びそれを実行するためのソースコードが必要になる。大問題なのは、このやり方でもインタプリタがボトルネックになることである。先の数値例からもわかる通り、レンダラ３４の個数を増やしても性能向上にはつながらない。
【００１６】
以上のことからわかるのは、インタプリタがボトルネックにならない方法及び装置を実現して処理速度を高めることや、インタプリタにおけるコード変換が不要な方法及び装置を実現することが望まれている、ということである。
【００１７】
図４に、集中解釈方式の別例たるＰＤＦ媒介方式を示す。この方式では、ＰＳ−ＰＤＦコンバータ４２がＰＳジョブ１１をＰＤＦジョブ４３に変換し、そのジョブ４３をＰＤＦディストリビュータ４４が複数個のプロセッサ４５に分配する。ＰＳジョブ１１からＰＤＦジョブ４３への変換には様々なＰＤ−ＰＤＦ変換ユーティリティを使用することができる。最も有名なのはＡｄｏｂｅＤｉｓｔｉｌｌｅｒであろう。
【００１８】
複数個のプロセッサ４５へのＰＤＦジョブ４３の分配も様々な手法で行うことができる。例えば、
ａ）丸ごとのＰＤＦジョブを全プロセッサに送ると共に、レンダリング対象ページを個々のプロセッサに指示する、という手法
ｂ）ＰＤＦジョブを一群の単一ページＰＤＦファイルに変換してプロセッサに送り、プロセッサでは単一ページＰＤＦファイルのうち自分がレンダリングすべきページに係るものだけを受け取る、という手法
ｃ）ＰＤＦジョブを一群の単一ページＰＳファイルに変換してプロセッサに送り、プロセッサでは単一ページＰＳファイルのうち自分がレンダリングすべきページに係るものだけを受け取る、という手法
ｄ）単一ページファイルへの変換に伴う潜在的リソースオーバヘッドを抑えるため、単一ページ毎にではなくページチャンク（幾ページかの集まり）毎のＰＤＦ又はＰＳファイルへと変換し、対応するプロセッサに分配する、という手法（丸ごとのＰＤＦジョブをプロセッサ個数と同個数（上の例では４個）の部分に分割するようにしてもよい）
等である。
【００１９】
こうしたＰＤＦ媒介方式は実用的な処理であり、業界でよく知られているものでもあるが、前述した集中解釈方式のそれに類する大きな短所、即ちＰＳインタプリタであるＰＳ−ＰＤＦコンバータがボトルネックになる、という短所も抱えている。更に、ＰＤＦ形式への変換はコンバータにとり大きな負担になることが知られている。これもボトルネックの狭窄につながる。こうしたボトルネックはプロセッサ追加によるシステム拡張に際し支障となりうる。
【００２０】
なお、図４中のＰＳ−ＰＤＦ変換を別種の変換に置き換えること、例えばＰＳ−ＰＳ変換、ＰＳ−ＡＦＰ変換、ＰＳ−ＸＰＳ（登録商標）変換等に置き換えることも可能であるが、これらのコンバータもＰＳインタプリタの一種であるので、前述した集中解釈方式やＰＤＦ媒介方式のそれに類する大きな短所が生じ、プロセッサ追加によるシステム拡張が妨げられることに変わりはない。
【００２１】
以上のことからわかるのは、インタプリタでの処理がボトルネックにならない方法及び装置を実現して処理速度を高めることや、ＰＳ−ＰＤＦ等の言語変換を伴わない方法及び装置を実現することが望まれている、ということである。
【００２２】
ＰＳジョブの非構造性にまつわる問題については、Ａｄｏｂｅ社が１９８６年にＤＳＣ仕様書バージョン１（非特許文献２）、１９９２年に同バージョン３．０（非特許文献３）を刊行している。ＤＳＣ仕様書のなかで最もよく知られているのはバージョン３．０であり、そこには「並列印刷」なる名の章が設けられている。この章には、ページ単位並列印刷が可能でないと対ＤＳＣ適合性のあるＰＳジョブとは認められない、と述べられている。
【００２３】
ＤＳＣ仕様書では、ＰＳで記述されているリソースのパーシングやページの並べ替えを容易に行えるようにする一群のタグを定めている。更に、ＰＳジョブ生成手段（プロデューサ）に対し、対ＤＳＣ適合性を認めて欲しければ生成するＰＳファイル中に「％！ＰＳ−Ａｄｏｂｅ−３．０」との記述を挿入するよう求めている。実際、大抵のプロデューサが、ファイル中に「％！ＰＳ−Ａｄｏｂｅ−３．０」を挿入するよう構成されている。しかし、そうして生成されるファイルのほとんどに、対ＤＳＣ適合性が備わっていないのが実情である。
【００２４】
ともあれ、ＰＳジョブの大群を成功裏に個別ページへと分割できることも経験的にわかっている。それには、ＤＳＣコメントやプロデューサ別パターンをパーシングすればよい。この処理は若干複雑であるが、１９８８年以降、幾つかの企業がその方式をうまく使いこなしている。例えば、Ｐｒｅｐｓ（登録商標）のＣｒｅｏ社やＦａｒｕｋｈ社等、複数の企業がこの方式を組版に適用している。即ち、並列印刷に比べかなり複雑な処理である組版を、この方式で実行できるようにしている。これらの企業は、様々な大規模ベンダからもたらされるＰＳジョブをページ間非依存性のあるものに変換する技術に加え、別々のアプリケーションで生成されたＰＳジョブ同士を結合させ、そのページ間非依存性が更に高いＰＳジョブを生成する技術も有している。
【００２５】
同時に、組版とは違い、印刷システムには
ａ）ＰＳ組版ソフトウェアよりも信頼性が高いこと、例えばより大群のＰＳジョブを処理することができ、またＤＳＣ及びパターン認識法で処理できなかったジョブについて忌憚なく報告することができること
ｂ）ＰＳ組版ソフトウェアに比べかなり高速であること
も求められる。
【００２６】
以上のことからわかるのは、既存のＤＳＣ利用システムに比べ信頼性や速度が顕著に高い方法及び装置を提供することが望まれている、ということである。
【００２７】
図５に、ページ単位並列処理方式でのそれに類する複雑性や非効率性が概ね生じないジョブ単位並列処理方式を示す。この方式では、複数個のプロセッサ５５で複数個のＰＳジョブ５１が並列的に処理されるため、解釈段階分離やジョブのページ単位分割によるオーバヘッドが本質的に発生せず、短小ジョブの大群を非常に効率的に処理することができる。即ち、ある短小ジョブに関する印刷が終わるまでに、別の短小ジョブの処理を済ませて印刷待ち状態にすることができる。逆にいえば、この方式は
ａ）最初のジョブがマルチプロセッサ方式の恩恵を受けない
ｂ）プリンタが前のジョブに係る印刷を終えるまで、ジョブ処理用のプロセッサが、大量のページストレージを使用しながら長時間に亘りアイドル状態になる
等の点で長大ジョブの処理に適していない。
【００２８】
この短所が特に強く現れるのはそのＰＳジョブが非常に長大な場合である。例えば、ＣｒｅｏＶＰＳ（登録商標；以下注記省略）等のＰＳ方言で表記されたＶＤＰ(variable data printing)（登録商標；以下注記省略）ジョブは、１０００００ページを超える長さになることがあり、その実行には多くの日数がかかる。こうしたジョブを処理する場合、ジョブ単位並列処理方式では、プロセッサのうち１個のみが使用され残りがアイドル、という状態が長く続くことになる。
【００２９】
翻って、対ＤＳＣ適合性に関していうと、対ＤＳＣ適合性に欠けるジョブには
ａ）ジョブ内ページ境界が曖昧でその特定が難しい（ジョブ構造曖昧性）
ｂ）複数ページに跨ると見られる所在特定困難なリソースがどのページにも含まれうる（ページ間依存性）
といった大問題がある。
【００３０】
なお、ＰＳプロデューサの動作で、全リソースをそのジョブのヘッダに移動させればよいのだが、そうするにはジョブ生成に当たり
ａ）全ページを解析してリソースを検出する解析パス
ｂ）個別ページの書込が終わるまで待ちリソースをジョブのヘッダに書き込む出力パス
の２パスに亘る処理を実行する必要がある。
【００３１】
アプリケーションによる高速ページ生成がプリンタによるページ出力と同等かそれ以上に重要であることや、従来はＰＳプロデューサに対しページ間非依存性が求められていなかったことを考えれば、ＰＳジョブにページ間依存性が生じるのは自然なことである。
【００３２】
こうした状況は、近年新たなＰＤＬ、例えばＰＰＭＬが導入されたことに伴い幾らか変化した。ＰＰＭＬはＸＭＬ利用ＶＤＰ言語、即ち高速印刷の実現に特化した言語であり、全ての大手プリンタコントローラ製造業者が参加し大手文書複製業者も多数参加している規格化委員会ＰＯＤｉによって制定されたものである。ジョブ構造上の問題に関しては、ＰＰＭＬ規格では、ある種のＸＭＬタグの挿入を義務づけることに加え、
ａ）ＰＰＭＬジョブが幾つかの文書セットから構成されること
ｂ）文書セットが幾つかの文書から構成されること
文書が幾枚かのページから構成されること
を規定し対処している。
【００３３】
ＰＰＭＬ規格では、こうしてページ構造への考慮が払われている。しかし、ページ間依存性の問題が解決されないままである。即ち、ＰＳジョブと同じくＰＰＭＬジョブでも、ページ内リソースが複数ページに跨っていることがある。これは、２パスに亘るデータ処理を回避しページ出力を超高速化するため、ＰＯＤｉメンバの総意で決定された事項である。結局、ＰＰＭＬで記述されたページは
ＢｅｇｉｎＰａｇｅ
データ，リソース，リソース，データ，データ，…
ＥｎｄＰａｇｅ
の如くリソースとデータが差し挟まる記述となっている。
【００３４】
ＰＳに対する大きな相違点は、リソースの所在を容易に特定できる点のみである。ＰＰＭＬジョブの構造を理解することは、既存の特許、ひいては本発明を理解をする上で助けとなろう。
【００３５】
そして、この分野には次のような従来技術
１．特許文献１（発明者：Ｖｅｎｎｅｋｅｎｓ，譲受人：Ａｇｆａ社）
２．特許文献２（出願人：Ｅｌｅｃｔｒｏｎｉｃｓ  Ｆｏｒ  Ｉｍａｇｉｎｇ社）
３．特許文献３（発明者：Ｋｌａｓｓｅｎ，譲受人：Ｘｅｒｏｘ社）
もある。
【００３６】
特許文献１に記載の発明は広い技術的範囲を有しており、ＰＳを含めあらゆるＰＤＬに適用することができる。記載されているのはＰＤＬデータストリームの並列処理方法である。本方法では、印刷ジョブを表すＰＤＬデータストリームが、データコマンドと制御コマンドの組合せであると見なしている。データコマンドとは、テキスト、グラフィクス、画像等、出力装置から出力されるべきデータを記述するコマンドのことであり、制御コマンドとは、フォント説明、ページ区分、フォーム、オーバレイ等、そのデータの出力形態を指定するコマンドのことである。本方法では、対応する単一のページ又は領域に含まれる画像を記述するデータコマンド幾つかと、それらのデータコマンドをどのように解釈すべきかを指示する制御コマンド幾つかと、をめいめいに含む互いに独立なデータストリーム断片複数個が生成される。
【００３７】
本方法では、ＰＤＬデータストリームをマスタプロセスに送り、そこでそのＰＤＬデータストリームを互いに独立な複数個の断片へと分割し、複数個のサブプロセスでそれら断片を複数個の中間データストリーム部分に変換するようにしている。断片間非依存性を得るためには、個々の断片に自断片の「解釈状態」、即ちそれに先行する制御コマンドの羅列を記述しておく必要がある。
【００３８】
これを実行するには、ＰＤＬデータストリームを解釈し、そのストリームに関する完全な知識を得る必要がある。こうした解釈がボトルネックになることを踏まえ、同文献では、解釈結果を複数個のサブプロセスに分配し、状態変化に遭遇したサブプロセスそれぞれがそのことをマスタプロセスに報告する、といった構成も提案している。複数個のサブプロセスからもたらされる状態報告を同期させる手段としては、特殊な技術が使用されている。
【００３９】
このように、同文献記載の発明は複雑なものである。それに加え、同文献には断片を生成する仕組みが開示されていない。例えば、ＰＳ等に関し、「データコマンド」や「制御コマンド」といった考え方が示されていない。グラフィクスオペレータを使用すると大抵は解釈状態が変化するのに、同文献には、ＰＳのオペレータをデータコマンドや制御コマンドにマッピングする手段が示されていない。
【００４０】
特許文献２に記載の発明も広い技術的範囲を有しており、ＰＳを含めあらゆるＰＤＬに適用することができる。その目的はページ間依存性の克服であり、他の様々な既知技術と同じく個々のページを複数個の断片に分割する構成を採っている。新規な点は、生成される個々の断片が新種の二ファイル、即ち大域データファイル及び断片データファイルで表現されていることである。ページを飛ばすには大域データファイルを実行すればよく、印刷するには断片データファイルを実行すればよい。
【００４１】
残念なことに、同文献には断片を特定する仕組みが開示されておらず、また大域データファイル、断片データファイル及びそれに対応する断片を生成する仕組みも開示されていない。同文献に「グラフィカルオブジェクト」の認識及び抽出が発明の効果として記載されていることや、同文献にＤＳＣやそれに関連する特許文献が何ら参照されていないことから、明示はないながらもインタプリタに基づく方式が採用されていて、前述した処理速度上の問題が生じることがわかる。
【００４２】
そして、特許文献３にはＰＳジョブを個別ページに分割する方式が記載されている。本方式では、ＰＳジョブの解析を通じリソース（同文献でいうイディオム）を検出、抽出して印刷ジョブのヘッダ内に書き込み、そのヘッダを各ページの冒頭に付加するようにしている。本方式によれば、必要なリソース全てを個々のページに付加含ませ、他ページに対し非依存的なページにすることができる。ページに付加される個々のヘッダには、そのページに先行する全リソースが含まれるが、そのページ上のリソースは含まれない。
【００４３】
同文献でも認めている通り、これではページに付加されるヘッダが肥大してしまう。この問題を避けるため、同文献では「チャンク」という考え方を導入し、ジョブを個別のページに分割するのではなく幾つかのチャンクに分割する方式も提案している。この方式であれば、チャンク内ページ数に応じヘッダの大きさが逓減されることとなる。チャンクの大きさは最小で１ページ、最大でジョブ全体である。チャンクは互いに独立であるので、任意順序で処理することも、複数個の処理ノードに分配して並列処理させることもできる。これはチャンク単位並列処理方式の一種といえよう。
【００４４】
しかしながら、このチャンク単位並列処理方式が、従来から知られている幾つかのチャンク単位並列処理方式とどのように相違するのか、判然としていない。例えば、非特許文献３ではチャンク単位並列処理方式に言及し
「例えば、文書の冒頭１００ページを５個の個別プリンタで並列印刷せよとユーザが指令すると、文書マネージャがその文書を２０ページずつに５分割し、その文書のプロローグ及びセッティングをコピーして個々の部分に付加する」
と述べている。更に、特許文献３では、対ＤＳＣ適合性に欠けるジョブの逆順印刷を最適実行する方式に関し
「幾らかであれ効率的な方式は、文書全体を単一パスで解析することで必須要素不具備ヘッダを探し、その必須要素をそのヘッダに補い、そのヘッダを１回だけ消してから、全ページの順序反転を行う方式である」
と述べられている。いわゆる当業者には自明な通りこの方式はまず以てうまくいかない。何故なら、どのページにも「セットフロント」等のＰＳオペレータ、即ち前のページから後のページへと跨っていて「ヘッダ」内に閉じ込められないオペレータが含まれうるからである。しかも、最適でないとした前掲の方式すら、各ページ冒頭へのヘッダ付加に由来する顕著な効率低下があるため使用することができない。結局のところ、効率的逆順印刷がどのようにして実現されるのか、同文献では明らかにされていない。
【００４５】
何より、特許文献３における最大の問題は、リソース入りヘッダを各ページの冒頭に付加することで生じるオーバヘッドである。このオーバヘッドは、ページ単位並列処理方式を用いテキストを処理する際の性能が標準以下に低下する原因になりうる。ページ単位並列処理方式に代えチャンク単位並列処理方式を用いるにしても、チャンクが大きすぎれば負荷バランスが標準以下となり、チャンクが小さすぎればヘッダ付加によるオーバヘッドが肥大するため、ページ難度、ジョブサイズ、システム内リソース、対システム現在負荷等の要因に基づき最適なチャンクサイズを推定する、という複雑な機構を使用しなければならなくなる。
【先行技術文献】
【特許文献】
【００４６】
【特許文献１】米国特許第５６５２７１１号明細書
【特許文献２】国際公開第ＷＯ０４／１１０７５９号パンフレット
【特許文献３】米国特許第６８１７７９１号明細書
【非特許文献】
【００４７】
【非特許文献１】"Adobe PostScript Language Reference Manual"
【非特許文献２】"Adobe PostScript Language Document Structuring Conventions Specification" (DSC Specifications) Version 1, 1986
【非特許文献３】"Adobe PostScript Language Document Structuring Conventions Specification" (DSC Specifications) Version 3.0, September 25, 1992
【発明の概要】
【発明が解決しようとする課題】
【００４８】
以上のことからわかる通り
１．大規模ヘッダの付加によるオーバヘッドを回避できる
２．チャンクサイズ推定問題のないページ単位並列処理方式を使用できる
３．効率的に範囲指定印刷を実行できる
４．正しくページ順反転印刷を実行できる
方法及び装置が求められている。本発明は、その実現を含む諸課題を解決することを目的としている。
【課題を解決するための手段】
【００４９】
本発明に係る方法及び装置では、ページ間非依存性を欠くＰＤＬデータストリーム（ジョブ）を効率的に処理できるよう、ジョブをページ、データ又はリソース単位で整頓することで
１．所与ジョブにおける高次構造、即ちジョブ解析、報告、画面確認編集（プリフライト）、組版決定等の処理に際し手がかりになる構造を表す整然化ジョブ(organized job)を生成する
２．その整然化ジョブを複数個のＰＤＬプロセッサに送りページ単位並列処理を効率的に実行する
３．特定のページ又はページ範囲を指定し効率的に印刷する
４．ページの並べ替えを伴うページ順反転印刷等の手順を効率的に実行する
５．ページプロパティを包括的に抽出する
ことができるようにしている。この整然化ジョブには
１．所与ジョブに対しデータ及びリソースの順序が不変
２．ワークフロー、ストレージ、性能等の条件を満たす諸形式をとりつつ効率的なパッケージングにすることが可能
３．所与ＰＳジョブにおける断片の所在がポインタ又はオフセットで指し示されるようディレクトリ類似の分離型外部構造として表現し、所与ジョブを保持しつつ修正後ジョブ書込に伴うオーバヘッドを避ける方式を採ることで、一層効率的なパッケージングにすることが可能
といった長所がある。ＰＳジョブの場合、本発明に係る処理にはＤＳＣ処理及びテキストパーシングを使用することができる。
【図面の簡単な説明】
【００５０】
【図１】架空装置を用いページ単位で並列処理する方式を示す模式図である。
【図２】架空装置を用いページ単位で二段階パイプラインで並列処理する方式を示す模式図である。
【図３】表示リストを用い解釈を集中実行する方式を示す模式図である。
【図４】ＰＤＦを用いページ単位で並列処理する方式を示す模式図である。
【図５】ジョブ単位で並列処理する方式を示す模式図である。
【図６】全体的な処理の流れを示す模式図である。
【図７】リソースストレージへのリソース分配を示す模式図である。
【図８】オーガナイザ構成要素を示す模式図である。
【発明を実施するための形態】
【００５１】
以下、前述のものを含め本発明の目的、構成及び効果に関し、いわゆる当業者が一読して容易に理解できるよう、本発明の代表的な実施形態を示す別紙図面を参照して詳細に説明する。この説明はいわゆる当業者が全面的に実施できるようにするためのものであり、実施者が創造性を発揮し本発明の性能を高めることや、本発明におけるプロデューサの扱い方を効率化することを、妨げるものではない。また、多々ある実施形態のうち１個についての説明であることを以て、本発明の技術的範囲がその実施形態に限定されるものと解してはならない。寧ろ、あらゆる変形物、改良物及び等価物が、別紙特許請求の範囲に記載の発明に包含されるものと解されたい。
【００５２】
まず、複数個のプロセッサを用いＰＳジョブやその係累であるＶＤＰジョブを処理する際に、どのようにすれば処理速度が高まるかという問題は、「数学的な解」が得られにくい厄介な問題である。そのため、本発明では、本件技術分野で広範な経験により確証されている幾つかの事実に依拠している。
【００５３】
１．まず、ページ単位並列印刷にページ間非依存性は必須でない、という事実である。ページ単位並列印刷に必要なのは、明示的な「対リソースマーキング」を伴う「ページ区分」だけである。ディストリビュータによるページ分配の際に、そのページ丸ごとをそのページ担当のレンダラに送ることか、ページ内リソースをそのページ担当でないレンダラに知らせることができればよい。ＰＰＭＬのようにページ間非依存性に欠ける構成の言語で効率的なページ単位並列印刷を実現できるのはそのためである。
【００５４】
２．ジョブ単位並列処理方式は短小ジョブの最も効率的な処理方式である、という事実もある。短小ジョブの定義はシステム構成、例えばプロセッサ個数、プリンタ速度、想定ジョブ難度等で異なる。従って、短小ジョブと呼べる上限のページ数が、４ページのシステムもあれば１００ページ超のシステムもありうる。
【００５５】
３．中庸又は長大なＰＳジョブではリソースの集中度が急速に降下する、という事実がある。即ち、リソースはその大半が第１ページ以前に現れ、第１ページより第２ページ、第２ページより第３ページと少なくなっていくのが普通である。例えば、５００ページあるジョブの第２５０ページ以降にはほとんどリソースが現れない。ＰＳジョブの係累に当たり、１０００００個超の文書が包括されることも珍しくないＶＤＰジョブでは、第１００文書以降にはリソースがまず以て現れない。
【００５６】
これらの事実に基づき、本発明では、ジョブの整頓、ひいてはジョブ内のページ、文書及びリソースに対する効率的なマーキングを通じ、対処理ノード分配を効率化する手法を採用している。図６に、供給されるＰＳジョブ１１をページ単位で整頓し整然化ジョブ６３を生成するジョブオーガナイザ６２、並びにそのジョブ６３を複数個のＰＤＬプロセッサ６５に分配するディストリビュータ６４を示す。
【００５７】
本発明に備わる特徴の一つは、オーガナイザで並べ替えが行われずデータやリソースの順序がそのままに保たれるため、他の技術では及ばないほどに分割や並列処理が高速化されることである。本発明の好適な実施形態では、所与ジョブ中の該当部分を指し示す参照リスト（ディレクトリ）によって整然化ジョブを表現しこれを実現している。この点について理解、納得するには、どのような整頓、パッケージングを通じ整然化ジョブが生成されるのかを考察すればよい。
【００５８】
整然化ジョブは複数個の断片で構成される。その断片は、メタデータを用いジョブ内構造を表すと共に、ジョブデータを含むものとなっている。個々の断片を規定するタグには次に示す七種類
ＢｅｇｉｎＪｏｂ
ＥｎｄＪｏｂ
ＢｅｇｉｎＤｏｃ
ＥｎｄＤｏｃ
ＢｅｇｉｎＰａｇｅ
ＥｎｄＰａｇｅ
Ｄａｔａ
がある。
【００５９】
そもそものＰＳジョブはこのうち五種類で記述されている。整然化ジョブは、例えば文書数が１、ページ数が２という単純なものならタグを用い
ＢｅｇｉｎＪｏｂ
Ｄａｔａ
ＢｅｇｉｎＤｏｃ
ＢｅｇｉｎＰａｇｅ
Ｄａｔａ
ＥｎｄＰａｇｅ
Ｄａｔａ
ＢｅｇｉｎＰａｇｅ
Ｄａｔａ
ＥｎｄＰａｇｅ
ＥｎｄＤｏｃ
ＥｎｄＪｏｂ
と記述される。即ち、整然化ジョブは、形式的には
ジョブ  ＝ＢｅｇｉｎＪｏｂ，  ［文書  ｜Ｄａｔａ］*，ＥｎｄＪｏｂ
文書    ＝ＢｅｇｉｎＤｏｃ，  ［ページ｜Ｄａｔａ］*，ＥｎｄＤｏｃ
ページ  ＝ＢｅｇｉｎＰａｇｅ，［Ｄａｔａ］*，        ＥｎｄＰａｇｅ
との表現になり、口語的には
・ジョブとは幾つかの文書及びデータ断片をＢｅｇｉｎＪｏｂタグとＥｎｄＪｏｂタグで括ったものである
・文書（ＶＰＳでいうところのブックレット）とは幾つかのページ及びデータ断片をＢｅｇｉｎＤｏｃタグとＥｎｄＤｏｃタグで括ったものである
・ページとは幾つかのデータ断片をＢｅｇｉｎＰａｇｅタグとＥｎｄＰａｇｅタグで括ったものである
との表現になる。
【００６０】
データ断片では、ＰＰＭＬに倣いスコープを指定することができる。指定できるスコープにはページ、文書、ジョブ及び大域がある。現在地に比べ上位のスコープ指定を伴うデータのことをリソースと呼ぶ。例えば、あるページ内に記述されていてそのスコープがジョブであるデータはリソースに該当する。リソースの従来式定義、例えばＰＳ、ＰＰＭＬ等のＰＤＬにおける定義も想起されたい。この仕組みはページ単位並列処理方式や文書単位並列処理方式による分配に役立つ。
【００６１】
ディストリビュータの役目はこうした整然化ジョブを処理することである。例えば、ページ単位並列処理方式の許では
・スコープ＝大域、ジョブ又は文書のデータは、そのジョブの処理に割り振られているプロセッサ全てに分配する
・スコープ＝ページのデータは、そのページの処理に割り振られているプロセッサ１個だけに分配する
というルールに従い処理し、文書単位並列処理方式の許では
・スコープ＝大域又はジョブのデータは、そのジョブの処理に割り振られている全てのプロセッサに分配する
・スコープ＝文書又はページのデータは、その（所属先）文書の処理に割り振られているプロセッサ１個だけに分配する
というルールに従い処理する。
【００６２】
処理される整然化ジョブは、システム上のストレージ条件及び性能条件が満たされるようパッケージングされたもの、例えば
・個々の断片がＸＭＬコンストラクトとして表されるよう、ＸＭＬを用いパッケージングされたもの、即ち（二値データに関する既知の諸問題を含め）ＰＰＭＬでのそれに類似しているもの
・断片別タグ／レングスフォーマットを用いより効率的にパッケージングされたもの、即ちＴＡＲ等の既知フォーマットに類似していて効率的な二値表現であるもの
・所与ＰＳジョブにおける断片の所在がポインタ又はオフセットで指し示されるようタグを含むディレクトリ類似の分離型外部構造で表すことで、一層効率的にパッケージングにされたもの
等である。最後のものは所与ジョブが丸ごと保存される表現形態であり、本願特許請求の範囲にもこれに関連する記載が盛り込まれている。この表現形態はＰＳジョブ変換の分野で知られていない斬新な形態であり、本願で初めて示されたものである。
【００６３】
図７に、それらの処理で使用される共有リソースストレージ７５を示す。このストレージ７５は共有リソース７４（の一部）を保存するためのものであり、ジョブオーガナイザ６２、ディストリビュータ６４、プロセッサ６６等のシステム構成ノード間で共有されている。
【００６４】
この共有リソースストレージ７５は、大域ＶＤＰオブジェクトが保存される形態、全てのＶＤＰリユーザブルオブジェクトが保存される形態、全て又は一部のＰＳリソースが保存される形態等で使用される。そのいずれでも、リソースの集中保持や整然化ジョブの小規模化といった効果を得ることができる。整然化ジョブは、ジョブ自体から保存済リソースが除かれる形態、所与ジョブにおける所在位置を指し示す効率的な外部構造なる形態等で生成される。いずれにせよ、ここで理解すべきことは、本発明に従い整然化表現を生成する際、データやリソースの順序が所与ジョブにおけるそれから変更されないことである。
【００６５】
スコープ＝大域のリソースに関しては次のこともいえる。まず、大域というスコープは、ＰＰＭＬでのそれに倣い、ジョブ間で広く共有すべきリソースを定義及び保存する際に使用される。これは大域なるスコープの主要且つ在来的な用法である。本発明の実施に当たっては、更に、ＰＳインタプリタにてその状態が恒久的に変化しかねないＰＳジョブ（非保護ＰＳジョブ）に関しても、大域なるスコープを使用することができる。ただ、前述したルールに従いこのジョブに係る分配を行うと、そのスコープが大域であるため各ノードに全データが分配され各ノードで全ページが印刷されてしまうことになる。これは、ｓｈｏｗｐａｇｅの再定義、架空装置の設定等といった周知技術を使用し、ｓｈｏｗｐａｇｅオペレータの効果を中和することで回避することができる。なお、これは本発明における非保護ジョブ取扱手法の一例であり、これ以外の非保護ジョブ取扱手法を採りつつ本発明を実施することもできる。
【００６６】
ジョブの整頓で高度にストリーミング的な性質が生じることも見逃してはならない。即ち、プロセッサに対するページ断片の分配をそれらに対するマーキングの直後に実行できる、という性質である。そのページに関する整頓が済む前に実行できるようになることもしばしばである。しかも、ジョブの整頓及び分配をたった１パスで実行することができる。
【００６７】
ジョブの整頓に当たり、ジョブ内でリソースを並べ替えず見つかったままに保つという好適な形態のほか、リソースの並べ替え、整然化ジョブ内移動、ジョブ外移動等を伴う形態も採りうる点に留意されたい。これらの形態はいずれも本発明の技術的範囲に包含されるものである。図７の記載も参照されたい。
【００６８】
例えば、見つかったリソースを同じページの冒頭に移動させ、美感向上等に役立てる形態で、本発明を実施することもできる。その分は効率が低下しかねないが、ページ間非依存性を求めるアプリケーションで行われるように全リソースをヘッダに集中させそのヘッダを各ページの冒頭に付加する構成に比べたら、その効率の高さはかなりのものである。また、整然化ジョブに基づくページ飛ばしは効率的に行えるので、本発明では、ページ単位並列処理方式によるページ範囲指定処理を効率的に実行することができる。
【００６９】
ジョブ内ページ並べ替えやページ順反転はより複雑な処理となる。ページ単位並列印刷の分野では、これまで、その面倒さのため対策が採られないか（特許文献２）、ごく僅かな解決に留まり大部分のファイルで処理が失敗になってしまっていたが（特許文献３）、本発明では次の手順でページ順反転印刷を実行することができる。
【００７０】
１．ジョブを整頓すべく全パスを実行する。これによりページ境界及びリソースがマーキングされる。
【００７１】
２．そのパスを実行中に、そのプロデューサに特有のイディオムのうち、複数のページ亘り持続するグラフィクス状態に影響するものを全て収集し、それを個々のページに関連付ける。例えばＷｉｎｄｏｗｓ（登録商標；以下注記省略）ドライバで提供される「ｆｏｎｔｎａｍｅ  Ｊｉ」コマンド、即ちフォントを「ｆｏｎｔｎａｍｅ」に設定するコマンドを収集する。これは、リソースの収集及び集積とは大きく違うのでその点に留意されたい。例えばＷｉｎｄｏｗｓドライバの場合、個々のページで最後の「Ｊｉ」コマンドをページに関連付ければ足る。リソースと違い、先行する全ての「Ｊｉ」コマンドを関連付ける必要がない。結果として、関連付け後の状態は非常に小さな状態、例えば数百バイト以下の状態となる。
【００７２】
３．全リソースを実行する。これにより相応のＰＳ仮想メモリ（ＶＭ）状態が生成される。
【００７３】
４．処理ノードにページを逆順分配する。それに先立ち、グラフィクス状態の所要部分を設定する小さなヘッダを付加する。
【００７４】
この手順は、非常に広範囲に亘る印刷ジョブでうまく稼働する。ここでは最悪のケースであるページ順反転印刷に的を絞って説明したが、その他のページ並べ替え印刷も同様に実行することができる。
【００７５】
オーガナイザの役目は、所与ジョブをストリーミング形式でパーシングし、その結果を解析し、対ＤＳＣ適合性の欠如を補い、そして複数個の処理ノードに対し効率的に分配できるよう形態を整え整然化ジョブとして出力することである。多様なプロデューサからもたらされる多数のジョブを成功裏に整頓するため、本発明の好適な実施形態では、このオーガナイザに図８に示す諸要素を設けている。本発明の本質を損なわない限り、諸要素の名称を変えることや、諸要素の役割を変えることや、諸要素を幾つかの下位構成要素に分割することや、一部の要素を省くこともできる。
【００７６】
まず、パーシングはライン単位、トークン単位等といった様々な刻みで実施できるが、説明の簡明化のためライン単位でのパーシングを例にして説明することとする。この場合、所与ジョブに含まれるラインがめいめいにストリーミング形式で解析される。「％％」で始まるラインが見つかったらＤＳＣラインの候補として扱う。簡略な追加解析を通じＤＳＣラインたる蓋然性を高めることもできる。有効なＤＳＣラインと見間違いそうな二値データに埋もれているライン等を、ＤＳＣラインと誤認する可能性もあるが、それは問題となるものではない。いずれか有効で且つ想定されているＤＳＣと一致する確率が無視できるほど低いからである。追加解析でもなかなか出会わない。ＤＳＣラインは重宝なものであり、全般的ＤＳＣ処理の実行、そのジョブのクリエータの特定、そのジョブの構造の特定、更にはリソースの検出の際に使用することができる。
【００７７】
また、前述の通りＰＳジョブの多くは対ＤＳＣ適合性を欠いている。しかし、対ＤＳＣ適合性の破られ方は、通常、そのジョブをもたらしたプロデューサを具体的に推定可能な破られ方になっている。個々のプロデューサが有限なプログラムであり、有限なプログラムからは有限通りの出力パターンしか得られないからである。従って、オーガナイザにてジョブデータを解析し、対ＤＳＣ適合性の欠如を補うことが可能である。それにより、より効率的に並列処理可能な整然化ジョブを得ることができる。対ＤＳＣ適合性の欠如を正しく且つ効率的に補うには、オーガナイザにてプロデューサ（クリエータとも呼ぶ）を特定する必要がある。
【００７８】
ここで、プロデューサなる語について若干説明する。まず、プロデューサがＸｙｚＳｏｆｔである、と述べるだけでは一般には不十分である。より詳しく、Ｗｉｎｄｏｗｓドライバを使用するＸｙｚＳｏｆｔである、ＬａｓｅｒＷｒｉｔｅｒ（登録商標；以下注記省略）ドライバを使用するＸｙｚＳｏｆｔである、ネイティブなコード生成手段を使用するＸｙｚＳｏｆｔである等と明示する必要がある。そのいずれであるかで、出力が大きく異なりうるからである。ＸｙｚＳｏｆｔのバージョン、Ｗｉｎｄｏｗｓドライバのバージョン等を特定しなければならない場合もあろう。総じて、プロデューサを特定するには、アプリケーション名、ドライバ名、バージョン等、様々な識別情報を完全に揃えることが必要になる。
【００７９】
それら識別情報の組合せは非常に多数に上りかねない。そうした組合せ数爆発を抑えるには、必ずとはいわないまでも多くの場合に成り立つ事実を利用すればよい。例えば、使用するドライバの種類によらずＸｙｚＳｏｆｔで現れることが多い出力パターンがある、といった事実である。従って、ＸｙｚＳｏｆｔ流パターン、Ｗｉｎｄｏｗｓ流パターン、ＬａｓｅｒＷｒｉｔｅｒ８流パターン等々が個別に解析されるように解析部材を分けるのが望ましい。本願では、そうした解析部材のことを「プロデューサ別プロセッサ」と呼んでいる。ジョブのレンダリングを担う複数個のプロセッサとはまた別物である。
【００８０】
なお、プロデューサなる語より精密な表現としてはアプリケーション・ドライバ対なる表現もある。プロデューサ列なる語の方がよいかもしれない。その構成要素数が１ならネイティブなプロデューサ、２ならアプリケーション・ドライバ対、というように、プロデューサ列なる語ならば、その構成要素数が３以上の場合を含め包括的に表すことができる。
【００８１】
［全般的処理手順］
まず、オーガナイザはＰＳジョブをライン単位でパーシングしていく。最初のうちはプロデューサがわからずプロデューサ列が空乏のままであり、処理には全般的ＤＳＣプロセッサ８２が使用されることになる。
【００８２】
その後、プロデューサ列に第１構成要素として登録できる情報が得られたら、オーガナイザ８１は、そのラインを対応するプロデューサ別プロセッサに送る。例えば、ＬａｓｅｒＷｒｉｔｅｒ８ドライバが検出されたら、そのラインをＬａｓｅｒＷｒｉｔｅｒ８用プロセッサへと送る。
【００８３】
プロデューサ別プロセッサ（例えばＬａｓｅｒＷｒｉｔｅｒ８用プロセッサ）は、送られてくるラインそれぞれを高速解析し、自プロセッサで処理する必要がないラインを除外する。通常は、ライン冒頭及び末尾の数バイトを解析するだけでその種のラインを除外することができる。大半のラインはこうして除外されることとなる。処理する必要がありそうなラインが見つかったら、そのプロセッサはより念入りな処理を実行する。即ち、そのラインのパターンがリソース的であるとリソーススニファ８５にて認識されたら、そのプロセッサは、自分固有のマーキング用ロジックを幾つか起動させる。使用されるロジックは、リソース始点を探す後方検索ロジックや、リソース終点を探す前方検索ロジックである。こうしてリソースを検出したら、そのプロセッサは、そのリソースの始点及び終点の位置をオーガナイザに報告する。オーガナイザは、前述したパッケージング方式に従いそのリソースにマーキングを施した上で、そのリソースの直後に当たる位置に処理を進める。これにより、そのリソースについての処理が終了する。
【００８４】
プロデューサ別プロセッサは、除外したラインを直ちにオーガナイザに回送する。オーガナイザは、後述する全般的ＤＳＣプロセッサにそのラインを処理させる。
【００８５】
この方式の強みは、全般的ＤＳＣプロセッサで実行されるデフォルト挙動の結果に対し個々のプロデューサ別プロセッサが必要に応じ上書きできることや、全般的ＤＳＣプロセッサの処理能力に依拠し大半のラインを処理できることにある。これは、個々のプロデューサ別プロセッサを、対ＤＳＣ適合性の欠如を個別に補うのに必要な最小限のコードライン数で実現できる、ということである。プロデューサの対ＤＳＣ適合性が高いほど、対応するプロデューサ別プロセッサの構成は簡略にすることができる。
【００８６】
オーガナイザはアプリケーションも検出する。例えば、ＬａｓｅｒＷｒｉｔｅｒ８ドライバの検出後に、ＡｄｏｂｅＡｃｒｏｂａｔ（登録商標；以下注記省略）を検出する。その場合、オーガナイザは、検出したアプリケーションをプロデューサ列に第２構成要素として登録した後、そのプロデューサ列の個々の構成要素に各ラインの処理を打診する。例えば、そのラインの処理を
・まずＡｄｏｂｅＡｃｒｏｂａｔに打診し、
・断られたらＬａｓｅｒＷｒｉｔｅｒ８に打診し、
・断られたら全般的ＤＳＣプロセッサに実行させる。
【００８７】
［全般的ＤＳＣプロセッサ］
図８に示す部材のうち、全般的ＤＳＣプロセッサ８２は、非特許文献３で規定されている手順に従い全般的ＤＳＣ処理を実行するロジックである。
【００８８】
対ＤＳＣ適合性に頼れないとはいえ、「全般的処理手順」欄に記載の通り、全般的ＤＳＣプロセッサは非常に重要な部材である。それを使用することで、オーガナイザのデフォルト挙動が実現され、また個別のプロデューサ別プロセッサが小型化、実現容易化されるからである。全般的ＤＳＣプロセッサで実行される動作としては、ジョブヘッダの解析、ジョブプロローグの解析、ジョブデフォルトの解析、リソースの解析、ＰｒｏｃＳｅｔの解析、ページ境界の探索、ジョブトレイラの探索等、全般的ＤＳＣ処理に必要とされる動作として非特許文献３で規定されている諸動作がある。加えて、並列処理向けのジョブ整頓に厳密に必要とはいえないものを含め、その実施形態に特有の機能を全般的ＤＳＣプロセッサで実行させてもよい。
【００８９】
［クリエータスニファ］
クリエータスニファ８３はプロデューサ列を特定するロジックである。ここでプロデューサ列と表現したのは、前述の通り、単一のクリエータ乃至プロデューサについてではなく複数のプロデューサからなるプロデューサ列について論じた方が厳密になるからである。特定手法としては、「％％Ｃｒｅａｔｏｒ  ＤＳＣ」を探す手法を使用することもできるが、一般には信頼性があまり高くならない。最も信頼できるのは、ＰＳジョブを解析し、ＰｒｏｃＳｅｔと呼ばれる特別な部分、即ち個別のプロデューサ向けに必要とされる処理手順がＰＳで記述されている部分を探す手法である。この手法を用いた場合、そのジョブがＬａｓｅｒＷｒｉｔｅｒ８ドライバによってもたらされたものなら、オーガナイザはいずれかの時点でＬａｓｅｒＷｒｉｔｅｒ８ＰｒｏｃＳｅｔに遭遇する。そのジョブがＡｄｏｂｅＡｃｒｏｂａｔアプリケーションによってもたらされたものなら、オーガナイザはいずれかの時点でＡｄｏｂｅＡｃｒｏｂａｔＰｒｏｃＳｅｔに遭遇する。仮に、そのジョブがＸｙｚＳｏｆｔによってもたらされたものであるのにＸｙｚＳｏｆｔＰｒｏｃＳｅｔに遭遇しなかったとしたら、それは、単に、ＸｙｚＳｏｆｔがそのジョブでＸｙｚＳｏｆｔ向けリソースを何ら使用しておらず、ＸｙｚＳｏｆｔ流パターンを解析する必要がない、ということである。とはいえ、プロデューサは多様であるので、「％％Ｃｒｅａｔｏｒ  ＤＳＣ」等のＤＳＣラインの方がプロデューサの特定に役立つ場合もある。
【００９０】
［ページ情報スニファ］
ページ情報スニファ８４は、ページを丸ごとリソースとしてマーキングすべきか否かを判別するロジックである。自明な通り、このロジックはプロデューサ毎に異なるものになる。
【００９１】
マルチＰＳ組版パッケージを例にして前述した通り、そのプロデューサで使用されたリソースをプロデューサを示す情報に基づき検出、抽出する部材は必ず実現できるが、かなりの開発時間が必要となるためその実現が容易であるとは限らない。しかし、ＰＳ組版アプリケーションのようにページ間非依存性を必須とするアプリケーションでは、リソースを検出、抽出する以外に現実的な策がない。そのため、その種のアプリケーションでは、１）複数のプロデューサを扱えるよう多大な努力を払う策か、２）サポートするプロデューサの種類を限定する策が、採られるのが普通である。
【００９２】
本発明では、ページ間非依存性を必須としないため別の策を採ることができる。例えば、ページ全体を１パスで素早く調べ、リソースが見つかったらそのページを丸ごとリソースとしてマーキングする、といった策を採ることができる。これは、ページ上でのリソース存否認識が抽出やマーキングに比べかなり容易である、という経験的知識に基づいている。前述した通り「ジョブ内ではリソースの集中度が急速に降下する」ので、この策を採り入れた実施形態は、その部分の処理が非常に短時間で済む有益な実施形態となる。なお、本発明はより複雑な形態、例えばこうした近道をあまり使用しない形態や、最も重要なプロデューサ向けにリソースへのマーキングを実行するよう試みる形態でも実施することができる。
【００９３】
［ページ設定スニファ］
ページ設定スニファ８９は、各ページのページプロパティ（ｐａｇｅｄｅｖｉｃｅ設定）が記述されている部分を検出するロジックである。ページプロパティの例はＰａｇｅＢｏｕｎｄｉｎｇＢｏｘ、ＰａｐｅｒＷｅｉｇｈｔ、ＰａｐｅｒＣｏｌｏｒ等である。一部のプロデューサからもたらされたジョブでは更なるパーシングが必要になるが、こうした部分を検出するには、「％％ＢｅｇｉｎＰａｇｅＳｅｔｕｐ」と「％％ＥｎｄＰａｇｅＳｅｔｕｐ」で括られているＰａｇｅＳｅｔｕｐ部を探し、そのＰａｇｅＳｅｔｕｐ部を一通り解析してｓｅｔｐａｇｅｄｅｖｉｃｅコマンドを探せばよい。
【００９４】
より確実且つ効率的なやり方としては、ＰＤＬデータからＰａｇｅＳｅｔｕｐ部を抽出し、その部分を必要なジョブ内リソースと併せＰＳインタプリタで実行する、というやり方がある。通常はｓｅｔｐａｇｅｄｅｖｉｃｅコマンドが再定義され、例えばｐａｇｅｄｅｖｉｃｅキー／値をＸＭＬ形式で出力する形式となるので、それを利用しｐａｇｅｄｅｖｉｃｅ設定を検出することができる。所与ＰＳファイルのうち僅かな部分が実行されるに過ぎないので、こうしたページプロパティ検出処理は非常に高速に実行することができる。
【００９５】
［リソーススニファ］
リソーススニファ８５は、リソースを認識してマーキングを施すロジックである。リソースを認識する（スニフする）やり方は前述の通りである。リソースを手早く見つけてページにマーキングする、という前述の近道を採用すれば、プロデューサ別のリソーススニファを実現するのに多くの時間をかける必要もなくなる。様々な組版アプリケーションの例を踏まえれば、いわゆる当業者ならば、リソーススニファを利用し本発明を効率的に実施することができよう。
【００９６】
［画像スニファ］
画像スニファ８６は、画像境界を検出して画像飛ばしを効率的に実行するロジックである。画像には非常に大きなものもあるため、その認識及び画像飛ばしを効率的に実行するのは有益である。自明な通り、全般的ＤＳＣプロセッサ８２でもＤＳＣ仕様書に従い画像飛ばしを実行することができるが、それにはプロデューサ別パターン認識ロジックを併用し対ＤＳＣ適合性の欠如をカバーする必要がある。
【００９７】
［ＥＰＳスニファ］
ＥＰＳスニファ８７は、ＰＳジョブからカプセル化ＰＳ（ＥＰＳ）境界を検出してＥＰＳ飛ばしを効率的に実行するロジックである。残念なことに、プロデューサのなかにはＥＰＳフラグメントの埋込にＤＳＣ用の機構を使用しないものがある。そのため、リソースに関するパーシングを実行してもＥＰＳの認識や飛ばしがうまくいかず、パーシングのエラー、例えばページ過剰、リソースマーキング過剰、それによるリソース間抵触等が生じてしまうことがある。そのため、ＥＰＳをスニフするには特別なプロデューサ別パターン認識ロジックが必要になる。
【００９８】
［グラフィクス状態スニファ］
グラフィクス状態スニファ８８は、そのプロデューサに特有のイディオムのうち恒常的なグラフィクス状態に影響を及ぼすものを収集するロジックである。こうしたプロデューサ別のスニファは、そのプロデューサに特有のイディオム、特にページ間に跨るグラフィクス状態に影響し上述の如くそれを個々のページに関連付けるものを、漏れなく収集するのに必要である。そうしたイディオムの例としては、Ｗｉｎｄｏｗｓドライバで提供される「ｆｏｎｔｎａｍｅ  Ｊｉ」コマンドがある。これはＰＳの「セットフロント」コマンドに対するエイリアスとなりページ範囲を跨いで持続する。
【符号の説明】
【００９９】
１１，５１  ＰＳジョブ、１２〜１５，４５，５５  プロセッサ、２２  インタプリタ、２６，３４  レンダラ、３２  集中インタプリタ、３３、６６  ページ、４２  ＰＳ−ＰＤＦコンバータ、４３  ＰＤＦジョブ、４４  ＰＤＦディストリビュータ、６２  ジョブオーガナイザ、６３  整然化ジョブ、６４  ディストリビュータ、６５  ＰＤＬプロセッサ、７４  共有リソース、７５  共有リソースストレージ、８１  オーガナイザ、８２  全般的ＤＳＣプロセッサ、８３  クリエータスニファ、８４  ページ情報スニファ、８５  リソーススニファ、８６  画像スニファ、８７  ＥＰＳスニファ、８８  グラフィクス状態スニファ、８９  ページ設定スニファ。
【図１】
2012517635.tif 000003
【図２】
2012517635.tif 000004
【図３】
2012517635.tif 000005
【図４】
2012517635.tif 000006
【図５】
2012517635.tif 000007
【図６】
2012517635.tif 000008
【図７】
2012517635.tif 000009
【図８】
2012517635.tif 000010
【国際調査報告】
2012517635.tif 000011