JP5648449B2 - 印刷文書処理システム、キャッシュ装置及びプログラム - Google Patents

Description

本発明は、印刷文書処理システム、キャッシュ装置及びプログラムに関する。

一般に、パーソナルコンピュータから印刷装置に送られる印刷文書データは、ＰｏｓｔＳｃｒｉｐｔ（登録商標）やＰＤＦ( Portable Data Format: ISO 32000-1) などのページ記述言語（以下、ＰＤＬと呼ぶ。ＰＤＬはPage Description Languageの略）で記述されている。印刷装置では、ＲＩＰ( Raster Image Processor)と呼ばれるデータ処理装置により印刷文書データをビットマップ形式（ラスター形式とも呼ばれる）の画像データに変換し、その画像データをプリントエンジンにより印刷する。また、ＰＤＬデータを直接ラスター画像に変換する方式の他に、ＰＤＬデータをＰＤＬコマンドよりは粒度の小さいディスプレイリスト等の中間言語形式のデータに変換してバッファし、バッファした中間言語形式のデータをビットマップ形式に変換するという２段階の変換を行う印刷装置もよく知られている。

従来、ＰＤＬデータからビットマップ形式又は中間言語形式の画像データへの変換を、ページ単位などのあらかじめ定められた単位ごとに、複数のデータ処理装置で並列的に実行するシステムも知られている。

また、従来、あるデータ処理装置が印刷文書データ中のＰＤＬで記述された文書要素（オブジェクト）をビットマップ形式又は中間言語形式へ変換した場合に、その変換結果のデータを文書要素の識別情報と対応づけてキャッシュメモリにキャッシュし、後で同じ又は異なるデータ処理装置が同じ文書要素を変換する必要が生じた場合には、キャッシュされたデータを使用することで、変換処理を省略することも行われている。

例えば、特許文献１には、複数の描画プロセッサにより印刷データの描画処理を並列して行う装置が開示されている。この装置は、各描画プロセッサにて描画処理されたフォーム等のビットマップデータを、印刷機構制御プロセッサ内の共通のキャッシュメモリにてキャッシュするように構成されている。

特開２０００−３３５０２２号公報

ところで、データ処理装置が作成した画像データをキャッシュメモリに記憶しようとする際に空き容量が足りない場合、例えば使用中でない画像データをキャッシュメモリから追い出す（削除する）ことにより空き容量を広げることが考えられる。しかし、使用中でない画像データを削除しただけでは、新たに記憶しようとする画像データに見合った十分な空き容量を確保できない場合も生じ得る。

本発明は、文書要素の画像データのための記憶領域をキャッシュメモリ内に確保する際に、使用中でない画像データをキャッシュメモリから追い出すだけよりも更に多くの空き容量を作ることができるようにすることを目的とする。

請求項１に係る発明は、キャッシュ装置と、複数のデータ処理装置と、を備え、前記複数のデータ処理装置の各々は、印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段と、前記画像データ作成手段が作成する前記画像データのための記憶領域を確保するための確保要求を前記キャッシュ装置に送信する確保要求送信手段と、を備え、前記キャッシュ装置は、前記各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、前記印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データのための記憶領域が前記キャッシュメモリ内に確保済であるか否か、及び、当該文書要素の画像データが前記キャッシュメモリに確保された記憶領域に既に記憶されているか否か、を含むキャッシュ状態の情報を記憶する状態記憶手段と、前記データ処理装置から文書要素の画像データのための記憶領域を確保するための確保要求を受けた際に、画像データの記憶領域が確保済であり且つ画像データが前記キャッシュメモリに確保された記憶領域に記憶されていない文書要素である確保済要素から選ばれた解放対象の記憶領域を解放することにより当該記憶領域を確保する領域確保手段と、を備える、ことを特徴とする印刷文書処理システムである。

請求項２に係る発明は、前記領域確保手段は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記確保済要素のうち、前記確保要求の対象である文書要素よりもキャッシュ優先度が低い文書要素の記憶領域を前記解放対象として選択する、ことを特徴とする請求項１に記載の印刷文書処理システムである。

請求項３に係る発明は、前記データ処理装置は、前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、を更に備え、前記領域確保手段は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐには解放せずに、前記キャッシュ装置を管理するオペレーティングシステムから前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保し、前記解放対象に選択した確保済要素について前記データ処理装置から画像データの登録を要求されたときに、当該文書要素のための確保済の記憶領域を解放する、ことを特徴とする請求項１又は２に記載の印刷文書処理システムである。

