JP2012183704A - 画像処理装置、画像処理方法及びプログラム - Google Patents

Abstract

【課題】 ＰＤＬデータを解釈しリソース情報で特定される描画情報をキャッシュする際に、リソース情報の特徴に適応してキャッシュ処理を変更する。
【解決手段】
ＰＤＬ解釈部が所定のＰＤＬデータから検出するリソース情報に対して描画処理する画像処理装置において、リソース情報を解釈する（Ｓ６０１〜Ｓ６０３）。そして、ＰＤＬ解釈部が解釈するリソース情報の特徴に応じて、当該リソース情報に対するキャッシュ処理を変更することを特徴とする（Ｓ６０４〜Ｓ６１１）。
【選択図】 図５

Description

本発明は、印刷情報を解析して画像処理を行う画像処理装置、画像処理方法及びプログラムに関するものである。

近年、画像処理装置が扱う電子フォーマットの一例として、Ｍｉｃｒｏｓｏｆｔ社が提唱するＸＰＳ（ＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）がある（非特許文献１）。ＸＰＳは、ＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅ、ＦｉｘｅｄＤｏｃｕｍｅｎｔ、ＦｉｘｅｄＰａｇｅの３つの階層を持っている。それぞれの階層に対して、ＲｅｓｏｕｒｃｅＤｉｃｔｉｏｎａｒｙ（以下、ＲＤと記す）という描画情報をリソース化することで、繰り返し描画に関する情報を参照することができる。

ＲＤのような、描画コマンドを一度キャッシュし、繰り返し参照する場合、キャッシュする保存形式が印刷速度およびデータサイズとして重要である。従来の技術として、最適な印刷速度を達成するため、キャッシュするイメージデータをエッジ化して保持しておくか、イメージデータのまま圧縮して保持しておく処理を条件に応じて切り替える手段がある（例えば、特許文献１参照）。

特開２００６−１５０９４４号公報

＜url: http://www.microsoft.com/whdc/xps/xpsspecdwn.mspx (XPS_1_0.exe)＞

ところで、上記ＸＰＳのＲＤは、参照可能なリソースの範囲が指定される仕様となっており、かつ、ページ（ＦｉｘｅｄＰａｇｅ）を超えるスコープを定義することができない。また、パフォーマンス向上のため、ページを跨いでキャッシュした際には、ＸＰＳＰｒｉｎｔＴｉｃｋｅｔによるページ例外の印刷設定の影響を受ける。
さらに、ＸＰＳのＲＤは、従来のキャッシュデータと異なり、リソースとして定義できるデータ形式が様々であり多様化された仕様である。

したがって、上記の先行技術のようにキャッシュされるデータを、エッジ化された状態で保持する、または、しないの判断のみでは、データによってキャッシュ効率が悪く、パフォーマンスの高速化効果が十分得られないという課題があった。
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、ＰＤＬデータを解釈しリソース情報で特定される描画情報をキャッシュする際に、リソース情報の特徴に適応してキャッシュ処理を変更できる仕組みを提供することである。

上記目的を達成する本発明の画像処理装置は以下に示す構成を備える。
所定のＰＤＬデータから検出するリソース情報に対して描画処理する画像処理装置であって、前記リソース情報を解釈する解釈手段と、前記解釈手段が解釈するリソース情報の特徴に応じて、当該リソース情報に対するキャッシュ処理を変更する制御手段と、を備えることを特徴とする。

本発明によれば、ＰＤＬデータを解釈しリソース情報で特定される描画情報をキャッシュする際に、リソース情報の特徴に適応してキャッシュ処理を変更できる。

