【課題】あるデータ処理装置が、ある文書要素の画像データがキャッシュメモリに存在するかどうかを問い合わせた場合に、別のデータ処理装置がその画像データを作成中であれば、その旨を知って対応できるようにする。
【解決手段】キャッシュ管理部１３０は、いずれかのＲＩＰ部１２０からオブジェクトについての問合せを受けた場合、エントリ管理テーブル１３２に記録されたそのオブジェクトのステージ（キャッシュ状態）を調べ、そのステージが、他のＲＩＰ部１２０が当該オブジェクトのキャッシュデータを作成中であることを示す「作成中」状態（“New chache”）である場合、その旨を示す「作成中」応答（“creating”）を返す。「作成中」応答を受け取ったＲＩＰ部１２０は、設定に従い、他のＲＩＰ部１２０による当該オブジェクトのキャッシュデータの作成完了を待つか、待たずに当該オブジェクトのＰＤＬデータをＲＩＰ処理するかの制御を行う。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷文書処理システム、キャッシュ装置、データ処理装置及びプログラムに関する。
【背景技術】
【０００２】
一般に、パーソナルコンピュータから印刷装置に送られる印刷文書データは、ＰｏｓｔＳｃｒｉｐｔ（登録商標）やＰＤＦ( Portable Data Format: ISO 32000-1) などのページ記述言語（以下、ＰＤＬと呼ぶ。ＰＤＬはPage Description Languageの略）で記述されている。印刷装置では、ＲＩＰ( Raster Image Processor)と呼ばれるデータ処理装置により印刷文書データをビットマップ形式（ラスター形式とも呼ばれる）の画像データに変換し、その画像データをプリントエンジンにより印刷する。また、ＰＤＬデータを直接ラスター画像に変換する方式の他に、ＰＤＬデータをＰＤＬコマンドよりは粒度の小さいディスプレイリスト等の中間言語形式のデータに変換してバッファし、バッファした中間言語形式のデータをビットマップ形式に変換するという２段階の変換を行う印刷装置もよく知られている。
【０００３】
従来、ＰＤＬデータからビットマップ形式又は中間言語形式の画像データへの変換を、ページ単位などのあらかじめ定められた単位ごとに、複数のデータ処理装置で並列的に実行するシステムも知られている。
【０００４】
また、従来、あるデータ処理装置が印刷文書データ中のＰＤＬで記述された文書要素（オブジェクト）をビットマップ形式又は中間言語形式へ変換した場合に、その変換結果のデータを文書要素の識別情報と対応づけてキャッシュメモリにキャッシュし、後で同じ又は異なるデータ処理装置が同じ文書要素を変換する必要が生じた場合には、キャッシュされたデータを使用することで、変換処理を省略することも行われている。
【０００５】
例えば、特許文献１には、複数の描画プロセッサにより印刷データの描画処理を並列して行う装置が開示されている。この装置は、各描画プロセッサにて描画処理されたフォーム等のビットマップデータを、印刷機構制御プロセッサ内の共通のキャッシュメモリにてキャッシュするように構成されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０００−３３５０２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、複数のデータ処理装置が並列的に、ページ記述言語をビットマップ形式又は中間言語形式に変換する処理を実行している場合、あるデータ処理装置（第１のデータ処理装置と呼ぶ）が、印刷文書データ中のある文書要素のページ記述言語データを処理して画像データを作成している最中に、別のデータ処理装置（第２のデータ処理装置と呼ぶ）が印刷文書データ中の別の場所にある同じ文書要素の画像データの作成を開始しようとする場合が起こり得る。この場合、第１のデータ処理装置が作成した画像データが既にキャッシュメモリにキャッシュされているのであれば、第２のデータ処理装置はそのキャッシュされた画像データを利用できる。しかし、いま想定している状況では、第１のデータ処理装置はその画像データを作成している途中であり、キャッシュメモリ中にはその画像データは存在しない。キャッシュメモリを管理するキャッシュ管理装置は、このような状況では、一般に、対象とする画像データがキャッシュされていない旨を示す応答（キャッシュミス：Cache Miss）を返す。この応答は、いずれかのデータ処理装置がその画像データを作成している場合でも、どのデータ処理装置もその画像データを作成していない場合でも、同じである。したがって、第２のデータ処理装置は、その文書要素の画像データを他の第１のデータ処理装置が作成中であるかどうかがキャッシュ管理装置からの応答からは分からないので、その画像データの作成を行い、作成した画像データをキャッシュメモリにキャッシュすることになる。
【０００８】
本発明は、複数のデータ処理装置がキャッシュメモリを共有するシステムにおいて、データ処理装置が、文書要素の画像データがキャッシュメモリに存在するかどうかを問い合わせた場合に、別のデータ処理装置がその画像データを作成中であれば、その旨を知って対応できるようにすることを目的とする。
【課題を解決するための手段】
【０００９】
請求項１に係る発明は、キャッシュ装置と、複数のデータ処理装置と、を備え、前記キャッシュ装置は、前記各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段と、前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、前記データ処理装置にその旨を示す「作成中」応答を提供する応答提供手段と、を備え、前記複数のデータ処理装置の各々は、前記印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段と、前記印刷文書データ内の文書要素ごとに、当該文書要素の画像データを前記画像データ作成手段に作成させる前に、当該画像データが前記キャッシュ装置内にあるか否かの問合せを行う問合せ手段と、前記問合せ手段による問合せに対する前記キャッシュ装置からの応答が前記「作成中」応答であった場合、当該画像データの作成の完了を待って当該画像データを使用するか、当該完了を待たずに前記画像データ作成手段に当該文書要素の画像データの作成を実行させるかを、あらかじめ定められた条件に応じて制御する制御手段と、を備える、ことを特徴とする印刷文書処理システムである。
【００１０】
請求項２に係る発明は、前記制御手段は、前記「作成中」応答を受けた場合、前記画像データの作成の完了を待ってその画像データを使用する第１の方式と、当該完了を待たずに当該文書要素の画像データの作成を実行する第２の方式と、のどちらを選択した方がその画像データをページの印刷画像データに対して早く合成できるかについての評価演算を行う評価演算手段、を備え、前記評価手段により早く合成できると評価された方式に従って制御を行う、ことを特徴とする請求項１に記載の印刷文書処理システムである。
【００１１】
請求項３に係る発明は、前記制御手段は、前記「作成中」応答を受けた場合において、当該制御手段を備える画像データ処理装置の処理負荷があらかじめ定められた閾値よりも高い場合に、前記評価演算手段による評価演算を実行せず、前記第１の方式に従って制御を行う、ことを特徴とする請求項２に記載の印刷文書処理システムである。
【００１２】
請求項４に係る発明は、前記各データ処理装置の処理能力の情報を記憶する処理能力情報記憶手段を更に備え、前記状態記憶手段は、前記「作成中」状態にある各文書要素の画像データを作成中のデータ処理装置を示す情報を更に記憶し、前記データ処理装置の前記評価手段は、前記「作成中」応答を受けた場合において、前記処理能力情報記憶手段から得た当該データ処理装置の処理能力及び当該文書要素の画像データを作成中のデータ処理装置の処理能力に基づき、前記評価演算を行う、ことを特徴とする請求項２又は３のいずれか１項に記載の印刷文書処理システムである。
【００１３】
請求項５に係る発明は、前記各データ処理装置の処理負荷の情報を計算する処理負荷計算手段を更に備え、前記状態記憶手段は、前記「作成中」状態にある各文書要素の画像データを作成中のデータ処理装置を示す情報を更に記憶し、前記データ処理装置の前記評価手段は、前記「作成中」応答を受けた場合において、前記処理能力負荷計算手段から得た当該データ処理装置の処理負荷及び当該文書要素の画像データを作成中のデータ処理装置の処理負荷に基づき、前記評価演算を行う、ことを特徴とする請求項２〜４のいずれか１項に記載の印刷文書処理システムである。
【００１４】
請求項６に係る発明は、前記データ処理装置の前記評価手段が実行する評価演算では、前記第１の方式については、前記文書要素の画像データをキャッシュメモリから当該データ処理装置に転送するのに要する時間及びその画像データをビットマップ形式にしてページの印刷画像データに合成するのに要する第１の予測時間を、前記第２の方式については、当該文書要素のページ記述言語のデータを処理してビットマップ形式の画像データを作成してページの印刷画像データに合成するのに要する第２の予測時間を、それぞれ計算し、前記第１の予測時間と前記第２の予測時間との比較により、当該文書要素の画像データをページの印刷画像データに対して早く合成できる方式を求める、ことを特徴とする請求項２〜５のいずれか１項に記載の印刷文書処理システムである。
【００１５】
請求項７に係る発明は、前記応答提供手段は、前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれのデータ処理装置も当該画像データを作成していない「非作成中」状態である場合に、前記データ処理装置にその旨を示す「非作成中」応答を提供すると共に、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態を「作成中」状態へと変更し、前記制御手段は、前記問合せ手段による問合せに対する前記キャッシュ装置からの応答が前記「非作成中」応答であった場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを前記キャッシュ装置に記憶させるための処理を行う、ことを特徴とする請求項１〜６のいずれか１項に記載の印刷文書処理システムである。
【００１６】
請求項８に係る発明は、前記キャッシュ装置は、各文書要素のキャッシュ優先度を記憶するキャッシュ優先度記憶手段と、前記データ処理装置から文書要素の画像データを前記キャッシュメモリに記憶するための要求を受けた場合において、当該文書要素よりもキャッシュ優先度が低い文書要素であって画像データがいずれのデータ処理装置も使用中でない文書要素の画像データをすべて追い出したとしても前記キャッシュメモリの空き容量が当該画像データを記憶するのに足りない場合には、前記画像処理装置に対してキャッシュ記憶不可の旨を示す応答を提供する第２の応答提供手段と、を更に備え、前記データ処理装置の前記制御手段は、前記要求に対する前記キャッシュ装置からの応答が前記キャッシュ記憶不可を示す応答であった場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データを前記キャッシュ装置に記憶させずに破棄する処理を行う、ことを特徴とする請求項７に記載の印刷文書処理システムである。
【００１７】
請求項９に係る発明は、前記第２の応答提供手段は、前記データ処理装置から文書要素の画像データを前記キャッシュメモリに記憶するための要求を受けた場合において、当該文書要素よりもキャッシュ優先度が低くかつ画像データがいずれのデータ処理装置からも使用中でないすべての文書要素の画像データをすべて追い出したとしても前記キャッシュメモリの空き容量が当該画像データを記憶するのに足りない場合には、前記要求の対象の文書要素のキャッシュ状態を「非作成中」状態に設定する、ことを特徴とする請求項８に記載の印刷文書処理システムである。
【００１８】
請求項１０に係る発明は、各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段と、前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、前記データ処理装置にその旨を示す「作成中」応答を提供する応答提供手段と、を備えるキャッシュ装置である。
【００１９】
請求項１１に係る発明は、印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段と、前記印刷文書データ内の文書要素ごとに、当該文書要素の画像データを前記画像データ作成手段に作成させる前に、当該画像データがキャッシュ装置内にあるか否かの問合せを行う問合せ手段と、前記問合せ手段による問合せに対する前記キャッシュ装置からの応答が、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態で有る旨を示す「作成中」応答であった場合、当該画像データの作成の完了を待って当該画像データを使用するか、当該完了を待たずに前記画像データ作成手段に当該文書要素の画像データの作成を実行させるかを、あらかじめ定められた条件に応じて制御する制御手段と、を備えるデータ処理装置である。
【００２０】
請求項１２に係る発明は、コンピュータを、各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリ、印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段、前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、前記データ処理装置にその旨を示す「作成中」応答を提供する応答提供手段、として機能させるためのプログラムである。
【００２１】
請求項１３に係る発明は、コンピュータを、印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段、前記印刷文書データ内の文書要素ごとに、当該文書要素の画像データを前記画像データ作成手段に作成させる前に、当該画像データがキャッシュ装置内にあるか否かの問合せを行う問合せ手段、前記問合せ手段による問合せに対する前記キャッシュ装置からの応答が、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態で有る旨を示す「作成中」応答であった場合、当該画像データの作成の完了を待って当該画像データを使用するか、当該完了を待たずに前記画像データ作成手段に当該文書要素の画像データの作成を実行させるかを、あらかじめ定められた条件に応じて制御する制御手段、として機能させるためのプログラムである。
【００２２】
請求項１４に係る発明は、キャッシュ装置と、複数のデータ処理装置と、を備え、前記キャッシュ装置は、前記各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段と、前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、当該画像データの作成の完了を待って当該データ処理装置にその画像データを提供する第１の方式と、当該完了を待たずに当該データ処理装置に当該文書要素の画像データの作成を開始させる第２の方式と、のどちらを選択した方が当該データ処理装置がその画像データをページの印刷画像データに早く合成できるかを評価し、より早く合成できると評価された方式が第１の方式である場合は、当該文書要素の画像データの作成が完了するのを待って第１の応答を当該データ処理装置に提供し、より早く合成できると評価された方式が前記第２の方式である場合は当該文書要素の画像データの作成が完了するのを待たずに第２の応答を当該データ処理装置に提供する応答提供手段と、を備え、前記複数のデータ処理装置の各々は、前記印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段と、前記印刷文書データ内の文書要素ごとに、当該文書要素の画像データを前記画像データ作成手段に作成させる前に、当該画像データが前記キャッシュ装置内にあるか否かの問合せを行う問合せ手段と、前記問合せ手段による問合せに応じて、前記キャッシュ装置から前記第１の応答を得た場合は前記キャッシュ装置から当該画像データを取得して使用し、前記キャッシュ装置から前記第２の応答を得た場合は、前記画像データ作成手段に当該画像データを作成させるよう制御する制御手段と、を備える、ことを特徴とする印刷文書処理システムである。
【００２３】
請求項１５に係る発明は、各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段と、前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、当該画像データの作成の完了を待って当該データ処理装置にその画像データを提供する第１の方式と、当該完了を待たずに当該データ処理装置に当該文書要素の画像データの作成を開始させる第２の方式と、のどちらを選択した方が当該データ処理装置がその画像データをページの印刷画像データに早く合成できるかを評価し、より早く合成できると評価された方式が第１の方式である場合は、当該文書要素の画像データの作成が完了するのを待って第１の応答を当該データ処理装置に提供し、より早く合成できると評価された方式が前記第２の方式である場合は当該文書要素の画像データの作成が完了するのを待たずに第２の応答を当該データ処理装置に提供する応答提供手段と、を備えるキャッシュ装置である。
【００２４】
請求項１６に係る発明は、コンピュータを、各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリ、印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段、前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、当該画像データの作成の完了を待って当該データ処理装置にその画像データを提供する第１の方式と、当該完了を待たずに当該データ処理装置に当該文書要素の画像データの作成を開始させる第２の方式と、のどちらを選択した方が当該データ処理装置がその画像データをページの印刷画像データに早く合成できるかを評価し、より早く合成できると評価された方式が第１の方式である場合は、当該文書要素の画像データの作成が完了するのを待って第１の応答を当該データ処理装置に提供し、より早く合成できると評価された方式が前記第２の方式である場合は当該文書要素の画像データの作成が完了するのを待たずに第２の応答を当該データ処理装置に提供する応答提供手段、として機能させるためのプログラムである。
【発明の効果】
【００２５】
請求項１，１０，１１，１２，１３に係る発明によれば、データ処理装置が、文書要素の画像データがキャッシュメモリに存在するかどうかの問合せを行った場合に、別のデータ処理装置がその画像データを作成中であれば、その旨を知って対応できる。
【００２６】
請求項２，１４，１５，１６に係る発明によれば、問合せを行ったデータ処理装置は、別のデータ処理装置による画像データの作成完了を待つ方式と、待たずに自ら画像データを作成する方式のうち、文書要素の画像データをより早くページの印刷画像データに合成できる方を用いることができる。
【００２７】
請求項３に係る発明によれば、データ処理装置の負荷が高い場合に、その負荷の更なる増大を避けることができる。
【００２８】
請求項４に係る発明によれば、データ処理装置同士の処理能力が異なる場合でも待つ方がよいか待たない方がよいかを判定できる。
【００２９】
請求項５に係る発明によれば、データ処理装置同士の処理負荷が異なる場合でも待つ方がよいか待たない方がよいかを判定できる。
【００３０】
請求項６に係る発明によれば、第１の方式と第２の方式のそれぞれに要する予測時間に応じて、待つ方がよいか待たない方がよいかを判定できる。
【００３１】
請求項７に係る発明によれば、「非作成中」状態の文書要素の画像データに対する問合せを契機として、問合せ元のデータ処理装置に画像データの作成を実行させ、その文書要素の状態を「作成中」状態に変更することができる。
【００３２】
請求項８に係る発明によれば、キャッシュメモリに必要な空きができるのを待たせることなく、データ処理装置に処理を進めさせることができる。
【００３３】
請求項９に係る発明によれば、今回は画像データをキャッシュ装置に登録できないとしても、その後にいずれかのデータ処理装置が同じ文書要素に対する問合せを行った際に、そのデータ処理装置がその文書要素の画像データを作成してキャッシュ装置に対する登録を試みるようにすることができる。
【図面の簡単な説明】
【００３４】
【図１】第１例の印刷文書変換システムの構成及びこれが接続される印刷システムの構成の一例を示す図である。
【図２】エントリ管理テーブルのデータ内容の一例を示す図である。
【図３】第１例におけるキャッシュエントリの５つのステージ間の状態遷移を示す図である。
【図４】ＲＩＰ部の全体的な処理手順の一例を示すフローチャートである。
【図５】キャッシュ管理部から応答“Miss”を受け取ったときのＲＩＰ部の処理手順の一例を示すフローチャートである。
【図６】キャッシュ管理部から応答“Creating”を受け取ったときのＲＩＰ部の処理手順の一例を示すフローチャートである。
【図７】ＲＩＰ部から問合せを受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図８】ＲＩＰ部から使用開始要求を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図９】ＲＩＰ部から使用終了通知を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図１０】ＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の一部を示すフローチャートである。
【図１１】ＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の残りの部分を示すフローチャートである。
【図１２】ＲＩＰ部から登録要求を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図１３】追い出し予約がなされたキャッシュエントリのキャッシュデータを追い出す処理の一例を示すフローチャートである。
【図１４】追い出し予約がなされたキャッシュエントリのキャッシュデータを、使用終了通知に対応する処理の中で追い出す例を示すフローチャートである。
【図１５】追い出されたキャッシュエントリの見直し処理の手順の一例を示すフローチャートである。
【図１６】第１例において作成中のキャッシュデータの完成をＲＩＰ部に待たせるかどうかをキャッシュ管理部が判定する変形例１−１の処理手順の一部を示すフローチャートである。
【図１７】第１例において作成中のキャッシュデータの完成をＲＩＰ部に待たせるかどうかをキャッシュ管理部が判定する変形例１−１の処理手順の残りの部分を示すフローチャートである。
【図１８】第１例において、ＲＩＰ部が自らの負荷に応じて、作成中のキャッシュデータの完成を待つか否かの判断をスキップする変形例１−２の処理手順の要部を示すフローチャートである。
【図１９】第２例におけるキャッシュエントリの５つのステージ間の状態遷移を示す図である。
【図２０】第２例におけるＲＩＰ部から問合せを受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図２１】第２例におけるＲＩＰ部から使用終了通知を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図２２】第２例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の一部を示すフローチャートである。
【図２３】第２例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の残りの部分を示すフローチャートである。
【図２４】第２例の変形例２−１におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の一部を示すフローチャートである。
【図２５】第２例の変形例２−２におけるＲＩＰ部から問合せを受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図２６】第２例の変形例２−２におけるＲＩＰ部から使用終了通知を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図２７】第２例の変形例２−２におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の一部を示すフローチャートである。
【図２８】第２例の変形例２−２におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の残りの部分を示すフローチャートである。
【図２９】第２例の変形例２−２における追い出されたキャッシュエントリの見直し処理の手順の一例を示すフローチャートである。
【図３０】第３例におけるエントリ管理テーブルのデータ内容の一例を示す図である。
【図３１】第３例におけるキャッシュエントリの５つのステージ間の状態遷移を示す図である。
【図３２】第３例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の一部を示すフローチャートである。
【図３３】第３例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の別の一部を示すフローチャートである。
【図３４】第３例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の第１方式の主要部を示すフローチャートである。
【図３５】第３例の第１方式におけるＲＩＰ部から登録要求を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図３６】第３例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の第２方式の主要部を示すフローチャートである。
【図３７】第３例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の第３方式の主要部を示すフローチャートである。
【図３８】第３例の第３方式におけるＲＩＰ部から登録要求を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図３９】第３例において、第１方式〜第３方式を動的に切り替える場合のキャッシュ管理部の処理手順の一例の一部を示すフローチャートである。
【図４０】第３例において、第１方式〜第３方式を動的に切り替える場合のキャッシュ管理部の処理手順の一例の残りの部分を示すフローチャートである。
【図４１】第４例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の第１方式の主要部を示すフローチャートである。
【図４２】第４例の第２方式で用いるエントリ管理テーブルのデータ内容の一例を示す図である。
【図４３】第４例の第２方式において使用開始要求を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図４４】第４例の第２方式において使用終了通知を受けたときのキャッシュ管理部の処理手順の一例を示すフローチャートである。
【図４５】第４例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の第２方式の主要部を示すフローチャートである。
【図４６】第４例におけるＲＩＰ部から領域確保要求を受けたときのキャッシュ管理部の処理手順の一例の第３方式の主要部を示すフローチャートである。
【図４７】第４例において、第１方式〜第３方式を動的に切り替える場合のキャッシュ管理部の処理手順の一例の一部を示すフローチャートである。
【図４８】第４例において、第１方式〜第３方式を動的に切り替える場合のキャッシュ管理部の処理手順の一例の残りの部分を示すフローチャートである。
【発明を実施するための形態】
【００３５】
以下、図面を参照して本発明の実施の形態（以下「実施形態」という）を説明する。図面において、同様の構成要素又はステップには同一符号を付す。
【００３６】
［第１例］
《装置構成》
図１を用いて、本実施形態の第１の例の印刷文書変換システムの構成及びこれが接続される印刷システムの構成の一例を説明する。
【００３７】
図１に示す印刷システムは、印刷文書変換システム１００，ホストコンピュータ２００，印刷制御装置２１０及びプリンタエンジン２２０を備える。
【００３８】
印刷文書変換システム１００は、ページ記述言語（ＰＤＬ）で記述された印刷文書データを、プリンタエンジン２２０が取扱可能なビットマップ形式（ラスター形式とも呼ばれる）等の印刷画像データに変換する装置である。図示は省略したが、ホストコンピュータ２００は、ＬＡＮ（ローカルエリアネットワーク）等のネットワークを介して印刷文書変換システム１００に対して接続されている。ホストコンピュータ２００は、そのネットワークを介して印刷文書変換システム１００に対して印刷文書データを送り、その印刷文書データの印刷を指示する。なお、図１にはホストコンピュータ２００を１つしか示さなかったが、ネットワーク上に複数のホストコンピュータ２００が存在していてもよい。
【００３９】
印刷文書変換システム１００は、ジョブ管理部１１０，ｎ個（ｎは２以上の整数）のＲＩＰ部１２０−１，１２０−２，…，１２０−ｎ，キャッシュ管理部１３０及びキャッシュメモリ１４０を備える。
【００４０】
ＲＩＰ( Raster Image Processor)部１２０−１，１２０−２，…，１２０−ｎ（以下、ここを区別する必要がない場合はＲＩＰ部１２０と総称する）は、ＲＩＰ処理を行うデータ処理装置である。ここで、ＲＩＰ処理とは、ＰＤＬで記述された印刷文書データをプリンタエンジン２２０が取扱可能なビットマップ（ラスター）形式等の印刷画像データに変換する変換処理である。印刷文書変換システム１００は、複数（ｎ個）のＲＩＰ部１２０により、ページ単位で並列的に、すなわち最大ｎページを並列的に、ＲＩＰ処理する。ＲＩＰ処理は、描画又はレンダリングとも呼ばれる。ＲＩＰ部１２０は、与えられたＰＤＬのデータを例えば先頭から順に調べていき、その過程で順番に見つかった各オブジェクト（すなわち文書要素）のＰＤＬデータを解釈し、中間言語形式又はビットマップ形式の画像データを生成する。ここで、オブジェクトには、例えば、テキスト（文字列）、図形（グラフィックス）、イメージ（連続調画像）など、いくつかの種類がある。個々のオブジェクトは、例えばＰＤＬの描画コマンドにより表される。
【００４１】
ＲＩＰ部１２０は、１つの例では、ＰＤＬのデータを直接ビットマップ形式等の印刷画像データに変換するものであってよい。また、別の例では、ＲＩＰ部１２０は、ＰＤＬのデータを、ＰＤＬコマンドよりは粒度の小さいディスプレイリスト等の中間言語データに変換してバッファし、バッファした中間言語データをビットマップ形式に変換するという２段階の変換を行うものであってよい。
【００４２】
ジョブ管理部１１０は、ホストコンピュータ２００から印刷文書データを受け取り、それら印刷文書データの印刷処理の管理を行う。以下では、ホストコンピュータ２００から受け取った１つの印刷文書データのことをジョブと呼ぶ。ホストコンピュータ２００からのジョブ（印刷文書データ）には、個々の対象（例えば顧客）ごとに、データベースに記憶された各対象のデータを定型データに組み合わせて印刷する、いわゆるバリアブルプリントのジョブも含まれ得る。
【００４３】
ジョブ管理部１１０が行う印刷処理の管理には、一般的な、ジョブ単位での印刷順序の管理の他に、１つのジョブ内の各ページを各ＲＩＰ部１２０に割り当てるページ割当管理も含まれる。後者のページ割当管理を担当するのが、ページ割当部１１２である。
【００４４】
例えば印刷文書データ（ジョブ）がページ独立（すなわち１つのページの描画に必要な情報がそのページのＰＤＬデータ内に完全に記述される印刷文書データの方式）である場合には、ページ割当部１１２は、各ＲＩＰ部１２０に対してそれぞれ異なるページのＰＤＬデータを順に供給し、そのページをＲＩＰ処理させるようにしてもよい。また、別の例では、ジョブ管理部１１０は全てのＲＩＰ部１２０に印刷文書データ全体を提供し、ページ割当部１１２はその印刷文書データの中で処理すべきページの番号を各ＲＩＰ部１２０に順に指示するようにしてもよい（この方式は、ページ独立、ページ非独立を問わず適用可）。
【００４５】
また、各ＲＩＰ部１２０に対するページ割当方式も特に限定されない。ページ割当部１１２は、例えばＲＩＰ部１２０に対してあらかじめ定められた順序に従い、ＲＩＰ部１２０−１，１２０−２，…，１２０−ｎに対して１，２，…ｎページと順にページを割り当てる動作を繰り返してもよい。また、別の例として、最初は各ＲＩＰ部１２０に順にページを割り当て、その後は割り当てたページのＲＩＰ処理を完了した順にページの割当を行う方式も可能である。
【００４６】
また、更に別の例として、各ページのＲＩＰ処理負荷量を事前（ＲＩＰ処理の開始前）に見積もって、その見積もり結果に従って各ＲＩＰ部１２０に割り当てるページをスケジューリングする方式も考えられる。ページのＲＩＰ処理負荷量は、例えば、ページに含まれる個々のオブジェクトのＲＩＰ処理負荷量を、全オブジェクトにわたって総和することで求められる。個々のオブジェクトのＲＩＰ処理負荷量は、例えば、そのオブジェクトの複雑さやサイズ（面積）などから求められる。オブジェクトの複雑さは、そのオブジェクトの種類（イメージ、フォント、グラフィックスなど）などに応じて決まっている。一般に、オブジェクトの数が多いほど処理負荷は高い。また、イメージのオブジェクトは図形オブジェクトよりも一般に処理負荷が高い。また、サイズが大きいほど一般に処理負荷が高い。このような各種のパラメータからページの処理負荷を推定する方式には様々な公知技術があり、本実施形態でもその公知技術を用いればよい。
【００４７】
また、各ＲＩＰ部１２０の現在の負荷、ページのＲＩＰ処理の進捗度、処理能力（ＣＰＵの速度など）、各ＲＩＰ部１２０がＲＩＰ処理しているページのＲＩＰ処理負荷量、割り当て対象のページのＲＩＰ処理負荷量などのパラメータのうちの一以上を考慮して、ページ割当のスケジューリングを行ってもよい。スケジューリングでは、それら例示したパラメータのうちの一部又は全部を総合的に考慮した上で、例えば、割り当て対象のページのＲＩＰ処理を最も早く完了できるＲＩＰ部１２０を特定し、そのＲＩＰ部１２０にそのページを割り当てる。この例では、ページ割当部１１２は、例えば、各ＲＩＰ部１２０がＲＩＰ処理しているページのＲＩＰ処理負荷量と処理の進捗度とから、未だ処理されずに残っているＲＩＰ処理負荷量を求める。そして、この残りのＲＩＰ処理負荷量に割り当て対象のページのＲＩＰ処理負荷量を加算し、その加算結果を処理能力（あるいは処理能力から現在の負荷を減じた結果である正味の処理能力）で除することで、現在時点から残りのＲＩＰ処理負荷量と割り当て対象のページのＲＩＰ処理負荷量を合わせた量の処理を完了するまでに要する時間の表す指標値を得る。そして、各ＲＩＰ部１２０についてそのような指標値を求め、比較することで、割り当て対象のページのＲＩＰ処理を最も早く完了できるＲＩＰ部１２０を特定する。
【００４８】
なお、このような評価のためのパラメータのうち、各ＲＩＰ部１２０の処理能力は、システム管理者等があらかじめジョブ管理部１１０に登録しておけばよい。また、各ＲＩＰ部１２０がＲＩＰ処理しているページや割り当て対象のページのＲＩＰ処理負荷量は、上述のようにして求めればよい。各ＲＩＰ部１２０の現在の負荷やＲＩＰ処理の進捗度は、次に説明する負荷監視部１１４が監視する。
【００４９】
負荷監視部１１４は、各ＲＩＰ部１２０の負荷状態を監視する機能モジュールである。例えば、負荷監視部１１４は、各ＲＩＰ部１２０から定期的に当該ＲＩＰ部１２０の現在の負荷の情報を受け取る。ＲＩＰ部１２０の負荷の情報には、例えばＲＩＰ部１２０のプログラムを実行しているコンピュータのＣＰＵ（中央演算装置）使用率や、ＣＰＵが実行中のアクティブプロセスの数、そのコンピュータにて仮想メモリが使用中であるかどうかの情報（例えばメモリスワッピングが起こっているかどうか）などがある。ＲＩＰ部１２０の現在の負荷をＣＰＵ使用率で代表してもよいし、ＣＰＵ使用率の他にアクティブプロセス数や仮想メモリの使用状況などといった他のパラメータも総合して負荷評価値を求めてもよい。
【００５０】
また、負荷監視部１１４は、各ＲＩＰ部１２０から、それぞれ割り当てたページについてのＲＩＰ処理の進捗度合い（例えばページの何％までＲＩＰ処理が完了したか）について情報を、例えば定期的に、あるいは一定割合ずつ進捗するごとに、取得してもよい。また、ＲＩＰ部１２０から定期的に取得される進捗度合いの時間的な変化率、または一定割合ずつ進捗するごとの時間間隔から求められる進捗度合いの時間的な変化率と、そのＲＩＰ部１２０がＲＩＰ中のページのデータサイズから、そのＲＩＰ部１２０の現在の正味の処理能力を推定し、この推定値を用いて、現在時点から残りのデータサイズと割り当て対象のページのデータサイズを合わせた量の処理を完了するまでに要する時間の表す指標値を算出してもよい。
【００５１】
なお、負荷監視部１１４が求めた各ＲＩＰ部１２０の負荷状況の情報は、前述したページ割当部１１２の判断材料として用いられる他、キャッシュ管理にも利用し得る。すなわち、例えば、ＲＩＰ部１２０がオブジェクトをＲＩＰ処理するときに、他のＲＩＰ部１２０がそのオブジェクトのＲＩＰ処理を既に開始している場合に、前者が後者の処理完了を待ってその処理結果（キャッシュデータ）を流用した方がよいのか否かを判定するのに利用し得る（詳細は後述）。
【００５２】
各ＲＩＰ部１２０は、ページ割当部１１２から割り当てられたページのＰＤＬデータについてのＲＩＰ処理を行う際、キャッシュメモリ１４０を利用することで、過去（すなわち割り当てられたページより前のページ群）のＲＩＰ処理結果を再利用する。すなわち、各ＲＩＰ部１２０は、割り当てられたページに含まれるオブジェクトのＰＤＬデータをＲＩＰ処理する際、そのオブジェクトのＲＩＰ処理結果がすでにキャッシュメモリ１４０内にあれば、ＲＩＰ処理は行わずにキャッシュメモリ１４０内のＲＩＰ処理結果を再利用することで、ページの印刷画像データに対してそのオブジェクトの画像を加える。なお、オブジェクトは、ひとまとまりの描画単位のことであり、例えば１つのＰＤＬ描画コマンドで表される。一方、オブジェクトのＲＩＰ処理結果がキャッシュメモリ１４０内にない場合は、ＲＩＰ部１２０はそのオブジェクトのＰＤＬデータをＲＩＰ処理することで、ページの印刷画像データに対してそのオブジェクトの画像を加える。また、このとき生成されたオブジェクトのＲＩＰ処理結果は、後の再利用のために、キャッシュメモリ１４０に登録（キャッシュ）される。
【００５３】
キャッシュメモリ１４０にキャッシュされるＲＩＰ処理結果（キャッシュデータ）は、ビットマップ形式のものであってもよいし、中間言語形式のものであってもよい。キャッシュメモリ１４０から読み出したキャッシュデータがビットマップ形式のものであれば、ＲＩＰ部１２０はそのキャッシュデータをページの印刷画像データに単に付加（合成）すればよい。また、キャッシュメモリ１４０から読み出したキャッシュデータが中間言語形式のものであれば、ＲＩＰ部１２０はそのキャッシュデータに対して更にＲＩＰ処理を施すことでビットマップ形式の画像を生成し、生成したビットマップ形式の画像をページの印刷画像データに単に付加（合成）すればよい。
【００５４】
このようなキャッシュメモリ１４０に対する各ＲＩＰ部１２０の読み書き（キャッシュされたＲＩＰ処理結果の読み出し、及びＲＩＰ処理結果のキャッシュメモリへの登録）を管理するのがキャッシュ管理部１３０である。キャッシュ管理部１３０は、エントリ管理テーブル１３２を備えており、このエントリ管理テーブル１３２に基づいて、各ＲＩＰ部１２０によるキャッシュ利用を制御する。
【００５５】
図２にエントリ管理テーブル１３２のデータ内容の一例を示す。図２の例では、最上部の見出し行以外の各行が、それぞれ１つのキャッシュエントリについての管理レコードを示している。キャッシュエントリは、印刷文書データ内のオブジェクトごとに用意される。個々のキャッシュエントリの管理レコードには、ＩＤ、ステージ、データ作成中のＲＩＰ、累計問合せ回数、使用カウンタ、キャッシュ領域のアドレス、キャッシュデータのサイズ、スコア、オブジェクト属性などの項目が含まれる。
【００５６】
「ＩＤ」は、キャッシュエントリを識別するための一意な識別情報である。ＰＤＬの中には、イメージ（ビットマップ）やフォント、フォーム（定型画像）等といった、ジョブ内で何度も再利用される可能性のあるオブジェクトに対してＩＤを割り当て、印刷文書データ内にて各オブジェクトのＩＤを記述するものもある。例えばＰＤＦ(Portable Document Format)がその一例である。このようなＰＤＬで記述された印刷文書データを処理する場合には、印刷文書データ中のオブジェクトのＩＤをキャッシュエントリのＩＤとして流用してもよい。また、別の例として、キャッシュ管理部１３０が個々のオブジェクトを識別してＩＤを付与してもよい。この場合、オブジェクトの識別は、例えば、ＰＤＬの描画コマンドとそのコマンドに付随するパラメータ群の組合せに基づき行えばよい。例えば、描画コマンドとそのコマンドに付随するパラメータ群の組合せが同じオブジェクトは、同一のオブジェクトと判定するなどの方式を用いればよい。
【００５７】
「ステージ」は、当該キャッシュエントリの現在の状態（言い換えれば、オブジェクトのＲＩＰ結果のキャッシュ状態）を示す情報である。ステージは、ステータスとも呼ばれる。本実施形態では、“New Cache”、“Caching”、“Cached”、“Cached Out”、及び“Never Cache”の５つのステージを用いている。これら各ステージの詳細については後で説明する。
【００５８】
「データ作成中のＲＩＰ」は、“New Cache”（「作成中」）ステージにあるキャッシュエントリについての項目であり、当該エントリのキャッシュデータを作成中のＲＩＰ部１２０の識別情報を示す。この項目は、ある第１のＲＩＰ部１２０があるオブジェクトをＲＩＰ処理しようとする時に、別の第２のＲＩＰ部１２０がそのオブジェクトのキャッシュデータを作成中である場合に、第１のＲＩＰ部１２０が第２のＲＩＰ部１２０によるキャッシュデータの作成完了を待つか待たないかの判定のための１つの材料として用いられる（具体例は後述）。この判定に「データ作成中のＲＩＰ」の情報を用いない例もあり、そのような例ではこの項目は不要である。なお、この項目に登録されたＲＩＰ部１２０の識別情報は、そのＲＩＰ部１２０からのキャッシュのための領域確保要求（後述）に対して確保失敗を返したとき、又はそのＲＩＰ部１２０からキャッシュデータの登録要求（後述）を受け取ったときに、キャッシュ管理部１３０により、作成中のＲＩＰがないことを示す値にリセットされる。
【００５９】
「累計問合せ回数」は、印刷文書データの先頭ページの先頭部分からＲＩＰ処理を開始した後、現在時点までの間に、ＲＩＰ部１２０群から当該キャッシュエントリについての問合せを受けた回数の累計値である。
【００６０】
「使用カウンタ」は、当該キャッシュエントリのキャッシュデータが現在いくつのＲＩＰ部１２０により使用されているかを示す数である。ここで、ＲＩＰ部１２０によるオブジェクトのキャッシュデータの「使用」とは、ＲＩＰ部１２０が、現在作成中のページの印刷画像データに対しそのオブジェクトのビットマップ画像を合成するために、そのオブジェクトのキャッシュデータが読み出して用いることを意味する。
【００６１】
「キャッシュ領域のアドレス」は、当該キャッシュエントリのキャッシュデータ（すなわちＲＩＰ処理結果のビットマップ形式又は中間言語形式のデータ）が格納されるキャッシュメモリ１４０内のアドレス（例えば先頭アドレス）を示す。ＲＩＰ結果のキャッシュデータがキャッシュメモリ１４０内に記憶されている（すなわち後述する“Cached”ステージの）キャッシュエントリについては、もちろんこの項目にアドレスが登録されている。キャッシュすることは決まっているがまだキャッシュデータが完成していない（すなわち後述する“New Cache”ステージの）オブジェクトのキャッシュエントリについても、アドレスを割り当ててこの項目に登録するようにしてもよい。逆に、ＲＩＰ結果をキャッシュする価値がそもそもないと判定されたオブジェクト（後述する“Never Cache”ステージ）のキャッシュエントリや、キャッシュデータがキャッシュメモリ１４０から追い出された（すなわち、削除された。後述する“Cached Out”ステージの）キャッシュエントリについては、この項目の値は空値となる。
【００６２】
「キャッシュデータのサイズ」は、当該キャッシュエントリのキャッシュデータのデータサイズを示す情報であり、例えばバイト、キロバイト、又はメガバイトなどの単位で表される。キャッシュデータがビットマップ形式の場合、そのデータサイズは当該キャッシュデータが表す画像の面積に対応する。例えば、イメージやフォーム、フォントなどのオブジェクトの画像サイズを描画コマンドの引数として明示するＰＤＬも多く（例えばＰＤＦ）、このようなＰＤＬの場合、例えばＲＩＰ部１２０が当該オブジェクトについてのＰＤＬ記述から画像サイズの情報を求め、その画像サイズからキャッシュデータのデータサイズが求めてエントリ管理テーブル１３２に登録してもよい。
【００６３】
「スコア」は、当該キャッシュエントリの優先度を示す評価値である。キャッシュメモリ１４０の容量には限りがあるので、全てのキャッシュエントリのキャッシュデータがキャッシュメモリ１４０内にキャッシュ（記憶）できない場合には、スコア（優先度）が相対的に高いキャッシュエントリの方が、スコアが相対的に低いキャッシュエントリよりも優先的にキャッシュされる。スコアの値は、キャッシュを利用することによる効果が高いものほど高い値となるよう、あらかじめ定めた関数等に基づき計算する。例えば、ＲＩＰ処理の負荷が大きいオブジェクトほど、キャッシュデータを再利用した場合の効果が大きい。
【００６４】
また、キャッシュデータをキャッシュメモリ１４０から読み出すためには、その読み出しの準備や完了などのプロトコルのために、キャッシュデータのデータサイズによらず一定のオーバーヘッド時間を要するが、そのオーバーヘッド時間はキャッシュデータのサイズが小さいほど相対的な割合は大きくなる。キャッシュデータのサイズが小さいほど、元のＰＤＬデータからそのキャッシュデータをＲＩＰするのに要する時間は短い。場合によっては、キャッシュデータを読み出すよりも、元のＰＤＬデータから描画した方が早いこともある。したがって、キャッシュデータのサイズが小さくなるほど、当該オブジェクトのＲＩＰ結果をキャッシュする意義・効果は小さくなる。
【００６５】
また、同じオブジェクトが描画される回数が多いほど、そのオブジェクトのＲＩＰ結果をキャッシュする意義・効果は大きくなる。
【００６６】
本実施形態では、このような考え方に従って、各キャッシュエントリのスコアを計算する。
【００６７】
スコアを決めるパラメータとしては、例えば、オブジェクトの種類がある。イメージ（ビットマップ）の方が、フォントやグラフィックス（図形）よりも一般的にＲＩＰ処理の負荷が大きいため、キャッシュの効果が高くなり、従ってスコアも高くなる。
【００６８】
また、オブジェクトの複雑さを、スコアを決めるパラメータとして用いてもよい。オブジェクトの複雑さは、例えば、そのオブジェクトに含まれる子オブジェクトの数や種類などから定義する。すなわち、フォーム（定型書式を表すオブジェクト）などのオブジェクトは、イメージやテキストなどといった子オブジェクトの組合せにより表現される。このようなオブジェクトについては、例えば、各オブジェクト種類に属する子オブジェクトの数とその種類に固有の重みとの積を、全種類にわたって総和するなどの方式で、そのオブジェクトの複雑さを求める。オブジェクト種類に固有の重みは、キャッシュ効果が高い種類ほど大きな値となる正の数である。例えば、イメージの重みは、グラフィックスやテキストの重みよりも大きい。このようにして求められた複雑さが高い（例えば数値として大きい）ほど、スコアも高くなる。もちろん、複雑さの求め方はこの例に限られるものではない。オブジェクトを記述するＰＤＬデータの長さ（データサイズ）やそのデータに含まれるコマンド数などを考慮して複雑さを規定してもよい。
【００６９】
また、オブジェクト種類が同じ子オブジェクトを一律に扱うのではなく、その子オブジェクトの属性（例えば、ビットマップに展開した場合の画像のサイズや、そのオブジェクトを描画するために必要な処理の種類など）に応じて、個々の子オブジェクトの重みを求めてもよい。
【００７０】
例えば、イメージの場合、色空間変換（例えばＲＧＢからＣＭＹＫへの変換）が必要なオブジェクトの方が、そうでないオブジェクトよりも処理負荷が重いので、色空間変換がある場合とない場合とで重みを異ならせてもよい。また、描画のための拡大率が小さい方が処理負荷が重いので、拡大率に応じて異なった重みとしてもよい。また、描画のために元のイメージデータを回転させる回転角に応じて、重みを異ならせてもよい。異なる回転角同士の間での処理負荷の比較では、例えば、回転角が０度の場合が最も処理負荷が軽く、９０度、１８０度、２７０度などといった９０度刻みのよく用いられる回転角の場合の処理負荷は、０度の場合よりも重いが、それ以外の自由な回転角の場合よりも軽い。また、そのような色空間変換や拡大、回転などの処理の対象となる元のイメージデータのサイズが大きいほど、処理対象の画素数が増えるので、処理負荷は重くなる。したがって、元のイメージデータの画素数に応じて重みを異ならせてもよい。
【００７１】
また、オブジェクトの種類によらず、オブジェクトの形状（フォントの場合の形状とは、フォントの形状ではなく、フォントを表現するビットマップの形状のこと）が長方形か否か、すなわち、クリップされているか否か（オブジェクトが長方形の場合はクリップが不要であり、長方形でなければクリップが必要である）、に応じて重みを異ならせてもよい。一般的に長方形（クリップされていない）の場合の方が処理負荷が軽い。
【００７２】
また、フォントオブジェクトの場合も、イメージオブジェクトと同様、回転しているか否か、あるいは回転角に応じて重みを異ならせてもよい。
【００７３】
また、オブジェクトの描画に当たってスムースシェード処理（グラデーション処理）を行う場合は、処理負荷が重くなる。一般に、スムースシェードの処理負荷は、イメージの描画よりも軽いが、グラフィックスやテキストの描画よりも重い。したがって、スムースシェード処理を行うか否かで異なる重みを用いてもよい。また１つのオブジェクト内でのスムースシェード処理による色の変化の量に応じても処理負荷が変わるので、スムースシェード処理を行う場合、その処理での色の変化量に応じて重みを異ならせてもよい。
【００７４】
１つのオブジェクトについての総合的な重みは、以上に例示した様々な属性パラメータ（例えば、色空間変換の有無、拡大率、回転角、クリップ処理の要否、スムースシェード処理の要否など）についての重みを総合（例えば乗算や加算など。具体的な総合のための演算の仕方は、重みの値の決め方などといった実装に依存する）することで求めればよい。
【００７５】
また、オブジェクトを記述するＰＤＬデータのサイズを、スコアを決めるパラメータとして用いてもよい。ＰＤＬデータのサイズが大きいほど、例えばＲＩＰ処理のための解釈処理に時間を要するため、ＲＩＰ処理の負荷が大きくなると言える。したがって、一例では、ＰＤＬデータのサイズが大きくなるほどスコアが高くなる。
【００７６】
また、同様の考え方で、オブジェクトを記述するＰＤＬデータをＲＩＰ処理するのに要する時間を、スコアを決めるパラメータとして用いてもよい。この所要時間は、例えば当該オブジェクトのＰＤＬデータをＲＩＰ処理した時に求めればよい。
【００７７】
また、オブジェクトのキャッシュデータ（すなわちＲＩＰ処理結果のビットマップ又は中間言語形式のデータ）のサイズを、スコアを決めるパラメータとして用いてもよい。例えば、前述した理由からキャッシュデータのサイズが小さくなるほど、当該オブジェクトのＲＩＰ結果をキャッシュする意義・効果は小さくなるので、一例では、キャッシュデータのサイズが大きくなるほどスコアが高くなる。また、ビットマップ形式のキャッシュデータをページに描画（すなわちページの印刷画像データに合成）するのには、データのサイズ（画素数に比例）に応じた時間がかかるので、この意味でも、キャッシュデータのサイズはスコアを決めるパラメータとなる。
【００７８】
また、同様の考え方で、キャッシュメモリ１４０とＲＩＰ部１２０との間でオブジェクトのキャッシュデータを転送するのに要する時間を、当該オブジェクトのスコアを決めるパラメータとして用いてもよい。例えば、転送に要する時間が長いほど、キャッシュ転送のためのオーバーヘッド時間の割合が相対的に低くなるので、キャッシュすることによるペナルティが相対的に低い（逆に言えば、キャッシュの効果が高い）と言える。
【００７９】
また、中間言語形式のデータをキャッシュする場合には、中間言語形式のキャッシュデータをＲＩＰ部１２０がビットマップ形式にＲＩＰするのに要する時間を、スコアを決めるパラメータとして用いてもよい。この所要時間が短いほど、キャッシュデータを再利用することの効果が大きいので、スコアも高くなる。
【００８０】
また、ＲＩＰ部１２０は、オブジェクトのＲＩＰ処理を開始しようとする際、キャッシュ管理部１３０にそのオブジェクトのキャッシュデータがあるか否かを問い合わせ、あればそのキャッシュデータを利用するが、そのような問合せの回数が多いほど、キャッシュしておく価値が高いといえる。したがって、前述の累計問合せ回数を、スコアを決めるパラメータの１つとして用いてもよい。累計問合せ回数が多いほどスコアは高くなる。
【００８１】
なお、各キャッシュエントリの累計問合せ回数は、時間の経過に従って単調増加する（すなわち減りはしない）。したがって、一例では、時間の経過に従った累計問合せ回数の単調増加に応じて、全てのキャッシュエントリのスコアが単調増加するようにしてもよい。
【００８２】
また、スコアの本質は、キャッシュエントリ同士の間でキャッシュする価値に関する優劣の順位付けをするものなので、別の例では、判断する時点ごとに全キャッシュエントリのスコアをあらかじめ定められた範囲内の値へと正規化してもよい。この場合、累積問合せ回数が増えてもスコアの値そのものは上昇するとは限らない。ただし、累積問合せ回数の増加度合いが他のキャッシュエントリより多ければ、そのスコアの全キャッシュエントリ内での順位は上昇する。
【００８３】
以上に例示したパラメータはあくまで例に過ぎず、その他のパラメータも考えられる。スコアは、それらパラメータのうちの１以上に基づき計算すればよい。キャッシュ管理部１３０は、この計算のために、例えば、それらパラメータのうちの１以上を引数とする関数、または、それらパラメータのうちの１以上に対応づけてスコアを登録したテーブルなどを用いる。なお、このようにキャッシュ優先度を表すスコアを計算する関数やテーブルは、従来も用いられており、そのような公知の関数又はテーブルを用いてもよい。
【００８４】
再び図２の説明に戻り、エントリ管理テーブル１３２に登録される項目「オブジェクト属性」は、当該オブジェクトの１以上の属性項目の情報が含まれる。オブジェクトの属性項目には、例えば、オブジェクトの種類、オブジェクトを表すＰＤＬデータのサイズ、オブジェクトの複雑さなどが含まれる。これら属性項目の情報は、例えば、既に前述のスコアについての説明の中で示した方法等を用いて、当該オブジェクトのＰＤＬ記述を解析することで求めればよい。これら各属性項目は、例えば前述のスコアを計算するのに用いられる。
【００８５】
キャッシュ管理部１３０は、エントリ管理テーブル１３２を参照して、各ＲＩＰ部１２０からのキャッシュメモリ１４０への読み書きのアクセスに応答する。また、キャッシュ管理部１３０は、そのようなアクセス等に応じて、エントリ管理テーブル１３２のデータ内容の更新を行う。キャッシュ管理部１３０の処理動作については、後で具体例を挙げて更に詳細に説明する。
【００８６】
各ＲＩＰ部１２０は、担当するページのＰＤＬデータに対してＲＩＰ処理を行い、またそのページ内のオブジェクトのうちキャッシュメモリ１４０内にキャッシュデータがあるものはそのキャッシュデータを用いることで、割り当てられたページの印刷画像データを生成する。そして、ＲＩＰ部１２０は、生成したページの印刷画像データを印刷制御装置２１０に送る。
【００８７】
以上に説明した印刷文書変換システム１００の構成要素のうち、キャッシュメモリ１４０は、例えば、ランダムアクセスメモリなどの高速に読み書きが可能なメモリから構成される。また、キャッシュメモリ１４０以外の各構成要素、すなわちジョブ管理部１１０、各ＲＩＰ部１２０及びキャッシュ管理部１３０は、前述及び後述するそれら各構成要素の機能を記述したプログラムをコンピュータに実行させることにより実現される。１つの例では、ジョブ管理部１１０、各ＲＩＰ部１２０及びキャッシュ管理部１３０が共通の１つのコンピュータ上にて実現されてもよい。この場合、各構成要素同士の情報のやりとりは、例えばプロセス間通信やスレッド間通信により行えばよい。また別の例では、ジョブ管理部１１０、各ＲＩＰ部１２０及びキャッシュ管理部１３０が、それぞれ別々のコンピュータ上に実現されてもよい。この場合、各構成要素同士の情報のやりとりは、例えば、それら各要素間を結ぶネットワークのプロトコルを用いて行えばよい。また、更に別の例では、それら各構成要素のうちの２以上を１つのコンピュータ上に実現することで、印刷文書変換システム１００全体をそれら構成要素の数よりも少ない数のコンピュータで実現してもよい。例えば、ジョブ管理部１１０とキャッシュ管理部１３０とを同一のコンピュータに実装し、両者が管理するデータベース（例えばジョブ管理部１１０が管理する各オブジェクトの情報と、キャッシュ管理部１３０が管理するエントリ管理テーブル１３２）を一元化することも考えられる。いずれの場合も、キャッシュメモリ１４０は、キャッシュ管理部１３０が実装されるコンピュータ上のメモリに構築する。また、いずれの場合も、使用するコンピュータは、シングルプロセッサのものでもマルチプロセッサのものでもよい。マルチプロセッサのコンピュータを用いる場合は、マルチプロセッサを構成する個々のプロセッサコアをそれぞれ別々のＲＩＰ部１２０に割り当てるなどの運用も考えられる。
【００８８】
プリンタエンジン２２０は、印刷画像データが表す画像をインクやトナーなどの色材を用いて用紙に対して印刷する印刷ハードウエアである。印刷制御装置２１０は、プリンタエンジン２２０を制御する装置であり、通信ケーブルやネットワーク（ホストコンピュータ２００・印刷文書変換システム１００間のネットワークと同じものでも異なるものでもよい）を介して印刷文書変換システム１００と通信する。そして、その通信により、各ページの印刷画像データを受信したり、印刷制御のために必要な各種の制御情報をやりとりしたりする。また、印刷制御装置２１０は、受信した各ページの印刷画像データを蓄積し、印刷順序に従ってプリンタエンジン２２０に供給する。プリンタエンジン２２０は、受け取った印刷画像データを用紙に印刷する。
【００８９】
さて、複数のＲＩＰ部１２０が、キャッシュメモリ１４０を介してＲＩＰ処理結果を再利用しつつ並列的に動作するシステムでは、あるＲＩＰ部１２０（第１のＲＩＰ部と呼ぶ）があるオブジェクトのＲＩＰ処理を開始しようとした時点で、別のＲＩＰ部１２０（第２のＲＩＰ部と呼ぶ）がそのオブジェクトのＲＩＰ処理を実行中である場合がある。このような状況では、キャッシュメモリ１４０にはそのオブジェクトのＲＩＰ処理結果のキャッシュデータはまだ存在しない。このような状況では、第１のＲＩＰ部の取り得る選択肢としては、次の２つが考えられる。最初の選択肢は、第２のＲＩＰ部のＲＩＰ処理完了を待って、その完了に伴ってキャッシュメモリ１４０に登録されたキャッシュデータを利用するという処理である。第２の選択肢は、第２のＲＩＰ部のＲＩＰ処理完了を待たずに、同じオブジェクトのＰＤＬデータのＲＩＰ処理を行うというものである。しかし、従来のＲＩＰ結果のキャッシュ管理方式では、第１のＲＩＰ部からの問合せに対してキャッシュメモリ側はキャッシュデータがあるかないか（すなわち“Hit”（ヒット）又は“Miss”（ミス））の応答しか返さない。すなわち、前述の状況では、キャッシュメモリ側は、第１のＲＩＰ部に対して、問い合わせたオブジェクトのキャッシュデータが無い（“Miss”）旨の応答をすることになる。この場合、当該オブジェクトのキャッシュデータを他のＲＩＰ部が作成中であることが分からない以上、第１のＲＩＰ部には選択肢はそもそも無く、そのオブジェクトのＰＤＬデータをＲＩＰ処理するしかない。また、第１のＲＩＰ部は、そのＲＩＰ処理結果を、第２のＲＩＰ部のＲＩＰ処理結果と重複してキャッシュメモリに登録しようとすることになる。
【００９０】
これに対し、本実施形態では、第１のＲＩＰ部から問い合わせられたオブジェクトのキャッシュデータが第２のＲＩＰ部で既に作成中であるが未完成である場合、キャッシュ管理部１３０がその状況を第１のＲＩＰ部に通知することで、第１のＲＩＰ部がその状況に応じた処置をとれるようにする。そのための構成を、以下に詳しく説明する。
【００９１】
《第１例の状態遷移》
そこで、まず図３を参照して、キャッシュ管理部１３０での管理のために用いられる、キャッシュエントリのステージ（Stage）について説明する。本実施形態では、キャッシュエントリのステージ（すなわちステータス）として、“New Cache”、“Caching”、“Cached”、“Cached Out”、及び“Never Cache”の５つを用いている。説明の便宜上、それら５つのステージに対して１から順に通し番号を割り当てる。図３は、それら５つのステージ間の状態遷移図である。
【００９２】
＜ステージ１＞ “New Cache”（新規キャッシュ、すなわちキャッシュデータ「作成中」）は、当該キャッシュエントリのキャッシュデータが作成中であり、まだキャッシュメモリ内には存在しないことを示すステージである。キャッシュ管理部１３０は、いずれかのＲＩＰ部１２０からあるオブジェクトについてのキャッシュデータについての最初の問合せを受けた時に、当該オブジェクトに対応するキャッシュエントリを生成し、そのキャッシュエントリのステージを“New Cache”とし、そのＲＩＰ部１２０に“Miss”（「キャッシュデータがない」）を応答することで、そのＲＩＰ部１２０にそのオブジェクトのＲＩＰ処理（すなわちキャッシュデータの作成）を開始させる。
【００９３】
また、後述する“Caching”ステージにあるキャッシュエントリに対していずれかのＲＩＰ部１２０から問合せがあった場合、そのエントリのステージは“New Cache”に遷移する。
【００９４】
“New Cache”ステージにあるキャッシュエントリに対してＲＩＰ部１２０から問合せがあると、キャッシュ管理部１３０は、“Creating”というコードを応答する。応答“Creating”は、当該キャッシュエントリのデータが別のＲＩＰ部１２０により作成中であることを示す。
【００９５】
＜ステージ２＞ “Caching”（空き待ち）は、キャッシュ領域が空くのを待機する状態である。“Caching”ステージは、当該キャッシュエントリのキャッシュデータがキャッシュメモリ１４０内にないという点では上述の“New Cache”ステージと同じであるが、どのＲＩＰ部１２０もそのキャッシュデータを現在作成中ではない点で、上述の“New Cache”とは異なる。
【００９６】
“Caching”ステージへ遷移する１つの例は、前述したステージ１“New Cache”からの遷移である。すなわち、“New Cache”ステージにあるキャッシュエントリについていずれかのＲＩＰ部１２０がキャッシュデータを作成しようとする際に、キャッシュメモリ１４０内にそのキャッシュデータを記憶する領域が空いていなければ、当該キャッシュエントリは“Caching”ステージに遷移する。“Caching”ステージにあるキャッシュエントリは、時間の経過に伴って他のキャッシュエントリのキャッシュデータがキャッシュメモリ１４０から追い出され（すなわち削除され）、当該キャッシュエントリのための空き領域ができるのを待つ。
【００９７】
ただし、“New Cache”から“Caching”への遷移は、当該キャッシュエントリがキャッシュする価値があると判定された場合のことである。当該キャッシュエントリがキャッシュする価値がないと判定された場合（例えばスコアが、現在キャッシュメモリ１４０内にキャッシュデータのある他のいずれのキャッシュエントリよりも低い場合）には、ステージは“Caching”にではなく次に説明する“Cached Out”（キャッシュ外）に遷移する。
【００９８】
また、“Caching”ステージに遷移する別の例としては、後述するステージ４すなわち“Cached Out”（キャッシュ外）ステージからの遷移がある（詳細は“Cached Out”ステージの説明にて述べる）。
【００９９】
“Caching”ステージにあるキャッシュエントリに対していずれかのＲＩＰ部１２０から問合せがあると、キャッシュ管理部１３０は、そのキャッシュエントリのステージを１すなわち“New Cache”に遷移し、“Miss”（「キャッシュデータがない」）を応答する。これに応じ、ＲＩＰ部１２０は、そのキャッシュエントリのキャッシュデータの作成のための処理を開始する。
【０１００】
＜ステージ３＞ “Cached”（キャッシュ済）は、当該キャッシュエントリのキャッシュデータがキャッシュメモリ１４０内に記憶されている状態である。“Cached”ステージには、前述したステージ１“New Cache”から遷移する。すなわち、“New Cache”ステージにあるキャッシュエントリについていずれかのＲＩＰ部１２０がキャッシュデータを作成しようとする際に、キャッシュメモリ１４０内にそのキャッシュデータを記憶する領域が確保でき、その領域にキャッシュデータが作成され登録されると、当該キャッシュエントリは“Cached”ステージに遷移する。
【０１０１】
“Cached”ステージにあるキャッシュエントリにいずれかのＲＩＰ部１２０から問合せがあると、キャッシュ管理部１３０は、“Hit”（「キャッシュデータがある」）を応答する。この応答を受けたＲＩＰ部１２０は、自らＰＤＬデータをＲＩＰ処理する代わりに、キャッシュメモリ１４０からそのキャッシュデータを受け取ってそのオブジェクトの画像を生成する。
【０１０２】
“Cached”ステージにあるキャッシュエントリは、キャッシュメモリ１４０の空き容量が少なくなると、“Cached Out”（キャッシュ外）に遷移する場合がある。概略的には、新たなキャッシュエントリのキャッシュデータをキャッシュメモリ１４０へ登録するよう要求された時に、そのキャッシュデータのデータ量がキャッシュメモリ１４０の空き容量を超えている場合、“Cached”ステージにあるキャッシュエントリの中から選ばれたエントリのキャッシュデータがキャッシュメモリ１４０から追い出される（削除される）。キャッシュメモリ１４０から追い出されるのは、例えば、その時点でいずれのＲＩＰ部１２０からもキャッシュデータが使用（参照）されていないキャッシュエントリである。このようにしてキャッシュデータが追い出されたキャッシュエントリのステージは、“Cached”から“Cached Out”に遷移する。また、その時点でいずれかのＲＩＰ部１２０からキャッシュデータが使用（参照）されているキャッシュエントリについては、使用中のＲＩＰ部１２０への悪影響を避けるには、その使用が終わるまではキャッシュデータを追い出せないが、使用が終われば追い出してもよくなる。そこで、キャッシュデータが使用中の段階でそのキャッシュエントリのステージを“Cached Out”に遷移させることで、いわば追い出しの予約を行ってもよい。追い出しの対象となるキャッシュエントリをスコアにより絞り込んでもよい。
【０１０３】
＜ステージ４＞ “Cached Out”（キャッシュ外、すなわち追い出し済）は、当該キャッシュエントリのキャッシュデータがキャッシュメモリ１４０から追い出された状態、又は追い出しの予約をされている状態である。このステージにあるキャッシュエントリのキャッシュデータは、キャッシュメモリ１４０内にはなく（「追い出し予約」の場合は、キャッシュデータは現時点ではキャッシュメモリ１４０内にあるが、極めて近い将来、なくなってしまう）、且つそのキャッシュデータはどのＲＩＰ部１２０によっても作成されてはいない。なお、「追い出し予約」の場合は、キャッシュデータは現時点ではキャッシュメモリ１４０内にあるが、極めて近い将来、なくなってしまう。
【０１０４】
“Cached Out”ステージには、前述した通りステージ３“Cached”から遷移する。
【０１０５】
また、特定の場合に、ステージ１当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態で有る旨を示す「作成中」応答であった場合、“New Cache”にあるキャッシュエントリをこの“Cached Out”ステージに遷移させてもよい。例えば、当該キャッシュエントリのスコアが、キャッシュする価値が十分にあるとみなされない程低い場合には、そのキャッシュエントリにキャッシュデータを登録せずに、そのキャッシュエントリを“Cached Out”に遷移させる。キャッシュする価値が十分にあるとみなされない程低い場合の例としては、当該キャッシュエントリのスコアが、キャッシュ中（“Cached”）のどのキャッシュエントリのスコアよりも低い場合がある。また、キャッシュに値するか否かのスコアの閾値を定めておき、当該キャッシュエントリのスコアがこの閾値よりも低い場合に、キャッシュを行わずにステージを“Cached Out”に遷移させるようにしてもよい（後述の図２４の例を参照）。
【０１０６】
“Cached Out”ステージにあるキャッシュエントリにいずれかのＲＩＰ部１２０から問合せがあると、キャッシュ管理部１３０は、“Deleted”（「キャッシュデータは削除済」）を応答する。この応答を受けたＲＩＰ部１２０は、当該オブジェクトの元のＰＤＬデータを自らＲＩＰ処理することで、当該オブジェクトの印刷画像データを生成する。ただし、このとき、ＲＩＰ部１２０は、生成した印刷画像データをキャッシュメモリ１４０に登録することはしない。当該キャッシュエントリは、キャッシュデータをキャッシュする価値がないと判定された状態だからである。
【０１０７】
“Cached Out”ステージは、キャッシュメモリ１４０内に当該キャッシュエントリのデータがないという点では、前述の“New Cache”ステージ及び“Caching”ステージと同じである。しかし、“New Cache”及び“Caching”の場合は問合せに対して“Miss”を応答するのに対し、“Cached Out”の場合は問合せに対して“Delete”を応答する。これら２つの応答の違いは、“Miss”の場合は問合せ元のＲＩＰ部１２０はＲＩＰ処理で作成した画像データをキャッシュ登録しようとするのに対し、“Delete”の場合は問合せ元のＲＩＰ部１２０はＲＩＰ処理で作成した画像データをキャッシュ登録しないという点である。すなわち、“Cached Out”ステージにあるキャッシュエントリは、ＲＩＰ部１２０から問合せがあっても、キャッシュデータがキャッシュメモリ１４０内に登録されることはない。これは、例えば、キャッシュする価値が低いといったんみなされたキャッシュエントリのキャッシュデータが、キャッシュメモリ１４０内に出たり入ったりを繰り返すことによる処理のオーバーヘッドを避けるためである。このように、この実施形態では、キャッシュする価値が低いといったんみなされたキャッシュエントリのキャッシュデータは、しばらくはキャッシュメモリ１４０内に戻らないようにしている。
【０１０８】
しかし、そのようなキャッシュエントリに対して問合せが増えてくると、それに応じて当該キャッシュエントリのスコアが高くなり、キャッシュメモリ１４０内にデータのある他のキャッシュエントリよりも相対的にキャッシュする価値が高くなる場合も出てくる。そこで、この実施形態では、“Cached Out”ステージにあるキャッシュエントリについて定期的な見直しを行う（例えば、後述する図１５の例を参照）。すなわち、“Cached Out”ステージにあるキャッシュエントリのスコアを例えば定期的にチェックし、スコアが再登録に値するほど十分に高くなっていれば、そのエントリを前述の“Caching”ステージに遷移させる。あるキャッシュエントリのステージが“Cached Out”から“Caching”に遷移すると、その後に当該エントリに対して問合せが到来すると、そのエントリのステージが“New Cache”に遷移し、そのエントリのキャッシュデータの作成・登録のための処理が開始される。
【０１０９】
＜ステージ５＞ “Never Cache”（キャッシュ対象外）は、当該キャッシュエントリに対応するオブジェクトが、あらかじめ定められた制限条件に抵触し、キャッシュの対象外であると判定された状態である。この制限条件は、例えば、スコアを他のキャッシュエントリと比較するまでもなく、キャッシュする価値がないと判断されるオブジェクトを規定する条件である。
【０１１０】
例えば、余りにも小さいオブジェクトや、余りにも単純なオブジェクト（例えば直線分一本のみ）は、キャッシュメモリ１４０からキャッシュデータを読み出すよりもＲＩＰ１２０が自ら描画した方が早い。そこで、オブジェクトのサイズ又は複雑さなどに関してそれぞれ条件（例えば閾値）を設定しておき、キャッシュしようとするオブジェクトのサイズ又は複雑さなどがそれぞれ対応する条件を満たす（例えば閾値よりも小さい又は低い）場合は、そのオブジェクトに対応するキャッシュエントリを“Never Cache”ステージに遷移させる。なお、サイズ又は複雑さなどについての条件の組合せ方は、ＡＮＤ条件（全ての条件が満たされて初めて“Never Cache”に遷移）でもＯＲ条件（いずれかの条件が満たされて初めて“Never Cache”に遷移）でも、どちらでもよい。
【０１１１】
また、効率の観点等から、キャッシュするオブジェクトの形状をページの縦横の辺に平行な矩形に限定している場合には、矩形以外の形状のオブジェクトは制限条件に抵触することになり、そのオブジェクトのキャッシュエントリは“Never Cache”ステージとなる。
【０１１２】
“Never Cache”ステージにあるキャッシュエントリに対していずれかのＲＩＰ部１２０から問合せがあると、キャッシュ管理部１３０は、“Invalid”（「キャッシュ無効」）を応答する。これに応じ、ＲＩＰ部１２０は、当該オブジェクトのＰＤＬデータをＲＩＰ処理する（そして、ＲＩＰ処理結果はキャッシュしない）。
【０１１３】
以上、キャッシュエントリのステージについて説明した。以上は、キャッシュ管理部１３０のエントリ管理テーブル１３２に登録されているキャッシュエントリがとり得るステージである。ところで、キャッシュ管理部１３０は、あるオブジェクトについての問合せを最初に受けた時に、そのオブジェクトのためのキャッシュエントリをエントリ管理テーブル１３２上に生成するので、その最初の問合せ以前にはキャッシュエントリは存在せず、したがってキャッシュエントリのステージもない。しかし、キャッシュエントリはオブジェクトと対応しているので、そのような最初の問合せを受ける以前にも、オブジェクトに対応するキャッシュエントリは潜在的に存在していると考えてもよい。このように考えると、最初の問合せを受ける以前は、その潜在的なキャッシュエントリの状態は、「キャッシュメモリ１４０内にキャッシュデータが存在しておらず、またどのＲＩＰ部１２０によってもそのキャッシュデータの作成は行われていない」状態に属すると考えられる。
【０１１４】
《ＲＩＰ部１２０処理手順》
次に、各ＲＩＰ部１２０の処理手順の一例を、図４〜図６を参照して説明する。
【０１１５】
ＲＩＰ部１２０は、それぞれ、ページ割当部１１２から割り当てられたページのＰＤＬデータを先頭から順に解釈していく。この中で、新たなオブジェクトのＰＤＬデータを見つけるごとに、図４〜図６に例示する手順を実行する。
【０１１６】
この手順では、図４に示すように、まず、そのオブジェクトのＰＤＬデータから、そのオブジェクトがキャッシュ対象であるかどうかを判定する（Ｓ１０）。例えば、ＰＤＬの一種といえるＰＤＦでは、オブジェクトを、フォームやイメージ（ビットマップ）、フォントなどといった繰り返し使用される可能性のある種類と、そうでない種類とに大別している。そして、前者に該当するオブジェクトにはＩＤを付与し、印刷文書データ中の複数の位置でそのオブジェクトが用いられる場合、同じＩＤでそのオブジェクトを呼び出すようにしている。逆に、ＩＤのないオブジェクトは、繰り返し使用されることが想定されていない種類のオブジェクトである。したがって、ＩＤが付与されたオブジェクトはキャッシュ対象であり、ＩＤが付与されていないオブジェクトはキャッシュ対象でないと判定される。なお、ＰＤＦ以外にも、オブジェクトについて同様の区別をしているＰＤＬはあり、そのようなＰＤＬについてはＳ１０と同様の判定が適用される。
【０１１７】
Ｓ１０でオブジェクトがキャッシュ対象でないと判定すると、ＲＩＰ部１２０は、そのオブジェクトのＰＤＬデータを解釈し描画することで、そのオブジェクトのビットマップ画像を生成し、生成したビットマップ画像を作成中のページの印刷画像データへ合成し（Ｓ１２）、当該オブジェクトについてのＲＩＰ処理を完了する。このとき生成したオブジェクトのビットマップ画像は、キャッシュされない。
【０１１８】
一方、Ｓ１０で当該オブジェクトがキャッシュ対象であると判定した場合、ＲＩＰ部１２０は、そのオブジェクトのキャッシュエントリの状態をキャッシュ管理部１３０に問い合わせる（Ｓ１４）。この問合せには、そのオブジェクトを特定する識別情報が含まれる。例えば、ＰＤＦのようにキャッシュ対象のオブジェクトにＩＤが付されている場合は、問合せにはそのＩＤを用いればよい。キャッシュエントリは、オブジェクトと一対一に対応しているので、オブジェクトのＩＤから、そのオブジェクトに対応するキャッシュエントリが特定される。例えば、オブジェクトのＩＤをキャッシュエントリのＩＤとして流用している場合は、オブジェクトのＩＤから、対応するキャッシュエントリが特定される。また、オブジェクトにＩＤを付さないＰＤＬの場合には、例えば、そのオブジェクトを記述するＰＤＬコマンドと引数の組を識別情報として問合せに含めるようにしてもよい。この場合、各キャッシュエントリには、当該エントリに対応するオブジェクトの識別情報として、ＰＤＬコマンドと引数の組（又はこれに紐付けられた識別情報）が登録しておけばよい。
【０１１９】
この問合せの後、ＲＩＰ部１２０は、キャッシュ管理部１３０からその問合せに対する応答を受け取ると、その応答の示す値を判別する（Ｓ１６）。前述したように、問合せに対するキャッシュ管理部１３０の応答には、“Hit”、“Miss”、“Creating”、“Deleted”、“Invalid”の５種類がある。
【０１２０】
キャッシュ管理部１３０からの応答が“Hit”であった場合、ＲＩＰ部１２０は、当該オブジェクトに対応するキャッシュデータの使用開始要求をキャッシュ管理部１３０に送る（Ｓ１８）。この使用開始要求には、当該オブジェクトに対応するキャッシュエントリを特定するＩＤが含まれる。この要求に応じ、キャッシュ管理部１３０は、要求されたキャッシュエントリのキャッシュデータをキャッシュメモリ１４０からＲＩＰ部１２０に提供する。ＲＩＰ部１２０は、このキャッシュデータを用いて当該オブジェクトのビットマップ画像を生成し、生成したビットマップ画像を作成中のページの印刷画像データへ合成する（Ｓ２０）。すなわち、キャッシュデータがビットマップ形式であれば、そのキャッシュデータをそのままページの印刷画像データへ合成すればよい。また、キャッシュデータがディスプレイリスト等の中間言語形式であれば、そのキャッシュデータに基づきそのオブジェクトを描画してビットマップ画像を生成し、そのビットマップ画像をページの印刷画像データへ合成すればよい。このようにしてキャッシュデータのＲＩＰ処理が完了すると、ＲＩＰ部１２０はキャッシュ管理部１３０に対して当該キャッシュエントリの使用が終了した旨の通知（「使用終了通知」）をキャッシュ管理部１３０に送る（Ｓ２２）。この通知には、使用していたキャッシュエントリを特定するＩＤが含まれる。この通知により、当該オブジェクトについてのＲＩＰ処理が終了する。
【０１２１】
次に、Ｓ１６の判定で、キャッシュ管理部１３０からの応答が“Miss”であった場合の処理手順を説明する。応答“Miss”は、前述した通り、「キャッシュデータがないので、作成して登録せよ」という命令に相当する。そこで、ＲＩＰ部１２０は図５に例示する処理手順を実行する。
【０１２２】
すなわち、ＲＩＰ部１２０はまずキャッシュ管理部１３０に領域確保要求を発する（Ｓ３０）。領域確保要求は、当該オブジェクトのＲＩＰ処理結果をキャッシュするための領域をキャッシュメモリ１４０内に確保することを指示する要求である。領域確保要求には、例えば、当該オブジェクトに対応するキャッシュエントリのＩＤ、及び確保すべき領域のサイズ（データ容量）の情報が含まれる。確保すべき領域のサイズは、当該オブジェクトのＲＩＰ処理結果（ビットマップ形式又は中間言語形式）のデータサイズであり、これはＰＤＬデータの解析から求められる。例えば、イメージやフォーム、フォントなどのオブジェクトの画像サイズを描画コマンドの引数として明示するＰＤＬも多く、このようなＰＤＬの場合、画像サイズの情報からキャッシュデータのデータサイズが求められる。ビットマップ形式の場合、キャッシュデータのサイズは画像サイズに比例するからである。中間言語形式のキャッシュデータのデータ量も、ＰＤＬデータの解析から見積もり可能である。また、実際に一度ＲＩＰ処理すれば中間言語形式のキャッシュデータのデータ量は正確に求められるので、それを例えばエントリ管理テーブル１３２に記憶しておき、再度キャッシュのための領域確保が必要となった場合に参照するようにしてもよい。
【０１２３】
この領域確保要求に対し、キャッシュ管理部１３０は、要求されたサイズの領域が確保できるかどうかを判定し（詳細は後述）、その判定結果を要求元のＲＩＰ部１２０に応答する。ＲＩＰ部１２０は、その応答が確保の成功及び失敗のいずれを示すものかを判定する（Ｓ３１）。
【０１２４】
Ｓ３１で応答が「確保成功」であると判定した場合、ＲＩＰ部１２０は、そのオブジェクトのＰＤＬデータをＲＩＰ処理し、確保された領域（その応答に、この領域のアドレスが含まれている）に対して、そのＲＩＰ処理の結果を書き込む（Ｓ３２）。これにより、その領域に当該オブジェクトのキャッシュデータが生成される。次に、ＲＩＰ部１２０は、生成したキャッシュデータを用いて当該オブジェクトのビットマップ画像を生成し、生成したビットマップ画像を作成中のページの印刷画像データに合成する（Ｓ３４）。このようにしてキャッシュデータの生成及びページの印刷画像データへの合成が完了すると、ＲＩＰ部１２０は、キャッシュ管理部１３０に対して、そのキャッシュデータについての登録要求を発する（Ｓ３６）。登録要求には、当該キャッシュエントリのＩＤが含まれる。この登録要求により、ＲＩＰ部１２０は当該オブジェクトについての処理を終了する。
【０１２５】
Ｓ３１で応答が「確保失敗」であると判定された場合、それはキャッシュメモリ１４０内には当該オブジェクトのＲＩＰ処理結果をキャッシュする余地がないということを意味する。この場合、ＲＩＰ部１２０は、そのオブジェクトのＰＤＬデータを解釈し描画することでビットマップ画像を生成し、そのビットマップ画像をページの印刷画像データへ合成する（Ｓ３８）。そして、生成したビットマップ画像をキャッシュせずに、当該オブジェクトについての処理を終了する。
【０１２６】
図４の説明に戻る。Ｓ１６でキャッシュ管理部１３０からの応答が“Creating”である場合、ＲＩＰ部１２０は図６に例示する処理手順を実行する。応答“Creating”は、前述した通り、「問合せの対象のキャッシュデータは、現在他のＲＩＰ部が作成中である」ことを意味する。本実施形態では、このような特徴的な応答“Creating”により、ＲＩＰ部１２０は、目的とするオブジェクトのキャッシュデータを他のＲＩＰ部が作成中であることを知る。これにより、ＲＩＰ部１２０には、他のＲＩＰ部によるそのキャッシュデータの完成を待つのか、待たずに自分でＲＩＰ処理を行うのかの選択の余地が生まれる。どちらを選択するかを固定的に設定してもよいし、状況に応じて動的に選択するようにしてもよい。図５では、待つ／待たないを動的に選択する場合の例を示す。
【０１２７】
この手順では、ＲＩＰ部１２０（第１のＲＩＰ部と呼ぶ）は、他のＲＩＰ部１２０（第２のＲＩＰ部と呼ぶ）によるそのキャッシュデータの完成を待ってそのキャッシュデータを利用する場合と、当該オブジェクトのＰＤＬデータを自らＲＩＰ処理する場合との、どちらが早く処理が完了するかを評価する（Ｓ４２）。この評価は、例えば、以下に例示するパラメータ（ａ１）〜（ｆ）のうちの一以上を用いて行う。
（ａ１）当該オブジェクトのＰＤＬデータをＲＩＰ処理してビットマップ画像を作成する場合のＲＩＰ処理負荷量
（ａ２）当該オブジェクトのＰＤＬデータをＲＩＰ処理して中間言語形式のデータを作成する場合のＲＩＰ処理負荷量（これは、中間言語形式のデータをキャッシュする場合に用いる）
（ｂ）キャッシュデータのデータサイズ（又はそのキャッシュデータを第１のＲＩＰ部１２０に転送するのに要する時間）
（ｃ）当該オブジェクトのキャッシュデータをビットマップ形式の画像に変換し、ページの印刷画像データへ合成する場合の処理負荷量
（ｄ１）第１のＲＩＰ部の処理能力（ＣＰＵの能力などの、理想条件での値。ただし、すべてのＲＩＰ部の処理能力が同一の場合には考慮不要）
（ｄ２）第２のＲＩＰ部の処理能力（同上）
（ｅ１）第１のＲＩＰ部の現在の処理負荷
（ｅ２）第２のＲＩＰ部の現在の処理負荷
（ｆ）第２のＲＩＰ部におけるキャッシュデータの作成の進捗度合い
【０１２８】
これらパラメータのうち（ａ１）及び（ａ２）は、前述した負荷監視部１１４によるページのＲＩＰ処理負荷量の算出と同様の方式で算出すればよい。また、例えば、負荷監視部１１４がページのＲＩＰ処理負荷量を求めるのに際し、その中の各オブジェクトのＲＩＰ処理負荷量を求め、オブジェクトのＩＤをキーとするデータベースに登録し、ＲＩＰ部１２０がそれを参照するようにしてもよい。
【０１２９】
またパラメータ（ｂ）は、キャッシュ管理部１３０のエントリ管理テーブル１３２から取得すればよい。
【０１３０】
またパラメータ（ｃ）は、キャッシュデータがビットマップ形式であれば、ビットマップ形式への変換は不要であり、ページの印刷画像データへの合成に要する処理の負荷量のみとなる。合成に要する処理負荷量は、ビットマップ形式のデータのサイズに応じたものであり、実験やシミュレーションなどで求められた係数をそのサイズに乗じることで求められる。また、キャッシュデータが中間言語形式である場合、例えばそのキャッシュデータから描画すべき画素数や、描画において行うべき画像処理の種類などから公知の方法で求めればよい。例えば、画素数に関しては、中間言語形式の命令として、長方形を塗りつぶす命令と同じ形状及びサイズの長方形の対角線を描画する命令とがあった場合、両命令はデータサイズとしてはほぼ同サイズであるが、描画すべき画素数は前者の方がはるかに多いため、前者の方が処理負荷量もはるかに多い。したがって、中間言語形式の命令の種類（これがオブジェクトについて描画すべき画素群の形状を規定する。例えば長方形の塗りつぶしと長方形の対角線の描画では命令が異なる。）及び、その命令の引数などにより示されるオブジェクトのサイズなどから、パラメータ（ｃ）を計算すればよい。また、描画において行うべき画像処理の種類としては、上述のスコアの計算方法の説明において例示した、色空間変換、拡大、回転、スムースシェード（グラデーション）等がある。そこで、例えば画像処理の種類のそれぞれについて、処理負荷量の計算のための関数などを定めておき、その関数にキャッシュデータが表す画像のサイズや、画像処理のパラメータ（例えば当該画像処理の有無や、拡大率、回転角、グラデーションでの色の変化量など）を入力することで、パラメータ（ｃ）に係る処理負荷量を計算するようにしてもよい。１つのオブジェクトに対して複数の画像処理を行う場合には、個々の画像処理についての処理負荷量の総和を当該オブジェクトのパラメータ（ｃ）に係る処理負荷量として求めてもよい。（なお、上述のスコアを同様の方法で計算してもよい。）
【０１３１】
またパラメータ（ｄ１）及び（ｄ２）は、既知の値であり、システム管理者があらかじめ登録しておけばよい。同じパラメータは、負荷監視部１１４でも用いられるので共用すればよい。
【０１３２】
またパラメータ（ｅ１），（ｅ２）及び（ｆ）は、負荷監視部１１４から取得すればよい。
【０１３３】
これらパラメータを用いたＳ４２の評価処理では、まず、例えば、パラメータ（ａ１）、（ｄ１）及び（ｅ１）から、第１のＲＩＰ部自身がそのオブジェクトのＰＤＬデータをＲＩＰ処理してオブジェクトのビットマップ画像を生成する場合の所要時間Ｔ１を見積もる。これには、例えば、（ｄ１）を（ｅ１）に応じて低減することで現在の実際の処理能力を求め、この実際の処理能力で（ａ１）を例えば除することで、前述の所要時間を表す評価値を求めればよい。
【０１３４】
また、同様に、パラメータ（ｂ）、（ｃ）、（ｄ２）、（ｅ２）及び（ｆ）と、（ａ１）又は（ａ２）とから、第２のＲＩＰ部でのキャッシュデータの完成を待ってそれを流用することによりオブジェクトのビットマップ画像を生成する場合の所要時間Ｔ２を見積もる。所要時間Ｔ２は、例えば、第２のＲＩＰ部が作成中のキャッシュデータが完成するまでの時間Ｔ２１と、そのキャッシュデータをキャッシュメモリ１４０から第１のＲＩＰ部へと読み出すのに要するプロトコル処理のオーバーヘッド時間Ｔ２２（これは固定値として登録しておけばよい）と、読み出したキャッシュデータを第１のＲＩＰ部がビットマップ画像に変換するのに要する時間Ｔ２３との和である。
【０１３５】
このうちＴ２１（第２のＲＩＰ部が作成中のキャッシュデータが完成するまでの時間）を表す評価値は、パラメータ（ａ１）又は（ａ２）（キャッシュデータがビットマップ形式の場合は前者、中間言語形式の場合は後者）と（ｆ）とからキャッシュデータ完成までの残りの処理負荷量Ｒを求め、（ｄ２）と（ｅ２）とから第２のＲＩＰ部の現在の処理能力Ｐ２を求め、このＰ２で残りの処理負荷量Ｒを除するなどの計算により求めればよい。
【０１３６】
また、Ｔ２２は、固定値でよく、あらかじめ登録しておけばよい。
【０１３７】
また、Ｔ２３は、キャッシュデータをキャッシュメモリ１４０から第１のＲＩＰ部に読み出すのに要する時間Ｔ２３１と、読み出したキャッシュデータを第１のＲＩＰ部がビットマップ形式に変換するのに要する時間との和である。このうち時間Ｔ２３１はパラメータ（ｂ）から求めればよい。また、時間Ｔ２３２は、パラメータ（ｄ１）と（ｅ１）から第１のＲＩＰ部の現在の処理能力を求め、これでパラメータ（ｃ）を除する等の計算により求めればよい。
【０１３８】
以上に説明した所要時間Ｔ１とＴ２の推定の仕方はあくまで一例に過ぎず、他の方法を用いてももちろんよい。例えば、以上に例示したパラメータのうちの一部を用いて推定を行ってもよいし、他のパラメータを用いてもよい。
【０１３９】
以上のようにして見積もられた所要時間Ｔ１とＴ２のうち、短い方に対応する方式を採用すればよい。すなわち、Ｔ１の方がＴ２より短ければ、第１のＲＩＰ部がキャッシュデータの完成を待たずに自らＰＤＬデータをＲＩＰする方式がよいと判定され、逆であれば第１のＲＩＰ部はキャッシュデータの完成を待ってそれを利用する方式の方がよいと判定される。
【０１４０】
以上では、ＲＩＰ部１２０が自らＰＤＬデータをＲＩＰ処理する場合と、他のＲＩＰ部が作成中のキャッシュデータの完成を待つ場合の各々の所要時間を見積もって比較することで、どちらの場合が有利かを判定したが、これは一例に過ぎない。例えば、オブジェクトの種類がイメージならばキャッシュデータの完成を待ち、イメージ以外（例えばフォーム又はフォント）ならば待たずにＲＩＰ処理を行うといった、１つのパラメータに基づく単純な判定でもよい。また、オブジェクトの複雑さがあらかじめ定めた閾値以上であれば待ち、閾値未満であれば待たないというような判定も考えられる。もちろん、これら以外の判定方式も考えられる。
【０１４１】
Ｓ４３では、Ｓ４２の評価の結果、待つ方がよいか待たない方がよいかを判定する。Ｓ４３で第１のＲＩＰ部１２０がキャッシュデータの完成を待った方がよいと判定された場合、第１のＲＩＰ部１２０はキャッシュ管理部１３０に対し、当該キャッシュデータ（例えばキャッシュエントリのＩＤで特定すればよい）が完成して登録されたら通知するように依頼し（Ｓ４４）、その通知を待つ（Ｓ４５）。そして、キャッシュ管理部１３０からその通知が到来すると、当該キャッシュデータを用いてビットマップ画像を生成し、ページの印刷画像データに合成する（Ｓ４６）。なお、このＳ４６は、より厳密には、Ｓ１８からＳ２２と同様、使用開始要求、ビットマップ生成、使用終了通知の３つのステップを含む。
【０１４２】
Ｓ４３で、第１のＲＩＰ部１２０がキャッシュデータの完成を待たない方がよいと判定された場合、第１のＲＩＰ部１２０は、当該オブジェクトのＰＤＬデータをＲＩＰ処理してビットマップ画像を生成し、ページの印刷画像データに合成する（Ｓ４８）。このとき生成されたビットマップ形式又は中間言語形式のデータは、第２のＲＩＰ部が生成してキャッシュ登録するものと重複するため、キャッシュメモリ１４０には登録されない。
【０１４３】
Ｓ４６又はＳ４８により、当該オブジェクトについての処理は終了する。
【０１４４】
再び図４に戻る。Ｓ１６でキャッシュ管理部１３０からの応答が“Deleted”である場合、この応答を受け取ったＲＩＰ部１２０は、当該オブジェクトのＰＤＬデータをＲＩＰ処理してビットマップ画像を生成し、ページの印刷画像データに合成する（Ｓ２４）。この場合、Ｓ２４の中で生成されたビットマップ形式又は中間言語形式のデータをキャッシュに登録することはしない。当該オブジェクトは、キャッシュする価値がないと判定されているからである。
【０１４５】
また、Ｓ１６でキャッシュ管理部１３０からの応答が“Invalid”（ステージが“Never Cache”）である場合、この応答を受け取ったＲＩＰ部１２０は、当該オブジェクトのＰＤＬデータをＲＩＰ処理してビットマップ画像を生成し、ページの印刷画像データに合成する（Ｓ２４）。この場合、Ｓ２４の中で生成されたビットマップ形式又は中間言語形式のデータをキャッシュに登録することはしない。当該オブジェクトは、キャッシュする価値がないからである。
【０１４６】
以上では、“Never Cache”に該当するオブジェクトの場合もＳ１４でキャッシュ管理部１３０に問合せ、Ｓ２４においてＲＩＰ部１２０が当該オブジェクトのＰＤＬデータをＲＩＰ処理するとしたが、これは必須ではない。この代わりに、ＲＩＰ部１２０自身が、オブジェクトがステージ“Never Cache”に該当するか否かを判定（この判定事態の処理負荷は極めて小さい）し、該当すると判定された場合には、キャッシュ管理部１３０への問合せを省略してもよい。また、“Never Cache”に該当すると判定したオブジェクトのＲＩＰ処理結果をＲＩＰ部１２０自身がローカルでキャッシュしておき、同じオブジェクトを再度描画する場合は、キャッシュ管理部１３０に問い合わせずに、ローカルのキャッシュを利用して描画を行ってもよい。
【０１４７】
なお、ステージ“Cashed Out”（応答は“Deleted”）は、ある観点では“Never Cache”と似ているが、“Never Cache”は上述のようにキャッシュ管理部１３０への問合せを省略できるのに対し、“Cashed Out”はそのような省略をしない点で異なる。すなわち、ステージ“Cashed Out”のオブジェクトの場合は、時間の経過に連れてスコアが変化し、共用のキャッシュメモリ１４０にキャッシュされる場合があるので、ＲＩＰ部１２０は、そのようなオブジェクトに出会うごとに、キャッシュ管理部１３０に問合せを行う必要がある。
【０１４８】
《キャッシュ管理部１３０の処理手順》
以上、各ＲＩＰ部１２０の処理手順の例を説明した。次に、キャッシュ管理部１３０の処理手順の例を、図７〜図１５を参照して説明する。
【０１４９】
まず、いずれかのＲＩＰ部１２０から問合せ（図４のＳ１４）が到来したときにキャッシュ管理部１３０が実行する処理手順の一例を、図７を参照して説明する。
【０１５０】
この手順では、キャッシュ管理部１３０は、問合せの対象であるオブジェクトのキャッシュエントリをエントリ管理テーブル１３２から検索する（Ｓ５０）。Ｓ５０では、問合せに含まれている、キャッシュエントリを特定する情報（例えばオブジェクトのＩＤ、またはＰＤＬコマンドと引数の組など）をキーとして検索すればよい。そして、そのオブジェクトに対応するキャッシュエントリが見つかったかどうかを判定し（Ｓ５２）、見つからなければ、そのオブジェクトに対応するキャッシュエントリを新たに作成する（Ｓ５４）。オブジェクトのＩＤをキャッシュエントリのＩＤとして用いる方式の場合は、問合せに含まれるオブジェクトのＩＤを当該キャッシュエントリのＩＤにセットすればよい。また、オブジェクトのＩＤがない場合は、新たに生成したキャッシュエントリに一意なＩＤを付与し、更に問合せに含まれるＰＤＬコマンドと引数の組などのキャッシュエントリを特定する情報を、そのキャッシュエントリに登録する（図２では省略）。また、キャッシュ管理部１３０は、そのキャッシュエントリのステージを１すなわち“New Cache”に設定し、累計問合せ回数を１に設定するなど、エントリ管理テーブル１３２（図２参照）における当該キャッシュエントリの各項目の値を初期化又は設定する（Ｓ５６）。オブジェクトの種類等のオブジェクト属性の情報は、例えばＲＩＰ部１２０からの問合せに含めておき、それをキャッシュ管理部１３０がエントリ管理テーブル１３２に設定すればよく、キャッシュデータのサイズも同様である。また、使用カウンタの値は０に初期化する。キャッシュ領域のアドレスは、未定のままとしておけばよい。また、オブジェクト属性（オブジェクトの種類など）や累計値合わせ回数から当該キャッシュエントリのスコア（キャッシュする価値を示す評価値）を前述のようにして計算し、エントリ管理テーブル１３２に登録する。また、問合せ元のＲＩＰ部１２０の識別情報を、「データ作成中のＲＩＰ」の欄に登録する。そして、キャッシュ管理部１３０は、問合せ元のＲＩＰ部１２０に対して応答“Miss”を返し（Ｓ５８）、この問合せについての処理を終了する。これに応じ、そのＲＩＰ部１２０は、当該オブジェクトについてのキャッシュデータの作成を開始する（図４及び図５参照）。
【０１５１】
Ｓ５２で、問合せの対象のキャッシュエントリがエントリ管理テーブル１３２から見つかった場合は、キャッシュ管理部１３０は、そのエントリの累計問合せ回数を１増加させる（Ｓ６０）。また、スコアは、前述のように累計問合せ回数が多くなるほど高くなるので、累計問合せ回数の増加に応じて当該エントリのスコアを更新する（Ｓ６０）。
【０１５２】
次に、キャッシュ管理部１３０は、当該キャッシュエントリのステージを判定する（Ｓ６２）。その判定の結果、ステージが１“New Cache”であれば問合せ元のＲＩＰ部１２０に“Creating”を応答する（Ｓ６４）。また、ステージが２“Caching”であれば問合せ元のＲＩＰ部１２０に“Miss”を応答し、当該キャッシュエントリのステージを１に遷移させる（Ｓ６６）。このとき、問合せ元のＲＩＰ部１２０の識別情報を、エントリ管理テーブル１３２の当該エントリの「データ作成中のＲＩＰ」の欄に登録する。また、ステージが３“Cached”であれば“Hit”を（Ｓ６８）、４“Cached Out”であれば“Deleted”を（Ｓ７０）、５“Never Cache”であれば“Invalid”を（Ｓ７２）、それぞれ問合せ元のＲＩＰ部１２０に応答する。この応答により、キャッシュ管理部１３０は、問合せについての処理を終了する。この応答に応じ、問合せ元のＲＩＰ部１２０は、図４〜図６に示した処理を実行する。
【０１５３】
次に、図８を参照して、いずれかのＲＩＰ部１２０からキャッシュデータの使用開始要求を受信したときのキャッシュ管理部１３０の処理手順の一例を説明する。
【０１５４】
この手順では、キャッシュ管理部１３０は、受信した使用開始要求の対象であるキャッシュデータをキャッシュメモリ１４０から求め、要求元のＲＩＰ部１２０に返信する（Ｓ８０）。これには、例えば、受信した使用開始要求に含まれる、ＩＤ等のキャッシュエントリを特定する情報をキーとしてエントリ管理テーブル１３２を検索し、これにより検索されたキャッシュエントリの中の「キャッシュ領域のアドレス」及び「キャッシュデータのサイズ」（図２参照）の情報に従い、キャッシュメモリ１４０からキャッシュデータを読み出せばよい。そして、キャッシュ管理部１３０は、当該キャッシュエントリの使用カウンタ（図２参照）の値に１を加える（Ｓ８２）。これにより、そのキャッシュエントリのキャッシュデータを現在使用しているＲＩＰ部１２０が１つ増えたことが記録される。
【０１５５】
次に、図９を参照して、いずれかのＲＩＰ部１２０からキャッシュデータの使用終了通知を受信したときのキャッシュ管理部１３０の処理手順の一例を説明する。
【０１５６】
この手順では、キャッシュ管理部１３０は、受信した使用終了通知に含まれるＩＤ等のエントリ特定情報からその通知の対象であるキャッシュエントリを特定し、そのキャッシュエントリの使用カウンタの値から１を減算する（Ｓ８５）。これにより、そのキャッシュエントリのキャッシュデータを現在使用しているＲＩＰ部１２０が１つ減ったことが記録される。
【０１５７】
次に、図１０及び図１１を参照して、いずれかのＲＩＰ部１２０からキャッシュのための領域確保要求を受信したときのキャッシュ管理部１３０の処理手順の一例を説明する。
【０１５８】
この手順では、図１０に示すように、まずキャッシュ管理部１３０は、当該領域確保要求に含まれるＩＤ等のエントリ特定情報からその通知の対象であるキャッシュエントリを特定する。そして、そのキャッシュエントリの情報などに基づき、そのキャッシュエントリのキャッシュデータがキャッシュメモリ１４０にキャッシュできるかどうかを、制限条件及びキャッシュメモリ１４０の空き容量の両面から評価する（Ｓ９０）。制限条件は、前述した通り、オブジェクトの複雑さやサイズ、形状などの点で、キャッシュに適さない、又はキャッシュした方が効率が悪いことが明らかなオブジェクトを特定する条件である。この判定は、特定したキャッシュエントリについてのエントリ管理テーブル１３２内の登録情報、例えばキャッシュデータのサイズやオブジェクト属性（例えばオブジェクトの種類や複雑さなど）などの情報を用いて行う。また、これらキャッシュデータのサイズやオブジェクト属性の情報は、領域確保要求と共にＲＩＰ部１２０から受け取り、エントリ管理テーブル１３２に登録する方式でもよい。
【０１５９】
Ｓ９０の評価の結果、制限条件がクリアされない（すなわちキャッシュに適さない）と判定した場合（Ｓ９２の判定結果がＮＯ）、キャッシュ管理部１３０は、特定されたキャッシュエントリ（以下「対象エントリ」と呼ぶ）のステージを５“Never Cache”に変更し（Ｓ９４）、要求元のＲＩＰ部１２０に対して領域確保の失敗を示すコードを応答する（Ｓ９６）。この応答に応じ、そのＲＩＰ部１２０は、図５のＳ３８に示したように、当該オブジェクトのＰＤＬデータを用いてビットマップ画像を生成してページの画像に合成し、そのビットマップ画像をキャッシュせずに処理を終了する。
【０１６０】
Ｓ９０の評価の結果、制限条件がクリアされたと判定した場合（Ｓ９２の判定結果がＹＥＳ）、キャッシュ管理部１３０は、更に、キャッシュメモリ１４０の空き領域（キャッシュデータが記憶されていない領域）の容量が、当該オブジェクトのキャッシュデータを記憶するのに十分かどうかを判定する（Ｓ９８）。この判定では、キャッシュデータのサイズの情報を参照する。この判定処理で、空き領域の容量が十分であると判定されると、キャッシュ管理部１３０は、キャッシュメモリ１４０内の空き領域の中から、そのキャッシュデータのサイズに応じた領域を確保し、領域確保の成功を示すコードと共に、確保した領域のアドレスを要求元のＲＩＰ部１２０に応答する（Ｓ１００）。この応答に応じ、そのＲＩＰ部１２０は、図５のＳ３２〜Ｓ３６の処理を実行する。なお、このときキャッシュ管理部１３０は、エントリ管理テーブル１３２の当該対象エントリの「キャッシュ領域のアドレス」に、確保した領域のアドレス（例えば先頭アドレス）を登録してもよい。
【０１６１】
Ｓ９８で空き領域の容量が十分でないと判定した場合、キャッシュ管理部１３０は、エントリ管理テーブル１３２から対象エントリのスコアを取得し（Ｓ１０２）、更にエントリ管理テーブル１３２に登録された各キャッシュエントリの中から、ステージが３“Cached”で且つ対象エントリよりもスコアの低いキャッシュエントリ（以下「劣位エントリ」と呼ぶ）を全て抽出する（Ｓ１０４）。
【０１６２】
キャッシュエントリのスコアは、前述したように、当該キャッシュエントリのキャッシュデータをキャッシュメモリ１４０にキャッシュする価値（効果）を表す評価値である。したがって、劣位エントリは、対象エントリよりも相対的にキャッシュする価値が低いキャッシュエントリといえる。本実施形態では、キャッシュメモリ１４０に対象エントリのキャッシュデータを収容するのに十分な空き領域がない場合、そのような劣位エントリのキャッシュデータをキャッシュメモリ１４０から追い出す（削除する）ことで、十分な空き領域を作るよう試みる。
【０１６３】
Ｓ１０６では、Ｓ１０４で劣位エントリが１つでも見つかったかどうかを判定する。劣位エントリが１つも見つからなければ、対象エントリは、キャッシュ対象を規定する最低限の条件（言い換えれば絶対的な条件）である制限条件は満たしているものの、既にキャッシュメモリ１４０内にデータがキャッシュされている他のいずれのエントリからみても相対的にキャッシュする価値が低いということになる。したがって、このような場合には、対象エントリのデータをキャッシュしないようにする。すなわちＳ１０６の判定結果がＮＯの場合には、キャッシュ管理部１３０は、対象エントリを現在のステージ１“New Cache”からステージ４“Cached Out”に変更し（Ｓ１０８）、要求元のＲＩＰ部１２０に領域確保の失敗を示すコードを応答する（Ｓ１１０）。この応答に応じ、そのＲＩＰ部１２０は、図５のＳ３８に示したように、当該オブジェクトのＰＤＬデータを用いてビットマップ画像を生成してページの画像に合成し、そのビットマップ画像をキャッシュせずに処理を終了する。
【０１６４】
Ｓ１０６で、劣位エントリが１以上見つかったことが分かった場合（判定結果がＹＥＳ）、キャッシュ管理部１３０は図１１に例示する手順を実行する。
【０１６５】
すなわち、まず見つかった劣位エントリのなかに、使用カウンタの値が０のものが残っているかどうかを判定する（Ｓ１１１）。使用カウンタの値が０ということは、どのＲＩＰ部１２０もそのキャッシュエントリ（劣位エントリ）のキャッシュデータを使用していないということなので、そのキャッシュデータを削除しても他のＲＩＰ部には悪影響がない。そこで、使用カウンタの値が０の劣位エントリがあれば、その中から最もスコアの低いものを１つ抽出する（Ｓ１１２）。そして、抽出した劣位エントリのキャッシュデータのアドレス及びサイズをエントリ管理テーブル１３２から求めて、そのアドレスからキャッシュデータをキャッシュメモリ１４０から追い出し（削除し）、その劣位エントリを現在のステージ３“Cached”からステージ４“Cached Out”に変更する（Ｓ１１４）。この追い出しにより、それまでそのキャッシュデータが占めていたキャッシュメモリ１４０内の領域が解放される。キャッシュ管理部１３０は、その解放された領域を空き領域に加入し、それにより広がった空き領域の容量（すなわち、キャッシュメモリ１４０の空き容量）が対象エントリのキャッシュデータのサイズを収容するのに必要な大きさとなったかどうかを判定する（Ｓ１１６）。この判定で、空き領域が必要な容量に達していないと判定した場合、キャッシュ管理部１３０はＳ１１１に戻り、使用カウンタの値が０の劣位エントリが残っている間は、その中からスコアの低い順に１つずつ、キャッシュデータの追い出し及びステージの変更を行う（Ｓ１１２，Ｓ１１４）。
【０１６６】
このようにして、使用カウンタの値が０の劣位エントリのみを追い出すことで、対象エントリをキャッシュするのに必要な空き容量が確保できた場合（Ｓ１１６の判定結果がＹＥＳ）、キャッシュ管理部１３０は、キャッシュメモリ１４０の空き領域の中から、そのキャッシュデータのサイズに応じた領域を確保し、領域確保の成功を示すコードと共に、確保した領域のアドレスを要求元のＲＩＰ部１２０に応答する（Ｓ１１８）。これにより領域確保要求に対するキャッシュ管理部１３０の処理が終了する。その応答に応じ、そのＲＩＰ部１２０は、図５のＳ３２〜Ｓ３６の処理を実行する。なお、このときキャッシュ管理部１３０は、エントリ管理テーブル１３２の当該対象エントリの「キャッシュ領域のアドレス」に、確保した領域のアドレスを登録してもよい。
【０１６７】
使用カウンタの値が０の劣位エントリを全てキャッシュメモリ１４０から追い出しても対象エントリをキャッシュするのに必要な空き容量が確保できない場合、Ｓ１１１の判定結果がＮＯとなる。これは、現在いずれかのＲＩＰ部１２０で使用されているキャッシュデータを追い出さない限り、対象エントリのキャッシュデータをキャッシュすることができないことを意味する。この場合、本実施形態では、例えば現在劣位エントリのキャッシュデータを使用しているＲＩＰ部１２０の処理に悪影響が及ぶことを避けるために、今回の要求については、対象エントリのキャッシュデータをキャッシュすることをあきらめる。ただし、対象エントリは、現在使用されている劣位エントリよりもキャッシュする価値（スコア）が高いので、あきらめたまま放置するのではなく、キャッシュするための準備を行う。
【０１６８】
すなわち、図１１の手順では、Ｓ１１１の判定結果がＮＯの場合、対象エントリを現在のステージ１“New Cache”からステージ２“Caching”に変更する（Ｓ１２２）。ステージ２“Caching”は、前述した通り、このケースのように、当該エントリは他と比べてキャッシュする価値はあるものの、使用中の劣位エントリのキャッシュデータを追い出さないと当該エントリをキャッシュするのに十分な領域が確保できない「空き待ち」状態を表す。そして、要求元のＲＩＰ部１２０に対して、領域確保の失敗を示すコードを応答する（Ｓ１２４）。この応答に応じ、そのＲＩＰ部１２０は、図５のＳ３８に示したように、当該オブジェクトのＰＤＬデータをＲＩＰ処理してビットマップ画像を生成してページの画像に合成し、ＲＩＰ処理結果をキャッシュせずに処理を終了する。
【０１６９】
このケースは、折角生成されたＲＩＰ処理結果がキャッシュされないという点では、対象エントリが制限条件に抵触する場合（図１０のＳ９２〜Ｓ９４）や劣位エントリがない場合（同Ｓ１０６〜Ｓ１１０）と同じである。しかし、これらの場合は、いずれも対象エントリをキャッシュする価値が絶対的に又は他と比べて相対的に低い場合であり、ステージが“Never Cache”又は“Cached Out”とされることで、今後ずっと、又はしばらくはキャッシュ登録されないよう制御される。これに対し、Ｓ１１１の判定結果がＮＯとなったこのケースでは、対象エントリはキャッシュする価値が相対的に十分高いので、対象エントリを“Caching”という特別なステージに置いておき、今後、いずれかのＲＩＰ部１２０から同じ対象エントリに問合せがあった際、その対象エントリのキャッシュ登録が再度試みられるようにする。
【０１７０】
また、キャッシュ管理部１３０は、使用カウンタの値が０でない劣位エントリを、スコアの低い順に１つずつ抽出し（Ｓ１２６）、抽出した劣位エントリをステージ３“Cached”からステージ４“Cached Out”に変更する（Ｓ１２８）。
【０１７１】
そして、“Cached Out”に変更した劣位エントリのキャッシュデータを追い出したと仮定した場合のキャッシュメモリ１４０の空き容量を計算し、その空き容量が対象エントリのキャッシュデータをキャッシュするのに十分な量に達するまで、Ｓ１２６及びＳ１２８の処理を繰り返す（Ｓ１３０）。必要な空き容量が確保された時点で、領域確保要求に対するキャッシュ管理部１３０の処理が終了する。
【０１７２】
前述のＳ１１４では、抽出した劣位エントリのキャッシュデータをキャッシュメモリ１４０から追い出したが、このＳ１２８では、抽出した劣位エントリのキャッシュデータをまだ他のＲＩＰ部１２０が使用しているので、この時点では追い出しは行わない。しかし、抽出された劣位エントリはステージが４“Cached Out”に変更されているので、いずれのＲＩＰ部１２０からも使用されなくなった後で、キャッシュデータがキャッシュメモリ１４０から追い出されることとなる（詳細は後述）。Ｓ１２８は、使用中の劣位エントリに対する追い出しの予約と捉えてもよい。このように、対象エントリよりもスコアの低いエントリ（劣位エントリ）に対して、追い出しの予約をしておくことで、例えば対象エントリが次の機会にキャッシュされる可能性が高まる。
【０１７３】
また、使用中の劣位エントリをステージ４“Cached Out”に遷移させると、その後いずれかのＲＩＰ部１２０からその劣位エントリに問合せがあった場合、キャッシュ管理部１３０は“Deleted”を応答する（図７のＳ７０）。この場合、問合せ元のＲＩＰ部１２０は、キャッシュデータを使用せずに、ＰＤＬデータをＲＩＰ処理する（図４のＳ２４）。すなわち、その劣位エントリは使用中なので、キャッシュデータが未だキャッシュメモリ１４０にあるにもかかわらず、本実施形態では、それを問合せ元のＲＩＰ部１２０に使用させないようにしている。仮にこのような場合に問合せ元のＲＩＰ部１２０にキャッシュデータの使用を認めると、いずれかのＲＩＰ部から使用されているキャッシュデータは追い出さないという基本方針の下では、追い出し予約中のエントリをいつまで経っても追い出せなくなってしまう可能性がある。これに対し、本実施形態では、追い出しが予約された劣位エントリの使用を認めないので、そのような不具合が回避される。
【０１７４】
なお、Ｓ１２２及びＳ１２４の処理と、Ｓ１２６〜Ｓ１３０の処理とは、どちらを先に実行してもよい。
【０１７５】
また、煩雑さを避けるために図１１では省略したが、使用カウンタが０でない劣位エントリの全てをステージ４“Cached Out”にしても、対象エントリをキャッシュするのに十分な容量が確保できない場合も起こり得る。このような場合、キャッシュ管理部１３０は、領域確保要求に対する処理を終了すればよい。ここで必要な領域が確保できなくても、今回の領域確保要求に対しては確保失敗を応答しているので問題はなく、また同じ対象エントリに対する今後の問合せに対しても、追い出し予約をした劣位エントリの分だけ、キャッシュ登録が成功する可能性が高まっている。
【０１７６】
次に、図１２を参照して、いずれかのＲＩＰ部１２０からキャッシュデータの登録要求を受信したときのキャッシュ管理部１３０の処理手順の一例を説明する。
【０１７７】
この手順では、図１２に示すように、まずキャッシュ管理部１３０は、当該登録要求に含まれるＩＤ等のエントリ特定情報からその通知の対象であるキャッシュエントリを特定し、そのキャッシュエントリにキャッシュデータを登録する（Ｓ１４２）。例えば、エントリ管理テーブル１３２にキャッシュデータの登録の有無を示す項目（図２では省略）を設けておき、Ｓ１４２ではその項目の値を「登録無し」から「登録有り」に変更すればよい。
【０１７８】
また、キャッシュ管理部１３０は、当該キャッシュエントリの使用カウンタの値を０にリセットするとともに（Ｓ１４４）、当該エントリをステージ１“New Cache”からステージ３“Cached”に遷移させる（Ｓ１４６）。このとき、当該エントリの「データ作成中のＲＩＰ」の項目をクリアする。
【０１７９】
以上、ＲＩＰ部１２０からの各種のアクセス（問合せ、使用開始要求、使用終了通知、領域確保要求、登録要求）に対するキャッシュ管理部１３０の処理手順の例を説明した。以上に説明した処理手順では、１以上のＲＩＰ部１２０から使用中のキャッシュエントリに対して追い出し予約（キャッシュデータは削除されないが、ステージは４“Cached Out”に変更される）がなされる場合がある。本実施形態では、追い出し予約がなされたキャッシュエントリについては、いずれのＲＩＰ部１２０からもキャッシュデータが使用されなくなった段階で、できるだけすみやかに実際の追い出しを行い、それまでのそのデータが占めていた領域を解放する。このような追い出し予約がなされたキャッシュエントリの解放には、いくつかの方式が考えられる。
【０１８０】
１つは、定期的にエントリ管理テーブル１３２を調べて、解放すべきキャッシュエントリを探す方式である。この方式に従った手順の例を図１３に示す。
【０１８１】
図１３の手順では、キャッシュ管理部１３０は、定期的な調査のタイミング（クリーニングタイミングと呼ぶ）が到来すると、エントリ管理テーブル１３２においてステージが４“Cached Out”で且つ使用カウンタの値が０であるエントリを探し（Ｓ１５０）、そのようなエントリがあれば（Ｓ１５２の判定結果がＹＥＳ）、そのエントリのキャッシュデータがまだキャッシュメモリ１４０内にあるかどうかを判定する（Ｓ１５４）。Ｓ１５４の判定結果がＹＥＳであれば、そのキャッシュデータをキャッシュメモリ１４０から追い出し、それまでそのデータが占めていた領域を解放し（Ｓ１５６）、再びＳ１５０に戻る。Ｓ１５４の判定結果がＮＯであれば、Ｓ１５６を飛ばしてＳ１５０に戻る。このようにして、ステージが４“Cached Out”で且つ使用カウンタの値が０である全てのキャッシュエントリのキャッシュデータを追い出す。
【０１８２】
また、追い出し予約がなされたキャッシュエントリの解放を、キャッシュデータの使用終了通知に対する処理の中で行う方式も考えられる。この方式に沿った手順の例を、図１４に示す。
【０１８３】
図１４の手順は、いずれかのＲＩＰ部１２０からキャッシュデータの使用終了通知が到来した場合に実行される。この手順では、キャッシュ管理部１３０は、使用終了通知に含まれるＩＤ等に対応するキャッシュエントリをエントリ管理テーブル１３２から特定し、そのエントリの使用カウンタの値を１つ減少させる（Ｓ１６０）。そして、そのエントリがステージ４“Cached Out”であるか否か（Ｓ１６２）及び使用カウンタの値が０であるか否か（Ｓ１６４）をそれぞれ判定し、両方の判定結果がＹＥＳの場合に、当該エントリのキャッシュデータをキャッシュメモリ１４０から追い出す（Ｓ１６６）。これにより、それまでそのキャッシュデータが占めていた領域が解放される。特定したエントリがステージ４でないか、又は使用カウンタの値が０でない場合は、キャッシュデータの削除は行わず、処理を終了する。追い出し予約がなされたキャッシュエントリのキャッシュデータは、この手順により、使用しているＲＩＰ部１２０が無くなり次第直ちに追い出されることとなる。
【０１８４】
次に、図１５を参照して、いったん“Cached Out”ステージに遷移させたキャッシュエントリの見直し処理の一例を説明する。この処理は、例えば一定周期ごとなどのように、あらかじめ定められた規則に応じて決定された見直しタイミングが到来するごとに実行される。
【０１８５】
この手順では、キャッシュ管理部１３０は、見直しのタイミングが到来すると、エントリ管理テーブル１３２からステージが４“Cached Out”である（すなわち追い出された状態にある）キャッシュエントリを探し（Ｓ１７０）、そのようなエントリがあれば（Ｓ１７２の判定結果がＹＥＳ）、そのエントリのスコアがあらかじめ定められた閾値以上であるかどうかを判定する（Ｓ１７４）。キャッシュエントリのスコアがある範囲に収まるように正規化されたものであれば、この判定に用いる閾値は固定値でもよい。そうでない場合は、エントリ管理テーブル１３２に登録されているキャッシュエントリのスコアの分布に応じて閾値を適応的に変化させる。閾値の決め方には、様々な方式が考えられる。例えば、全キャッシュエントリにわたるスコアの平均値を閾値としてもよいし、全キャッシュエントリのスコアのうち上位から見てあらかじめ定められた順位に該当するスコアを閾値としてもよい。また、現在ステージが３“Cached”であるキャッシュエントリのうちの最低スコアを基準に閾値を定めてもよい（例えば、最低スコアに対してあらかじめ定めた値を足した値を閾値とするなど）。
【０１８６】
Ｓ１７４で当該キャッシュエントリのスコアが閾値以上であると判定された場合、それはそのキャッシュエントリはキャッシュメモリ１４０に戻す価値があることを意味する。この場合、キャッシュ管理部１３０は、そのキャッシュエントリをステージ４“Cached Out”からステージ２“Caching”へと遷移させる（Ｓ１７６）。これにより、その後当該キャッシュエントリに対していずれかのＲＩＰ部１２０から問合せが到来すると、当該エントリはステージ１“New Cache”に遷移し、そのＲＩＰ部１２０が当該エントリのキャッシュデータの登録を試みることとなる（図７のＳ６６及び図４，図５を参照）。
【０１８７】
《変形例１−１》
以上、１つの実施形態を説明した。以上の第１例の実施形態では、あるキャッシュエントリのキャッシュデータが作成中（すなわちステージ１“New Cache”）である場合、そのエントリの問合せを行ったＲＩＰ部１２０が、そのキャッシュデータが完成するのを待つのか待たないのかを判断した（図６のＳ４２，Ｓ４３参照）。しかし、その判断は、問合せを受けたキャッシュ管理部１３０が行ってもよい。その判断をキャッシュ管理部１３０が行う例を、以下に説明する。
【０１８８】
この例において、ＲＩＰ部１２０からキャッシュエントリの問合せを受けたときのキャッシュ管理部１３０の処理手順を、図１６及び図１７に示す。図１６に示す手順は、問合せの対象のキャッシュエントリのステージが１“New Cache”である場合の処理を除き、図７の手順と同じである。
【０１８９】
問合せの対象のキャッシュエントリのステージが１“New Cache”である場合は、キャッシュ管理部１３０は、図１７に例示する手順を実行する。この手順では、キャッシュ管理部１３０は、問合せ元のＲＩＰ部１２０（第１のＲＩＰ部と呼ぶ）が当該オブジェクトのＰＤＬデータを自らＲＩＰ処理する場合と、そのオブジェクトのキャッシュデータを作成中のＲＩＰ部１２０（第２のＲＩＰ部と呼ぶ）がそのキャッシュデータを完成させるのを待って第１のＲＩＰ部にそのキャッシュデータを利用させる場合との、どちらが早く処理が完了するかを評価する（Ｓ１８２）。評価の仕方は、図６のＳ４２の評価と同様でよい。
【０１９０】
Ｓ１８３では、Ｓ１８２の評価の結果に基づき、作成中のキャッシュデータの完成を待つ方がよいか待たない方がよいかを判定する。Ｓ１８３で第１のＲＩＰ部がキャッシュデータの完成を待った方がよいと判定された場合、キャッシュ管理部１３０は、第２のＲＩＰ部から当該キャッシュデータの登録要求が来るのを待つ（Ｓ１８４）。登録要求が来ることで、キャッシュデータが完成したことが分かる。すると、キャッシュ管理部１３０は、第１のＲＩＰ部に対し“Hit”を応答する（Ｓ１８６）。この時点では、そのキャッシュデータはキャッシュメモリ１４０内にあるので、“Hit”を受け取った第１のＲＩＰ部は、そのキャッシュデータを用いてページのＲＩＰ処理を進める。
【０１９１】
すなわち、この例では、待つ方がよいと判断した場合は、キャッシュ管理部１３０はすぐには問合せ元のＲＩＰ部１２０（第１のＲＩＰ部）に応答を行わず、そのキャッシュデータの完成を待って“Hit”を応答している。その間、問合せ元のＲＩＰ部１２０は、キャッシュ管理部１３０の応答を待っている。しかし、このような処理は一例に過ぎない。この代わりに、待つ方がよいと判断した時点で即座に問合せ元のＲＩＰ部１２０に待つように明示的に指示を行い、その後キャッシュデータが完成した時点で“Hit”を応答するようにしてもよい。
【０１９２】
一方、Ｓ１８３で、待たない方がよい（すなわち第１のＲＩＰ部がＰＤＬデータをＲＩＰ処理した方が早く処理が完了する）と判定した場合は、キャッシュ管理部１３０は、即座に、第１のＲＩＰ部に対し“Creating”を応答する（Ｓ１８８）。“Creating”を受け取った第１のＲＩＰ部は、キャッシュデータの完成を待たずに、当該オブジェクトのＰＤＬデータをＲＩＰ処理し、ページの描画を進める。この場合、ＲＩＰ処理結果はキャッシュされない。
【０１９３】
《変形例１−２》
また、更に別の変形例も考えられる。すなわち、上記第１例の実施形態では、あるキャッシュエントリのキャッシュデータが作成中である場合、そのエントリの問合せを行ったＲＩＰ部１２０が、そのキャッシュデータが完成するのを待つのか待たないのかを判断していた（図６のＳ４２，Ｓ４３参照）が、この変形例では、そのＲＩＰ部１２０の処理負荷が高い場合にはこの判断自体を取りやめる。この変形例の手順の一例を図１８に示す。図１８は、図４の手順のＳ１６で応答が“Creating”であると判定された後の処理の流れを示す。
【０１９４】
この変形例では、その場合、まず、ＲＩＰ部１２０は自身の負荷があらかじめ定めた閾値以上であるかどうかを判定する（Ｓ４１）。ここでの負荷は、負荷監視部１１４が監視している当該ＲＩＰ部１２０の負荷と同じものである。負荷がその閾値を超えている場合、図６の手順と同様のＳ４２及びＳ４３の処理を実行すること自体が、当該ＲＩＰ部１２０にとって無視できない負担となる（すなわち、実行中の他の処理の妨げとなる）。逆に言えば、閾値は、そのような状況を生じる下限の負荷であり、これは実験等によりあらかじめ求めておけばよい。
【０１９５】
Ｓ４１の判定で、ＲＩＰ部１２０の負荷が閾値以上と判定された場合、ＲＩＰ部１２０は、Ｓ４２及びＳ４３を飛ばし、キャッシュデータの完成を待つと自動的に判定し、Ｓ４４へと進む。すなわち、この場合、ＲＩＰ部１２０は負荷が高いので、自分でＰＤＬデータをＲＩＰ処理することはしない。その他のステップは、図６と同様でよい。
【０１９６】
《変形例１−３》
また、上記第１例では、ＲＩＰ部１２０は、キャッシュ管理部１３０から“Creating”の応答を受け取った場合、作成中のキャッシュデータの完成を待つか否かを判定したが、このような判定を行わず、“Creating”を受け取った場合には、作成中のキャッシュデータの完成を必ず待つようにしてもよい。また、この逆に、必ず、待たずに自らＲＩＰ処理し、処理結果をキャッシュしないようにしてもよい。このような場合でも、ＲＩＰ部１２０は、“Creating”というキャッシュデータ作成中を示す従来にない応答を受け取ることで、“Miss”又は“Hit”という従来の応答の場合とは異なる対応をとる。すなわち、“Miss”及び“Hit”という応答しか無ければ、“Miss”という応答を受けた場合、ＲＩＰ部１２０は目的のキャッシュデータが作成中であってもそのことが分からないので、その完成を待つこともできず、自分でＰＤＬデータをＲＩＰ処理することとなり、その処理結果をキャッシュメモリ１４０に重複登録してしまうことになる。
【０１９７】
［第２例］
本発明の実施形態の第２の例を説明する。この第２例の印刷文書変換システムの構成は、図１に示したものと同様でよい。
【０１９８】
《第２例の概要》
上述の第１例では、領域確保要求があった段階で、その要求の対象エントリよりもスコアの低い使用中のキャッシュエントリをステージ４“Cached Out”に遷移させることで、明示的にそのキャッシュエントリの追い出し予約を行った（図１１のＳ１２６，Ｓ１２８）。これに対し、この第２例では、追い出すべきと判定される使用中のキャッシュエントリをステージ３“Cached”のままで、暗黙のうちに追い出し予約状態とする。第１例ではステージ４“Cached Out”は、キャッシュデータがキャッシュメモリ１４０内にあるキャッシュエントリ（追い出し予約されたエントリ）にも適用されるのに対し、この第２例ではステージ４“Cached Out”はそのようなエントリには適用されず、キャッシュデータがキャッシュメモリ１４０から実際に追い出されたエントリのみに適用される。
【０１９９】
《第２例の状態遷移》
この第２例でのキャッシュエントリの状態遷移を図１９に示す。図１９に示す通り、第２例では、ステージ３“Cached”のキャッシュエントリに対していずれかのＲＩＰ部１２０から問合せがあった場合、キャッシュ管理部１３０は、そのキャッシュエントリのスコアに応じて応答を“Hit”と“Deleted”の間で切り替える。すなわち、そのキャッシュエントリのスコアが閾値以上であれば“Hit”を応答し、そうでなければ“Deleted”を応答する。応答“Deleted”の意味とこれを受け取ったときのＲＩＰ部１２０の挙動は、第１例の場合と同じである。すなわち、この第２例では、スコアが閾値未満であれば、“Deleted”を応答することで当該キャッシュエントリのキャッシュデータの使用を認めないようにする。これにより、当該キャッシュエントリのキャッシュデータが新たに使用されることが無くなるので、仮に現在そのキャッシュデータが使用中であっても、時間の経過に伴い使用カウンタの値が減っていき、追い出しが可能な状態（すなわち使用カウンタの値が０）に至る。このように、第２例では、スコアが閾値より低いと“Deleted”を応答することで、暗黙のうちに（すなわち明示的に“Cached Out”に遷移させることなく）当該キャッシュエントリを追い出し予約状態としている。ここで用いる閾値は、第１例の図１５の手順のＳ１７４で用いる閾値とは使用目的が異なるものなので、基本的にはＳ１７４で用いる閾値とは独立に定めればよいが、処理の簡略化などのためにＳ１７４で用いる閾値と同じ値を用いてもよい。
【０２００】
ステージ３“Cached”のキャッシュエントリがステージ４“Cached Out”に遷移するのは、そのキャッシュエントリのキャッシュデータが実際にキャッシュメモリ１４０から追い出されたときである。
【０２０１】
図１９の状態遷移は、以上に説明した点以外は、図３の例と同様である。
【０２０２】
《第２例の処理手順》
第２例での各ＲＩＰ部１２０の処理手順は、第１例の場合と同様でよい（図４〜図６参照）。
【０２０３】
第２例でのキャッシュ管理部１３０の動作は、第１例の場合と一部異なる。以下では、第１例と異なる部分に焦点を当てて説明する。
【０２０４】
まず、いずれかのＲＩＰ部１２０から問合せを受けたときのキャッシュ管理部１３０の処理手順の一例を図２０に示す。この例では、キャッシュ管理部１３０は、問合せの対象のキャッシュエントリのステージが３“Cached”である場合、そのエントリのスコアを調べ、スコアが閾値以上であれば“Hit”を応答し、閾値未満であれば“Deleted”を応答する（Ｓ６８Ａ）。図２０の他のステップは、第１例の図７のステップと同様でよい。
【０２０５】
いずれかのＲＩＰ部１２０から使用開始要求を受けたときのキャッシュ管理部１３０の処理手順は、第１例の図８の手順と同様でよい。
【０２０６】
いずれかのＲＩＰ部１２０から使用終了通知を受けたときのキャッシュ管理部１３０の処理手順は、例えば図２１に示すようなものとなる。
【０２０７】
この手順では、キャッシュ管理部１３０は、使用終了通知に含まれるＩＤ等から、対象となるキャッシュエントリを特定し、そのエントリの使用カウンタの値を１つ減少させる（Ｓ１６０）。そして、そのキャッシュエントリの使用カウンタの値が０であるか否か（Ｓ１６３）及びそのキャッシュエントリのスコアが閾値未満であるか否か（Ｓ１６５）をそれぞれ判定する。そして、両方の判定結果がＹＥＳの場合には、当該キャッシュエントリのキャッシュデータをキャッシュメモリ１４０から追い出し、そのエントリのステージを現在値３“Cached”から４“Cached Out”に変更する（Ｓ１６７）。これにより、それまでそのキャッシュデータが占めていた領域が解放される。対象のキャッシュエントリの使用カウンタの値が０でないか、又はスコアが閾値以上である場合は、キャッシュデータの削除及びステージ変更（Ｓ１６７）は行わず、処理を終了する。スコアが閾値未満となって暗黙のうちに追い出し予約状態（すなわち新規の使用を受け付けない状態）となっていたキャッシュエントリは、この手順により、使用しているＲＩＰ部１２０が無くなり次第直ちに追い出され、ステージ４“Cached Out”に遷移することとなる。
【０２０８】
図２１の例では、スコアが閾値より低いキャッシュエントリのキャッシュデータを、使用終了通知を受けたタイミングで追い出したが、これは一例に過ぎない。この代わりに、例えば、第１例における図１３の手順と同様の方法で、見直しタイミングごとにステージが３“Cached”の各キャッシュエントリのスコアと使用カウンタを調べ、スコアが閾値未満且つ使用カウンタの値が０となっているエントリのキャッシュデータを追い出すようにしてもよい。
【０２０９】
いずれかのＲＩＰ部１２０から領域確保要求が到来した場合のキャッシュ管理部１３０の処理手順は、例えば図２２及び図２３に示すものとなる。
【０２１０】
まず図２２に示す手順は、ほとんどの部分は図１０に示した第１例における処理手順と同様であり、Ｓ９９を含む点のみが第１例の場合と異なる。すなわち、この第２例では、Ｓ９６及びＳ９８で領域確保の対象のキャッシュエントリ（オブジェクト）が制限条件をクリアし、キャッシュメモリ１４０の空き領域に収容可能（空き容量が十分）と判定された場合に、図２１の手順のＳ１６５で用いられるスコアの閾値を、取り得る範囲の最低値（例えば０）にリセットする（Ｓ９９）。Ｓ９８で空き容量が十分と判定されたということは、この判定の時点では、キャッシュメモリ１４０の空き領域が追い出しを必要としない程度に十分大きいということである。そこで、この例では、そのような場合に、キャッシュメモリ１４０内に残すキャッシュエントリの選別基準を下げて、現在キャッシュメモリ１４０内にあるキャッシュデータができるだけ追い出されないようにしている。
【０２１１】
なお、以上の例ではＳ９９で閾値を最低値にリセットしたが、これは一例に過ぎない。この代わりに、Ｓ９９では閾値をあらかじめ定められた幅又は割合だけ低下させるようにしてもよい。
【０２１２】
また、図２２の手順のＳ１０６で劣位エントリ有りと判定した場合にキャッシュ管理部１３０が行う処理手順は、図２３に示すようなものとなる。この処理手順は、第１例における図１１の手順とほぼ同様であるが、図１１の手順におけるＳ１２６〜Ｓ１３０のステップ群が、図２３の手順ではＳ１２５に置き換えられている。
【０２１３】
使用されていない劣位エントリのキャッシュデータをすべてキャッシュメモリ１４０から追い出してもまだ必要な空き容量が確保できない場合、図２３の手順でも、図１１の手順と同様、領域確保要求の対象のキャッシュエントリ（「対象エントリ」）のステージを２“Caching”に変更し（Ｓ１２２）、要求元のＲＩＰ部１２０に領域確保の失敗を示す応答を行う（Ｓ１２４）。すなわち、第２例でも、今回の領域確保要求については失敗を返すことで、要求元のＲＩＰ部１２０は、対象エントリのＰＤＬデータをＲＩＰ処理してビットマップ画像を生成し、それをキャッシュしないようにする。そして、その後同じ対象エントリに対して問合せが到来したときにその対象エントリのキャッシュデータを収容するだけの空き容量ができるよう、現時点では、使用中の他のエントリのキャッシュデータの追い出しの予約を行う。図２３の手順は、その予約の仕方が図１１の手順と異なる。
【０２１４】
すなわち、図１１の手順では、まだいずれかのＲＩＰ部１２０から使用されているキャッシュエントリのステージを明示的に４“Cached Out”に遷移させることで追い出しの予約を行った。これに対し、図２３の手順ではそのような明示的なステージ変更は行わず、追い出し処理（図２１のＳ１６５及びＳ１６７）における追い出し対象の判定の閾値の調整を行い（Ｓ１２５）、調整後の閾値よりもスコアの低いキャッシュエントリが今後新たに使用されないようにする（図２０のＳ６８Ａ参照）ことで、それらスコアの低いキャッシュエントリが追い出されやすくする。
【０２１５】
Ｓ１２５の閾値の調整は、対象エントリのスコアを基準とする。すなわち、ここでは、対象エントリをキャッシュできるようにするために、対象エントリのスコアより少し低いスコアを閾値に設定する。すなわち、Ｓ１２５では、例えば、対象エントリのスコアからあらかじめ定められた値又は割合を減じた結果を閾値に設定する。より厳密には、閾値は、対象エントリのスコアより低く、少なくとも１つの劣位エントリのスコアよりも高い値に設定する。このように閾値を設定すれば、その閾値よりスコアの低いキャッシュエントリのキャッシュデータは、いずれのＲＩＰ部１２０からも使用されなくなった時点で図２１の手順でキャッシュメモリ１４０から追い出されることとなる。その後いずれかのＲＩＰ部１２０がキャッシュ管理部１３０に対象エントリについて問合せ行った時点で、閾値に基づく追い出しにより対象エントリのキャッシュデータ以上の容量が確保できていれば、対象エントリのキャッシュデータがキャッシュメモリ１４０に登録されることになる。対象エントリのスコアは、Ｓ１２５で設定された閾値よりも高いので、その設定の後閾値を更に上昇させる変更が行われていなければ、対象エントリのキャッシュデータは追い出されずにキャッシュメモリ１４０に残ることとなる。
【０２１６】
いずれかのＲＩＰ部１２０からキャッシュデータの登録要求を受けたときのキャッシュ管理部１３０の処理手順は、第１例の図１２の手順と同様でよい。
【０２１７】
また、この第２例でも、第１例と同様、いったん“Cached Out”ステージに遷移させたキャッシュエントリの見直し処理（図１５）を行ってもよい。
【０２１８】
《変形例２−１）》
以上、実施形態の第２例を説明した。以上では、閾値は、追い出すキャッシュエントリを判別するために用いた（図２０のＳ６８Ａ及び図２１のＳ１６５及びＳ１６７参照）。これに対し、同じ閾値を用いて、キャッシュを要求されたキャッシュエントリがキャッシュ登録に値するかどうかを判定してもよい。このような判定を行う例を図２４に示す。
【０２１９】
図２４に示す手順は、いずれかのＲＩＰ部１２０から領域確保要求があった場合のキャッシュ管理部１３０の処理手順であり、図２２の手順に対してＳ１０３を追加したものである。図２４の手順では、キャッシュメモリ１４０の空き容量が十分でない場合、対象エントリに対する劣位エントリを抽出（Ｓ１０４）する前に、対象エントリのスコアが閾値以上であるかどうかを判定する（Ｓ１０３）。そして、対象エントリのスコアが閾値未満であれば、そもそもその対象エントリはキャッシュする価値がないとみなし、劣位エントリの抽出（Ｓ１０４）等のステップは実行せずに、その対象エントリをステージ４“Cached Out”に遷移させ（Ｓ１０８）、要求元のＲＩＰ部１２０に領域確保の失敗を応答する（Ｓ１１０）。
【０２２０】
《変形例２−２》
上述の変形例２−１では、追い出すキャッシュエントリを判別するための閾値（図２０のＳ６８Ａ及び図２１のＳ１６５及びＳ１６７参照）と、キャッシュエントリを登録するか否かの判定に用いる閾値（図２４のＳ１０３参照）とが共通のものであった。これに対し、この変形例２−２では、それら２種類の閾値を使い分ける例を説明する。以下では、前者の閾値を追出用閾値、後者の閾値を登録用閾値と呼ぶ。
【０２２１】
この変形例２−２では、いずれかのＲＩＰ部１２０からキャッシュエントリについての問合せが来た場合に、図２５に示すように、そのキャッシュエントリのスコアが「追出用」閾値以上であれば“Hit”を応答し、「追出用」閾値未満であれば“Deleted”を応答する（Ｓ６８Ｂ）。図２５の他のステップは、図２０に示した第２例の手順と同様でよい。すなわち、この例では、Ｓ６８Ｂにて暗黙的な追い出し予約状態とするキャッシュエントリを判定するのに、２種類の閾値のうち追出用閾値を用いる。
【０２２２】
また、いずれかのＲＩＰ部１２０から使用終了通知を受けたときのキャッシュ管理部１３０の処理手順は図２６に示すようなものとなる。この手順は、対象のエントリのスコアを「追出用」閾値と比較する（Ｓ１６５Ａ）点以外は、図２１の手順と同様である。すなわち、この例では、キャッシュエントリを追い出すか否かの判定に、２種類の閾値のうち追出用閾値を用いている。
【０２２３】
また、いずれかのＲＩＰ部１２０から領域確保要求が到来した場合のキャッシュ管理部１３０の処理手順は、図２７及び図２８に示すものとなる。
【０２２４】
図２７の手順は、上述の変形例２−１の図２４の手順に対応するものである。変形例２−１（図２４）では対象エントリがキャッシュするのに値するかどうかを判定する場合に、対象エントリのスコアを（追出用と登録用とに分けない）共通の閾値と比較していたのに対し、この変形例２−２では、対象エントリのスコアを「登録用」閾値と比較する（Ｓ１０３Ａ）。また、変形例２−１（図２４）ではＳ９８で空き容量が十分と判定した場合、共通の閾値をリセット（Ｓ９９）したのに対し、この変形例２−２では、その場合には登録用閾値をリセットする（Ｓ９９Ａ）。
【０２２５】
また、図２８の手順は、第２例の図２３の手順に対応している。第２例（図２３）では、ステップＳ１２５において、（追出用と登録用とに分けない）共通の閾値を対象エントリのスコアに基づき計算していたのに対し、この変形例２−２では、追出用及び登録用の各閾値を対象エントリのスコアに基づき計算する（Ｓ１２５Ａ）。例えば、追出用及び登録用の各閾値は、ともに、対象エントリのスコアより低く、少なくとも１つの劣位エントリのスコアよりも高い値に設定する。ここでは、例えば、登録用閾値の方が追出用閾値以上となるよう、各閾値を定めればよい。例えば、対象エントリのスコアから第１の正の値を引いた値を登録用閾値とし、更にその登録用閾値から第２の正の値を引いた値を追出用閾値とするなどである。
【０２２６】
また、この変形例２−２でも、第１例の図１５の手順と同様、いったん“Cached Out”ステージに遷移させたキャッシュエントリの見直し処理を行ってもよい。ここで、この変形例２−２では、図２９に示すように、“Cached Out”ステージにあるキャッシュエントリを、キャッシュ登録の対象に戻すか否かを判定する閾値として、登録用閾値を用いる（Ｓ１７４Ａ）。図２９の手順のそれ以外のステップは、図１５の場合と同じである。
【０２２７】
［第３例］
《概要》
本発明の実施形態の第３の例を説明する。この第３例の印刷文書変換システムの構成は、図１に示したものと同様でよい。
【０２２８】
上述の第１例及び第２例では、ＲＩＰ部１２０から領域確保要求を受け取ったときに、空き容量が足りない場合に、キャッシュ済（ステージ３“Cached”）である劣位エントリを追い出す（削除する）ことで、空き容量を増大させた（図１０のＳ１０４、Ｓ１０６及び図１１参照）。これに対し、この第３例では、ステージが３“Cached” である劣位エントリを追い出すのに加え、キャッシュデータ作成中（ステージ１“New Cache”）の劣位エントリが確保した領域も解放することで、空き容量を増大させる。
【０２２９】
すなわち、キャッシュデータを作成するＲＩＰ部１２０は、図５に示すようにまず領域確保要求（Ｓ３０）を行ってキャッシュデータを記憶させる領域を確保し、その後その領域にキャッシュデータを生成し（Ｓ３２）、登録する（Ｓ３６）。したがって、ステージ１“New Cache”のキャッシュエントリには、領域が確保されてはいるもののキャッシュデータがまだ完成していない期間が存在する。この第３例では、このような期間に該当するステージ１“New Cache”のキャッシュエントリの領域を解放するのである。なお、ステージ１“New Cache”のキャッシュエントリでも、領域確保前のものについては、解放する領域がないので、第３例の処理の対象とはならない。
【０２３０】
第３例では、キャッシュ管理部１３０は、図３０に示すようにエントリ管理テーブル１３２にてキャッシュエントリの領域確保が済んでいるか否かを示す項目（図中の「領域確保」欄）を管理している。この項目は、ステージ１“New Cache”のキャッシュエントリについてのみ値が登録されていればよく、他のステージのキャッシュエントリについてはこの項目は空値である。
【０２３１】
《第３例の状態遷移》
第３例におけるキャッシュエントリの状態遷移は、図３１に示すようなものとなる。図３１の状態遷移は、図３に示した第１例の状態遷移とほぼ同じであり、異なる点は、ステージ１“New Cache”からステージ４“Cached Out”に遷移する条件が増えている点である。すなわち、第３例では、領域確保が成功した後、他のキャッシュエントリの領域確保のためにその領域を強制的に解放された場合にも、ステージ１“New Cache”からステージ４“Cached Out”への遷移が起こる。
【０２３２】
第３例での各ＲＩＰ部１２０の処理手順は、第１例の場合と同様でよい（図４〜図６参照）。
【０２３３】
第３例でのキャッシュ管理部１３０の動作は、第１例と同様の部分が多い。同様の点を説明すると、まずいずれかのＲＩＰ部１２０から問合せを受けたときのキャッシュ管理部１３０の処理手順は、第１例と同様でよい（図７参照）。また、いずれかのＲＩＰ部１２０から使用開始要求を受けたときのキャッシュ管理部１３０の処理手順も、第１例と同様でよい（図８参照）。また、いずれかのＲＩＰ部１２０から使用終了通知を受けたときのキャッシュ管理部１３０の処理手順も、第１例と同様でよい（図９又は図１４参照）。また、クリーニングタイミング到来時及び見直しタイミング到来時の処理も、第１例の場合と同様でよい（図１３及び図１５参照）。
【０２３４】
以下、第１例と異なる部分に焦点を当てて説明する。
【０２３５】
第３例において、いずれかのＲＩＰ部１２０から領域確保要求が到来した場合のキャッシュ管理部１３０の処理手順は、例えば図３２〜図３８に示すものとなる。
【０２３６】
まず図３２に示す手順は、ほとんどの部分は図１０に示した第１例における処理手順と同様であり、Ｓ１００Ａ及びＳ１０４Ａのみが異なる。Ｓ１００Ａでは、領域確保を要求元のＲＩＰ部１２０に応答することに加え、当該キャッシュエントリの領域が確保済になったことをエントリ管理テーブル１３２の「領域確保」の欄に登録する。なお、キャッシュエントリの「領域確保」の欄は、当該エントリがステージ１“New Cache”に遷移したときに、「未確保」に初期化されているものとする。Ｓ１０４Ａでは、ステージ３だけでなく、ステージ１且つ領域確保済のキャッシュエントリの中からも劣位エントリ（対象エントリよりもスコアが低いエントリ）を探す。このとき、領域確保済かどうかは、エントリ管理テーブル１３２の「領域確保」の欄を参照して判定すればよい。
【０２３７】
また、図３２の手順のＳ１０６で劣位エントリ有りと判定した場合、キャッシュ管理部１３０は図３３の手順に進む。
【０２３８】
図３３の手順では、まず見つかった劣位エントリのなかに、ステージが３“Cached”で使用カウンタの値が０のものが残っているかどうかを判定する（Ｓ１１１Ａ）。残っていれば、その中からスコアの低い順に１つずつ抽出し（Ｓ１１２Ａ）、抽出した劣位エントリのキャッシュデータをキャッシュメモリ１４０から追い出し（削除し）、その劣位エントリを現在のステージ３ “Cached”からステージ４“Cached Out”に変更する（Ｓ１１４）。ステージが３“Cached”で使用カウンタの値が０の劣位エントリが残っている間は、Ｓ１１２Ａ及びＳ１１４を繰り返すことで、キャッシュメモリ１４０の空き容量を増大させる（Ｓ１１６）。このような手順で対象エントリをキャッシュするのに必要な空き容量が確保できた場合（Ｓ１１６の判定結果がＹＥＳ）、キャッシュ管理部１３０は、キャッシュメモリ１４０の空き領域の中から、そのキャッシュデータのサイズに応じた領域を確保し、領域確保の成功を要求元のＲＩＰ部１２０に応答すると共に、当該キャッシュエントリの領域が確保済になったことをエントリ管理テーブル１３２の「領域確保」の欄に登録する。（Ｓ１１８Ａ）。
【０２３９】
ステージ３ “Cached”且つ使用カウンタの値が０の劣位エントリを全てキャッシュメモリ１４０から追い出しても対象エントリをキャッシュするのに必要な空き容量が確保できない場合、Ｓ１１１Ａの判定結果がＮＯとなる。
【０２４０】
Ｓ１１１Ａの判定結果がＮＯとなった場合、キャッシュ管理部１３０は、ステージ１“New Cache”且つ領域確保済のキャッシュエントリの領域を解放することで、十分な空き容量を確保することを試みる。このための処理手順には、例えば、３つの方式がある。以下、それら３つの方式の処理手順の例を順に説明する。
【０２４１】
《第１方式：一時的オーバーフロー方式》
この方式では、キャッシュ管理部１３０は図３４に例示する処理手順を実行する。この手順では、まず、ステージ１“New Cache”で領域確保済の劣位エントリが残っているかどうかを判定する（Ｓ２００）。残っていれば、その中から最もスコアの低いものを１つ抽出する（Ｓ２０２）。そして、抽出した劣位エントリをステージ１“New Cache”からステージ４“Cached Out”に遷移させ（Ｓ２０４）、この領域を解放したと仮定した場合のキャッシュメモリ１４０の空き容量を計算する。この空き容量が、対象エントリのキャッシュデータを収容するのに十分な大きさかどうかを判定し（Ｓ２０６）、まだ不十分であれば、Ｓ２００に戻り、ステージ１“New Cache”で領域確保済の別の劣位エントリが残っている間は、Ｓ２０２〜Ｓ２０４の処理を繰り返す。このようなステージ１“New Cache”で領域確保済の劣位エントリ群の領域の解放で対象エントリに必要な空き領域が確保できれば（Ｓ２０６の判定結果がＹＥＳ）、キャッシュ管理部１３０は、対象エントリのための領域をキャッシュメモリ１４０内で確保し、要求元のＲＩＰ部１２０に領域確保の旨を示すコードと確保した領域のアドレスの情報を返す（Ｓ２０８）。また、このとき、エントリ管理テーブル１３２の対象エントリのレコードの「領域確保」欄に対し、領域確保が済んだ旨を記録する。Ｓ２０８の後、キャッシュ管理部１３０は、当該領域確保要求についての処理を終了する。
【０２４２】
ここで注意すべきは、Ｓ２０４では、劣位エントリをステージ１“New Cache”からステージ４“Cached Out”に遷移させるのみであり、その劣位エントリのために確保されているキャッシュ領域は実際には解放しない点である。この解放は、現在作成されているその劣位エントリのキャッシュデータの作成が完了し、作成しているＲＩＰ部１２０がそのデータを使用し終えた時点で行われる。このように、Ｓ２０４では、いわば領域解放の予約が行われるだけである。このため、Ｓ２０８を実行する時点では、キャッシュメモリ１４０の空き容量は、実際には対象エントリのために必要な量よりも少ない。このため、Ｓ２０８での領域の確保は、オペレーティングシステムからキャッシュメモリ１４０に割り当てられた全体容量の制限を一時的に超える（オーバーフローする）形で行う。すなわち、キャッシュ管理部１３０及びキャッシュメモリ１４０を実現するコンピュータのオペレーティングシステムは、自身が管理するメモリ空間の一部をキャッシュメモリ１４０に割り当てており、Ｓ２０８ではその割り当てられた領域からはみ出して対象エントリのためのキャッシュ領域を確保するのである。このような確保処理により、キャッシュメモリ１４０として実際に使用される領域のサイズは、本来割り当てられたキャッシュメモリサイズを超えることとなるが、このオーバーフロー状態は領域解放を予約された劣位エントリ群のキャッシュデータの作成が完了するまでの一時的な状態に過ぎない。
【０２４３】
なお、ステージ１“New Cache”で領域確保済のすべての劣位エントリの領域を解放したとしても、対象エントリのために必要な領域が確保できない場合、Ｓ２００の判定結果がＮＯとなる。この場合、キャッシュ管理部１３０は、第１例の図１１のＳ１２２〜Ｓ１３０と同様の処理を行う。すなわち、対象エントリのステージを２“Caching”に変更し（Ｓ１２２）、要求元のＲＩＰ部１２０に領域確保の失敗を応答し（Ｓ１２４）、ステージ３の使用中の劣位エントリに対し、スコアの低い順に、必要な空き容量が確保されるまで追い出し予約（ステージ４への変更）を行う（Ｓ１２６〜Ｓ１３０）。
【０２４４】
この第１方式では、対象エントリのための領域確保を要求したＲＩＰ部１２０は、ステージ３で使用カウンタ値が０のキャッシュエントリと、ステージ１で領域確保済のキャッシュエントリの領域を解放すれば、必要な容量が得られる場合には、即座にキャッシュ領域の割当を受けることとなる。
【０２４５】
また、この第１方式では、Ｓ２０４で領域解放の予約がなされたキャッシュエントリについての領域の解放を、例えば、キャッシュデータの登録要求をトリガとして実行する。この手順を図３５に示す。
【０２４６】
図３５の手順では、キャッシュ管理部１３０は、いずれかのＲＩＰ部１２０からキャッシュデータの登録要求（この要求にはキャッシュエントリを特定するＩＤ等の特定情報が含まれている）が到来すると、その要求の対象であるキャッシュエントリ（対象エントリ）のステージをエントリ管理テーブル１３２から求める（Ｓ１４０）。この場合、対象エントリのステージは１“New Cache”又は４“Cached Out”のどちらかである。ステージが１“New Cache”の場合は、第１例における図１２の手順と同様、Ｓ１４２〜Ｓ１４６の各ステップを実行する。ステージが４“Cached Out”の場合、対象エントリのキャッシュ領域は他のキャッシュエントリのキャッシュ領域を確保するために解放するべく予約されている（図３４のＳ２０４参照）ので、作成されたばかりの対象エントリのキャッシュデータを削除し、それまでそのキャッシュデータが占めていた領域を解放する（Ｓ１４８）。なお、この解放の前までに対象エントリのキャッシュデータを作成していたＲＩＰ部１２０は、既にそのキャッシュデータをページの印刷画像データに合成する処理を済ませている（図５の手順で、登録要求（Ｓ３６）の前にビットマップ作成（Ｓ３４）が実行されている）ので、この時点でキャッシュデータを削除しても、そのＲＩＰ部１２０に悪影響はない。
【０２４７】
このような領域解放の処理により、キャッシュメモリ１４０のオーバーフロー状態が解消されていくことになる。
【０２４８】
《第２方式：即時強制解放方式》
この方式では、キャッシュ管理部１３０は図３６に例示する処理手順を実行する。この手順では、まず、ステージ１“New Cache”で領域確保済の劣位エントリが残っているかどうかを判定する（Ｓ２００）。残っていれば、その中から最もスコアの低いものを１つ抽出する（Ｓ２０２）。そして、抽出した劣位エントリのキャッシュデータを作成中のＲＩＰ部１２０（これはエントリ管理テーブル１３２から分かる）に対し、キャッシュデータの作成中止、及びキャッシュ領域ではなく通常のメモリ領域を用いて当該オブジェクトの元のＰＤＬデータをＲＩＰ処理すること、を指示する（Ｓ２０３）。これに応じ、そのＲＩＰ処理部１２０は、そのオブジェクトのＲＩＰ処理を行い、そのＲＩＰ処理結果をページの画像に合成した後、キャッシュせずに破棄する。また、抽出した劣位エントリをステージ１“New Cache”からステージ４“Cached Out”に遷移させ、この劣位エントリのために確保していたキャッシュ領域を解放する（Ｓ２０４Ａ）。
【０２４９】
すなわち、上述の第１方式のＳ２０４では、劣位エントリのステージを４に変更するだけでキャッシュ領域は解放しなかったのに対し、この第２方式ではキャッシュ領域を解放する。そして、この解放の後、キャッシュメモリ１４０の空き容量が対象エントリのキャッシュデータを収容するのに十分な大きさかどうかを判定し（Ｓ２０６）、まだ不十分であれば、Ｓ２００に戻り、ステージ１“New Cache”で領域確保済の別の劣位エントリが残っている間は、Ｓ２０２〜Ｓ２０４Ａの処理を繰り返す。このようなステージ１“New Cache”且つ領域確保済の劣位エントリ群の領域の解放で対象エントリに必要な空き領域が確保できれば（Ｓ２０６の判定結果がＹＥＳ）、キャッシュ管理部１３０は、対象エントリのための領域をキャッシュメモリ１４０に確保し、要求元のＲＩＰ部１２０に領域確保の旨を示すコードと確保した領域のアドレスの情報を返す（Ｓ２０８）。また、このとき、エントリ管理テーブル１３２の対象エントリのレコードの「領域確保」欄に対し、領域確保が済んだ旨を記録する。Ｓ２０８の後、キャッシュ管理部１３０は、当該領域確保要求についての処理を終了する。
【０２５０】
なお、ステージ１“New Cache”で領域確保済のすべての劣位エントリの領域を解放したとしても、対象エントリのために必要な領域が確保できない場合、Ｓ２００の判定結果がＮＯとなる。この場合、キャッシュ管理部１３０は、第１例の図１１のＳ１２２〜Ｓ１３０と同様の処理を行う。
【０２５１】
この第２方式では、キャッシュ領域を強制解放されたＲＩＰ部１２０は再度ＰＤＬデータのＲＩＰ処理を行う必要があるが、キャッシュメモリ１４０に割り当てられた容量の超過は生じず、対象エントリに必要なキャッシュ領域が即座に確保される。なお、キャッシュ領域を強制解放されたステージ１の劣位エントリは、対象エントリよりもスコアが低いので、対象エントリのキャッシュをあきらめるより、劣位エントリの作成中のキャッシュデータの領域を解放した方が、キャッシュの利用効率の点では有利と言える。
【０２５２】
《第３方式：作成完了後解放方式》
この方式では、キャッシュ管理部１３０は図３７に例示する処理手順を実行する。この手順は、Ｓ２００〜Ｓ２０６までは、図３４に示した第１方式の場合と同様である。すなわち、ステップＳ２０４では、ステージ１“New Cache”で領域確保済の劣位エントリのステージを４に変更するのみで、キャッシュ領域の解放は行わない。
【０２５３】
前述の第１方式では、それらステージ４に遷移させたステージ１の劣位エントリの領域解放を待たず、キャッシュメモリ１４０に割り当てられた容量からオーバーフローする形で対象エントリのための領域確保（Ｓ２０８）を行った。これに対し、この第３方式ではオーバーフローせずに、それらステージ４に遷移させたステージ１のすべての劣位エントリの領域解放を待ち（Ｓ２０７）、それらすべての劣位エントリの領域が解放された後に、対象エントリのための領域確保を行う（Ｓ２０８）。ここで、Ｓ２０７では、例えば、ステージ４に遷移させたステージ１の各劣位エントリについて、エントリ管理テーブル１３２の「領域確保」欄（図３０参照）を監視し、それら監視対象のすべての劣位エントリの「領域確保」欄が「解放済」を示す値となったときに、Ｓ２０７の判定結果をＹＥＳとする。すなわち、この方式では、「領域確保」欄の取り得る値は、「未確保」、「確保済」、及び「開放済」の３値である。なお、それら各劣位エントリの「領域確保」欄には、後述するように、登録要求に対する処理の中で、「解放済」の値が書き込まれる。その他のステップは、第１方式の図３４の手順と同様でよい。
【０２５４】
この第３方式では、いずれかのＲＩＰ部１２０からキャッシュデータの登録要求があった場合、キャッシュ管理部１３０は図３８に示す処理を実行する。この手順は、図３５に示した第１方式の手順にＳ１４９を追加したものである。すなわち、第３例では、キャッシュ管理部１３０は、Ｓ１４８で登録要求の対象のキャッシュデータをキャッシュメモリ１４０から削除してその領域を解放した後、例えばエントリ管理テーブル１３２の当該エントリの「領域確保」の欄の値を、当該エントリの領域が解放された旨の値「確保済」に変更する。
【０２５５】
この第３方式では、対象エントリに必要なキャッシュ領域が即座には確保されないものの、キャッシュメモリ１４０に割り当てられた容量を超えることはない。
【０２５６】
《混合方式》
以上、３つの方式について説明した。キャッシュ管理部１３０は、それら３つの方式の１つに従って処理を実行してもよいが、それら３つの方式を動的に切り替えながら処理を進めてもよい。このような動的切り替えの手順の一例を、図３９及び図４０に例示する。
【０２５７】
図３９の手順は、図３２の手順のＳ１０６の判定結果がＹＥＳとなった場合の手順であり、図３３の手順にＳ３００及びＳ３０２を追加したものである。したがって、図３３を参照して既に説明したステップについては説明を省略する。
【０２５８】
図３９の手順では、Ｓ１１１Ａの判定結果がＮＯとなった場合、すなわち、使用されていないキャッシュデータを全てキャッシュメモリから削除しても対象エントリに必要なキャッシュ領域が確保できない場合、まずキャッシュ管理部１３０はオペレーティングシステム（ＯＳ）に対し、ＯＳが管理しているメモリの空き容量（あるいは使用率など）を問い合わせる（Ｓ３００）。キャッシュ管理部１３０は、ＯＳが管理するメモリのうちの一部をキャッシュメモリ１４０として割り当ててもらっているが、Ｓ３００ではその割り当てられたメモリ空間を超えて（オーバーフローして）キャッシュメモリ１４０の領域を一時的に拡大できるかどうかを判定するために、メモリの空き容量を問い合わせるのである。そして、キャッシュ管理部１３０は、その結果得られたメモリの空き容量に基づき、ＯＳが管理するメモリに、対象エントリのためのキャッシュ領域分だけキャッシュメモリ１４０のための割当を増やす余裕があるかどうかを判定する（Ｓ３０２）。この判定では、例えば、ＯＳが管理するメモリの空き容量から対象エントリのキャッシュデータサイズを減算し、その減算結果が、ＯＳが適切に動作するためのメモリの空き容量の閾値を超えていれば、「余裕がある」と判定するなどすればよい。
【０２５９】
Ｓ３０２でメモリに余裕があると判定すると、キャッシュ管理部１３０は図３４に示す第１（オーバーフロー）方式の処理を実行する。
【０２６０】
Ｓ３０２でメモリに余裕がないと判定すると、キャッシュ管理部１３０は、第２（即時強制解放）方式又は第３（作成完了後解放）方式を選択する。このための手順の例を図４０に示す。図４０の手順は、図３７（第３方式）の手順に似ている。図４０の手順では、まず、ステージ１“New Cache”で領域確保済の劣位エントリが残っているかどうかを判定する（Ｓ２００）。Ｓ２００の判定結果がＮＯとなった場合は、図３７の手順と同様、Ｓ１２２〜Ｓ１３０の処理を実行する。
【０２６１】
Ｓ２００の判定結果がＹＥＳであれば、未処理で残っているステージ１“New Cache”で領域確保済の劣位エントリの中から最もスコアの低いものを１つ抽出する（Ｓ２０２）。そして、抽出した劣位エントリをステージ１“New Cache”からステージ４“Cached Out”に遷移させ（Ｓ２０４）、この領域を解放したと仮定した場合のキャッシュメモリ１４０の空き容量を計算する。また、抽出した劣位エントリのキャッシュ領域を今すぐに強制的に解放したと仮定した場合のペナルティを評価する（Ｓ３０４）。ここでいう「ペナルティ」は、抽出した各劣位エントリのキャッシュ領域を即時に解放した場合に、それまでそれら劣位エントリのキャッシュデータを作成していた各ＲＩＰ部１２０が被る損害を表す評価値である。
【０２６２】
Ｓ３０４のペナルティ評価には、様々な方式が考えられる。例えば１つの方式として、評価対象の劣位エントリのキャッシュデータのサイズ（このキャッシュデータは作成中であり未だ完成してはいないが、ＰＤＬの記述からキャッシュデータのサイズが計算又は推定され、エントリ管理テーブル１３２に登録されている）に基づいて評価する方式がある。この方式では、キャッシュデータのサイズが大きいほど、そのキャッシュデータの領域をすぐに解放した場合のペナルティが高くなる。これは、大きいキャッシュデータは、再度作成するのにコストがかかるからである。
【０２６３】
また、別の方式では、評価対象の劣位エントリのキャッシュデータの作成の完了率（すなわちキャッシュデータの全体のうち作成が完了した部分の割合）に基づいて評価する。この方式では、キャッシュデータの作成完了率が高いほど、そのキャッシュデータの領域をすぐに解放した場合のペナルティが高くなる。これは、領域解放によりそれまでのキャッシュデータ作成のための処理が無駄になるが、作成完了率が高いほどその無駄が大きくなるためである。なお、この方式のためには、各キャッシュエントリのキャッシュデータの作成完了率は、当該キャッシュデータを作成しているＲＩＰ部１２０から例えば定期的にキャッシュ管理部１３０に通知する。キャッシュ管理部１３０は、通知された作成完了率をエントリ管理テーブル１３２等に登録して管理すればよい。
【０２６４】
また、更に別の方式では、評価対象の劣位エントリのキャッシュデータの作成が完了する時刻の予測値（作成完了予測時刻）に基づいて評価する。この方式では、キャッシュデータの作成完了予測時刻が現在時刻に近いほど、そのキャッシュデータの領域をすぐに解放した場合のペナルティが高くなる。これは、作成完了予測時刻が現在時刻に近いほど、対象エントリのためにその作成完了を待つ時間が短いので、すぐに領域を解放しない方が損が少ない（すなわちペナルティが低い）ためである。なお、この方式のためには、各キャッシュエントリのキャッシュデータを作成しているＲＩＰ部１２０から例えば定期的にキャッシュ管理部１３０に作成完了率を通知し、キャッシュ管理部１３０が、毎回通知される作成完了率の時間的な変化から、作成完了予測時刻を求めればよい。求めた作成完了予測時刻は、エントリ管理テーブル１３２等に登録して管理すればよい。
【０２６５】
また、Ｓ２０４で計算した空き容量が、対象エントリのキャッシュデータを収容するのに十分な大きさかどうかを判定し（Ｓ２０６）、まだ不十分であれば、Ｓ２００に戻り、ステージ１“New Cache”で領域確保済の別の劣位エントリが残っている間は、Ｓ２０２、Ｓ２０４、Ｓ３０４の処理を繰り返す。このような繰り返しによりＳ２０６の判定結果がＹＥＳとなると、キャッシュ管理部１３０は、Ｓ２０２で抽出した領域解放の対象の劣位エントリのすべてについて、Ｓ３０４で計算したペナルティの値があらかじめ定められた閾値より小さいかどうかを判定する（Ｓ３０６）。ある劣位エントリについてのペナルティが閾値より小さい場合、その劣位エントリのために確保したキャッシュ領域をすぐに解放しても、その解放による不利益（例えば解放される領域にキャッシュデータを作成していたＲＩＰ部１２０が再度ＰＤＬデータをＲＩＰ処理することによるコスト）が、対象エントリのためのキャッシュエントリをすぐに確保することによる利益より補ってあまりあるものである可能性が高い。逆に言えば、そのような閾値を実験やシミュレーションによりあらかじめ求めておく。
【０２６６】
Ｓ３０６の判定で、領域解放対象の劣位エントリのペナルティがすべて閾値より小さければ、どの劣位エントリについてもキャッシュ領域を即時解放しても不利益が少ないということである。この場合、キャッシュ管理部１３０は、それら領域解放対象の各劣位エントリのキャッシュデータを作成中のＲＩＰ部１２０に領域解放を行う旨を通知し、それら各劣位エントリのために確保したキャッシュ領域を解放する（Ｓ３０８）。これは第２（即時解放）方式である。そして、Ｓ２０８に進み、対象エントリのための領域をキャッシュメモリ１４０に確保し、要求元のＲＩＰ部１２０に領域確保の旨を示すコードと確保した領域のアドレスの情報を返す。
【０２６７】
一方、Ｓ３０６の判定で、領域解放対象の劣位エントリのなかに１つでもペナルティが閾値以上のものがあれば、キャッシュ領域を即時解放すると不利益が多い劣位エントリが存在するということである。この場合、第３（作成完了後解放）方式を採用する。すなわち、キャッシュ管理部１３０は、領域解放対象のすべての劣位エントリのキャッシュ領域が実際に解放されるのを待ち（Ｓ２０７）、それらすべての劣位エントリの領域が解放された後に、対象エントリのための領域確保を行う（Ｓ２０８）。
【０２６８】
図３９及び図４０の例では、３つの方式を動的に切り替えて使用したが、３つの方式全てを用いる必要はない。別の例として、それら３つの方式のうちの２つを動的に切り替えて使用してもよい。例えば、第１（オーバーフロー）方式と第２（即時強制解放）方式とを動的に切り替える場合は、図３９のＳ３００及びＳ３０２のステップによりどちらの方式を使用するかを判定すればよい。第１方式と第３（作成完了後解放）方式とを動的に切り替える場合も同様である。また第２方式と第３方式とを動的に切り替える場合は、図４０のＳ３０４及びＳ３０６のステップによりどちらの方式を使用するかを判定すればよい。
【０２６９】
以上の例では、第２方式と第３方式を切り替えるのに、Ｓ３０６ですべてのペナルティ値が閾値より小さいか否か、という判定基準を用いたが、これは一例に過ぎない。この代わりに、ペナルティ値が閾値以上である劣位エントリの割合が、あらかじめ定められた割合閾値以下であれば、第２（即時強制解放）方式を採用するなどといった、他の判定基準も考えられる。
【０２７０】
なお、以上に説明した第３例は、上述の第１例に基づく形で説明したが、上述の第２例に基づく例も考えられる。すなわち、第１例と第２例の相違は、ステージが３“Cached”であり且つ使用カウンタの値が０でないキャッシュエントリの追い出し（キャッシュデータの削除）の予約を明示的（第１例）に行うか、暗黙的に行うか（第２例）の相違であり、この相違は、第３例における、ステージ１“New Cache”の領域確保済のキャッシュエントリの領域を解放する処理とは依存関係にない。第３例の領域確保方法を第２例に適用する場合、例えば図３４の手順のうちＳ１２２〜Ｓ１３０のステップ群を、図２３のＳ１２２、Ｓ１２４及びＳ１２５に置き換えればよい。
【０２７１】
［第４例］
《概要》
本発明の実施形態の第４の例を説明する。この第４例の印刷文書変換システムの構成は、図１に示したものと同様でよい。また、エントリ管理テーブル１３２のデータ構造は図２に例示した第１例のものと同様でよい。また、キャッシュエントリの状態遷移も、図３に例示した第１例の状態遷移と同様でよい。
【０２７２】
上述の第１例では、領域確保要求に応じた領域確保処理の際、ステージが３“Cached”で使用カウンタの値が０の劣位エントリのキャッシュデータを全て追い出しても必要な空き容量が確保できない場合、その時点での領域の確保はあきらめ、要求元のＲＩＰ部１２０に対して領域確保の失敗を応答した（例えば図１１のＳ１２４）。
【０２７３】
これに対し、この第４例では、そのような場合に、ステージ３で使用カウンタの値が０でない（すなわちいずれかのＲＩＰ部１２０により使用中）の劣位エントリがあれば、それら劣位エントリのキャッシュデータを追い出す（削除する）ことで領域確保を行う。
【０２７４】
第４例での各ＲＩＰ部１２０の処理手順は、第１例の場合と同様でよい（図４〜図６参照）。
【０２７５】
第４例でのキャッシュ管理部１３０の動作については、いずれかのＲＩＰ部１２０から問合せを受けたときのキャッシュ管理部１３０の処理手順は、第１例と同様でよい（図７参照）。また、いずれかのＲＩＰ部１２０から使用開始要求を受けたときのキャッシュ管理部１３０の処理手順も、第１例と同様でよい（図８参照）。また、クリーニングタイミング到来時及び見直しタイミング到来時の処理も、第１例の場合と同様でよい（図１３及び図１５参照）。
【０２７６】
一方、いずれかのＲＩＰ部１２０から領域確保要求を受けたときのキャッシュ管理部１３０の動作は、第１例（図１０及び図１１参照）及び第２例（図２２及び図２３参照）の場合と異なる。特に領域確保要求に応じた領域確保処理の際、ステージが３“Cached”で使用カウンタの値が０の劣位エントリのキャッシュデータを全て追い出しても必要な空き容量が確保できない場合（第１例では図１１のＳ１１１の判定結果がＮＯの場合、第２例では図２３のＳ１１１の判定結果がＮＯの場合）の処理が、第１例及び第２例の場合と異なってくる。
【０２７７】
領域確保要求に応じた領域確保処理の際、ステージが３“Cached”で使用カウンタの値が０の劣位エントリのキャッシュデータを全て追い出しても必要な空き容量が確保できない場合における、この第４例の処理については、例えば以下の３つの方式がある。以下、それら３つの方式の処理手順の例を順に説明する。
【０２７８】
《第１方式：一時的オーバーフロー方式》
この第４例の第１方式では、いずれかのＲＩＰ部１２０から領域確保要求を受けたとき、キャッシュ管理部１３０は、図１０に示す第１例の手順と同じ動作を行う。この手順を実行する中で、Ｓ１０６で劣位エントリありと判定されると、この第１方式では、キャッシュ管理部１３０は、図４１に示す手順を実行する。図４１の手順のうち、Ｓ１１１〜Ｓ１１８及びＳ１２６〜Ｓ１３０は、図１１に示される第１例の場合と同様である。
【０２７９】
図４１の手順が図１１の手順と異なるのは、まず、Ｓ１１１でステージが３“Cached”で使用カウンタの値が０の劣位エントリがなくなったと判定された後、Ｓ１２２及びＳ１２４の処理（対象エントリをステージ２“Caching”に遷移、及び確保失敗を応答）を行わない点である。また、別の異なる点は、Ｓ１３０で必要な容量が確保できたと判定すると、キャッシュ管理部１３０は、対象エントリのための領域をキャッシュメモリ１４０に確保し、要求元のＲＩＰ部１２０に領域確保の旨を示すコードと確保した領域のアドレスの情報を返す（Ｓ１３２）点である。
【０２８０】
すなわち、Ｓ１２８では、使用中の劣位エントリのステージを４“Cached Out”に遷移させるだけで、それら使用中の劣位エントリのキャッシュデータをキャッシュメモリ１４０から追い出すことはしない。Ｓ１３０でキャッシュメモリ１４０に必要な空き容量が確保できたと判定されたとしても、それはそれら使用中の劣位エントリのキャッシュデータを追い出したと仮定した場合のことである。このため、Ｓ１３２を実行する時点では、キャッシュメモリ１４０の空き容量は、実際には対象エントリのために必要な量よりも少ない。したがって、Ｓ１３２で行っているのは、まだ実際には追い出されていない劣位エントリ（追い出し予約された劣位エントリ）の容量が、近い将来、その使用が終了した時点で追い出されることを見込んで、対象エントリのための領域を確保してしまうことである。このため、Ｓ１３２での領域の確保は、オペレーティングシステムからキャッシュメモリ１４０に割り当てられた全体容量の制限を一時的に超える（オーバーフローする）形で行う。すなわち、キャッシュ管理部１３０及びキャッシュメモリ１４０を実現するコンピュータのオペレーティングシステムは、自身が管理するメモリ空間の一部をキャッシュメモリ１４０に割り当てており、Ｓ１３２ではその割り当てられた領域からはみ出して対象エントリのためのキャッシュ領域を確保するのである。このような確保処理により、キャッシュメモリ１４０として実際に使用される領域のサイズは、本来割り当てられたキャッシュメモリサイズを超えることとなるが、このオーバーフロー状態は追い出し予約された劣位エントリ群のキャッシュデータの作成が完了するまでの一時的な状態に過ぎない。
【０２８１】
煩雑さを避けるために図４１では省略したが、使用カウンタが０でない劣位エントリの全てをステージ４“Cached Out”にしても、対象エントリをキャッシュするのに十分な容量が確保できない場合も起こり得る。このような場合、キャッシュ管理部１３０は、例えば、領域確保要求に対して確保失敗を応答すればよい。
【０２８２】
この第１方式では、対象エントリのための領域確保を要求したＲＩＰ部１２０は、ステージ３の劣位エントリの領域を解放すれば必要な容量が得られる場合には、即座にキャッシュ領域の割当を受けることとなる。
【０２８３】
また、この第１方式では、Ｓ１２８で追い出しの予約がなされたキャッシュエントリについての領域の解放を、第１例と同様、図１３又は図１４に例示した手順により行えばよい。追い出し予約された劣位エントリのキャッシュデータが図１３又は図１４の手順により実際にキャッシュメモリ１４０から追い出されることにより、キャッシュメモリ１４０のオーバーフロー状態が解消される。
【０２８４】
《第２方式：即時強制追い出し方式》
この第４例の第２方式は、対象エントリのための領域を即座に確保する点では上述の第１方式と同じである。しかし、第１方式では対象エントリのための領域を、キャッシュメモリ１４０に割り当てられた容量をオーバーフローするように確保することで、使用中の劣位エントリを実際には追い出さなかった（追い出しの予約をするのみであった）のに対し、この第２方式では、そのようなオーバーフローを避けるために、使用中の劣位エントリを実際に追い出してから、対象エントリのための領域を確保する。ここで、使用中の劣位エントリを実際に追い出すと、その劣位エントリのキャッシュデータを使用しているＲＩＰ部１２０は、ＲＩＰ処理を続けることができなくなるので、この第２方式では、追い出す劣位エントリのキャッシュデータを使用中のＲＩＰ部１２０に対し、そのキャッシュデータを削除する旨を通知する。これに応じ、そのＲＩＰ部１２０は、削除されるキャッシュデータに対応するオブジェクトの元のＰＤＬデータをＲＩＰ処理する。
【０２８５】
このような処理のために、この第２方式では、例えば、エントリ管理テーブル１３２に対し、図４２に例示するように、「使用中のＲＩＰ」を記録する。「使用中のＲＩＰ」には、当該キャッシュエントリのキャッシュデータを使用している（すなわち当該キャッシュデータに対する使用開始要求を発した後、使用終了通知を発するまでの期間にある）ＲＩＰ部１２０の識別情報が登録される。１つのキャッシュエントリのキャッシュデータを使用しているＲＩＰ部１２０が複数あれば、それら使用している複数のＲＩＰ部１２０すべての識別情報が登録される。キャッシュデータがキャッシュメモリ１４０内にないキャッシュエントリ（ステージ３“Cached”以外のステージのエントリ）については、「使用中のＲＩＰ」は空欄である。ステージが３“Cached”であるキャッシュエントリも、どのＲＩＰ部１２０からも使用されていない期間は、「使用中のＲＩＰ」は空欄である。
【０２８６】
「使用中のＲＩＰ」欄の保守のために、キャッシュ管理部１３０は、いずれかのＲＩＰ部１２０からキャッシュデータの使用開始要求が到来すると、図４３に例示するように、キャッシュデータを登録し（Ｓ８０）、使用カウンタの値を１増加させるとともに（Ｓ８２）、要求元のＲＩＰ部１２０の識別情報を当該キャッシュエントリの「使用中のＲＩＰ」欄に追加する（Ｓ８３）。また、キャッシュ管理部１３０は、いずれかのＲＩＰ部１２０からキャッシュデータの使用終了通知が到来すると、図４４に例示するように、使用カウンタの値を１減少させるとともに（Ｓ８５）、通知元のＲＩＰ部１２０の識別情報を当該キャッシュエントリの「使用中のＲＩＰ」欄から削除する（Ｓ８７）。
【０２８７】
また、この第４例の第２方式では、いずれかのＲＩＰ部１２０から領域確保要求を受けたとき、キャッシュ管理部１３０は、図１０に示す第１例の手順と同じ動作を行う。この手順を実行する中で、Ｓ１０６で劣位エントリありと判定されると、この第２方式では、キャッシュ管理部１３０は、図４５に示す手順を実行する。図４５の手順は、Ｓ１２７及びＳ１２８Ａ及びＳ１３２Ａ以外は、上述の第１方式の場合の手順（図４１）と同様である。
【０２８８】
すなわち、図４５の手順は、Ｓ１１１でステージが３“Cached”で使用カウンタの値が０の劣位エントリがなくなったと判定された後、Ｓ１２２及びＳ１２４の処理（対象エントリをステージ２“Caching”に遷移、及び確保失敗を応答）を行わない点では、上述の第１方式の手順（図４１）と同じである。図４５の手順が図４１の手順と異なる点は、Ｓ１２６の後、Ｓ１２７にて抽出したキャッシュエントリの「使用中のＲＩＰ」欄に登録された各ＲＩＰ部１２０に対して、そのエントリのキャッシュデータの使用中止（及び元のＰＤＬデータからの再ＲＩＰ処理）を指示する点、及びＳ１２８Ａにてそのエントリのステージを４に変更するのに加え、そのエントリのキャッシュデータを実際にキャッシュメモリ１４０から削除し、そのデータの領域を解放してしまう点である。
【０２８９】
このように、この第２方式では実際にキャッシュデータが削除されて領域が解放されているので、図４５の手順におけるＳ１３２Ａでは、対象エントリのためのキャッシュ領域をそれら空いた領域から確保すればよい。したがって、オペレーティングシステムからキャッシュメモリ１４０として割り当てられた範囲を超えてキャッシュ領域を確保する必要はない。この第２方式では、対象エントリに必要なキャッシュ領域が即座に確保される。なお、キャッシュ領域を強制解放されたステージ１の劣位エントリは、対象エントリよりもスコアが低いので、対象エントリのキャッシュをあきらめるより、劣位エントリの使用中のキャッシュデータの領域を解放した方が、キャッシュの利用効率の点では有利な場合が少なくない。
【０２９０】
《第３方式：使用完了後追い出し方式》
前述の第１方式では、ステージ４に遷移させた劣位エントリの使用が終了してデータが削除されるのを待たず、キャッシュメモリ１４０に割り当てられた容量からオーバーフローする形で対象エントリのための領域確保（Ｓ１３２）を行った。これに対し、この第３方式では、図４６に示すように、キャッシュメモリ１４０のオーバーフローは、それらステージ４に遷移させたすべての劣位エントリの使用の終了を待ち（Ｓ１３１）、その後それらすべての劣位エントリの領域が解放された後に、対象エントリのための領域確保を行う（Ｓ１３２Ａ）。ここで、Ｓ１３１では、Ｓ１２６〜Ｓ１３０の繰り返しの中でステージを４“Cached Out”に変更した各劣位エントリを記憶しておき、それら各劣位エントリの使用カウンタを例えば定期的に監視し、それら劣位エントリの全ての使用カウンタの値が０になったときに、それら劣位エントリの使用が全て終了したと判定する。
【０２９１】
なお、図４６の手順では、Ｓ１２８では、劣位エントリのステージを３“Cached”から４“Cached Out”に変更するが、第２方式のＳ１２８Ａとは異なり、キャッシュデータの削除は行わない。
【０２９２】
この第３方式では、対象エントリに必要なキャッシュ領域は、ステージ４に変更した劣位エントリ群の使用が終了するまでは確保されないものの、キャッシュメモリ１４０に割り当てられた容量を超えることはない。
【０２９３】
《混合方式》
以上、３つの方式について説明した。キャッシュ管理部１３０は、それら３つの方式の１つに従って処理を実行してもよいが、それら３つの方式を動的に切り替えながら処理を進めてもよい。このような動的切り替えの手順の一例を、図４７及び図４８に例示する。
【０２９４】
図４７の手順は、図１０の手順のＳ１０６の判定結果がＹＥＳとなった場合の手順であり、図４１の手順にＳ３２０及びＳ３２２を追加したものである。したがって、図４１を参照して既に説明したステップについては説明を省略する。
【０２９５】
図４１の手順では、Ｓ１１１の判定結果がＮＯとなった場合、すなわち、使用されていないキャッシュデータを全てキャッシュメモリから削除しても対象エントリに必要なキャッシュ領域が確保できない場合、まずキャッシュ管理部１３０はオペレーティングシステム（ＯＳ）に対し、ＯＳが管理しているメモリの空き容量（あるいは使用率など）を問い合わせる（Ｓ３２０）。キャッシュ管理部１３０は、ＯＳが管理するメモリのうちの一部をキャッシュメモリ１４０として割り当ててもらっているが、Ｓ３２０ではその割り当てられたメモリ空間を超えて（オーバーフローして）キャッシュメモリ１４０の領域を一時的に拡大できるかどうかを判定するために、メモリの空き容量を問い合わせるのである。そして、キャッシュ管理部１３０は、その結果得られたメモリの空き容量に基づき、ＯＳが管理するメモリに、対象エントリのためのキャッシュ領域分だけキャッシュメモリ１４０のための割当を増やす余裕があるかどうかを判定する（Ｓ３２２）。この判定では、例えば、ＯＳが管理するメモリの空き容量から対象エントリのキャッシュデータサイズを減算し、その減算結果が、ＯＳが適切に動作するためのメモリの空き容量の閾値を超えていれば、「余裕がある」と判定するなどすればよい。Ｓ３２２でメモリに余裕があると判定すると、キャッシュ管理部１３０は、Ｓ１２６〜Ｓ１３２に示す第１（オーバーフロー）方式の処理を実行する。
【０２９６】
Ｓ３２２でメモリに余裕がないと判定すると、キャッシュ管理部１３０は、第２（即時強制追い出し）方式と第３（使用完了後追い出し）方式との選択を行う。このための手順の例を図４８に示す。図４８の手順では、劣位エントリ（ステージ３）の中から最もスコアの低いものを１つ抽出する（Ｓ１２６）。そして、抽出した劣位エントリをステージ４“Cached Out”に遷移させ（Ｓ１２８）、その劣位エントリのキャッシュデータを追い出してキャッシュ領域を解放したと仮定した場合のキャッシュメモリ１４０の空き容量を計算する。また、その劣位エントリのキャッシュデータを今すぐに強制的に追い出すと仮定した場合のペナルティを評価する（Ｓ３２４）。ここでいう「ペナルティ」は、抽出した各劣位エントリのキャッシュデータを即時に追い出した場合に、それまでそれら劣位エントリのキャッシュデータを使用していた各ＲＩＰ部１２０が被る損害を表す評価値である。
【０２９７】
Ｓ３２４のペナルティ評価には、様々な方式が考えられる。例えば１つの方式として、評価対象の劣位エントリのキャッシュデータのサイズに基づいて評価する方式がある。この方式では、キャッシュデータのサイズが大きいほど、そのキャッシュデータを追い出す場合のペナルティが高くなる。即時強制追い出し方式の場合、使用されているキャッシュデータを追い出してしまうことになり、これによりそのキャッシュデータを使用中のＲＩＰ部１２０は、そのキャッシュデータに対応するＰＤＬデータをＲＩＰ処理する必要がある。一般にキャッシュデータが大きいほどＲＩＰ処理に時間がかかるので、ペナルティを高くする。
【０２９８】
また、別の方式では、評価対象の劣位エントリのキャッシュデータを使用している各ＲＩＰ部１２０についての、そのキャッシュデータの読み出し完了率（すなわちキャッシュデータの全体のうち読み出しが完了した部分の割合）に基づいて評価する。この方式では、キャッシュデータの読み出し完了率が高いほど、そのキャッシュデータをすぐに追い出した場合のペナルティが高くなる。これは、追い出しによりそれまでのキャッシュデータの読み出し処理が無駄になるが、読み出し完了率が高いほどその無駄が大きくなるためである。１つの劣位エントリのキャッシュデータを使用しているＲＩＰ部１２０が複数ある場合は、個々のＲＩＰ部１２０についてペナルティを求める。なお、この方式のために、キャッシュ管理部１３０は、ＲＩＰ部１２０ごとに、当該ＲＩＰ部１２０に現在キャッシュデータを提供しているキャッシュエントリと、そのキャッシュデータのうち提供済の割合（すなわちＲＩＰ部１２０から見れば読み出し完了率）とを例えば定期的に記録する。
【０２９９】
また、更に別の方式では、評価対象の劣位エントリのキャッシュデータの使用が完了する時刻の予測値（使用完了予測時刻）に基づいて評価する。１つの劣位エントリのキャッシュデータを使用しているＲＩＰ部１２０が複数ある場合は、個々のＲＩＰ部１２０ごとに、使用完了予測時刻を求め、その使用完了予測時刻からペナルティ値を求める。この方式では、キャッシュデータの使用完了予測時刻が現在時刻に近いほど、そのキャッシュデータをすぐに追い出した場合のペナルティが高くなる。これは、使用完了予測時刻が現在時刻に近いほど、対象エントリのためにその使用の完了を待つ時間が短いので、すぐに追い出さない方が損が少ない（すなわちペナルティが低い）ためである。なお、この方式のためには、キャッシュ管理部１３０は、ＲＩＰ部１２０ごとに、当該ＲＩＰ部１２０に現在キャッシュデータを提供しているキャッシュエントリと、そのキャッシュデータのうち提供済の割合（すなわちＲＩＰ部１２０から見れば読み出し完了率）とを例えば定期的に記録し、その読み出し完了率の時間的な変化から、読み出し完了予測時刻を求めればよい。
【０３００】
また、Ｓ１２８で計算した空き容量が、対象エントリのキャッシュデータを収容するのに十分な大きさかどうかを判定し（Ｓ１３０）、まだ不十分であれば、Ｓ１２６に戻り、スコアの低い別の劣位エントリが残っている間は、Ｓ１２６、Ｓ１２８、Ｓ３２４の処理を繰り返す。このような繰り返しによりＳ１３０の判定結果がＹＥＳとなると、キャッシュ管理部１３０は、Ｓ１２６で抽出した追い出し対象の劣位エントリのすべてについて、Ｓ３２４で計算したペナルティの値があらかじめ定められた閾値より小さいかどうかを判定する（Ｓ３２６）。ある劣位エントリについてのペナルティが閾値より小さい場合、その劣位エントリのキャッシュデータをすぐに追い出しても、その追い出しによる不利益（例えば追い出したキャッシュデータを使用していたＲＩＰ部１２０が再度ＰＤＬデータをＲＩＰ処理することによるコスト）が、対象エントリのためのキャッシュエントリをすぐに確保することによる利益よりも少ない可能性が高い。逆に言えば、そのような閾値を実験やシミュレーションによりあらかじめ求めておく。
【０３０１】
Ｓ３２６の判定で、領域解放対象の劣位エントリのペナルティがすべて閾値より小さければ、どの劣位エントリについてもキャッシュデータを即時追い出しても不利益が少ないということである。この場合、即時強制追い出し方式を採用する。すなわち、キャッシュ管理部１３０は、それら追い出し対象の各劣位エントリのキャッシュデータを使用中の各ＲＩＰ部１２０にそのデータの使用中止の指示を通知し、それら各劣位エントリのキャッシュデータを追い出して、それらキャッシュデータがそれまで占めていたキャッシュ領域を解放する（Ｓ３２８）。そして、Ｓ１３２に進み、対象エントリのための領域をキャッシュメモリ１４０に確保し、要求元のＲＩＰ部１２０に領域確保の旨を示すコードと確保した領域のアドレスの情報を返す。
【０３０２】
一方、Ｓ３２６の判定で、追い出し対象の劣位エントリのなかに１つでもペナルティが閾値以上のものがあれば、キャッシュデータをすぐに追い出すと不利益が多い劣位エントリが存在するということである。この場合、第３（使用完了後追い出し）方式を採用する。すなわち、キャッシュ管理部１３０は、追い出し対象のすべての劣位エントリのキャッシュデータを使用しているすべてのＲＩＰ部１２０がその使用を完了するのを待ち（Ｓ１３１）、それらすべての劣位エントリの領域が解放された後に、対象エントリのための領域確保を行う（Ｓ１３２）。
【０３０３】
以上の例では、第２方式と第３方式を切り替えるのに、Ｓ３２６ですべてのペナルティ値が閾値より小さいか否か、という判定基準を用いたが、これは一例に過ぎない。この代わりに、ペナルティ値が閾値以上である劣位エントリの割合が、あらかじめ定められた割合閾値以下であれば、第２（即時強制追い出し）方式を採用するなどといった、他の判定基準も考えられる。
【０３０４】
図４７及び図４８の例では、３つの方式を動的に切り替えて使用したが、３つの方式全てを用いる必要はない。別の例として、それら３つの方式のうちの２つを動的に切り替えて使用してもよい。例えば、第１（オーバーフロー）方式と第２（即時強制追い出し）方式とを動的に切り替える場合は、図４７のＳ３２０及びＳ３２２のステップによりどちらの方式を使用するかを判定すればよい。第１方式と第３（使用完了後追い出し）方式とを動的に切り替える場合も同様である。また第２方式と第３方式とを動的に切り替える場合は、図４８のＳ３２４及びＳ３２６のステップによりどちらの方式を使用するかを判定すればよい。
【０３０５】
以上に例示した印刷文書変換システム１００、またはこれを構成するジョブ管理部１１０、ＲＩＰ部１２０及びキャッシュ管理部１３０は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカル・エリア・ネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。
【符号の説明】
【０３０６】
１００ 印刷文書変換システム、１１０ ジョブ管理部、１１２ ページ割当部、１１４ 負荷監視部、１２０ ＲＩＰ部、１３０ キャッシュ管理部、１３２ エントリ管理テーブル、１４０ キャッシュメモリ、２００ ホストコンピュータ、２１０ 印刷制御装置、２２０ プリンタエンジン。