請求項４に係る発明は、前記領域確保手段は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐに解放し、記憶領域を解放した確認済要素についての画像データを作成中のデータ処理装置に対して、作成した画像データを前記キャッシュ装置に登録しないよう指示する、ことを特徴とする請求項１又は２に記載の印刷文書処理システムである。

請求項５に係る発明は、前記データ処理装置は、前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、を更に備え、前記領域確保手段は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択したすべての確保済要素について画像データの登録の要求を受けたときに、それら解放対象の確保済要素の画像データの記憶領域を解放し、この解放の後、前記データ処理装置に対して確保成功の旨を応答する、ことを特徴とする請求項１又は２に記載の印刷文書処理システムである。

請求項６に係る発明は、前記データ処理装置は、前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、を更に備え、前記領域確保手段は、前記キャッシュ装置を管理するオペレーティングシステムが管理するメモリの空き容量に基づき、前記確保要求の対象の文書要素の画像データの記憶領域を、前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保できるか否か判定し、確保できる場合は第１の方式を、確保できない場合は第２の方式を採用し、前記第１の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐには解放せずに、前記キャッシュ装置を管理するオペレーティングシステムから前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保し、前記解放対象に選択した確保済要素について前記データ処理装置から画像データの登録を要求されたときに、当該文書要素のための確保済の記憶領域を解放する、という方式であり、前記第２の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐに解放し、記憶領域を解放した確認済要素についての画像データを作成中のデータ処理装置に対して、作成した画像データを前記キャッシュ装置に登録しないよう指示する、という方式である、ことを特徴とする請求項１又は２に記載の印刷文書処理システムである。

請求項７に係る発明は、前記データ処理装置は、前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、を更に備え、前記領域確保手段は、前記キャッシュ装置を管理するオペレーティングシステムが管理するメモリの空き容量に基づき、前記確保要求の対象の文書要素の画像データの記憶領域を、前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保できるか否か判定し、確保できる場合は第１の方式を、確保できない場合は第２の方式を採用し、前記第１の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐには解放せずに、前記キャッシュ装置を管理するオペレーティングシステムから前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保し、前記解放対象に選択した確保済要素について前記データ処理装置から画像データの登録を要求されたときに、当該文書要素のための確保済の記憶領域を解放する、という方式であり、前記第２の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択したすべての確保済要素について画像データの登録の要求を受けたときに、それら解放対象の確保済要素の画像データの記憶領域を解放し、この解放の後、前記データ処理装置に対して確保成功の旨を応答する、という方式である、ことを特徴とする請求項１又は２に記載の印刷文書処理システムである。

請求項８に係る発明は、前記データ処理装置は、前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、を更に備え、前記領域確保手段は、前記解放対象に選択した確保済要素の記憶領域をすぐに解放した場合に当該確保済要素の画像データを作成していたデータ処理装置が被る損害の評価値を計算し、その評価値があらかじめ定められた閾値以下である場合は第１の方式を、そうでない場合は第２の方式を採用し、前記第１の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐに解放し、記憶領域を解放した確認済要素についての画像データを作成中のデータ処理装置に対して、作成した画像データを前記キャッシュ装置に登録しないよう指示する、という方式であり、前記第２の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択したすべての確保済要素について画像データの登録の要求を受けたときに、それら解放対象の確保済要素の画像データの記憶領域を解放し、この解放の後、前記データ処理装置に対して確保成功の旨を応答する、という方式である、ことを特徴とする請求項１又は２に記載の印刷文書処理システムである。

請求項９に係る発明は、前記データ処理装置は、前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、を更に備え、前記領域確保手段は、前記キャッシュ装置を管理するオペレーティングシステムが管理するメモリの空き容量に基づき、前記確保要求の対象の文書要素の画像データの記憶領域を、前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保できるか否か判定し、確保できる場合は第１の方式を採用し、確保できない場合は更に前記解放対象に選択した確保済要素の記憶領域をすぐに解放した場合に当該確保済要素の画像データを作成していたデータ処理装置が被る損害の評価値を計算し、その評価値があらかじめ定められた閾値以下である場合は第２の方式を、そうでない場合は第３の方式を採用し、前記第１の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐには解放せずに、前記キャッシュ装置を管理するオペレーティングシステムから前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保し、前記解放対象に選択した確保済要素について前記データ処理装置から画像データの登録を要求されたときに、当該文書要素のための確保済の記憶領域を解放する、という方式であり、前記第２の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐに解放し、記憶領域を解放した確認済要素についての画像データを作成中のデータ処理装置に対して、作成した画像データを前記キャッシュ装置に登録しないよう指示する、という方式であり、前記第３の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択したすべての確保済要素について画像データの登録の要求を受けたときに、それら解放対象の確保済要素の画像データの記憶領域を解放し、この解放の後、前記データ処理装置に対して確保成功の旨を応答する、という方式である、ことを特徴とする請求項１又は２に記載の印刷文書処理システムである。

