JP2010128941A - 印刷制御装置、印刷制御方法、及びコンピュータプログラム - Google Patents

Abstract

【課題】 描画されたデータをページ単位でキャッシュして再利用するための処理を、従来よりも簡略化する。
【解決手段】 ＲＩＰ済データを使用するかどうかを判定するに際し、処理対象のページが再利用可能なオブジェクトのみで構成されているか否かを判定する。この判定の結果、処理対象のページが再利用可能なオブジェクトのみで構成されていない場合には、ＲＩＰ済データを使用せずに当該処理対象のページに対してＲＩＰを行う。一方、処理対象のページが再利用可能なオブジェクトのみで構成されていない場合には、当該処理対象のページと一致する共通ページが共通ページテーブル５０７に登録されているか否かを判定する。この判定の結果、登録されている場合にはＲＩＰ済データを再利用し、登録されていない場合にはＲＩＰ済データを使用せずに当該処理対象のページに対してＲＩＰを行う。
【選択図】 図５

Description

本発明は、印刷制御装置、印刷制御方法、及びコンピュータプログラムに関し、特に、描画済みのデータを再利用して印刷するために用いて好適なものである。

近年、電子写真方式の印刷装置やインクジェット方式の印刷装置の高速化・高画質化に伴い、印刷業界に対抗して、プリント・オン・デマンド（Print On Demand：以下、ＰＯＤと表記する）と呼ばれる印刷形態が出現しつつある。ＰＯＤは、ディジタル印刷機を活用して、大規模な印刷装置で扱うジョブより比較的小ロットのジョブを扱い、ディジタルプリントを実現するものである。

また、ＰＯＤから派生し、ディジタル印刷機の特徴を生かしたＶＤＰ（Variable Data Print）と呼ばれる手法がある。これは、データベース等にある情報に従って、プリントする内容をその都度変えることができるものである。ＶＤＰは、例えば、提供する商品情報を顧客情報に従って変えるダイレクトメールや、光熱費等の利用状況に従って数値を変える利用明細書等に利用することができる。そのため、ＶＤＰは、ダイレクトメール作成等を行う市場において急速に利用が広まっている。
このＶＤＰにおける印刷ジョブを記述する標準フォーマットとしてＰＰＭＬ（Personalized Print Markup Language）がある。ＰＰＭＬの特徴としては、描画時に再利用される描画オブジェクトと、一度しか描画されない描画オブジェクトとを分けて記述することが挙げられる。

前述した通り、ＶＤＰは、データベース等にある情報を参照してプリントする内容をその都度変える手法である。この場合、現実的には複数のレコードで内容が共通なページが印刷ジョブに含まれていることが多々ある。例えば、顧客毎に内容をカスタマイズした商品カタログにおいて、商品の注文方法を記述したページを共通にする場合がある。その他の例としては、顧客に応じてページごと差し替えたジョブを生成して印刷する"バージョニング"という手法がある。バージョニングは、例えば女性にはページＡを掲載し、男性にはページＢを掲載する、といったように、ページ単位での差し替えが行われる。

以上のような共通な内容のページについてＲＩＰ（Raster Image Processing）を行ったＲＩＰ済データをプリンタのメモリやＨＤＤにキャッシュし、再利用することで印刷の高速化を図ることができる。ただし、そのためには、今ＲＩＰしたいページに対応するＲＩＰ済データが既にキャッシュされているかどうかを調べる必要がある。ここで、どのページがどのページと共通しているのか、という情報を文法上記述できるＰＤＬ（Page Description Language）スクリプトをＲＩＰする場合を考える。ＰＤＬスクリプトをＲＩＰする場合には、ＲＩＰの際に、プリンタ側にどのページがキャッシュ済みなのかという情報を記憶しておく。そして、記憶しておいた情報と、ＰＤＬスクリプトの情報とを参照することで、今ＲＩＰしたいページがキャッシュ済みかどうかをすぐに判定できる。

しかしながら、先に述べたＰＰＭＬのスクリプトにおいては、その文法上、どのページがどのページと共通しているのか、という情報を記述できない。従って、今ＲＩＰしたいページがキャッシュ済みかどうかを判定するためには、今ＲＩＰしたいページのスクリプトと、キャッシュに記憶されているページに対応するスクリプトとの一致を判定する一致判定処理を行う必要がある。しかしながら、この一致判定処理にかかる計算量によって、ページをキャッシュする利点が失われてしまう可能性がある。

ページ単位でキャッシュを行う従来技術として特許文献１に記載の技術がある。特許文献１では、ＰＤＬをページ単位のデータに分割し、ページ単位でデータをキャッシュする。そして、ページ毎に前回のデータとの比較を行い、比較の結果、両者が一致したページについては、ＲＩＰを行わずに、前回のＲＩＰ済データを利用する。このようにすることによって、ページ単位の差込み印刷等において、印刷データの展開に要する時間を短縮する。

また、特許文献２に記載の技術では、複数のページで共通して使用されるオブジェクト単位の再利用データを抽出し、抽出した再利用データを合成してフォームデータを作成する。そして、ここで作成されたフォームデータと、当該フォームデータに含まれないオブジェクト単位のデータとを合成して印刷する。

特開平１０−０２１０１８号公報 特開２００６−２３７８２５号公報

しかしながら、特許文献１に記載の技術では、あらゆるＰＤＬを対象としてページのキャッシュを行うことを想定している。このため、印刷ジョブに含まれる全てのページをキャッシュし、比較する必要がある。したがって、一致判定回数が多くなるという問題がある。

また、特許文献２に記載の技術では、ページ間で共通しているオブジェクトを見つけるために、どのオブジェクトがどのページに出現するかという一覧を予め作成する必要がある。また、その一覧を作成するために、オブジェクト同士の一致判定回数が増えてしまうという問題があった。

前述したように、ＰＰＭＬで記述されたジョブを処理する際に、共通ページのＲＩＰ済データのキャッシュを行おうとすると、今ＲＩＰしたいページのスクリプトと、キャッシュに記憶されているページに対応するスクリプトとの一致判定処理を行う必要がある。しかしながら、従来の技術では、この一致判定処理を必ず行わなければならない。また、この一致判定処理にかかる計算量が多い。したがって、ページ単位でデータをキャッシュして再利用することの利点が失われる虞があるという問題点がある。

本発明は、このような問題点に鑑みてなされたものであり、描画されたデータをページ単位でキャッシュして再利用するための処理を、従来よりも簡略化することを目的とする。

本発明の印刷制御装置は、再利用可能なオブジェクトと、一度しか描画されないオブジェクトとを分けて記述することができる言語でページデータが記述されたスクリプトを解析する解析手段と、前記スクリプトに記述されているページデータのうち、再利用可能なオブジェクトのみで構成されているページデータを抽出する抽出手段と、前記抽出手段により抽出されたページデータに対して描画のための処理を行って描画処理済データを生成する生成手段と、前記生成手段により生成された描画処理済データと、当該描画処理済データの生成元であるページデータとを相互に対応付けて記憶媒体に記憶する記憶手段と、前記抽出手段により抽出されたページデータと、前記記憶媒体に既に記憶されているページデータとを比較して、これらが一致するか否かを判定する判定手段と、前記判定手段により、前記抽出手段により抽出されたページデータと、前記記憶媒体に既に記憶されているページデータとが一致していると判定された場合に、当該ページデータに対応付けられて前記記憶媒体に既に記憶されている描画処理済データを、前記生成手段により描画処理済データを生成する代わりに出力する出力手段と、を有することを特徴とする。

本発明によれば、スクリプトに記述されているページデータが、再利用可能なオブジェクトのみで構成されている場合には、スクリプトに記述されているページデータと、既に記憶されているページデータとが一致するかどうかを判定する必要がなくなる。したがって、描画済データをページ単位でキャッシュして再利用するための処理を、従来よりも簡略化することが可能になる。

（第１の実施形態）
以下に、図面を参照しながら、本発明の第１の実施形態について説明する。
本実施形態では、ＰＰＭＬの文法上の特性を活かし、ページ同士の一致判定回数を減らす施策と、オブジェクト同士の一致判定回数を減らす施策を講じている。前述したように、ＰＰＭＬは、描画時に再利用される描画オブジェクトと、一度しか描画されない描画オブジェクトとを分けて記述することができるものである。
ページ同士の一致判定回数を減らす施策としては以下の２つがある。
まず１つ目は、最初に共通ページの候補を絞り込む処理を行う施策である。このようにすれば、全てのページに対して、キャッシュされたページとの一致判定を行わずに済む。よって、ページ同士の一致判定回数を減らすことができる。この処理に関しては、図９等を用いて説明する。
２つ目は、ページの遷移を考慮して、一致判定を行うページの順番を決定する処理を行う施策である。このようにすれば、一致する可能性の高いページからページの一致判定を行うことになる。よって、なるべく早く一致するページを見つけられる可能性が高くなり、結果的にページ同士の一致判定回数を減らすことができる。この処理に関しては、図１１及び図１２等を用いて説明する。