画像処理装置を適用する画像処理システムの一例を示す図である。 画像処理装置の制御装置のソフトウェアモジュールを示す図である。 画像処理装置で処理可能なＸＰＳ文書のデータ構成を示す構成図である。 ＲＤ記入例を示す図である。 画像処理装置のデータ処理方法を説明するフローチャートである。 画像処理装置におけるキャッシュ形式及びその特徴を示す模式図である。 画像処理装置のデータ処理方法を説明するフローチャートである。 画像処理装置におけるキャッシュ範囲の変更を示す模式図である。 画像処理装置におけるパフォーマンス効果を示す図である。 画像処理装置のデータ処理方法を説明するフローチャートである。

次に本発明を実施するための最良の形態について図面を参照して説明する。
＜システム構成の説明＞
〔第１実施形態〕
＜印刷システム概要＞

図１は、本実施形態を示す画像処理装置を適用する画像処理システムの一例を示す図である。本例は、画像処理装置を適用する画像形成装置がＬＡＮ１９０を介して複数のデータ処理装置（ＰＣ）と通信可能な画像処理システムの例である。なお、本実施形態において、画像形成装置１００は、ＭＦＰ（Multi Function Printer）を例とする。もちろん、画像処理装置を適用可能なＳＦＰ（Single Function Printer）やＬＢＰ（Laser Beam Printer）で構成してもよい。さらに、本発明は、上記以外のプリント方式のプリンタにも適用可能なものである。また、本実施形態に示す画像処理装置は、所定の電子フォーマットとして、ＸＰＳ（ＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）を例とし、う描画情報を処理する構成例を示す。上述したようにＸＰＳでは、ＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅ、ＦｉｘｅｄＤｏｃｕｍｅｎｔ、ＦｉｘｅｄＰａｇｅの３つの階層を備える構造となっている。

図１において、画像形成装置１００は、イーサネット（登録商標）等のＬＡＮ（Local Area Network）１９０にて、ホストコンピュータ（本実施形態では第一のデータ処理装置（ＰＣ）１９１、第二のデータ処理装置（ＰＣ）１９２）に接続されている。

画像形成装置１００は、リーダ装置（リーダ部）２００、プリンタ装置（プリンタ部）３００、操作部１５０、画像記憶部１６０、これら各構成要素を制御する制御装置（コントローラ部）１１０によって構成されている。

画像形成装置１００は、ＲＯＭ、ＲＡＭ、ＣＰＵ等を有し、ＣＰＵがＲＯＭまたは他の記憶媒体に格納されたプログラムに基づいて、画像形成装置１００全体を統括制御する。なお、前記ＲＡＭは、ＣＰＵの作業領域として用いられる。リーダ装置２００では、画像データの読み取りを行う。プリンタ装置３００では、プリンタエンジンを用いて画像データの出力を行う。操作部１５０は、画像データの入出力操作を行うキーボード、及び画像データや各種機能の表示／設定などを行う液晶パネルを備える。画像記憶部１６０では、電子文書や画像データなどのデータの格納／保存ができる。

ホストコンピュータ１９１は、ＬＡＮ１９０を介して電子文書を印刷装置１００へ送信する。印刷装置１００は、制御装置１１０のＣＰＵを用いて、受信した前記電子文書の解釈および出力画像データの生成処理を行い、プリンタ装置３００で紙などの印刷媒体に出力する。ここでは、ＬＡＮ１９０を介して電子文書が入力された例を示したが、印刷装置１００に接続したＵＳＢメモリ等の可搬メディアや画像記憶部１６０に保存された電子文書を使用してもよい。
図２は、図１に示した画像処理装置１００の制御装置１１０において動作するソフトウェアモジュール図の一例を示す図である。

図２において、ジョブ制御部２００は、印刷ジョブの入力から出力を関数コールやメッセージ通信などの手段による制御する。ＰＤＬ解析部２０１／２０２／２０３は、画像形成装置１００に搭載されるＰＤＬの種類（例えば、ＰｏｓｔＳｃｒｉｐｔ、ＰＣＬ、ＸＰＳなど）だけの数が存在する。ＰＤＬ解析部２０１／２０２／２０３は、ジョブ制御部２００からの制御に従い、ＰＤＬ受信バッファに格納されたＰＤＬデータを読み込み、解釈処理を実行する。