請求項１０に係る発明は、各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データのための記憶領域が前記キャッシュメモリ内に確保済であるか否か、及び、当該文書要素の画像データが前記キャッシュメモリに確保された記憶領域に既に記憶されているか否か、を含むキャッシュ状態の情報を記憶する状態記憶手段と、前記データ処理装置から文書要素の画像データのための記憶領域を確保するための確保要求を受けた際に、画像データの記憶領域が確保済であり且つ画像データが前記キャッシュメモリに確保された記憶領域に記憶されていない文書要素である確保済要素から選ばれた解放対象の記憶領域を解放することにより当該記憶領域を確保する領域確保手段と、を備える、ことを特徴とするキャッシュ装置である。

請求項１１に係る発明は、コンピュータを、各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリ、印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データのための記憶領域が前記キャッシュメモリ内に確保済であるか否か、及び、当該文書要素の画像データが前記キャッシュメモリに確保された記憶領域に既に記憶されているか否か、を含むキャッシュ状態の情報を記憶する状態記憶手段、前記データ処理装置から文書要素の画像データのための記憶領域を確保するための確保要求を受けた際に、画像データの記憶領域が確保済であり且つ画像データが前記キャッシュメモリに確保された記憶領域に記憶されていない文書要素である確保済要素から選ばれた解放対象の記憶領域を解放することにより当該記憶領域を確保する領域確保手段、として機能させるためのプログラムである。

請求項１，１０又は１１に係る発明によれば、文書要素の画像データのための記憶領域をキャッシュメモリ内に確保する際に、使用中でない画像データをキャッシュメモリから追い出すだけよりも更に多くの空き容量を作ることができる。

請求項２に係る発明によれば、記憶領域の確保要求の対象の文書要素よりもキャッシュ優先度が高い文書要素の画像データはキャッシュメモリに記憶されるようにすることができる。

請求項３に係る発明によれば、解放対象の画像データの作成を中断することなく、確保要求に対して即座に空き容量を確保することができる。

請求項４に係る発明によれば、キャッシュメモリに割り当てられた容量を超えることなく、確保要求に対して即座に空き容量を確保することができる。

請求項５に係る発明によれば、解放対象の画像データの作成を中断することなく、かつキャッシュメモリに割り当てられた容量を超えることなく、空き容量を確保することができる。

請求項６に係る発明によれば、キャッシュメモリに割り当てられたメモリ空間からはみ出して記憶領域を確保できるかどうかに応じて、適切な方式で記憶領域の確保を行うことができる。

請求項７に係る発明によれば、キャッシュメモリに割り当てられたメモリ空間からはみ出して記憶領域を確保できるかどうかに応じて、適切な方式で記憶領域の確保を行うことができる。

請求項８に係る発明によれば、作成中の画像データのための記憶領域を解放することによる損失を考慮して、適切な方式で記憶領域の確保を行うことができる。

請求項９に係る発明によれば、状況に応じた適切な方式で記憶領域の確保を行うことができる。

第１例の印刷文書変換システムの構成及びこれが接続される印刷システムの構成の一例を示す図である。 エントリ管理テーブルのデータ内容の一例を示す図である。 第１例におけるキャッシュエントリの５つのステージ間の状態遷移を示す図である。 ＲＩＰ部の全体的な処理手順の一例を示すフローチャートである。 キャッシュ管理部から応答"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"の領域確保済のキャッシュエントリの領域を解放する処理とは依存関係にない。本実施形態の領域確保方法を第２例に適用する場合、例えば図３４の手順のうちＳ１２２〜Ｓ１３０のステップ群を、図２３のＳ１２２、Ｓ１２４及びＳ１２５に置き換えればよい。

以上に例示した印刷文書変換システム１００、またはこれを構成するジョブ管理部１１０、ＲＩＰ部１２０及びキャッシュ管理部１３０は、例えば、汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）を制御するＨＤＤコントローラ、各種Ｉ／Ｏ（入出力）インタフェース、ローカル・エリア・ネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

１００ 印刷文書変換システム、１１０ ジョブ管理部、１１２ ページ割当部、１１４ 負荷監視部、１２０ ＲＩＰ部、１３０ キャッシュ管理部、１３２ エントリ管理テーブル、１４０ キャッシュメモリ、２００ ホストコンピュータ、２１０ 印刷制御装置、２２０ プリンタエンジン。