次に、オブジェクト同士の一致判定回数を減らす施策としては以下の２つがある。
まず１つ目は、既に記憶しているページのバイト数と、これからＲＩＰを行うページのバイト数とを比較してから、実際のオブジェクトの一致判定を行う施策である。このようにすれば、ページのバイト数が異なるページに対しては、オブジェクト同士の一致判定回数が不要になる。このため、オブジェクト同士の一致判定回数を減らすことができる。この処理に関しては、図１３等を用いて説明する。
２つ目は、ページ内で前景となるオブジェクトから順番に一致判定を行う。これにより、背景は共通しているが前景が異なる共通ページ同士の一致判定において、早い段階で不一致と判定することができる。このため、オブジェクト同士の一致判定回数を減らすことができる。この処理に関しては、図１４等を用いて説明する。

まず、共通ページの定義を説明する。図１は、共通ページを含んだ複数ページの印刷ジョブの概念の一例を示す図である。図１に示す例では、４人分のレコード１０１〜１０４の夫々が、２ページの個別ページと２ページの共通ページとから構成されていることを示している。尚、個別ページとは、レコード毎にパーソナライズされたページのことである。この例のように本実施形態では、全てのレコードに共通したページだけでなく、一部のレコードに共通したページも共通ページと呼ぶこととする。

＜システム構成＞
次に、本実施形態における印刷システムの構成について説明する。
図２は、印刷システムの概略構成の一例を示す図である。
図２において、１台以上のクライアントパーソナルコンピュータ（以下、クライアントＰＣと称する）２０２、プリンタコントローラ２０３及びプリンタ２０４がネットワーク２０１を介して相互に接続されている。

クライアントＰＣ２０２は、ＰＰＭＬで記述された印刷ジョブ（以下、ＰＰＭＬジョブと称する）を生成し、ネットワーク２０１を通じてプリンタコントローラ２０３にＰＰＭＬジョブを送信する。ＰＰＭＬジョブを受け付けたプリンタコントローラ２０３は、ＰＰＭＬジョブの各ページのページデータに対してＲＩＰを行ってＲＩＰ済データを生成する。このとき、ＲＩＰ済データが既にキャッシュされている共通ページについては、キャッシュされているＲＩＰ済データを再利用する。そして、プリンタコントローラ２０３は、プリンタ２０４にＲＩＰ済データを送信する。プリンタ２０４は、受信したＲＩＰ済データを、プリンタエンジンを用いて用紙に印刷する。

＜クライアントＰＣの構成＞
次に、クライアントＰＣ２０２のハードウェア構成について説明する。図３は、クライアントＰＣ２０２のハードウェア構成の一例を示すブロック図である。図３に示すクライアントＰＣ２０２のハードウェア構成は一例である。図３に示すものの他にも、クライアントＰＣのハードウェアの接続方法として様々な方法を採ることができることが一般に知られている。また、図３に示すものの他にも、様々なバスやインタフェースを有したクライアントＰＣの構成が一般に知られている。

ＣＰＵ３０１は、ＲＡＭ３０２に展開されている制御プログラムに従って、クライアントＰＣ２０２全体の制御を行う。ＲＡＭ３０２は、ＣＰＵ３０１が実行するクライアントＰＣ２０２の制御プログラムや、文書・画像等のデータが展開される（書き込まれる）内部記憶部である。ネットワークインタフェース（Ｎｅｔ Ｉ／Ｆ）３０３は、ＣＰＵ３０１の制御に基づいて、インターネットやＬＡＮ等のネットワーク２０１との接続を行ってデータ等を送受信する。ハードディスクドライブ（ＨＤＤ）３０４は、クライアントＰＣ２０２の制御ソフトウェアを初めとして、様々なデータを保存する。また、クライアントＰＣ２０２は、ディスプレイ３０５、キーボード３０６、及びマウス等のポインティングデバイス３０７を備える。

ＨＤＤ３０４に記憶されている各種ソフトウェアは、必要に応じてＲＡＭ３０２に展開され、同じくＲＡＭ３０２に展開されているオペレーティングシステムの機能を必要に応じて使用し、ＣＰＵ３０１の制御のもと実行される。

＜プリンタコントローラの構成＞
次に、プリンタコントローラ２０３のハードウェア構成について説明する。図４は、本実施形態で使用されるプリンタコントローラ２０３のハードウェア構成の一例を示すブロック図である。クライアントＰＣ２０２と同様に、図４に示すプリンタコントローラ２０３のハードウェア構成は一例であり、様々な接続方法や、様々なバスやインタフェースを有した構成を採ることができる。

ＣＰＵ４０１は、ＲＡＭ４０２に展開されている制御プログラムに従って、プリンタコントローラ２０３全体の制御を行う。ＲＡＭ４０２は、ＣＰＵ４０１が実行するプリンタコントローラ２０３の制御プログラムや、文書・画像等のデータが展開される（書き込まれる）内部記憶部である。ネットワークインタフェース（Ｎｅｔ Ｉ／Ｆ）４０３は、ＣＰＵ４０１の制御に基づいて、ネットワーク２０１との接続を行ってデータ等を送受信する。ハードディスクドライブ（ＨＤＤ）４０４は、プリンタコントローラ２０３の制御ソフトウェアを初めとして、様々なデータを保存する。ビデオインタフェース４０８は、ビデオケーブルによりプリンタ２０４と相互に接続され、ＲＩＰ済データをプリンタ２０４に送信するのに用いられる。また、プリンタコントローラ２０３は、ディスプレイ４０５、キーボード４０６、及びマウス等のポインティングデバイス４０７を備える。

ＨＤＤ４０４に記憶されている各種ソフトウェアは、必要に応じてＲＡＭ４０２に展開され、同じくＲＡＭ４０２に展開されているオペレーティングシステムの機能を必要に応じて使用し、ＣＰＵ４０１の制御のもと実行される。

＜モジュール構成＞
次に、ＲＩＰモジュール５０１のモジュール構成を説明する。図５は、ＲＩＰモジュール５０１のモジュール構成の一例を示す図である。ＲＩＰモジュール５０１は、プリンタコントローラ２０３のＨＤＤ４０４に記憶され、ＨＤＤ４０４からＲＡＭ４０２に適宜展開され、ＣＰＵ４０１の制御のもとで実行される。このＲＩＰモジュール５０１において、特に特徴的な処理を行っているのは共通ページ判定部５０３である。共通ページ判定部５０３が行う処理の詳細に関しては図９等を用いて後述する。

次に、ＲＩＰモジュール５０１を構成するモジュールについて説明する。
インタプリタ５０２は、ＰＰＭＬスクリプトの解釈を行うモジュールである。まず、外部のモジュールからＰＰＭＬスクリプトを受け付け、ＰＰＭＬスクリプトをパーズ（parse）し、ＲＡＭ４０２上に展開する。そして、インタプリタ５０２は、パーズしたページデータを共通ページ判定部５０３に渡し、共通ページ判定部５０３で行われた判定結果に応じて処理対象ページをＲＩＰするか、キャッシュに記憶されているＲＩＰ済データを出力するかを決定する。インタプリタ５０２が行う処理の流れの詳細は図６を用いて後述する。

共通ページ判定部５０３は、インタプリタ５０２から受け取った処理対象ページが共通ページかどうかの判定を行う。また、共通ページ判定部５０３は、処理対象ページが、キャッシュされている共通ページのうち、どれと一致したかどうかを判定する。前述の通り、共通ページ判定部５０３は、本実施形態における特徴的な処理を行っており、その処理の流れの詳細は図９等を用いて後述する。

レンダラ５０４は、インタプリタ５０２が解釈したＰＰＭＬスクリプトの描画命令を受け付け、ラスタライズを行うモジュールである。また、レンダラ５０４は、インタプリタ５０２の指示に応じて、描画したＲＩＰ済データをそのまま出力部５０６に送信するか、キャッシュを行うためにインタプリタ５０２に送信するかを選択し、選択した方にＲＩＰ済データを送信する。

キャッシュマネージャ５０５は、共通ページのキャッシュを管理するモジュールである。インタプリタ５０２の指示に応じて以下の処理のどちらかを行う。一つは、インタプリタ５０２から、処理対象ページのＲＩＰ済データのキャッシュの登録指示を受け付け、それを共通ページキャッシュ５０８に登録する。もう一つは、インタプリタ５０２から、共通ページキャッシュ５０８に登録されている"共通ページのＲＩＰ済データ"の出力指示を受け付け、そのＲＩＰ済データを出力部５０６へ渡す。

本実施形態では、ＲＩＰ済データとしてラスタデータを想定しており、ラスタデータをキャッシュすることを想定している。しかしながら、本発明において、キャッシュされるデータはラスタデータに限ったものではなく、デバイス（プリンタ２０４）に依存しない中間データをキャッシュするようにしてもよい。