中間データ（Ｄｉｓｐｌａｙ Ｌｉｓｔ）生成部２１０は、ジョブ制御部２００からの制御とＰＤＬ解析部２０１／２０２／２０３から渡された描画情報により描画処理を実行し、生成したＤｉｓｐｌａｙ ＬｉｓｔをＲＡＭ１１６上に確保されるフレームバッファに格納する。イメージデータ生成部２１５は、フレームバッファからＤｉｓｐｌａｙ Ｌｉｓｔをロードし、ＲＡＭ１１６上でレンダリングしたイメージデータをプリンタ装置３００に出力する処理を行う。
本発明におけるＲＤのキャッシュ形式判定方法について図３から図６を用いて説明する。
図３は、本実施形態を示す画像処理装置で処理可能なＸＰＳ文書のデータ構成の一例を示す構成図である。

図３において、ＸＰＳのＲＤは、ＦｉｘｅｄＰａｇｅやＣａｎｖａｓといったリソース情報として有効な範囲が指定される。
この記入例の場合は、ＦｉｘｅｄＰａｇｅにリソースが従属し、有効範囲は、このＦｉｘｅｄＰａｇｅ内である。ＲＤによって円のパスが定義、宣言されている。その後、ストローク幅１、ブラシカラーを黒とした描画情報を付加した状態で、ＲＤを参照し、描画指定している。また、ＦｉｘｅｄＰａｇｅが終了した状態で、このリソースの有効範囲は終了し、言語仕様として、それ以降、この円パスを参照することができない。
図４は、図３に示したＸＰＳ ＲＤの具体的な記入例を示す図である。

図４の（ａ）は、座標設定のＲＤである。１．５倍拡大およびＸ、Ｙ方向へ２０平行移動する座標設定を、再利用可能なようにリソース定義化したものである。

図４の（ｂ）は、塗り指定のＲＤである。（Ｒ，Ｇ，Ｂ）＝（１３６、１３６、１３６）のソリッドカラーブラシの塗り設定を、再利用可能なようにリソース定義化したものである。

図４の（ｃ）は、パス指定のＲＤである。（２０、２０）、（１２０、２０）、（１２０、７０）、（２０、７０）の４点を線形で結ぶ矩形パスを、再利用可能なようにリソース定義化したものである。

図４の（ｄ）は、クリップのかかった文字のＲＤである。"Ｎ"の文字に対して、矩形のクリップがかかった描画オブジェクトを、再利用可能なようにリソース定義化したものである。

図５は、本実施形態を示す画像処理装置のデータ処理方法を説明するフローチャートである。本例は、ＰＤＬデータから検出するリソース情報に対する描画処理を行う際のキャッシュ形式判定を含むキャッシュ処理例である。また、各ステップは、制御装置１１０のＣＰＵ１１２がＲＯＭ１１４やその他の記憶装置からＲＡＭ１１６にロードする制御プログラム（ジョブ制御部、ＰＤＬ解釈部、中間データ生成部、イメージデータ生成部等）を実行することにより実現される。

なお、画像形成装置１００のＣＰＵ１１２は、ＰＣ１９１、１９２から受信したＰＤＬデータをＲＡＭ１１６へ書き込む。それをジョブ制御部２００が受信し、各ＰＤＬ解釈部２０１、２０２、２０３へ、ジョブ開始を通知する。この際、ジョブ制御部２００は、ＰＤＬの種別に対応したＰＤＬ解釈部２０１等へジョブの開始を通知する。説明上、以下、ＰＤＬ解釈部２０１へジョブ開始が通知されたものとする。
ＰＤＬ解釈部２０１は、Ｓ６０１で、ＰＣ１９１またはＰＣ１９２から受信したＰＤＬデータをロードする。次に、Ｓ６０２へ進み、ＸＰＳデータ内部に含まれ、印刷設定が記載されているＰｒｉｎｔＴｉｃｋｅｔを解析する。次に、Ｓ６０３へ進み、ＲＤの解析を行う。