Claims (11)

1. キャッシュ装置と、複数のデータ処理装置と、を備え、
   前記複数のデータ処理装置の各々は、
   印刷文書データ内の各文書要素のページ記述言語のデータを処理してビットマップ形式又は中間言語形式の画像データを作成する画像データ作成手段と、
   前記画像データ作成手段が作成する前記画像データのための記憶領域を確保するための確保要求を前記キャッシュ装置に送信する確保要求送信手段と、
   を備え、
   前記キャッシュ装置は、
   前記各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、
   前記印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データのための記憶領域が前記キャッシュメモリ内に確保済であるか否か、及び、当該文書要素の画像データが前記キャッシュメモリに確保された記憶領域に既に記憶されているか否か、を含むキャッシュ状態の情報を記憶する状態記憶手段と、
   前記データ処理装置から文書要素の画像データのための記憶領域を確保するための確保要求を受けた際に、画像データの記憶領域が確保済であり且つ画像データが前記キャッシュメモリに確保された記憶領域に記憶されていない文書要素である確保済要素から選ばれた解放対象の記憶領域を解放することにより当該記憶領域を確保する領域確保手段と、
   を備える、
   ことを特徴とする印刷文書処理システム。
2. 前記領域確保手段は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記確保済要素のうち、前記確保要求の対象である文書要素よりもキャッシュ優先度が低い文書要素の記憶領域を前記解放対象として選択する、
   ことを特徴とする請求項１に記載の印刷文書処理システム。
3. 前記データ処理装置は、
   前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、
   を更に備え、
   前記領域確保手段は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐには解放せずに、前記キャッシュ装置を管理するオペレーティングシステムから前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保し、前記解放対象に選択した確保済要素について前記データ処理装置から画像データの登録を要求されたときに、当該文書要素のための確保済の記憶領域を解放する、
   ことを特徴とする請求項１又は２に記載の印刷文書処理システム。
4. 前記領域確保手段は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐに解放し、記憶領域を解放した確認済要素についての画像データを作成中のデータ処理装置に対して、作成した画像データを前記キャッシュ装置に登録しないよう指示する、
   ことを特徴とする請求項１又は２に記載の印刷文書処理システム。
5. 前記データ処理装置は、
   前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、
   を更に備え、
   前記領域確保手段は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択したすべての確保済要素について画像データの登録の要求を受けたときに、それら解放対象の確保済要素の画像データの記憶領域を解放し、この解放の後、前記データ処理装置に対して確保成功の旨を応答する、
   ことを特徴とする請求項１又は２に記載の印刷文書処理システム。
6. 前記データ処理装置は、
   前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、
   を更に備え、
   前記領域確保手段は、前記キャッシュ装置を管理するオペレーティングシステムが管理するメモリの空き容量に基づき、前記確保要求の対象の文書要素の画像データの記憶領域を、前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保できるか否か判定し、確保できる場合は第１の方式を、確保できない場合は第２の方式を採用し、
   前記第１の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐには解放せずに、前記キャッシュ装置を管理するオペレーティングシステムから前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保し、前記解放対象に選択した確保済要素について前記データ処理装置から画像データの登録を要求されたときに、当該文書要素のための確保済の記憶領域を解放する、という方式であり、
   前記第２の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐに解放し、記憶領域を解放した確認済要素についての画像データを作成中のデータ処理装置に対して、作成した画像データを前記キャッシュ装置に登録しないよう指示する、という方式である、
   ことを特徴とする請求項１又は２に記載の印刷文書処理システム。
7. 前記データ処理装置は、
   前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、
   を更に備え、
   前記領域確保手段は、前記キャッシュ装置を管理するオペレーティングシステムが管理するメモリの空き容量に基づき、前記確保要求の対象の文書要素の画像データの記憶領域を、前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保できるか否か判定し、確保できる場合は第１の方式を、確保できない場合は第２の方式を採用し、
   前記第１の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐには解放せずに、前記キャッシュ装置を管理するオペレーティングシステムから前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保し、前記解放対象に選択した確保済要素について前記データ処理装置から画像データの登録を要求されたときに、当該文書要素のための確保済の記憶領域を解放する、という方式であり、
   前記第２の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択したすべての確保済要素について画像データの登録の要求を受けたときに、それら解放対象の確保済要素の画像データの記憶領域を解放し、この解放の後、前記データ処理装置に対して確保成功の旨を応答する、という方式である、
   ことを特徴とする請求項１又は２に記載の印刷文書処理システム。