出力部５０６は、ＲＩＰされたページをプリンタ２０４に出力するためのモジュールである。
共通ページテーブル５０７は、処理対象ページと、共通ページキャッシュ５０８に格納されている共通ページとの一致判定を効率的に行うために用いられるテーブルであり、プリンタコントローラ２０３のＲＡＭ４０２に記録される。図６は、共通ページテーブル５０７のデータ構造の一例を概念的に示す図である。

図６において、リソースＩＤフィールド６０１は、リソースＩＤを示すフィールドである。リソースＩＤは、次に説明する共通ページキャッシュ５０８を参照するためのＩＤである。
遷移履歴フィールド６０２は、どの共通ページがどの順番で出現したのかを示すフィールドである。以下の説明では、この遷移履歴フィールド６０２内の内容を、必要に応じて遷移履歴と称する。例えば、リソースＩＤが００２のページ（共通ページＢ）の遷移履歴フィールド６０２には、「Ａ→Ｂ→Ｃ：２回」というデータ（遷移履歴）が記憶されている。この遷移履歴は、リソースＩＤが００２のページ（共通ページＢ）の１ページ前に共通ページＡが出現し、リソースＩＤが００２のページ（共通ページＢ）の次のページに共通ページＣが出現したことが、２回あったことを示している。この遷移履歴を用いることで、処理対象ページと一致する可能性の高い共通ページを容易に且つ確実に推測できるようになる。

累積回数フィールド６０３は、各共通ページが１ページ目に出現した回数（累積回数）を示すフィールドである。
ポインタフィールド６０４は、インタプリタ５０２のパーズ処理によりＲＡＭ４０２に展開された各共通ページのページデータ６０５へのポインタを示すフィールドである。
尚、この共通ページテーブル５０７の使用方法は、図１０〜図１２等を用いて後述する。

図５の説明に戻り、共通ページキャッシュ５０８は、ＲＩＰが済んだ共通ページのデータ（ＲＩＰ済データ）をキャッシュするものであり、ＲＡＭ４０２に記録される。図７は、共通ページキャッシュ５０８の概念的なデータ構造の一例を示す図である。
図７において、リソースＩＤフィールド７０１は、リソースＩＤを示すフィールドである。このリソースＩＤは、キャッシュしたページデータを特定するためのＩＤである。このリソースＩＤの値は、図６に示した共通ページテーブル５０７内のリソースＩＤフィールド６０１内のリソースＩＤと対応する。

ポインタフィールド７０２は、プリンタコントローラ２０３のＲＡＭ４０２に展開されているＲＩＰ済データ７０３へのポインタを示したフィールドである。
尚、ここでは、ＲＩＰ済データ７０３をＲＡＭ４０２に記録する場合を例に挙げて示した。しかしながら、ＲＩＰ済データ７０３を記録する装置はＲＡＭ４０２に限定されない。例えば、ＲＩＰ済データ７０３をプリンタコントローラ２０３のＨＤＤ４０４に記憶するようにしてもよい。また、ＲＩＰ済データ７０３をＲＡＭ４０２とＨＤＤ４０４との両方に記憶するようにしてもよい。

一般的に、データへのアクセス速度はＨＤＤ４０４よりもＲＡＭ４０２の方が高速である。このため、ＲＡＭ４０２とＨＤＤ４０４との両方にＲＩＰ済データ７０３を記憶する場合には、なるべくＲＡＭ４０２に記憶した方が処理は高速となる。しかしながら一方でＲＡＭ４０２は記憶容量がＨＤＤ４０４よりも少ない。そのため、全てのＲＩＰ済データ７０３をＲＡＭ４０２に記憶すると、ＲＡＭ４０２の容量が不十分なときに問題が生じる。
このような問題があるため、どのＲＩＰ済データをＲＡＭ４０２とＨＤＤ４０４のどちらに記憶するのかを判断する方法が処理効率に影響する。

以下に、ＲＩＰ済データ７０３をＲＡＭ４０２とＨＤＤ４０４のどちらに記憶するのかを判断する方法の一例を説明する。
例えば、ＰＰＭＬには、再利用オブジェクトを参照するための要素（OCCURRENCE＿REF）にＷｅｉｇｈｔ属性が付与されている場合がある。この場合には、そのＷｅｉｇｈｔ属性の値の大きさに応じて、ＲＩＰ済データ７０３をＲＡＭ４０２とＨＤＤ４０４のどちらに記憶するのかを決定してもよい。この場合、ページを構成する再利用オブジェクトに付与されているＷｅｉｇｈｔ属性の値から、例えば平均値を求め、その平均値に基づいて各ページの重要度を算出する。そして、ＲＡＭ４０２の記憶容量を超えてＲＩＰ済データ７０３（ページ）をキャッシュしなければならなくなった際には、最も重要度の低いページのＲＩＰ済データ７０３をＲＡＭ４０２からＨＤＤ４０４に移し変える。

また、例えばＬＲＵ（Least Recently Used）アルゴリズムやＬＦＵ（Least Frequently Used）アルゴリズムを用いて、ＲＩＰ済データ７０３をＲＡＭ４０２とＨＤＤ４０４のどちらに記憶するのかを決定してもよい。ＬＲＵアルゴリズムを用いる場合には、前回再利用されてからその時点まで最も長い間再利用されなかったページのＲＩＰ済データ７０３をＲＡＭ４０２からＨＤＤ４０４に移し変える。一方、ＬＦＵアルゴリズムを用いる場合には、その時点で最も再利用されていないページのＲＩＰ済データ７０３をＲＡＭ４０２からＨＤＤ４０４に移し変える。

＜ＲＩＰの流れ（インタプリタ５０２の処理）＞
次に、図８のフローチャートを参照しながら、インタプリタ５０２により実行されるＲＩＰの一例を説明する。図８は、１ページ分のページデータに対してＲＩＰを行う場合のインタプリタ５０２の処理の一例を表すフローチャートである。以下、各処理について説明する。

まず、ステップＳ８０１において、インタプリタ５０２は、ＰＰＭＬスクリプトの１ページ分をパーズし、ＲＡＭ４０２に展開する。ここでパーズされた１つのページが以降の処理の処理対象ページとなる。
以上のように本実施形態では、例えば、ステップＳ８０１の処理を行うことにより解析手段の一例が実現される。

次に、ステップＳ８０２において、インタプリタ５０２は、処理対象ページを共通ページ判定部５０３に渡し、共通ページ判定部５０３に共通ページの一致判定を指示する。
共通ページ判定部５０３が、処理対象ページと、共通ページテーブル５０７に登録されている共通ページとが一致したと判定した場合、インタプリタ５０２は、その一致したページのリソースＩＤと、共通ページと一致したことを示すフラグを受け取る。以下の説明では、このフラグを必要に応じて一致フラグと称する。この場合、インタプリタ５０２は、ＴＲＵＥの値が代入された一致フラグを受け取る。

また、処理対象ページは共通ページであると判定されたが、処理対象ページと、共通ページテーブル５０７に登録されている共通ページとが一致しなかった場合、インタプリタ５０２は、次の情報を共通ページ判定部５０３から受け取る。すなわち、インタプリタ５０２は、そのページのリソースＩＤと、ＦＡＬＳＥの値が代入された一致フラグを共通ページ判定部５０３から受け取る。
また、処理対象ページが共通ページであると判定されなかった場合、インタプリタ５０２は、共通ページと判定されなかったことを示す値、例えば負の値が代入されたリソースＩＤと、ＦＡＬＳＥの値が代入された一致フラグを共通ページ判定部５０３から受け取る。
尚、共通ページ判定部５０３で行われる以上の処理の内容は、図９を用いて後述する。

次に、ステップＳ８０３において、インタプリタ５０２は、ステップＳ８０２で受け取った一致フラグの値がＴＲＵＥだったか否かを判定する。この判定の結果、ステップＳ８０２で受け取った一致フラグの値がＴＲＵＥだった場合、つまり現在の処理対象ページが、共通ページテーブル５０７に登録されている共通ページと一致した場合には、ステップＳ８０４へ進む。一方、ステップＳ８０２で受け取った一致フラグの値がＴＲＵＥでなかった場合、つまり現在の処理対象ページが共通ページテーブル５０７に存在していない場合には、ステップＳ８０５へ進む。

ステップＳ８０４に進むと、インタプリタ５０２は、共通ページキャッシュ５０８を参照して、共通ページのＲＩＰ済データ７０３を出力することをキャッシュマネージャ５０５に指示する。このステップＳ８０４の処理により、現在の処理対象ページをＲＩＰすることなくＲＩＰ済データ７０３を出力することができるためＲＩＰの高速化を図ることができる。
以上のように本実施形態では、例えば、ステップＳ８０４の処理を行うことにより出力手段の一例が実現される。