次に、Ｓ６０４で、ＰＤＬ解釈部２０１は、ＲＤが描画情報の一部であるかどうか判定する。Ｓ６０４にて、ＲＤが描画情報の一部であるとＰＤＬ解釈部２０１が判定した場合は、Ｓ６０６へ進む。これは、ＲＤが、図４の（ａ）や図４の（ｂ）のように、描画情報の一部に過ぎない場合は、抽象度の低い描画可能なレベルに落とし込むことができないため、ＰＤＬ形式でキャッシュまたは、キャッシュしないものとする。

そして、Ｓ６０６で、ＰＤＬ解釈部２０１は、ＸＰＳ解釈部が利用するＸＭＬパーサーの構成モデルがＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）か、否かを判定する。ここで、ＤＯＭモデルであるとＰＤＬ解釈部２０１が判定した場合は、ランダムアクセスが可能であり、リソースを後から参照する際には、直接そのオブジェクトへアクセスすることが可能であるため、あえてキャッシュせずに、Ｓ６０８へ進む。

一方、Ｓ６０６で、ＤＯＭモデルでないとＰＤＬ解釈部２０１が判定した場合、例えばＳＡＸ（Ｓｉｍｐｌｅ ＡＰＩ ＸＭＬ）のような、各要素をシーケンシャルにパースして、要素を展開する場合は、キャッシュする必要がある。そこで、Ｓ６０９で、ＰＤＬ解釈部２０１はＰＤＬ形式でキャッシュする。

一方、Ｓ６０４にて、ＲＤが描画情報の一部ではないとＰＤＬ解釈部２０１が判定した場合は、Ｓ６０７へ進む。そして、Ｓ６０７で、ＰＤＬ解釈部２０１は、ＲＤが、エッジ、レベル、フィルといったレンダリングに必要な要素で構成されているかどうか判定する。ここで、レンダリングに必要な要素で構成されていないとＰＤＬ解釈部２０１が判定した場合、Ｓ６１０に進む。
そして、Ｓ６１０で、ＰＤＬ解釈部２０１は、図６の（２）に示すような、エッジ、レベル情報に分離した、中間データ形式でＲＡＭ１１６上にキャッシュしておく。

一方、Ｓ６０７にて、レンダリングに必要な要素で構成されているとＰＤＬ解釈部２０１が判定した場合、Ｓ６１１に進み、ＰＤＬ解釈部２０１は、図６の（３）に示すような、レンダリング後のビットマップイメージ形式でキャッシュしておく。

これは、レンダリング可能な場合は、再利用時の再生時間が早いイメージデータ形式でキャッシュする。一方、レンダリング可能なまで描画要素が揃っていないＲＤの場合は、その前の中間データの状態でキャッシュ保持することで、パフォーマンス向上を図っている。
図６は、本実施形態を示す画像処理装置におけるキャッシュ形式およびその特徴を示す模式図である。

図５に示したキャッシュ形式判定に関するフローチャートに従うと、図４の（ａ）から（ｄ）のＲＤは、図６の（１）から図６の（３）の形式へと分類される。
図６の（１）は、ＰＤＬ形式でキャッシュされるＲＤの一例である。

図４の（ａ）の座標設定を示すものや、図４の（ｂ）のように塗り指定を示すものは、描画情報の一部であり、中間データまで落とし込むことができないため、コマンドレベルのＰＤＬ形式でキャッシュされる。ＰＤＬ形式は、抽象度が高く解像度非依存の状態となっている。