【特許請求の範囲】
【請求項１】
キャッシュ装置と、複数のデータ処理装置と、を備え、
前記キャッシュ装置は、
前記各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、
印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段と、
前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、前記データ処理装置にその旨を示す「作成中」応答を提供する応答提供手段と、
を備え、
前記複数のデータ処理装置の各々は、
前記印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段と、
前記印刷文書データ内の文書要素ごとに、当該文書要素の画像データを前記画像データ作成手段に作成させる前に、当該画像データが前記キャッシュ装置内にあるか否かの問合せを行う問合せ手段と、
前記問合せ手段による問合せに対する前記キャッシュ装置からの応答が前記「作成中」応答であった場合、当該画像データの作成の完了を待って当該画像データを使用するか、当該完了を待たずに前記画像データ作成手段に当該文書要素の画像データの作成を実行させるかを、あらかじめ定められた条件に応じて制御する制御手段と、
を備える、
ことを特徴とする印刷文書処理システム。
【請求項２】
前記制御手段は、
前記「作成中」応答を受けた場合、前記画像データの作成の完了を待ってその画像データを使用する第１の方式と、当該完了を待たずに当該文書要素の画像データの作成を実行する第２の方式と、のどちらを選択した方がその画像データをページの印刷画像データに対して早く合成できるかについての評価演算を行う評価演算手段、
を備え、前記評価手段により早く合成できると評価された方式に従って制御を行う、ことを特徴とする請求項１に記載の印刷文書処理システム。
【請求項３】
前記制御手段は、前記「作成中」応答を受けた場合において、当該制御手段を備える画像データ処理装置の処理負荷があらかじめ定められた閾値よりも高い場合に、前記評価演算手段による評価演算を実行せず、前記第１の方式に従って制御を行う、ことを特徴とする請求項２に記載の印刷文書処理システム。
【請求項４】
前記各データ処理装置の処理能力の情報を記憶する処理能力情報記憶手段を更に備え、
前記状態記憶手段は、前記「作成中」状態にある各文書要素の画像データを作成中のデータ処理装置を示す情報を更に記憶し、
前記データ処理装置の前記評価手段は、前記「作成中」応答を受けた場合において、前記処理能力情報記憶手段から得た当該データ処理装置の処理能力及び当該文書要素の画像データを作成中のデータ処理装置の処理能力に基づき、前記評価演算を行う、
ことを特徴とする請求項２又は３のいずれか１項に記載の印刷文書処理システム。
【請求項５】
前記各データ処理装置の処理負荷の情報を計算する処理負荷計算手段を更に備え、
前記状態記憶手段は、前記「作成中」状態にある各文書要素の画像データを作成中のデータ処理装置を示す情報を更に記憶し、
前記データ処理装置の前記評価手段は、前記「作成中」応答を受けた場合において、前記処理能力負荷計算手段から得た当該データ処理装置の処理負荷及び当該文書要素の画像データを作成中のデータ処理装置の処理負荷に基づき、前記評価演算を行う、
ことを特徴とする請求項２〜４のいずれか１項に記載の印刷文書処理システム。
【請求項６】
前記データ処理装置の前記評価手段が実行する評価演算では、前記第１の方式については、前記文書要素の画像データをキャッシュメモリから当該データ処理装置に転送するのに要する時間及びその画像データをビットマップ形式にしてページの印刷画像データに合成するのに要する第１の予測時間を、前記第２の方式については、当該文書要素のページ記述言語のデータを処理してビットマップ形式の画像データを作成してページの印刷画像データに合成するのに要する第２の予測時間を、それぞれ計算し、前記第１の予測時間と前記第２の予測時間との比較により、当該文書要素の画像データをページの印刷画像データに対して早く合成できる方式を求める、
ことを特徴とする請求項２〜５のいずれか１項に記載の印刷文書処理システム。
【請求項７】
前記応答提供手段は、前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれのデータ処理装置も当該画像データを作成していない「非作成中」状態である場合に、前記データ処理装置にその旨を示す「非作成中」応答を提供すると共に、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態を「作成中」状態へと変更し、
前記制御手段は、前記問合せ手段による問合せに対する前記キャッシュ装置からの応答が前記「非作成中」応答であった場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを前記キャッシュ装置に記憶させるための処理を行う、
ことを特徴とする請求項１〜６のいずれか１項に記載の印刷文書処理システム。
【請求項８】
前記キャッシュ装置は、
各文書要素のキャッシュ優先度を記憶するキャッシュ優先度記憶手段と、
前記データ処理装置から文書要素の画像データを前記キャッシュメモリに記憶するための要求を受けた場合において、当該文書要素よりもキャッシュ優先度が低い文書要素であって画像データがいずれのデータ処理装置も使用中でない文書要素の画像データをすべて追い出したとしても前記キャッシュメモリの空き容量が当該画像データを記憶するのに足りない場合には、前記画像処理装置に対してキャッシュ記憶不可の旨を示す応答を提供する第２の応答提供手段と、
を更に備え、
前記データ処理装置の前記制御手段は、前記要求に対する前記キャッシュ装置からの応答が前記キャッシュ記憶不可を示す応答であった場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データを前記キャッシュ装置に記憶させずに破棄する処理を行う、
ことを特徴とする請求項７に記載の印刷文書処理システム。
【請求項９】
前記第２の応答提供手段は、
前記データ処理装置から文書要素の画像データを前記キャッシュメモリに記憶するための要求を受けた場合において、当該文書要素よりもキャッシュ優先度が低くかつ画像データがいずれのデータ処理装置からも使用中でないすべての文書要素の画像データをすべて追い出したとしても前記キャッシュメモリの空き容量が当該画像データを記憶するのに足りない場合には、前記要求の対象の文書要素のキャッシュ状態を「非作成中」状態に設定する、
ことを特徴とする請求項８に記載の印刷文書処理システム。
【請求項１０】
各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、
印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段と、
前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、前記データ処理装置にその旨を示す「作成中」応答を提供する応答提供手段と、
を備えるキャッシュ装置。
【請求項１１】
印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段と、
前記印刷文書データ内の文書要素ごとに、当該文書要素の画像データを前記画像データ作成手段に作成させる前に、当該画像データがキャッシュ装置内にあるか否かの問合せを行う問合せ手段と、
前記問合せ手段による問合せに対する前記キャッシュ装置からの応答が、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態で有る旨を示す「作成中」応答であった場合、当該画像データの作成の完了を待って当該画像データを使用するか、当該完了を待たずに前記画像データ作成手段に当該文書要素の画像データの作成を実行させるかを、あらかじめ定められた条件に応じて制御する制御手段と、
を備えるデータ処理装置。
【請求項１２】
コンピュータを、
各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリ、
印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段、
前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、前記データ処理装置にその旨を示す「作成中」応答を提供する応答提供手段、
として機能させるためのプログラム。
【請求項１３】
コンピュータを、
印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段、
前記印刷文書データ内の文書要素ごとに、当該文書要素の画像データを前記画像データ作成手段に作成させる前に、当該画像データがキャッシュ装置内にあるか否かの問合せを行う問合せ手段、
前記問合せ手段による問合せに対する前記キャッシュ装置からの応答が、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態で有る旨を示す「作成中」応答であった場合、当該画像データの作成の完了を待って当該画像データを使用するか、当該完了を待たずに前記画像データ作成手段に当該文書要素の画像データの作成を実行させるかを、あらかじめ定められた条件に応じて制御する制御手段、
として機能させるためのプログラム。
【請求項１４】
キャッシュ装置と、複数のデータ処理装置と、を備え、
前記キャッシュ装置は、
前記各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、
印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段と、
前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、当該画像データの作成の完了を待って当該データ処理装置にその画像データを提供する第１の方式と、当該完了を待たずに当該データ処理装置に当該文書要素の画像データの作成を開始させる第２の方式と、のどちらを選択した方が当該データ処理装置がその画像データをページの印刷画像データを早く合成できるかを評価し、より早く合成できると評価された方式が第１の方式である場合は、当該文書要素の画像データの作成が完了するのを待って第１の応答を当該データ処理装置に提供し、より早く合成できると評価された方式が前記第２の方式である場合は当該文書要素の画像データの作成が完了するのを待たずに第２の応答を当該データ処理装置に提供する応答提供手段と、
を備え、
前記複数のデータ処理装置の各々は、
前記印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段と、
前記印刷文書データ内の文書要素ごとに、当該文書要素の画像データを前記画像データ作成手段に作成させる前に、当該画像データが前記キャッシュ装置内にあるか否かの問合せを行う問合せ手段と、
前記問合せ手段による問合せに応じて、前記キャッシュ装置から前記第１の応答を得た場合は前記キャッシュ装置から当該画像データを取得して使用し、前記キャッシュ装置から前記第２の応答を得た場合は、前記画像データ作成手段に当該画像データを作成させるよう制御する制御手段と、
を備える、
ことを特徴とする印刷文書処理システム。
【請求項１５】
各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、
印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段と、
前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、当該画像データの作成の完了を待って当該データ処理装置にその画像データを提供する第１の方式と、当該完了を待たずに当該データ処理装置に当該文書要素の画像データの作成を開始させる第２の方式と、のどちらを選択した方が当該データ処理装置がその画像データをページの印刷画像データに早く合成できるかを評価し、より早く合成できると評価された方式が第１の方式である場合は、当該文書要素の画像データの作成が完了するのを待って第１の応答を当該データ処理装置に提供し、より早く合成できると評価された方式が前記第２の方式である場合は当該文書要素の画像データの作成が完了するのを待たずに第２の応答を当該データ処理装置に提供する応答提供手段と、
を備えるキャッシュ装置。
【請求項１６】
コンピュータを、
各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリ、
印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データの前記キャッシュメモリにおけるキャッシュ状態があらかじめ定義された複数の状態のうちのいずれであるかを記憶する状態記憶手段であって、前記複数の状態の中には、当該文書要素の画像データが前記キャッシュメモリ内になく且ついずれかのデータ処理装置が当該画像データの作成中である「作成中」状態が含まれることを特徴とする状態記憶手段、
前記データ処理装置から文書要素の画像データの問合せを受けた場合において、前記状態記憶手段に記憶された当該文書要素の画像データのキャッシュ状態が前記「作成中」状態である場合には、当該画像データの作成の完了を待って当該データ処理装置にその画像データを提供する第１の方式と、当該完了を待たずに当該データ処理装置に当該文書要素の画像データの作成を開始させる第２の方式と、のどちらを選択した方が当該データ処理装置がその画像データをページの印刷画像データを早く合成できるかを評価し、より早く合成できると評価された方式が第１の方式である場合は、当該文書要素の画像データの作成が完了するのを待って第１の応答を当該データ処理装置に提供し、より早く合成できると評価された方式が前記第２の方式である場合は当該文書要素の画像データの作成が完了するのを待たずに第２の応答を当該データ処理装置に提供する応答提供手段、
として機能させるためのプログラム。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４６】

【図４７】

【図４８】

【公開番号】特開２０１２−１１８７３８（Ｐ２０１２−１１８７３８Ａ）
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１０−２６７５４２（Ｐ２０１０−２６７５４２）
【出願日】平成２２年１１月３０日（２０１０．１１．３０）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【Ｆターム（参考）】