一方、ステップＳ８０５に進むと、インタプリタ５０２は、現在の処理対象ページの解釈を行う。
次に、ステップＳ８０６において、インタプリタ５０２は、ステップＳ８０５で解釈された処理対象ページの描画命令をレンダラ５０４に渡し、処理対象ページのラスタライズをレンダラ５０４に指示する。これにより処理対象ページのＲＩＰが行われる。レンダラ５０４は、出力部５０６にＲＩＰ済データを渡す。このＲＩＰ済データに基づいてプリンタ２０４で印刷出力が行われる。
以上のように本実施形態では、例えば、ＲＩＰが描画のための処理の一例となり、ＲＩＰ済データが描画処理済データの一例となる。また、ステップＳ８０６の処理を行うことにより生成手段の一例が実現される。尚、ＲＩＰ済データだけでなく、例えば中間データも描画処理済データに含まれる。

次に、ステップＳ８０７において、インタプリタ５０２は、ステップＳ８０２において共通ページ判定部５０３から正の値のリソースＩＤを受け取ったか否かを判定する。この判定の結果、共通ページ判定部５０３から正の値のリソースＩＤを受け取っている場合、つまり処理対象ページは共通ページであるが、共通ページテーブル５０７には含まれていない場合には、ステップＳ８０８に進む。ステップＳ８０８に進むのは、共通ページキャッシュ５０８に処理対象ページのＲＩＰ済データを格納するためである。一方、共通ページ判定部５０３から正の値のリソースＩＤを受け取っていない場合には、図８のフローチャートによる処理を終了する。

ステップＳ８０８に進むと、まずインタプリタ５０２は、レンダラ５０４に処理対象ページのＲＩＰ済データを要求し、ＲＩＰ済データを受け取る。そして、インタプリタ５０２は、キャッシュマネージャ５０５に、処理対象ページのＲＩＰ済みデータを渡し、処理対象ページのＲＩＰ済データを共通ページキャッシュ５０８へ登録することを依頼する。
以上のように本実施形態では、例えば、ステップＳ８０８の処理を行うことにより記憶手段の一例が実現される。また、例えば、リソースＩＤフィールド６０１、７０１とポインタフィールド６０４、７０２を用いることにより、ＲＡＭ４０２に記憶された"ＲＩＰ済データと、そのＲＩＰ済データ生成元であるページデータ"が相互に対応付けられる。

＜共通ページの判定（共通ページ判定部５０３の処理）＞
前述したように、図８のステップＳ８０２の処理が行われると、共通ページ判定部５０３はインタプリタ５０２からの指示を受け付ける。この指示を受け付けると、共通ページ判定部５０３は、現在の処理対象ページが共通ページか否かの判定と、処理対象ページと一致する共通ページの探索とを行う。
ここで、このような共通ページ判定部５０３の処理の一例について図９のフローチャートを参照しながら説明する。図９は、共通ページ判定部５０３における処理の一例を説明するフローチャートである。

まず、ステップＳ９０１において、共通ページ判定部５０３は、処理対象ページが再利用オブジェクトのみで構成されているかを判定することで、共通ページの候補を絞り込む。
このステップＳ９０１の処理は、共通ページに含まれるオブジェクトは必ず複数回再利用されるため、ＰＰＭＬを出力するアプリケーションであれば、共通ページに含まれるオブジェクトは全て再利用オブジェクトとして出力されるという仮定に基づいている。このステップＳ９０１の処理を行うことで、共通ページとはなり得ないページと、共通ページテーブル５０７に記録されている共通ページとの無駄な一致判定処理を回避できる。
以上のように本実施形態では、例えば、ステップＳ９０１の処理を行うことにより抽出手段の一例が実現される。

このステップＳ９０１の判定の結果、処理対象ページが再利用オブジェクトのみで構成されていないと判定された場合には、後述するステップＳ９０６に進む。一方、処理対象ページが再利用オブジェクトのみで構成されている場合には、ステップＳ９０２に進む。ステップＳ９０２に進むと、共通ページ判定部５０３は、ステップＳ９０１にて共通ページの候補と判定された処理対象ページと一致する"共通ページキャッシュ５０８内の共通ページ"を探索する。そして、共通ページ判定部５０３は、処理対象ページと一致する共通ページが共通ページキャッシュ５０８にあるか否かを判定する。このステップＳ９０２の処理でも、ＰＰＭＬの性質を利用した"一致判定回数を低減させる施策"を行っている。その詳細は図１０を用いて後述する。
以上のように本実施形態では、例えば、ステップＳ９０２の処理を行うことにより判定手段の一例が実現される。

このステップＳ９０２の判定の結果、処理対象ページと一致する共通ページがあると判定された場合には、ステップＳ９０３に進み、そうでない場合には、ステップＳ９０４に進む。
ステップＳ９０３に進むと、共通ページ判定部５０３は、ステップＳ９０３において処理対象ページと一致したと判定された共通ページのリソースＩＤと、ＴＲＵＥの値が代入された一致フラグとを、インタプリタ５０２に返す。
このステップＳ８０３の処理により、図８のステップＳ８０４の処理が行われ、共通ページ判定部５０３から受け取ったリソースＩＤを持った共通ページのＲＩＰ済データの再利用が行われる。そして、後述するステップＳ９０５に進む。

一方、ステップＳ９０４に進むと、共通ページ判定部５０３は、新規に発行したリソースＩＤと、ＦＡＬＳＥの値が代入された一致フラグとをインタプリタ５０２に返す。
ここで、共通ページ判定部５０３は、共通ページテーブル５０７のリソースＩＤフィールド６０１に格納されていない正の値を持ったリソースＩＤを新規に発行する。
このステップＳ９０４の処理により、図８のステップＳ８０６、Ｓ８０７、Ｓ８０９の処理が行われ、処理対象ページのＲＩＰと、その処理対象ページのＲＩＰ済データが共通ページキャッシュ５０８に記憶される。そして、ステップＳ９０５に進む。

ステップＳ９０５に進むと、共通ページ判定部５０３は、共通ページテーブル５０７の更新を行う。ステップＳ９０５の前に、ステップＳ９０３、Ｓ９０４のどちらが処理されたかによって、共通ページテーブル５０７の更新内容は異なる。
ステップＳ９０５で共通して行う処理は、共通ページの並び順の更新である。具体的には、図６に示した遷移履歴フィールド６０２と、累積回数フィールド６０３の更新が行われる。
また、ステップＳ９０４を処理した場合のみ必要となる処理は、新規に発行したリソースＩＤを用いて、リソースＩＤフィールド６０１とポインタフィールド６０４へのレコードの追加が行われる。

前述したように、ステップＳ９０１の判定の結果、処理対象ページが再利用オブジェクトのみで構成されていないと判定された場合には、ステップＳ９０６に進む。ステップＳ９０６に進むと、共通ページ判定部５０３は、負の値をもったリソースＩＤと、ＦＡＬＳＥの値が代入された一致フラグとをインタプリタ５０２に返す。
このステップＳ９０６の処理により、図８のステップＳ８０６、Ｓ８０７の処理が行われ、対象処理ページのＲＩＰが行われる。この場合、処理対象ページは、共通ページキャッシュ５０８に記憶されない。

＜処理対象ページと一致するキャッシュ内共通ページの探索＞
前述したように、図９のステップＳ９０２において、共通ページ判定部５０３は、ステップＳ９０２にて共通ページの候補と判定した処理対象ページと一致する"共通ページテーブル５０７内の共通ページ"を探索する。
ここで、この共通ページ判定部５０３の処理の一例について図１０のフローチャートを参照しながら説明する。図１０は、図９のステップＳ９０２の詳細な処理の一例を説明するフローチャートである。

まず、ステップＳ１００１において、共通ページ判定部５０３は、処理対象ページが、ＰＰＭＬジョブの１レコード目にあたるか否かを判定する。
この判定の結果、処理対象ページが、ＰＰＭＬジョブの１レコード目であった場合には、ステップＳ１００８に進み、共通ページ判定部５０３は、この処理対象ページと一致するページは共通ページキャッシュ５０８には存在しないと判定する。このステップＳ１００８の処理は、１レコード目にあたるページは、それ以前に処理されたページがないので、共通ページテーブル５０７に同じ内容のページが登録されていることはないという前提に基づいている。

この前提に当てはまらないケースとして、１レコード目に含まれる複数のページに、共通したページが含まれるケースも考えられるが、これは稀なケースであるため本実施形態では前述した前提を置いている。この前提に当てはまらないケースでは、ステップＳ１００１の処理を行うと、レコードに共通するページ、つまり同じ内容のページが、異なったキャッシュとして登録されるためＲＡＭ４０２に無駄が生じる。このケースに対処する方法として、ステップＳ１００１の処理を行わないようにしてもよい。この場合、１レコード目に含まれるページ同士も一致判定の対象となる。