図６の（２）は、中間データ形式でキャッシュされるＲＤの一例である。中間データ（ＤｉｓｐｌａｙＬｉｓｔ）は、外郭情報を示すエッジ、合成手段や高さを示すレベル、塗り情報を示すフィルで構成され、それぞれがリンクされた状態になってレンダリングが可能となる。

図４の（ｃ）のようにパス指定は、中間データにおけるエッジへと変換可能な描画情報であり、図６の（２）のように座標位置と向き情報をもつエッジ情報へ変換された状態でキャッシュされる。実際に描画される場合は、参照時に、レベルおよびフィル情報が付加されてレンダリングされ、イメージデータとなる。

図６の（３）は、イメージデータ形式でキャッシュされるＲＤの一例である。レンダリングに必要な全ての情報がＲｅｓｏｕｒｃｅＤｉｃｉｔｏｎａｒｙにて定義されている場合は、レンダリングした結果のイメージデータにてキャッシュを行う。
図６の（Ａ）は、各キャッシュ形式の特徴を示す表である。ＰＤＬ形式でキャッシュした場合のメリットとして、解像度に依存しないという点がある。

これにより、キャッシュ参照時によって印刷設定が変わった場合にも、キャッシュデータを作り直さずに対応できる。これに対して、ＰＤＬ形式でキャッシュした場合のデメリットとして、ＰＤＬの解析処理から開始するため、再利用に時間がかかりやすいというものがある。

一方、中間データ形式でキャッシュした場合のメリットとして、ＰＤＬ解釈処理をスキップし、中間データレベルに落とし込めているので、高速に再利用できるという点がある。これに対して、中間データ形式でキャッシュした場合のデメリットとして、解像度に依存した状態になっている点がある。

したがって、キャッシュ参照時によって印刷設定が変わった場合は、中間データのキャッシュデータを作り直す必要がある。イメージデータ形式でキャッシュした場合のメリットとして、ＰＤＬ解釈処理をスキップし、中間データをレンダリング済みなので、非常に高速に再利用できるという点がある。

これに対して、イメージデータ形式でキャッシュした場合のデメリットとして、解像度に依存した状態になっている点がある。したがって、キャッシュ参照時によって印刷設定が変わった場合は、中間データのキャッシュデータを作り直す必要がある。さらに、エッジ、レベル、フィルといった描画情報の変更ができないため、描画情報が確定している必要がある。
〔第２実施形態〕
本発明におけるＲＤのキャッシュ範囲の変更を行う方法について図７から図９を用いて説明する。

図７は、本実施形態を示す画像処理装置のデータ処理方法を説明するフローチャートである。本例は、キャッシュ範囲を変更する処理例である。また、各ステップは、制御装置１１０のＣＰＵ１１２がＲＯＭ１１４やその他の記憶装置からＲＡＭ１１６にロードする制御プログラム（ジョブ制御部、ＰＤＬ解釈部、中間データ生成部、イメージデータ生成部等）を実行することにより実現される。

なお、画像処理装置１００のＣＰＵ１１２は、ＰＣ１９１、１９２から受信したＰＤＬデータをＲＡＭ１１６へ書き込む。それをジョブ制御部２００が受信し、各ＰＤＬ解釈部２０１、２０２、２０３のいずれかに、ジョブ開始を通知する。

Ｓ８０１で、各ＰＤＬ解釈部２０１、２０２、２０３は、受信したＰＤＬデータをロードする。次に、Ｓ８０２へ進み、各ＰＤＬ解釈部２０１、２０２、２０３は、ＸＰＳデータの解釈を行い、ページ開始であるＦｉｘｅｄＰａｇｅのコマンドを解釈する。次に、Ｓ８０３へ進み、各ＰＤＬ解釈部２０１、２０２、２０３は、ＲＤの解析を行う。説明上、以下、ＰＤＬ解釈部２０１へジョブ開始が通知されたものとする。