8. 前記データ処理装置は、
   前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、
   を更に備え、
   前記領域確保手段は、前記解放対象に選択した確保済要素の記憶領域をすぐに解放した場合に当該確保済要素の画像データを作成していたデータ処理装置が被る損害の評価値を計算し、その評価値があらかじめ定められた閾値以下である場合は第１の方式を、そうでない場合は第２の方式を採用し、
   前記第１の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐに解放し、記憶領域を解放した確認済要素についての画像データを作成中のデータ処理装置に対して、作成した画像データを前記キャッシュ装置に登録しないよう指示する、という方式であり、
   前記第２の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択したすべての確保済要素について画像データの登録の要求を受けたときに、それら解放対象の確保済要素の画像データの記憶領域を解放し、この解放の後、前記データ処理装置に対して確保成功の旨を応答する、という方式である、
   ことを特徴とする請求項１又は２に記載の印刷文書処理システム。
9. 前記データ処理装置は、
   前記確保要求に応じて前記キャッシュ装置から確保成功の旨の応答を受けた場合、前記画像データ作成手段に当該文書要素の画像データの作成を実行させ、その結果作成された画像データを用いて印刷用画像を作成した後、その画像データの登録を前記キャッシュ装置に要求する登録要求手段、
   を更に備え、
   前記領域確保手段は、前記キャッシュ装置を管理するオペレーティングシステムが管理するメモリの空き容量に基づき、前記確保要求の対象の文書要素の画像データの記憶領域を、前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保できるか否か判定し、確保できる場合は第１の方式を採用し、確保できない場合は更に前記解放対象に選択した確保済要素の記憶領域をすぐに解放した場合に当該確保済要素の画像データを作成していたデータ処理装置が被る損害の評価値を計算し、その評価値があらかじめ定められた閾値以下である場合は第２の方式を、そうでない場合は第３の方式を採用し、
   前記第１の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐには解放せずに、前記キャッシュ装置を管理するオペレーティングシステムから前記キャッシュメモリに割り当てられたメモリ空間からはみ出して確保し、前記解放対象に選択した確保済要素について前記データ処理装置から画像データの登録を要求されたときに、当該文書要素のための確保済の記憶領域を解放する、という方式であり、
   前記第２の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択した確保済要素の記憶領域をすぐに解放し、記憶領域を解放した確認済要素についての画像データを作成中のデータ処理装置に対して、作成した画像データを前記キャッシュ装置に登録しないよう指示する、という方式であり、
   前記第３の方式は、前記確保要求に応じてその対象の画像データのための記憶領域を確保するにあたり、前記解放対象に選択したすべての確保済要素について画像データの登録の要求を受けたときに、それら解放対象の確保済要素の画像データの記憶領域を解放し、この解放の後、前記データ処理装置に対して確保成功の旨を応答する、という方式である、
   ことを特徴とする請求項１又は２に記載の印刷文書処理システム。
10. 各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリと、
    印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データのための記憶領域が前記キャッシュメモリ内に確保済であるか否か、及び、当該文書要素の画像データが前記キャッシュメモリに確保された記憶領域に既に記憶されているか否か、を含むキャッシュ状態の情報を記憶する状態記憶手段と、
    前記データ処理装置から文書要素の画像データのための記憶領域を確保するための確保要求を受けた際に、画像データの記憶領域が確保済であり且つ画像データが前記キャッシュメモリに確保された記憶領域に記憶されていない文書要素である確保済要素から選ばれた解放対象の記憶領域を解放することにより当該記憶領域を確保する領域確保手段と、
    を備える、ことを特徴とするキャッシュ装置。
11. コンピュータを、
    各データ処理装置が作成したビットマップ形式又は中間言語形式の画像データを記憶するためのキャッシュメモリ、
    印刷文書データの各文書要素について、それぞれ、当該文書要素の画像データのための記憶領域が前記キャッシュメモリ内に確保済であるか否か、及び、当該文書要素の画像データが前記キャッシュメモリに確保された記憶領域に既に記憶されているか否か、を含むキャッシュ状態の情報を記憶する状態記憶手段、
    前記データ処理装置から文書要素の画像データのための記憶領域を確保するための確保要求を受けた際に、画像データの記憶領域が確保済であり且つ画像データが前記キャッシュメモリに確保された記憶領域に記憶されていない文書要素である確保済要素から選ばれた解放対象の記憶領域を解放することにより当該記憶領域を確保する領域確保手段、
    として機能させるためのプログラム。

Images