尚、ここではレコードという用語を用いたが、実際には、ＰＰＭＬには文書階層上のレコードにあたる階層を指定するための仕様は存在しない。そのためＰＰＭＬの記述から直接的にどのページがどのレコードに所属しているのかを識別する方法はない。そこで、以下の説明では、ＰＰＭＬが持つ階層のうち、１つのDOCUMENT要素が１レコードにあたるものとして説明を行う。

ステップＳ１００１において、処理対象ページが、ＰＰＭＬジョブの１レコード目でないと判定された場合には、ステップＳ１００２に進む。ステップＳ１００２に進むと、共通ページ判定部５０３は、処理対象ページがレコードの１ページ目であるか否かを判定する。この判定の結果、処理対象ページがレコードの１ページ目である場合には、後述するステップＳ１００６に進み、１ページ目に特有な探索処理が行われる。一方、処理対象ページがレコードの２ページ目以降である場合には、ステップＳ１００３に進む。

ステップＳ１００３に進むのは、ステップＳ１００１、Ｓ１００２にて該当しなかったページ、つまり処理対象ページが２レコード目以降であり、且つ２ページ目以降であった場合である。ステップＳ１００３では、共通ページ判定部５０３は、図６の遷移履歴フィールド６０２に記録されている"ページの遷移履歴"を用いて、処理対象ページに一致する共通ページの探索を行う。ページの遷移履歴とは、どの共通ページがどの順番で出現したのかを記録したものである。このページの遷移履歴を用いることにより、現在の処理対象ページが、共通ページテーブル５０７内のどのページと一致する可能性が高いかを予測することができる。これにより、処理対象ページと一致するキャッシュ内の共通ページを早い段階で発見することができ、結果的にページ同士の一致判定の回数を低減することが可能となる。具体的な処理の流れは図１１を用いて後述する。

次に、ステップＳ１００４において、共通ページ判定部５０３は、ステップＳ１００３の探索の結果に基づいて処理対象ページと一致する共通ページがあるか否かを判定する。この判定の結果、処理対象ページと一致する共通ページがある場合には、ステップＳ１００５へ進み、共通ページ判定部５０３は、処理対象ページと一致するページが共通ページキャッシュ５０８に存在すると判定する。一方、処理対象ページと一致する共通ページがない場合には、ステップＳ１００８へ進み、共通ページ判定部５０３は、処理対象ページと一致するページは共通ページキャッシュ５０８に存在しないと判定する。

前述したようにステップＳ１００２において、処理対象ページがレコードの１ページ目であると判定された場合には、ステップＳ１００６に進む。ステップＳ１００６に進むと、共通ページ判定部５０３は、１ページ目に特有な方法で、処理対象ページに一致する共通ページを探索する。ステップＳ１００３における"２ページ目以降の探索処理"では、ページの遷移履歴を用いるようにした。しかしながら、１ページ目に対しては、１ページ目より前のページは存在しない。このため、ページの遷移履歴からでは、処理対象ページがどのページと一致する可能性が高いのかを予測することはできない。そこで、本実施形態では、１ページ目に対しては、図６に示した共通ページテーブル５０７の、累積回数フィールド６０３に記憶されている"共通ページが１ページ目に出現した回数"を用いるようにする。具体的には、１ページ目に出現する回数が多い共通ページを参照し、その回数が多い共通ページを、比較の優先順位が高いとみなす。そして、優先順位の高い共通ページから順に処理対象ページとの比較を行う。このように１ページ目に出現する頻度が高い共通ページから処理対象ページと比較することにより、処理対象ページと一致するキャッシュ内の共通ページを早い段階で発見することができ、結果的にページ同視の一致判定の回数を低減することが可能となる。このときの実際の探索の流れについては、図１３を用いて後述する。

尚、本実施形態では、図６に示した共通ページテーブル５０７に、１ページ目に出現する回数の情報を記憶しているが、２ページ目に出現する回数や、３ページ目に出現する回数等、所定のページに出現する回数を記憶するようにしてもよい。この場合、例えば、処理対象ページが、或るレコードの３ページ目であるとする。この場合、共通ページ判定部５０３は、共通ページテーブル５０７を参照し、３ページ目に出現する回数の多い共通ページから順に処理対象ページとの比較を行う。また、この方法を、遷移履歴を用いた方法と併用してもよい。その場合、共通ページテーブル５０７内の各共通ページに対し、遷移履歴を用いて評価された優先順位と、所定のページに出現する回数を用いて評価された優先順位とを加重平均する等して優先順位を決定する。

次に、ステップＳ１００７において、共通ページ判定部５０３は、ステップＳ１００６の探索の結果に基づいて処理対象ページと一致する共通ページがあるか否かを判定する。この判定の結果、処理対象ページと一致する共通ページがある場合には、ステップＳ１００５へ進み、共通ページ判定部５０３は、処理対象ページと一致するページが共通ページキャッシュ５０８に存在すると判定する。一方、処理対象ページと一致する共通ページがない場合には、ステップＳ１００８へ進み、共通ページ判定部５０３は、処理対象ページと一致するページは共通ページキャッシュ５０８に存在しないと判定する。

＜遷移履歴を用いたページ同士の一致判定＞
前述したように図１０のステップＳ１００３において、共通ページ判定部５０３は、図６の遷移履歴フィールド６０２に記録されている"ページの遷移履歴"を用いて、処理対象ページがどの共通ページと一致する可能性が高いかを予測する。そして、その可能性が高い共通ページから順に処理対象ページとの一致判定を行う。
ここで、この共通ページ判定部５０３の処理の一例について図１１、図１２を参照しながら説明する。図１１は、図１０のステップＳ１００３、Ｓ１００４の詳細な処理の一例を説明するフローチャートである。図１２は、図１０のステップＳ１００３の処理の一例を概念的に説明する図である。図１２では、１レコード目から３レコード目までの全ページと、４レコード目の２ページ目までの処理が完了しており、４レコード目の３ページ目が処理対象ページとなっている例を示している。

まず、ステップＳ１１０１において、共通ページ判定部５０３は、処理対象ページの１ページ前と２ページ前のリソースＩＤを、共通ページテーブル５０７から取得する。図１２に示す例では、処理対象ページ１２０２の１ページ前はＢ（リソースＩＤは００２）、２ページ前はＡ（リソースＩＤは００１）である。もし、処理対象ページが２ページ目だった場合、２ページ前は存在しないので、処理対象ページの１ページ前のリソースＩＤのみを取得する。

次に、ステップＳ１１０２において、共通ページ判定部５０３は、ステップＳ１１０１で取得した２つのリソースＩＤに基づいて、処理対象ページと比較する共通ページの、比較を行う優先順位を決定する。本実施形態では、優先順位付けの基準の一例として、以下の（１）〜（３）を採用している。
（１）処理対象ページの１つ前と２つ前のページが一致する遷移履歴に対応する共通ページ。
（２）処理対象ページの１つ前のページが一致する遷移履歴に対応する共通ページ。
（３）処理対象ページの１つ前のページと一致しない遷移履歴に対応する共通ページ。
この例では、（１）が最も優先順位が高い共通ページであり、（３）が最も優先順位が低い共通ページとなる。

具体的に優先順位を付ける過程を説明する。
ステップＳ１１０１で述べたとおり、図１２に示す例では、処理対象ページ１２０２の１ページ前はＢ（リソースＩＤは００２）、２ページ前はＡ（リソースＩＤは００１）である。例えば、図１１において点線で示された「Ａ→Ｂ→Ｃ」という遷移履歴は、処理対象ページの２つ前のページ１２０４と１つ前のページ１２０３と処理対象ページ１２０２の遷移に一致する。従って、この遷移履歴「Ａ→Ｂ→Ｃ」に対応する共通ページＣが、優先順位が最も高い共通ページであると評価する。また、例えば、「Ｆ→Ｂ→Ｄ」という遷移履歴は、処理対象ページ１２０２の１つ前のページ１２０３と処理対象ページ１２０２との遷移には一致するが、２つ前のページ１２０４からの遷移とは一致しない。そこで、この遷移履歴「Ｆ→Ｂ→Ｄ」に対応する共通ページＤが、２番目に優先順位が高い共通ページであると評価する。また、例えば、「Ｆ→Ｂ」という遷移履歴は、処理対象ページ１２０２の１つ前のページ１２０３と処理対象ページ１２０２との遷移に一致しないため、この遷移履歴「Ｆ→Ｂ」に対応する共通ページＢが、最も優先順位が低い共通ページであると評価する。この場合における、各共通ページの優先順位を図１２の各遷移履歴の右にかっこ書きで記載している。

ここで示した優先順位の基準の例では、例えば「Ａ→Ｂ→Ｃ」、「Ａ→Ｂ→Ｋ」のように、優先順位が同じ遷移履歴が存在する場合がある。この場合には、その遷移履歴の出現回数が大きいものほど優先順位が高いと評価する。例えば、遷移履歴「Ａ→Ｂ→Ｃ」が２回出現しており、遷移履歴「Ａ→Ｂ→Ｋ」が１回だけ出現しているとすると、遷移履歴「Ａ→Ｂ→Ｃ」の方がより優先順位が高いと評価する。