次に、Ｓ８０４で、ＰＤＬ解釈部２０１は、Ｓ８０３で生成されたＲＤを参照するコマンドを解釈する。次に、Ｓ８０５で、ＰＤＬ解釈部２０１は、そのＲＤに関連付ける参照回数を示す変数を１つインクリメントする。

次に、Ｓ８０６で、ＰＤＬ解釈部２０１は、インクリメントした参照回数が閾値以上かどうか判定する。ここで、参照回数が閾値以上でないとＰＤＬ解釈部２０１が判定した場合は、再利用の回数がまだ少ないためキャッシュされていないものとして、キャッシュ生成処理に進まず、Ｓ８０３へ戻り、ＰＤＬ解釈部２０１はＸＰＳデータの解析を続ける。

一方、Ｓ８０６において、参照回数が閾値以上であるとＰＤＬ解釈部２０１が判定した場合は、Ｓ８０７へ進み、ＰＤＬ解釈部２０１は、リソースの有効範囲（リソース範囲）をＦｉｘｅｄＰａｇｅから、ページ間を跨いで有効となるジョブ範囲へと変更する。

次に、Ｓ８０８で、ＰＤＬ解釈部２０１は、ＰｒｉｎｔＴｉｃｋｅｔにて、ページ間で異なる印刷設定が存在するかどうか判定する。ここで、ＰｒｉｎｔＴｉｃｋｅｔにて、ページ間で異なる印刷設定（出力解像度や色変換方法といった）が存在するとＰＤＬ解釈部２０１が判定した場合は、Ｓ８０９へ進む。そして、Ｓ８０９で、ＰＤＬ解釈部２０１は、印刷設定に依存しないデータ形式であるＰＤＬ形式でＲＡＭ１１６上に描画情報をキャッシュする。

一方、Ｓ８０８で、ＰｒｉｎｔＴｉｃｋｅｔにて、ページ間で異なる印刷設定（出力解像度や色変換方法といった）が存在しないとＰＤＬ解釈部２０１が判定した場合は、Ｓ８１０へ進む。そして、Ｓ８１０で、ＰＤＬ解釈部２０１は、印刷設定するデータ形式であるイメージデータ形式でＲＡＭ１１６上に描画情報をキャッシュする。次に、Ｓ８１１で、ＰＤＬ解釈部２０１はＦｉｘｅｄＰａｇｅが終了となり、各ページで一連の処理を繰り返す。
図８は、本実施形態を示す画像処理装置におけるキャッシュ範囲の変更を示す模式図である。

本例は、ＸＰＳの仕様上、ＲＤは、ＦｉｘｅｄＰａｇｅを超えるスコープで定義せれていない。実際の印刷物には、同じリソースが毎ページ続くことがあり、ページ毎に同一リソースを生成、消去している。それを一定回数以上、同一のリソースがジョブ内で参照される場合に、ＰＤＬ解釈部２０１は、有効範囲をＦｉｘｅｄＰａｇｅからジョブ範囲へと広げて、キャッシュする。

ＰｒｉｎｔＴｉｃｋｅｔよってページ毎に印刷設定が異なる場合は、ＰＤＬ解釈部２０１は、図８の（ａ）のように、出力設定に依存しないＰＤＬレベルで描画情報をＲＡＭ１１６上にキャッシュする。一方、例外設定がない場合は、ＰＤＬ解釈部２０１は、図８の（ｂ）のように、出力設定に依存する中間データレベルでＲＡＭ１１６上に描画情報をキャッシュする。
図９は、本実施形態を示す画像処理装置におけるパフォーマンス効果を示す図である。なお、本例は、第１、第２実施形態のパフォーマンス効果の例を示す。

図９の（ａ）は、第１実施形態のＲＤの特徴に合わせて、リソースデータのキャッシュ形式を判定する手段をあるテストジョブで適用した場合の処理時間を示す模式図である。
図４の（ｄ）のようなＲＤをＰＤＬ形式でキャッシュする従来手法では、最初のリソース生成時間（ＲＣ）は、比較的短くて済むが、リソース再生時間（ＲＲ）に中間データ生成、レンダリング時間が含まれるため時間的コストがかかる。