図１２に示す例では、最も優先順位が高い遷移履歴は「Ａ→Ｂ→Ｃ」である。従って、前述した優先順位の基準では、処理対象ページはＣ（リソースＩＤは００３）である可能性が最も高い。そこで、ステップＳ１１０３の次の処理であるステップＳ１１０４では、共通ページＣから処理対象ページとの一致判定を開始し、優先順位が高い共通ページから順に処理対象ページとの比較を行う。これにより、共通ページと一致する処理対象ページをなるべく早く見つけられる可能性が高くなり、結果的に一致判定回数を減らすことができる。

ステップＳ１１０２において、処理対象ページが２ページ目だった場合、処理対象ページの１ページ前のリソースＩＤのみしか取得できない場合があることを先に述べた。この場合、優先順位の基準は、１ページ前と２ページ前のリソースＩＤを取得できる場合と異なる方法を用いる必要がある。この場合、優先順位の基準は例えば以下のようにする。すなわち、処理対象ページの１つ前のページと一致する遷移履歴から導かれる共通ページを最も優先順位が高い共通ページとする。そして、処理対象ページの１つ前のページとは一致しない遷移履歴から導かれる共通ページを最も優先順位が低い共通ページとする。

尚、本実施形態では、３ページ分のページの遷移を遷移履歴として記憶しているが、遷移履歴に記憶するページ数は、３ページに限定されない。例えば、それ以上、つまり４ページ分以上の履歴を遷移履歴として共通ページテーブル５０７に記憶するようにしてもよい。また、２ページ分だけの履歴を遷移履歴として共通ページテーブル５０７に記憶するようにしてもよい。
また、前述した優先順位の基準は一例であり、その他の優先順位の基準で優先順位を決定してもよい。
以上のように本実施形態では、例えば、ステップＳ１１０２の処理を行うことにより決定手段の一例が実現される。また、例えば、遷移履歴フィールド６０２に遷移履歴を記憶することにより第２の記憶手段の一例が実現される。

次に、ステップＳ１１０３において、共通ページ判定部５０３は、ステップＳ１１０２で決定した優先順位に基づいて、処理対象ページと共通ページとの比較を行う。ステップＳ１１０３の具体的な処理の流れについては図１３を用いて後述する。
次に、ステップＳ１１０４において、共通ページ判定部５０３は、ステップＳ１１０３の比較の結果に基づいて、処理対象ページと一致する共通ページがあったか否かを判定する。この判定の結果、処理対象ページと一致する共通ページがある場合には、ステップＳＳ１１０５に進み、共通ページ判定部５０３は、現在の処理対象ページと一致する共通ページが共通ページテーブル５０７（共通ページキャッシュ５０８）に存在すると判定する。
一方、処理対象ページと一致する共通ページがない場合には、ステップＳ１１０７に進み、共通ページ判定部５０３は、現在の処理対象ページと一致する共通ページが共通ページテーブル５０７（共通ページキャッシュ５０８）に存在しないと判定する。

＜処理対象ページと共通ページとの一致判定＞
図１０のステップＳ１００７及び図１１のステップＳ１１０４において、比較の優先順位に基づき、処理対象ページと、その比較対象となる共通ページとの一致判定処理を行うことを述べた。ここで、この共通ページ判定部５０３の処理の一例について、図１３のフローチャートを参照しながら説明する。図１３は、図１０のステップＳ１００６、Ｓ１００７及び図１１のステップＳ１１０３、Ｓ１１０４の詳細な処理の一例を説明するフローチャートである。

まず、ステップＳ１３０１において、共通ページ判定部５０３は、図１０のステップＳ１００７、図１１のステップＳ１１０４で説明した処理を行う。すなわち、共通ページ判定部５０３は、比較する優先順位が最も高い共通ページを選択する。図１０のステップＳ１００７では、優先順位が高い共通ページは、図６に示した共通ページテーブル５０７の累積回数フィールド６０３の値が最も大きい共通ページである。一方、図１１のステップＳ１１０４では、優先順位が高い共通ページは、図１１のステップＳ１１０２で説明した優先順位の基準に基づいて決定される共通ページである。
ここで、既に処理対象ページとの比較が行われた共通ページはどれなのかという情報をＲＡＭ４０２に記憶しておき、この共通ページについては再度比較しないようにしてもよい。

次に、ステップＳ１３０２において、共通ページ判定部５０３は、処理対象ページのスクリプトのバイト数と、一致判定の対象となる共通ページのスクリプトのバイト数とが一致するか否かを判定する。この判定の結果、処理対象ページのスクリプトのバイト数と、一致判定の対象となる共通ページの夫々のスクリプトのバイト数とが一致しない場合には、後述するステップ１３０５に進む。
以上のように本実施形態では、例えば、スクリプトのバイト数がスクリプトの情報量の一例であり、ステップＳ１３０２の処理を行うことにより情報量判定手段の一例が実現される。

一方、処理対象ページのスクリプトのバイト数と、一致判定の対象となる共通ページの夫々のスクリプトのバイト数とが一致する場合には、ステップＳ１３０３に進む。ステップＳ１３０３に進むと、共通ページ判定部５０３は、処理対象ページに配置されているオブジェクトと、一致判定の対象となる共通ページに配置されているオブジェクトとが全て同一か否かを判定する。

本実施形態では、ステップＳ１３０３において、共通ページ判定部５０３は、背景オブジェクトからではなく、前景オブジェクトからオブジェクトの一致判定を行う。この処理により、背景が共通しているが前景が異なるページ同士の一致判定において、早い段階で両ページのオブジェクトが不一致と判定することができる。このため、オブジェクト同士の一致判定の回数を減らすことができる。
この処理において、どのオブジェクトが前景なのか、背景なのかという判定を直接行う必要はない。ＰＰＭＬスクリプトにおいては、ページの最初の方に記述されているオブジェクトは背景オブジェクトである場合が多く、また、ページの最後の方に記述されているオブジェクトは前景オブジェクトである場合が多い。その理由は、ＰＰＭＬの文法上、先に記述されるオブジェクトが、後に記述されるオブジェクトに上書きされて描画されるためであり、ＰＰＭＬスクリプトを出力するアプリケーションも前述したような記述を行うことが多いためである。

そこで、前景オブジェクトから順にオブジェクト同士の一致判定を行う。本実施形態では、図１４に示すように、ページの最後に記述されているオブジェクトから順に判定を開始し、ページの最初に記述されているオブジェクトを最後に判定するようにしている。
図１４は、処理対象ページに配置されているオブジェクトと、一致判定の対象となる共通ページに配置されているオブジェクトとの一致判定を行う方法の一例を概念的に示す図である。
以上のように本実施形態では、例えば、ステップＳ１３０３の処理を行うことによりオブジェクト判定手段の一例が実現される。
尚、ここでは前景オブジェクトから順にオブジェクトの一致判定を行う方法を例に挙げて説明したが、必ずしもこのようにする必要はなく、背景オブジェクトから順にオブジェクトの一致判定を行うようにしてもよい。この場合、ＰＰＭＬスクリプトにおいてページの最初に記述されているオブジェクトから順番に一致判定を行っていけばよい。

以上のようなステップＳ１３０３の判定の結果、処理対象ページに配置されているオブジェクトと、一致判定の対象となる共通ページに配置されているオブジェクトとが全て一致した場合には、ステップＳ１３０４に進む。ステップＳ１３０４に進むと、共通ページ判定部５０３は、処理対象ページと、一致判定の対象となる共通ページとが一致すると判定する。
一方、処理対象ページに配置されているオブジェクトと、一致判定の対象となる共通ページに配置されているオブジェクトとが全て一致しない場合には、ステップＳ１３０５に進む。

ステップＳ１３０５に進むと、共通ページ判定部５０３は、処理対象ページと比較していない共通ページが共通ページテーブル５０７にあるか否かを判定する。
ステップＳ１３０５の判定の結果、処理対象ページと比較していない共通ページが共通ページテーブル５０７にない場合には、ステップＳ１３０６に進む。ステップＳ１３０６に進むと、共通ページ判定部５０３は、処理対象ページと、一致判定の対象となる共通ページとが一致しないと判定する。

一方、処理対象ページと比較していない共通ページが共通ページテーブル５０７にある場合には、ステップＳ１３０７に進む。ステップＳ１３０７に進むと、共通ページ判定部５０３は、一致判定の対象となる共通ページとして前回選択した共通ページの次に優先順位が高い共通ページを一致判定の対象となる共通ページとして新たに選択する。そして、新たに選択した共通ページについてステップＳ１３０２以降の処理を行う。このようにして、共通ページテーブル５０７にリソースＩＤが登録されている全ての共通ページについて優先順位が高いものから順番にステップＳ１３０２以降の処理が繰り返し行われる。

尚、処理対象ページと、一致判定の対象となる共通ページとが一致するか否かを判定する方法は、図１３に示したものに限定されない。例えば、予め共通ページのスクリプトに対しハッシュ値を求めておき、そのハッシュ値が処理対象ページのハッシュ値と一致するかどうかを判定するようにしてもよい。ハッシュ値を用いる方法は、スクリプトのバイト数が一致するかどうかの判定の代わりとして用いてもよいし、併用するようにしてもよい。

また、図１３では、ステップＳ１３０５の処理で説明した通り、共通ページテーブル５０７内の全ての共通ページを処理対象ページとの比較対象としている。しかしながら、処理対象ページと一致判定しなければならない共通ページが非常に多い場合、一致判定処理を行って、共通ページのＲＩＰ済データを再利用する処理よりも、インタプリット及びラスタライズにかかる時間の方が短くなる場合がある可能性がある。これに対処するため、共通ページテーブル５０７内の全ての共通ページに対して一致判定を行わずに、共通ページテーブル５０７内の一部の共通ページだけに対して一致判定を行うようにしてもよい。

例えば、最も高い優先順位を得た共通ページから所定順位までの共通ページだけを対象に一致判定を行うようにしてもよい。この所定順位を決定するには、例えば以下のような方法をとる。まず、図５に示したインタプリタ５０２が１ページ分の解釈を行うのにかかる平均時間（図８のステップＳ８０５の処理にかかる平均時間）と、レンダラ５０４が１ページ分のラスタライズを行うのにかかる平均時間とをＲＡＭ４０２に記憶する。これらの時間の合計を時間Ａとする。そして、キャッシュマネージャ５０５が１ページ分のＲＩＰ済データを出力するのにかかる平均時間（図８のステップＳ８０４の処理にかかる平均時間）をＲＡＭ４０２に記憶する。この時間を時間Ｂとする。最後に、ページ同士の一致判定を１回行うのにかかる平均時間をＲＡＭ４０２に記憶する。この時間を時間Ｃとする。そして、共通ページ判定部５０３は、以下の（１）式を用いて、許容される一致判定回数、つまり所定順位を求めることができる。
許容される一致判定回数＝（Ａ−Ｂ）／Ｃ ・・・（１）

図１５は、許容される一致判定回数を導出する方法を説明する図である。
図１５において、インタプリット平均処理時間とは、インタプリタ５０２が１ページ分の解釈を行うのにかかる平均時間（図８のステップＳ８０５の処理にかかる平均時間）である。ラスタライズ平均処理時間とは、レンダラ５０４が１ページ分のラスタライズを行うのにかかる平均時間である。キャッシュ出力平均処理時間とは、キャッシュマネージャ５０５が１ページ分のＲＩＰ済データを出力するのにかかる平均時間（図８のステップＳ８０４の処理にかかる平均時間）である。一致判定平均処理時間とは、ページ同士の一致判定を１回行うのにかかる平均時間である。

図１５に示すように、インタプリット平均処理時間とラスタライズ平均処理時間との合計である時間Ａから、キャッシュ出力平均処理時間Ｂを減算した値が、一致判定処理に許容される時間と考えることができる。そして、この時間を、一致判定平均処理時間Ｃで除算すると、許容される一致判定回数を求めることができる。
以上の方法では、（１）式に示す時間Ａ、Ｂ、Ｃを計測する必要がある。この時間Ａ、Ｂ、Ｃはオフラインで計測してもよいし、オンラインで計測してもよい。つまり、処理対象のＰＰＭＬジョブにおいて、最初の所定数のレコードを処理する際に時間Ａ、Ｂ、Ｃを計測し、（１）式により所定順位を算出し、その所定順位を残りのレコードに対して適用するようにしてもよい。または、処理対象のＰＰＭＬジョブとは別の複数のＰＰＭＬジョブに対し、予め時間Ａ、Ｂ、Ｃを計測し、（１）式により所定順位を算出しておき、それを実際の処理対象のＰＰＭＬジョブに対して適用するようにしてもよい。

以上のように本実施形態では、ＲＩＰ済データを使用するかどうかを判定するに際し、処理対象のページが再利用可能なオブジェクトのみで構成されているか否かを判定する。この判定の結果、処理対象のページが再利用可能なオブジェクトのみで構成されていない場合には、ＲＩＰ済データを使用せずに当該処理対象のページに対してＲＩＰを行う。一方、処理対象のページが再利用可能なオブジェクトのみで構成されていない場合には、当該処理対象のページと一致する共通ページが共通ページテーブル５０７に登録されているか否かを判定する。この判定の結果、登録されている場合にはＲＩＰ済データを再利用し、登録されていない場合にはＲＩＰ済データを使用せずに当該処理対象のページに対してＲＩＰを行う。したがって、ＲＩＰ済データを再利用するか否かを判定するための処理を従来よりも簡略化することができる。例えば、ページ同士の一致判定の回数、オブジェクト同士の一致判定の回数を減らすことができるため、ページ単位のキャッシュの利点を失わずに印刷処理の高速化を図ることができる。特に、処理対象のページが再利用可能なオブジェクトのみで構成されている場合には、ページ同士の一致判定とオブジェクト同士の一致判定を行わないようにすることができる。よって、どのページがどのページと共通しているのかという情報を文法上記述できない言語（例えばＰＰＭＬ）で記述されたデータをページ単位でキャッシュして再利用するための処理を、従来よりも簡略化することができる。

また、処理対象のページと一致する共通ページが共通ページテーブル５０７に登録されているか否かを判定するに際し、２レコード目以降の１ページ目については、過去に１ページ目として印刷した回数の多い共通ページから優先して処理対象のページと比較する。一方、２レコード目移行の２ページ目以降については、過去に印刷を行ったジョブにおけるページの遷移に対応する共通ページから優先して処理対象のページと比較する。したがって、ＲＩＰ済データを再利用するか否かを判定するための処理を、より一層簡略化することができる。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。前述した第１の実施形態では、遷移履歴を用い、処理対象ページと一致する可能性が高い共通ページを予測することで、処理対象ページとの一致判定を行う共通ページの優先順位を決定していた。これに対し本実施形態では、遷移履歴を用いずに、処理対象ページが含まれるレコードのページ構成が、どのレコードのページ構成と似ているか、という情報に基づいて、一致判定を行う共通ページの優先順位を決定する。このように本実施形態と前述した第１の実施形態とは、処理対象ページとの一致判定を行う共通ページの優先順位を決定する方法が主として異なる。したがって、本実施形態の説明において、前述した第１の実施形態と同一の部分については、図１〜図１５に付した符号と同一の符号を付す等して詳細な説明を省略する。

図１６は、レコード間のページ構成の類似度を求める方法の一例を概念的に示す図である。図１６に示す例では、５レコード目の５ページ目が処理対象ページであり、１レコード目の１ページ目から、処理対象ページの１つ前のページまでが処理済であることを想定している。
ここで問題となるのは、レコード間のページ構成の類似度を求める方法である。
本実施形態では、レコード間のページ構成の類似度を例えば以下のようにして求めるようにしている。すなわち、処理対象ページ１６０１が含まれるレコードを構成するページ（図１６に示す例では、５レコード目における、処理対象ページ１６０１以外のページ）が何ページあるかということや、それらのページの並び順がどれくらい類似しているか等を評価する。そして、最終的な類似度は、以上のような評価によって得られた類似度を、加重平均等を用いて総合したものとする。そして、この最終的な類似度が最も高いレコードに含まれる共通ページから順に処理対象ページ１６０１との一致判定を行う。具体的に説明すると、処理対象ページ１６０１が含まれないレコードのページ群のうち、処理対象ページ１６０１が含まれるレコードを構成する共通ページと一致したページ群の次のページから順番に一致判定を行う。

図１６に示す例では、矩形の点線で囲っている共通ページが、処理対象ページ１６０１が含まれるレコードを構成する共通ページと一致するページ群であり、楕円の点線で囲っている共通ページが、一致判定の対象となる共通ページである。
また、処理対象ページ１６０１が含まれるレコードのページ構成との類似度が最も高いのは、１レコード目である。したがって、優先順位が最も高い共通ページはＳとなる。また、処理対象ページ１６０１が含まれるレコードのページ構成との類似度が２番目に高いのは、２レコード目である。したがって、優先順位が２番目高い共通ページはＬとなる。また、処理対象ページ１６０１が含まれるレコードのページ構成との類似度が３番目に高いのは、４レコード目である。したがって、優先順位が３番目高い共通ページはＭとなる。
以上のように、レコード間のページ構成の類似度に基づいて、一致判定を行う共通ページの優先順位を決定するようにしても、第１の実施形態で説明したのと同じ効果を得ることができる。