一方、図４の（ｄ）のようなＲＤをイメージデータ形式でキャッシュする本発明手法では、最初のリソース生成時間（ＲＣ）は、中間データ生成、レンダリング時間が含まれる時間的コストがかかるが、リソース再生時間（ＲＲ）が短縮されるため、結果として印刷パフォーマンスが向上する。

図９の（ｂ）は、第２実施形態の参照回数の多いＲＤのキャッシュ有効範囲をＦｉｘｅｄＰａｇｅからページを跨いで参照できるように広げる処理を適用した場合の処理時間を示す模式図である。
ＦｉｘｅｄＰａｇｅ内でリソース生成、開放を繰り返す従来手法では、図８の（ｂ）に示したような印刷データにおいて、ＲＤの生成、削除をページ内で繰り返すため、それぞれに時間的コストがかかる。一方、参照回数の多いＲＤのキャッシュ有効範囲をＦｉｘｅｄＰａｇｅからページを跨いで参照できるように広げる本発明手法では、リソース生成時間（ＲＣ）が、２ページ目以降で省略できるため、印刷パフォーマンスが向上する。
〔第３実施形態〕
本発明におけるＲＤのキャッシュ削除を行う方法について図１０を用いて説明する。

図１０は、本実施形態を示す画像処理装置のデータ処理方法を説明するフローチャートである。本例は、キャッシュ範囲削除処理例である。また、各ステップは、制御装置１１０のＣＰＵ１１２がＲＯＭ１１４やその他の記憶装置からＲＡＭ１１６にロードする制御プログラム（ジョブ制御部、ＰＤＬ解釈部、中間データ生成部、イメージデータ生成部等）を実行することにより実現される。

なお、画像形成装置１００のＣＰＵ１１２は、ＰＣ１９１、１９２から受信したＰＤＬデータをＲＡＭ１１６へ書き込む。それをジョブ制御部２００が受信し、各ＰＤＬ解釈部２０１、２０２、２０３へ、ジョブ開始を通知する。

Ｓ１００１で、ＰＤＬ解釈部２０１は、ジョブ制御部２００が受信したＰＤＬデータをロードする。次に、Ｓ１００２へ進み、ＰＤＬ解釈部２０１は、ＸＰＳデータの解釈を行い、ＲＤのコマンドを解析する。次に、Ｓ１００３へ進み、第１実施形態で説明したフローにそってキャッシュ形式を決定する。説明上、以下、ＰＤＬ解釈部２０１へジョブ開始が通知されたものとする。

次に、Ｓ１００４で、ＰＤＬ解釈部２０１はキャッシュを登録するにあたり、ＲＡＭ１１６に確保できるメモリが空いているかどうかを判定する。キャッシュ用メモリが空いているとＰＤＬ解釈部２０１はが判定した場合は、Ｓ１０１０に進み、判定されたキャッシュ形式でキャッシュを登録する。
一方、Ｓ１００４で、キャッシュ用メモリが空いていないとＰＤＬ解釈部２０１が判定した場合は、Ｓ１００５へ進み、キャッシュ参照順リストの最終要素を参照する。

次に、Ｓ１００６で、ＰＤＬ解釈部２０１はキャッシュ参照順リストの対象要素のサイズを算出する。次に、Ｓ１００７で、ＰＤＬ解釈部２０１は参照リストの要素サイズが必要なキャッシュサイズより大きいかどうか判定する。ここで、参照リストの要素サイズが小さいとＰＤＬ解釈部２０１が判定した場合は、キャッシュ容量として足りないので、リストの次の要素を検索するため、Ｓ１００８へ進み、参照リストの要素を１つ前へ進め、Ｓ１００６の判定へ戻る処理を繰り返す。
一方、Ｓ１００７において、参照リストの要素サイズが必要なキャッシュサイズより大きいとＰＤＬ解釈部２０１が判定した場合は、キャッシュ容量が十分であるので、Ｓ１００９へ進み、キャッシュ参照順リストからオブジェクトを削除する。次に、Ｓ１０１０へ進み、ＰＤＬ解釈部２０１はキャッシュを登録し、一連の処理を終了する。

本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）をパソコン（コンピュータ）等の処理装置（ＣＰＵ、プロセッサ）にて実行することでも実現できる。

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。

１００ 画像入出力システム
１１０ 制御装置（コントローラ部）
１１２ ＣＰＵ
１１４ ＲＯＭ
１１６ ＲＡＭ
１５０ 操作部
１６０ 画像記憶部
１９０ ＬＡＮ
１９１ ホストコンピュータ

近年、画像処理装置が扱う電子フォーマットの一例として、Ｍｉｃｒｏｓｏｆｔ社が提唱するＸＰＳ（ＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）がある。ＸＰＳは、ＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅ、ＦｉｘｅｄＤｏｃｕｍｅｎｔ、ＦｉｘｅｄＰａｇｅの３つの階層を持っている。それぞれの階層に対して、ＲｅｓｏｕｒｃｅＤｉｃｔｉｏｎａｒｙ（以下、ＲＤと記す）という描画情報をリソース化することで、繰り返し描画に関する情報を参照することができる。

特開２００６−１５０９４４号公報 米国特許第７７１６５７０号明細書

Claims (9)

1. 所定のＰＤＬデータから検出するリソース情報に対して描画処理する画像処理装置であって、
   前記リソース情報を解釈する解釈手段と、
   前記解釈手段が解釈するリソース情報の特徴に応じて、当該リソース情報に対するキャッシュ処理を変更する制御手段と、
   を備えることを特徴とする画像処理装置。
2. 前記制御手段は、前記解釈手段が解釈するリソース情報の特徴に応じて、当該リソース情報に対するキャッシュデータのキャッシュ形式を変更することを特徴とする請求項１記載の画像処理装置。
3. 前記制御手段は、前記解釈手段が解釈するリソース情報の特徴に応じて、当該リソース情報に対するキャッシュデータのキャッシュ範囲を変更することを特徴とする請求項１記載の画像処理装置。
4. 前記制御手段は、前記解釈手段がリソース情報を解析するためのパーサを備える場合、前記パーサの構成モデルに応じてキャッシュ形式を変更することを特徴とする請求項１記載の画像処理装置。
5. 前記キャッシュデータのキャッシュ形式は、ＰＤＬ形式、中間データ形式、イメージ形式を含むことを特徴とする請求項２記載の画像処理装置。
6. 所定のＰＤＬデータは、ＸＰＳデータであることを特徴とする請求項１記載の画像処理装置。
7. 所定のＰＤＬデータから検出するリソース情報に対して描画処理する画像処理装置の画像処理方法であって、
   前記リソース情報を解釈する解釈工程と、
   前記解釈工程が解釈するリソース情報の特徴に応じて、当該リソース情報に対するキャッシュ処理を変更する制御工程と、
   を備えることを特徴とする画像処理装置の画像処理方法。
8. 請求項６に記載の画像処理装置の画像処理方法をコンピュータに実行させることを特徴とするプログラム。
9. リソースの参照回数が閾値を超えるか否かを判定する判定手段と、
   前記判定手段によりリソースの参照回数が閾値を超えると判定された場合、リソース範囲をページ間を跨いで有効となるように変更する変更手段と、
   ページ間で異なる印刷設定が存在する場合、ＰＤＬ形式でキャッシュし、ページ間で異なる印刷設定が存在しない場合、イメージ形式でキャッシュするキャッシュ手段とを有することを特徴とする画像処理装置。
   
   

Images