（本発明の他の実施形態）
前述した本発明の実施形態における印刷制御装置を構成する各手段、並びに印刷制御方法の各ステップは、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図８、図９、図１０、図１１、図１３に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接、あるいは遠隔から供給するものを含む。そして、そのシステムあるいは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

尚、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

本発明の第１の実施形態を示し、共通ページを含んだ印刷ジョブの概念の一例を示す図である。 本発明の第１の実施形態を示し、印刷システムの概略構成の一例を示す図である。 本発明の第１の実施形態を示し、クライアントＰＣのハードウェア構成の一例を示すブロック図である。 本発明の第１の実施形態を示し、プリンタコントローラのハードウェア構成の一例を示すブロック図である。 本発明の第１の実施形態を示し、ＲＩＰモジュールのモジュール構成の一例を示す図である。 本発明の第１の実施形態を示し、共通ページテーブルのデータ構造の一例を概念的に示す図である。 本発明の第１の実施形態を示し、共通ページキャッシュの概念的なデータ構造の一例を示す図である。 本発明の第１の実施形態を示し、１ページ分のＲＩＰ処理を行う場合のインタプリタの処理の一例を表すフローチャートである。 本発明の第１の実施形態を示し、共通ページ判定部における処理の一例を説明するフローチャートである。 本発明の第１の実施形態を示し、図９のステップＳ９０２の詳細な処理の一例を説明するフローチャートである。 本発明の第１の実施形態を示し、図１０のステップＳ１００３、Ｓ１００４の詳細な処理の一例を説明するフローチャートである。 本発明の第１の実施形態を示し、図１０のステップＳ１００３の処理の一例を概念的に説明する図である。 本発明の第１の実施形態を示し、図１０のステップＳ１００６、Ｓ１００７及び図１１のステップＳ１１０３、Ｓ１１０４の詳細な処理の一例を説明するフローチャートである。 本発明の第１の実施形態を示し、処理対象ページに配置されているオブジェクトと、一致判定の対象となる共通ページに配置されているオブジェクトとの一致判定を行う方法の一例を概念的に示す図である。 本発明の第１の実施形態を示し、許容される一致判定回数を導出する方法を説明する図である。 本発明の第２の実施形態を示し、レコード間のページ構成の類似度を求める方法の一例を概念的に示す図である。

符号の説明

２０１ ネットワーク
２０２ クライアントＰＣ
２０３ プリンタコントローラ
２０４ プリンタ
５０１ ＲＩＰモジュール
５０２ インタプリタ
５０３ 共通ページ判定部
５０４ レンダラ
５０５ キャッシュマネージャ
５０７ 出力部
５０７ 共通ページテーブル
５０８ 共通ページキャッシュ

Claims (11)

1. 再利用可能なオブジェクトと、一度しか描画されないオブジェクトとを分けて記述することができる言語でページデータが記述されたスクリプトを解析する解析手段と、
   前記スクリプトに記述されているページデータのうち、再利用可能なオブジェクトのみで構成されているページデータを抽出する抽出手段と、
   前記抽出手段により抽出されたページデータに対して描画のための処理を行って描画処理済データを生成する生成手段と、
   前記生成手段により生成された描画処理済データと、当該描画処理済データの生成元であるページデータとを相互に対応付けて記憶媒体に記憶する記憶手段と、
   前記抽出手段により抽出されたページデータと、前記記憶媒体に既に記憶されているページデータとを比較して、これらが一致するか否かを判定する判定手段と、
   前記判定手段により、前記抽出手段により抽出されたページデータと、前記記憶媒体に既に記憶されているページデータとが一致していると判定された場合に、当該ページデータに対応付けられて前記記憶媒体に既に記憶されている描画処理済データを、前記生成手段により描画処理済データを生成する代わりに出力する出力手段と、を有することを特徴とする印刷制御装置。
2. 前記抽出手段により抽出されたページデータの遷移を記憶媒体に記憶する第２の記憶手段と、
   前記第２の記憶手段により記憶された、ページデータの遷移に基づいて、前記スクリプトに記述されているページデータと比較されるページデータの優先順位を決定する決定手段とを有し、
   前記判定手段は、前記決定手段により決定された優先順位に従って、前記記憶媒体に既に記憶されているページデータを選択し、選択したページデータと、前記スクリプトに記述されているページデータとを比較して、これらが一致するか否かを判定することを特徴とする請求項１に記載の印刷制御装置。
3. 前記判定手段は、前記スクリプトに記述されているページデータの情報量と、前記記憶媒体に既に記憶されているページデータの情報量とが一致するか否かを判定する情報量判定手段と、
   前記情報量判定手段により情報量が一致すると判定された場合に、前記スクリプトに記述されているページデータのオブジェクトと、前記記憶媒体に既に記憶されているページデータのオブジェクトとが一致するか否かを判定するオブジェクト判定手段とを有し、
   前記情報量判定手段により情報量が一致しないと判定された場合と、前記オブジェクト判定手段によりオブジェクトが一致しないと判定された場合に、前記スクリプトに記述されているページデータと、前記記憶媒体に既に記憶されているページデータとが一致しないと判定し、
   前記オブジェクト判定手段によりオブジェクトが一致すると判定された場合に、前記記憶媒体に既に記憶されているページデータとが一致すると判定することを特徴とする請求項１又は２に記載の印刷制御装置。
4. 前記オブジェクト判定手段は、前景となるオブジェクトから先にオブジェクトが一致するか否かを判定することを特徴とする請求項３に記載の印刷制御装置。
5. 前記判定手段は、前記記憶媒体に記憶された複数ページのページデータのうち、一部のページのページデータについて、前記スクリプトに記述されているページデータと一致するか否かを判定することを特徴とする請求項１〜４の何れか１項に記載の印刷制御装置。
6. 前記一部のページは、１ページ分の前記ページデータから前記描画処理済データを生成するのに要する時間から、前記描画処理済データを出力するのに要する時間を減算した時間に対応する数のページであることを特徴とする請求項５に記載の印刷制御装置。
7. 前記生成手段は、前記判定手段により、前記スクリプトに記述されているページデータと、前記記憶媒体に既に記憶されているページデータとが一致しないと判定された場合に、当該ページデータに対して描画のための処理を行って描画処理済データを生成することを特徴とする請求項１〜６の何れか１項に記載の印刷制御装置。
8. 前記生成手段は、前記抽出手段により再利用可能なオブジェクトのみで構成されているページデータが抽出されたかった場合にも、当該ページデータに対して描画のための処理を行って描画処理済データを生成することを特徴とする請求項１〜７の何れか１項に記載の印刷制御装置。
9. 前記言語は、ＰＰＭＬであることを特徴とする請求項１〜８の何れか１項に記載の印刷制御装置。
10. 再利用可能なオブジェクトと、一度しか描画されないオブジェクトとを分けて記述することができる言語でページデータが記述されたスクリプトを解析する解析ステップと、
    前記スクリプトに記述されているページデータのうち、再利用可能なオブジェクトのみで構成されているページデータを抽出する抽出ステップと、
    前記抽出ステップにより抽出されたページデータに対して描画のための処理を行って描画処理済データを生成する生成ステップと、
    前記生成ステップにより生成された描画処理済データと、当該描画処理済データの生成元であるページデータとを相互に対応付けて記憶媒体に記憶する記憶ステップと、
    前記抽出ステップにより抽出されたページデータと、前記記憶媒体に既に記憶されているページデータとを比較して、これらが一致するか否かを判定する判定ステップと、
    前記判定ステップにより、前記抽出ステップにより抽出されたページデータと、前記記憶媒体に既に記憶されているページデータとが一致していると判定された場合に、当該ページデータに対応付けられて前記記憶媒体に既に記憶されている描画処理済データを、前記生成ステップにより描画処理済データを生成する代わりに出力する出力ステップと、を有することを特徴とする印刷制御方法。
11. 再利用可能なオブジェクトと、一度しか描画されないオブジェクトとを分けて記述することができる言語でページデータが記述されたスクリプトを解析する解析ステップと、
    前記スクリプトに記述されているページデータのうち、再利用可能なオブジェクトのみで構成されているページデータを抽出する抽出ステップと、
    前記抽出ステップにより抽出されたページデータに対して描画のための処理を行って描画処理済データを生成する生成ステップと、
    前記生成ステップにより生成された描画処理済データと、当該描画処理済データの生成元であるページデータとを相互に対応付けて記憶媒体に記憶する記憶ステップと、
    前記抽出ステップにより抽出されたページデータと、前記記憶媒体に既に記憶されているページデータとを比較して、これらが一致するか否かを判定する判定ステップと、
    前記判定ステップにより、前記抽出ステップにより抽出されたページデータと、前記記憶媒体に既に記憶されているページデータとが一致していると判定された場合に、当該ページデータに対応付けられて前記記憶媒体に既に記憶されている描画処理済データを、前記生成ステップにより描画処理済データを生成する代わりに出力する出力ステップと、をコンピュータに実行させることを特徴とするコンピュータプログラム。

Images