JP3713937B2 - 画像処理装置および画像処理方法 - Google Patents
画像処理装置および画像処理方法 Download PDFInfo
- Publication number
- JP3713937B2 JP3713937B2 JP02603398A JP2603398A JP3713937B2 JP 3713937 B2 JP3713937 B2 JP 3713937B2 JP 02603398 A JP02603398 A JP 02603398A JP 2603398 A JP2603398 A JP 2603398A JP 3713937 B2 JP3713937 B2 JP 3713937B2
- Authority
- JP
- Japan
- Prior art keywords
- image data
- code image
- intermediate code
- size
- holding block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Accessory Devices And Overall Control Thereof (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、１ページ分のラスタデータ保持用のメモリを持たず、入力されたコード画像データを中間コード画像データに変換して保持し、保持した中間コード画像データを展開してラスタデータを生成しつつ、このラスタデータを出力する画像処理装置および画像処理方法に関する。
【０００２】
【従来の技術】
従来より、ページプリンタのように、写真などのイメージデータや、線図、表、文字などをＰＤＬ（ページ記述言語）により記述して得られるコード画像データを入力し、当該コード画像データを解釈し、ラスタデータに展開してバッファに一旦格納し、印刷や送信などの出力動作に同期してラスタデータをバッファから読み出す画像処理装置が知られている。この種の画像処理装置では、コード画像データを展開して得られるラスタデータを一旦格納するバッファとして、フレームバッファを用いるものと、複数のバンドバッファを用いるものとがある。
【０００３】
前者を用いた装置では、フレームバッファに１ページ分のラスタデータを一旦格納し、格納したラスタデータを読み出して出力する処理が行われる。したがって、フレームバッファには１ページ分のラスタデータを格納可能な容量が要求され、コスト高を招致するという問題がある。また、複数ページにわたる画像を連続して出力する場合、各ページの出力は当該ページがフレームバッファに格納され終わるまで待たされることになり、コード画像データの入力からラスタデータの出力までにかかる時間が長いという欠点もある。
【０００４】
これに対して後者は、出力画像を副走査方向に帯状に分割した画像（バンド画像）を表すラスタデータをバンドバッファに一旦格納しつつ、格納が完了したラスタデータを順に読み出して出力する。具体的には、バンド画像を格納するバンドバッファを複数用意し、ＰＤＬで記述されたコード画像データを解釈し、バンド画像に対応するラスタデータを得るためのバンド（分割単位）毎の中間コード画像データに変換してメモリ上に一旦格納し、バンド毎の中間コード画像データを展開処理して得られるバンド画像のラスタデータをバンドバッファに一旦格納する作業を、対象バンドが変わる毎にバンドバッファを順に変更して行うとともに、複数のバンドバッファから順にラスタデータを読み出して出力する。
【０００５】
例えば、図９に示すように、出力画像を分割するバンド数が６４、バンドバッファ数が２の場合、バンド毎に生成された中間コード画像データは中間コード画像データ格納領域に格納される。この中間コード画像データ格納領域に格納された各中間コード画像データは、バンド毎に順に読み出されて展開され、バンド１に対するラスタデータがバンドバッファＡに、バンド２に対するラスタデータがバンドバッファＢに、バンド３に対するラスタデータがバンドバッファＡに、…という順序で交互に格納される。この格納作業に並行して、バンドバッファＡ，Ｂから交互にラスタデータを読み出すことにより、１ページ分のラスタデータを得ることが可能となる。
【０００６】
中間コード画像データ格納領域の容量は、バンドバッファＡ，Ｂと中間コード画像データ格納領域との総容量が１ページ分のラスタデータの容量未満となるよう設定されるので、必要となるメモリ容量はページバッファの容量未満となる。したがって、後者では、画像処理装置の製造コストを低減できるという利点がある。しかも、出力画像がカラー画像の場合、前者ではカラープレーンの数だけバッファ数を倍増させる必要があるが、後者では必ずしもその必要はない、という差異がある。さらに、後者では、ある程度のバンド画像に相当するラスタデータが得られた段階で出力段へのデータ供給を開始できるので、コード画像データの入力からラスタデータの出力までにかかる時間を短縮することができるとともに、出力段の処理がボトルネックとなりがちなプリンタに適用した場合には、印刷処理全体の所要時間を短縮することができる。
【０００７】
ここで、中間コード画像データ格納領域の具体的な管理方式について例を挙げて説明する。特開平３−１１４８５６号公報に開示されたプリンタデータ管理方式では、入力したコード画像データに対して複数のバンドが設定されると、まず、中間コード画像データを格納する上で必要な最小容量の基本ブロックをバンド毎に確保し、中間コード画像データが生成されると、当該中間コード画像データに対応したバンドの基本ブロックに当該中間コード画像データを格納し、当該バンドにおいて基本ブロックの容量を超えて中間コード画像データが生成されると、ある程度の中間コード画像データを保持可能な拡張ブロックをメモリから確保し、確保した拡張ブロックに中間コード画像データを格納し、中間データ管理テーブルによって、使用中の各ブロックと当該バンドと対応付けるようにしている。
【０００８】
【発明が解決しようとする課題】
ところで、特開平３−１１４８５６号公報に開示されたプリンタデータ管理方式では、基本ブロックはバンド毎に必ず確保されるブロックであり、その容量は固定的に定まっている。また、拡張ブロックの容量も固定的に定まっており、このことがメモリの利用効率の低下を招いている。ここでは、説明の繁雑化を回避するために、基本ブロックの容量と拡張ブロックの容量とを同一として、メモリの利用効率について検討する。
【０００９】
基本ブロックおよび拡張ブロック（以後、中間コード画像データ保持ブロック）の平均総未使用領域サイズは次式で表される。ただし、０．５は、各ブロックにおける平均利用効率である。
ここで、例えば、バンド分割数を６４、各ブロックのサイズを１６ＫＢ（キロバイト）とすると、中間コード画像データ保持ブロックの平均総未使用領域サイズは５１２ＫＢとなる。このことは、中間コード画像データ保持用のブロックとして確保されながら、中間コード画像データが格納されない領域のサイズが５１２ＫＢに達することを意味する。したがって、中間コード画像データ格納領域のサイズが４ＭＢ（メガバイト）の場合には、その１／８が他の用途に使用できない未使用領域となってしまい、メモリの利用効率が低く抑制されてしまう。
【００１０】
本発明は上述した事情に鑑みてなされたものであり、１ページ分のラスタデータ保持用のメモリを持たず、入力されたコード画像データを中間コード画像データに変換して保持し、保持した中間コード画像データを展開してラスタデータを生成しつつ、このラスタデータを出力する画像処理装置において、中間コード画像データを効率よく保持することができる画像処理装置および画像処理方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
上述した課題を解決するために、本発明に係る画像処理装置は、ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、コード画像データを変換して中間コード画像データを生成する変換手段と、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段とを備え、前記サイズ決定手段は、前記分割単位の数に基づいて、または、前記中間コード画像データの形式に基づいて、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定することを特徴としている。
上記画像処理装置によれば、サイズ決定手段によって、上記保持ブロックのサイズが、分割単位の数または中間コード画像データの形式に基づいて適切なサイズに決定され、保持ブロックにおいて使用されない未使用領域が減少する。
また、本発明の別の態様に係る画像処理装置は、ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、コード画像データを変換して中間コード画像データを生成する変換手段と、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段と、１つの中間コード画像データを分割して複数の中間コード画像データを生成する分割手段と、を備え、前記格納手段は、前記分割手段により生成された複数の中間コード画像データを、前記確保手段により確保された対応する分割単位の複数の保持ブロックに格納することを特徴としている。
上記画像処理装置によれば、上記分割手段によって１つの中間コード画像データが複数に分割され、その各々が上記確保手段によって確保された保持ブロックへ上記格納手段によって格納されるので、保持ブロックにおいて使用されない未使用領域が減少する。
また、本発明の別の態様に係る画像処理装置にあっては、ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、コード画像データを変換して中間コード画像データを生成する変換手段と、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段とを備え、前記確保手段は、前記変換手段により中間コード画像データが生成されない分割単位については、保持ブロックを確保しないことを特徴としている。
上記画像処理装置によれば、上記変換手段により中間コード画像データが生成されない分割単位については、上記確保手段による保持ブロックの確保は行われないので、保持ブロックにおける未使用領域が減少する。
【００１３】
また、上述した課題を解決するために、本発明に係る画像処理方法は、ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理方法において、前記分割単位の数あるいは中間コード画像データの形式に基づいて、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定ステップと、コード画像データを変換して中間コード画像データを生成する変換ステップと、前記サイズ決定ステップで決定されたサイズの保持ブロックを分割単位毎に確保する確保ステップと、前記確保ステップで確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納ステップとを有することを特徴としている。このため、サイズ決定ステップで決定される保持ブロックのサイズは適切なサイズとなり、各分割単位について確保される保持ブロックにおいて使用されない総未使用領域が減少する。
【００１４】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について説明する。
１：構成
図１は本発明の一実施形態による画像処理装置１１の機能構成を示すブロック図であり、この図に示す機能構成の画像処理装置１１は、実際には、動作プログラムを格納したＲＯＭ（Read Only Memory）、ＲＯＭに格納された動作プログラムを実行するＣＰＵ（中央処理装置）、ＣＰＵに読み書きされるＲＡＭ（Random Access Memory）、各種Ｉ／Ｏインタフェースとを備えている。この画像処理装置１１は、プリンタエンジン２１が接続されていることから明らかなように、コード画像データを入力し、これに対応した印刷出力を得るプリンタに適用されている。
【００１５】
図１の画像処理装置１１において、１２はＰＤＬで記述されたコード画像データを入力してその内容を解釈する上位処理部であり、コード画像データの特定部（例えばヘッダ）の解釈によって得られる用紙サイズと予め設定されたバンドバッファのサイズとに基づいてバンドの分割数を決定し、決定した分割数を後述する中間コード画像データブロックサイズ決定部１３へ通知するとともに、中間コード画像データブロックサイズ決定部１３に対して中間コード画像データ保持ブロック（以後、単に保持ブロック）のサイズの決定処理を行うよう指示する。また、上位処理部１２は、コード画像データの内容を解釈して、展開すべきコード画像データ中の描画データを後述する中間コード画像データ生成部１５へ供給して中間コード画像データを分割数に応じた単位であるバンド単位で生成するよう指示するとともに、分割数などを後述する展開部１６へ渡し、中間コード画像データ生成部１５にて生成される中間コード画像データをバンド単位で展開するよう指示する。
【００１６】
中間コード画像データブロックサイズ決定部１３は、上位処理部１２からの指示の入力を契機とし、上位処理部１２から供給された分割数とＲＡＭ上に設定された中間コード画像データ格納領域のサイズとに基づいて保持ブロックのサイズ（以後、ブロックサイズ）を決定し、決定したブロックサイズを後述する中間コード画像データブロック管理部１４へ供給するとともに、中間コード画像データブロック管理部１４に対して、当該ブロックサイズを単位とした中間コード画像データ格納領域の管理を開始するよう指示する。なお、中間コード画像データ格納領域のサイズは、各バンドバッファと中間コード画像データ格納領域との合計サイズが１ページ分の出力画像を表すラスタデータのサイズ未満となるよう予め設定されている。
【００１７】
展開部１６は、上位処理部１２からの指示に基づいて作動し、上位処理部１２から供給された分割数を中間コード画像データ生成部１５へ供給するとともに、中間コード画像データ生成部１５により生成された中間コード画像データを展開してバンド毎のラスタデータを生成し、生成したラスタデータをバンドバッファに書き込む処理を行う。
【００１８】
中間コード画像データ生成部１５は、上位処理部１２からの指示に基づいて、描画データをバンド毎に変換し、バンド毎の中間コード画像データを生成する。この中間コード画像データ生成部１５は、あるバンドの中間コード画像データの最初の生成時に、中間コード画像データブロック管理部１４へ当該バンドの識別情報（例えばバンド番号）を供給するとともに、当該バンドについての保持ブロックを確保するよう指示する。そして、中間コード画像データ生成部１５は、生成した中間コード画像データを、中間コード画像データブロック管理部１４から供給された情報（例えば、保持ブロックの開始および終了アドレス）で表される保持ブロックに格納する。また、中間コード画像データ生成部１５は、あるバンドについて生成した中間コード画像データの累計サイズが、現在使用中の保持ブロックの未使用領域サイズを超過した時に、中間コード画像データブロック管理部１４に対して、当該バンドの識別情報を供給するとともに当該バンドについての保持ブロックを新たに確保するよう指示する。
【００１９】
中間コード画像データブロック管理部１４は、中間コード画像データブロックサイズ決定部１３からの指示を契機とし、中間コード画像データブロックサイズ決定部１３で決定されたブロックサイズに基づいて、当該ブロックサイズによる中間コード画像データ格納領域の管理を開始する。また、中間コード画像データブロック管理部１４は、中間コード画像データ生成部１５からの指示および識別情報に基づいて保持ブロックを確保して管理するとともに、確保した保持ブロックを表す情報を中間コード画像データ生成部１５へ供給する。なお、ここでいう「管理」とは、保持ブロックのアドレスと識別情報および確保順序とを対応付けて記憶しておくことを意味する。また、中間コード画像データブロック管理部１４は、中間コード画像データ格納領域内の未使用保持ブロックの不足により保持ブロックを確保できなかった場合には、その旨の情報を中間コード画像データ生成部１５へ供給する。
【００２０】
また、展開部１６は、上位処理部１２による１ページあるいは１ジョブ分のコード画像データの解釈および中間コード画像データ生成部１５による変換処理が完了すると、保持ブロックに格納された中間コード画像データをバンド毎に読み出して展開することでバンド毎のラスタデータを生成し、これらをバンドバッファ１９に書き込む。バンドバッファ１９は同一容量のバンドバッファＡ，Ｂ，Ｃ，Ｄから構成されており、展開部１６は各バンドバッファに対してバンド毎に巡回的にラスタデータを書き込む。
【００２１】
また、中間コード画像データ生成部１５は重畳図形処理部を包含している。重畳図形処理部は中間コード画像データのデータ表現を簡素化する処理を行うものであり、中間コード画像データブロック管理部１４において新たな保持ブロックの確保に失敗した場合（例えば中間コード画像データ格納領域の全てを使い切ってしまった場合など）に、中間コード画像データのサイズを低減し、不要となった保持ブロックを回収して再利用可能とする目的で上記簡素化処理を行う。
【００２２】
ここでいう簡素化処理は周知の処理であり、例えば、同一バンド内で空間的に重なっている複数の図形を別々のコード群ではなく１つの図形を表す１つのコード群で表す処理などを言う。例えば、ＰＤＬの仕様が、複数の図形の重複部分の色を最後に描画された図形の色とするような仕様の場合には、背後に隠れてしまう部分のデータは冗長であり、この冗長部分を削除すればデータの簡素化を図ることができる、というのが上記簡素化処理の基本的思想である。この重畳図形処理部がバンド毎の中間コード画像データを簡素化することによって全領域が未使用となった保持ブロックは中間コード画像データブロック管理部１４により解放され、解放された領域は新たな保持ブロックとして確保可能な領域となる。
【００２３】
１７はスケジュール管理部であり、展開部１６から中間コード画像データへの変換が終了した旨の情報を受け取ると、コード画像データの展開処理とプリンタエンジン２１による出力処理との間のタイミング調整を行う。特に、本装置のようにバンドバッファ１９を用いる場合には、バンドバッファ２９へのラスタデータへの書き込みが間に合わないと、出力画像にいわゆる「白抜け」が発生してしまうため、スケジュール管理部１７は、各バンドの中間コード画像データを展開してバンドバッファ１９に書き込む処理にかかる時間（以後、処理時間）を展開部１６に問い合わせ、これに対応して展開部１６から各バンドの処理時間の予測値が渡されると、これらを出力順に並べたスケジュールとプリンタエンジン２１の出力速度とを比較し、バンドバッファ１９への書き込みが間に合わないバンドを抽出し、当該バンドの中間コード画像データに簡素化処理を施すよう指示する。ただし、簡素化処理を行うのは、バンドバッファ１９への書き込みが間に合わないバンドについて未だ簡素化処理が行われていない場合のみである。
【００２４】
また、スケジュール管理部１７は、バンドバッファ１９への書き込みが間に合わないバンドが存在しない場合には、展開部１６に対してバンドバッファ１９への書き込みを開始するよう指示するとともに、上記スケジュールに応じたタイミングでバンドバッファ１９からの読み出しを許可する旨の情報を後述の転送部２０へ供給する。なお、簡素化処理を行ってもバンドバッファ１９への書き込みが間に合わないバンドが存在する場合には、エラー処理部１８に対してその旨を表す情報を供給する。ただし、本装置１１では、バンドバッファの数を４としているので、展開部１６による展開処理の開始タイミングをプリンタエンジン２１による出力処理の開始タイミングよりも十分に早く設定することが可能であり、簡素化処理を行ってもバンドバッファ１９への書き込みが間に合わないバンドが存在する確率は極めて低い。なお、エラー処理部１８の処理内容は適用する装置（ここではプリンタ）に応じて適宜設計すべき事項であることから、ここではその説明を省略する。
【００２５】
一方、展開部１６は、スケジュール管理部１７から展開処理時間の問い合わせを受けると、中間コード画像データの形式に応じた方法により、各バンドの中間コード画像データの内容とバンドバッファ１９への中間コード画像データの書き込み速度とに基づいた計算処理を行って各バンドの展開処理時間を算出し、各処理時間をスケジュール管理部１７へ供給する。また、展開部６は、スケジュール管理部１７からバンドバッファ１９への書き込みが間に合わないバンドの中間コード画像データの簡素化を指示されると、当該中間コード画像データの簡素化処理を中間コード画像データ生成部１５内の重畳図形処理部に依頼する。さらに、展開部１６は、スケジュール管理部１７からの所定の指示を契機として、中間コード画像データをラスタデータへ展開しバンドバッファ１９に格納する展開処理を開始する。
【００２６】
転送部２０は、バンドバッファＡ，Ｂ，Ｃ，Ｄ，Ａ，Ｂ，…というように巡回的に対象バンドバッファを変更しつつ、対象バンドバッファから読み出したラスタデータをプリンタエンジン２１へ転送する。具体的には、転送部２０は、スケジュール管理部１７から対象バンドバッファからの読み出しを許可する情報が供給され、さらにプリンタエンジン２１による出力処理が可能となると、対象バンドバッファから１バンド分のラスタデータを読み出しプリンタエンジン２１へ転送し、この転送が終了すると、その旨の情報をスケジュール管理部１７へ渡すとともに、対象バンドバッファを次のバンドバッファとする。なお、転送部２０とスケジュール管理部１７とのやりとりを排し、転送部２０が予め設定されたタイミングで対象バンドバッファからのラスタデータの読み出しを行うようにしてもよい。
【００２７】
２：動作
次に、上述した構成の本装置１１の動作例について図２を参照して説明する。なお、以降の説明において、処理の主体については上述した構成の説明から明らかであることから、処理の主体の記載を省略することがある。
図２は本装置１１による処理の流れの一例を示すフローチャートであり、この例はコード画像データの解釈がバンド１〜バンド６４まで順に行われることを前提としている。この図に示す例では、本装置１１では、外部からＰＤＬで記述されたコード画像データが入力されると、まずブロックサイズが決定され（ステップＳＡ１）、最初のバンド（図９中ではバンド１）が以降の処理の対象バンドとなる（ステップＳＡ２）。
【００２８】
次に、対象バンドに未変換のコード画像データが存在するか否かが判定され（ステップＳＢ３）、存在する場合には未変換のコード画像データが中間コード画像データへ変換される（ステップＳＡ４）。そして、この変換により生成された中間コード画像データを格納するための保持ブロックを新たに確保する必要があるか否かが判定される（ステップＳＡ５）。各バンドについて、最初は保持ブロックが確保されていないことから、この判定結果は「ＹＥＳ」となり、４ＫＢの保持ブロックが新たに確保される（ステップＳＡ６）。ステップＳＡ６において保持ブロックの確保に成功した場合、ステップＳＡ４で生成された中間コード画像データが当該保持ブロックに格納され（ステップＳＡ７，ＳＡ８）、処理はステップＳＡ３に戻る。
【００２９】
以後、ステップＳＡ３以降の処理が繰り返されるが、保持ブロックを確保した直後であることから、通常は新たに保持ブロックを確保する必要はない。したがって、ステップＳＡ５の判定結果は「ＮＯ」となり、生成された中間コード画像データが保持ブロックに追記され（ステップＳＡ８）、ステップＳＡ３の処理に戻る。
【００３０】
なお、ステップＳＡ７での判定結果が「ＹＥＳ」となった場合、すなわち新たな保持ブロックの確保に失敗し、さらにステップＳＡ９での判定結果が「ＹＥＳ」となった場合、すなわち簡素化処理を施していないバンドが存在しないときには、エラー処理が行われてステップＳＡ３以降のループから脱出する。逆に、ステップＳＡ９での判定結果が「ＮＯ」となった場合、すなわち簡素化処理を施していないバンドが存在するときには、当該バンドの中間コード画像データに簡素化処理が施され、中間コード画像データ格納領域における空き領域の拡大が図られる（ステップＳＡ１０）。
【００３１】
対象バンドの全コード画像データの変換を終了し、ステップＳＡ３の判定結果が「ＮＯ」となると、処理はステップＳＡ１１へ進み、ここで次のバンドが存在するか否かが判定される。ここでは現在の対象バンドはバンド１であり、次のバンドはバンド２として存在することからステップＳＡ１１の判定結果は「ＹＥＳ」となり、次のバンド（ここではバンド２）が対象バンドとなり（ステップＳＡ１２）、ステップＳＡ３の処理に戻る。以後、対象バンドがバンド６４となるまで上述した処理が繰り返され、全てのバンド１〜６４についての中間コード画像データが生成・格納される。
【００３２】
全てのバンド１〜６４についての中間コード画像データが生成・格納されると、ステップＳＡ１１の判定結果が「ＮＯ」となり、スケジュールに無理があるか否か、すなわち「白抜け」が発生し得るか否かが判定される（ステップＳＡ１３）。なお、上記スケジュールは、前述したように、各バンドの中間コード画像データの内容とバンドバッファ１９へのデータの書き込み速度とに基づいて求められる。そして、ステップＳＡ１３の判定結果が「ＮＯ」の場合、中間コード画像データの展開処理およびプリンタエンジン２１による出力処理が上記スケジュールに従って開始される（ステップＳＡ１４）。
【００３３】
逆にステップＳＡ１３の判定結果が「ＹＥＳ」の場合、全てのバンドについて中間コード画像データの簡素化処理が施されたか否かが判定される（ステップＳＡ１５）。この判定結果が「ＹＥＳ」であれば簡素化処理を行っても無意味であり、スケジュールを調整することは不可能であることから、エラー処理が行われる。
【００３４】
逆にステップＳＡ１５の判定結果が「ＮＯ」であれば、簡素化処理を施されていないバンドの中間コード画像データについて簡素化処理が行われる（ステップＳＡ１６）。前述したように、簡素化処理を施すと、最終的なラスタデータに反映されない冗長部分のデータが削除される。このことは、バンドバッファ１９の各アドレスにデータを書き込む回数が１回に低減されることを意味している。中間コード画像データを展開してラスタデータを生成し、当該ラスタデータをバンドバッファ１９に書き込む展開処理においては、最も時間を要する処理がバンドバッファ１９へのデータの書き込み処理であることから、バンドバッファ１９上の各アドレスにデータを書き込む回数を１回に低減することにより、展開処理の所要時間を大幅に短縮することができる。
そして、ステップＳＡ１６において、簡素化されていない全てのバンドについて簡素化処理が行われると、処理はステップＳＡ１３に戻り、再度、スケジュールに無理があるか否かが判定される。以降の処理は上述したことから明らかであるので、その説明を省略する。
なお、コード画像データの解釈がバンド１〜バンド６４まで順に行われない場合には、未処理のコード画像データが存在するか否か判定し、存在する場合には、そのコード画像データに対応するバンドを特定し、当該バンドに対応する保持ブロックに中間コード画像データを格納するという処理となる。
【００３５】
３：平均総未使用領域サイズ
ここで、本装置１１における保持ブロックの平均総未使用領域サイズについて検討する。
前述のように、本装置１１では、保持ブロックのサイズを中間コード画像データ格納領域のサイズとバンド分割数とに基づいて自動的に設定している。すなわち、保持ブロックのサイズは可変となっている。本装置１１における保持ブロックのサイズは、バンド分割数に反比例し、中間コード画像データ格納領域のサイズの約数となるように設定され、例えば、図３に示すように、バンド分割数を６４、中間コード画像データ格納領域のサイズを４ＭＢの場合には、保持ブロックのサイズは１６ＫＢとなっている。
【００３６】
（１）式から明らかなように、保持ブロックの平均総未使用領域サイズは、バンド分割数と保持ブロックのサイズとの積に比例する。したがって、保持ブロックの平均総未使用領域サイズを低減するためには、保持ブロックのサイズを小さくした方がよいが、小さくし過ぎると保持ブロックの管理にかかるオーバーヘッドが増大してしまう。このような理由により、例えば、本装置１１では、上述の条件の下で保持ブロックのサイズを４ＫＢとする。このような条件下で（１）式により算出される保持ブロックの平均総未使用領域サイズは、保持ブロックのサイズを１６ＫＢに固定した場合における平均総未使用領域サイズの１／４となる。ここで、例えば、中間コード画像データ格納領域のサイズを４ＭＢとすると、未使用領域の割合が１／３２となることから、未使用領域が大幅に低減されていることが分かる。しかも、本装置１１では、格納すべき中間コード画像データが存在しないバンドについては保持ブロックを確保しないことから、保持ブロックの総未使用領域サイズの更なる低減が実現されている。
【００３７】
ところで、保持ブロックのサイズの最適値を設定する際に考慮する要素の１つとして、保持ブロックの管理にかかるオーバーヘッドを挙げたが、本装置１１では、中間コード画像データの形式をも考慮して保持ブロックのサイズの最適値を設定している。本装置１１が採用している中間コード画像データの形式は、ディスプレイリストにおける矩形や台形を表す形式であり、このような形式では、各図形は同一サイズのデータ群で表現される。例えば、矩形は、基準点の座標（Ｘ，Ｙ）、高さ（Ｈ）、および幅（Ｗ）の４要素によって表現可能であり、円は、中心点の座標（Ｘ，Ｙ）、半径（Ｒ）の３要素によって表現可能である。中間コード画像データは各図形単位で得られるのが普通であることから、保持ブロックには上記４要素を単位とした書き込みが行われることになる。ここで、各要素をそれぞれ１バイトで表現するものと仮定すると、円や矩形は４バイトのデータ群によって表現されることになり、保持ブロックを有効に使用するためには、４バイトの倍数となるように保持ブロックのサイズを設定することが望ましい。このことをも考慮して本装置１１では、保持ブロックのサイズを４ＫＢとしている。なお、後述するエッジリストの集合体の場合と異なり、各図形に対する中間コード画像データのサイズは固定されていることから、ある図形について生成された中間コード画像データが、対象保持ブロックの空き領域に収まりきらないケースの発生確率は低いので、保持ブロックのサイズを更に小さくすることも可能であるが、ここでは、保持ブロックの確保にかかるオーバーヘッドを考慮して４ＫＢとしている。
【００３８】
次に、中間コード画像データがエッジリストの集合体からなる場合について検討する。この場合には、１つの図形は複数のエッジリストによって表現される。エッジリストの集合体は、図形を走査して得られる平行な線分の集合体であり、各エッジリストは１つの線分を表すデータである。通常、各エッジリストのサイズは同一であるが、１つの図形に対するエッジリストの集合体のサイズ（すなわちエッジリストの数）は同一形状の図形であっても異なる場合がある。すなわち、中間コード画像データの格納単位のサイズは可変であり、保持ブロックのサイズを小さくし過ぎると、図４に示すように、対象保持ブロック内の空き領域に収まりきらない中間コード画像データが生成され、新しい保持ブロックを確保しなければならなる可能性が高くなる。
【００３９】
さらに、場合によっては、図５に示すように、新たに確保した保持ブロックに収まらないサイズの中間コード画像データが生成されることも考えられる。もちろん、あるバンドについて新たに確保する保持ブロックのサイズを既に確保した保持ブロックよりも大きくするようにすれば、このような問題をある程度は回避することができる。しかし、各保持ブロックのサイズが同一でないと、中間コード画像データ格納領域の管理が複雑化してしまうという問題がある。例えば、重畳図形処理部の処理により不要となった保持ブロックを解放した後に、解放された領域を新しい保持ブロックに使用する場合、両ブロックのサイズが一致していないとガベージコレクションのような複雑な領域管理が必要となる。
【００４０】
さらに、対象保持ブロック内の空き領域に収まりきらない中間コード画像データが生成された場合に新しい保持ブロックを確保するようにすると、使用中の保持ブロックの空き領域が未使用領域となってしまうという欠点もある（図４参照）。この欠点は、中間コード画像データがエッジリストの集合体で表されている場合のように、中間コード画像データのサイズが可変の場合に共通して存在する欠点である。
【００４１】
４：変形例
ここで、上述した問題および欠点を解決可能な変形例について説明する。なお、説明の繁雑化を回避する目的で、ここでは中間コード画像データがエッジリストの集合体で表される場合の変形例についてのみ例示するが、エッジリストに限らず、中間コード画像データが可変サイズであれば、容易に応用可能である。
本変形例の構成は図６に示す通りであり、中間コード画像データ生成部１５に代えて、中間コード画像データ生成部１５’を設けた点のみが異なっている。ここで、中間コード画像データ生成部１５’が１つのバンドについて行う処理を図７に示す。ただし、図７は、コード画像データの変換がバンド単位で順に行われることを前提としている。この図に示すように、中間コード画像データ生成部１５’は、１つの中間コード画像データを生成すると（ステップＳＢ１）、生成した中間コード画像データのサイズと対象保持ブロックの空き容量とを比較する（ステップＳＢ２）。そして、中間コード画像データを対象保持ブロックに格納可能であれば、前述の実施形態と同様、当該中間コード画像データが当該保持ブロックに追記される（ステップＳＢ３）。
【００４２】
逆に、ステップＳＢ２の比較により中間コード画像データを対象保持ブロックに格納できないことが判明した場合には、中間コード画像データが複数（例えば２つ）の中間コード画像データに分割され、分割によって得られた各中間コード画像データ（以後、分割データ）を格納するための新しい保持ブロックが確保され、これらの保持ブロックに各分割データが格納される（ステップＳＢ４）。
【００４３】
ステップＳＢ３およびＳＢ４に後続した処理がステップＳＢ５であり、ステップＳＢ５では、対象バンド内で未変換のコード画像データが存在するか否かが判定される。この判定結果が「ＹＥＳ」の場合にはステップＳＢ１以降の処理が次のコード画像データについて繰り返され、ステップＳＢ５の判定結果が「ＮＯ」となると、当該バンドについての処理は終了する。
【００４４】
上述したステップＳＢ４における分割方法は任意であるが、本変形例では、分割された中間コード画像データ（以後、分割データ）の１つのサイズが対象保持ブロックの空き容量に最も近い、あるいは一致したサイズとなり、他の分割データのサイズが新たに確保する保持ブロックの空き領域を最小とするサイズとなるように分割される。
【００４５】
ここで、中間コード画像データの分割例を図８に示す。この図に示す例では、生成した中間コード画像データを格納するために１つの新たな保持ブロックを確保する必要があり、対象保持ブロックの空き領域のサイズと中間コード画像データのヘッダ部のサイズとに基づいた適切な位置で中間コード画像データの内容部分、すなわちエッジリストの集合体が分割される。中間コード画像データのヘッダ部のサイズは固定的に定まっていることから、エッジリストの集合体の内容部分の分割位置は、実質的には、使用中の保持ブロックの空き領域のサイズに応じて定まる。そして、ヘッダ部分を複製し、それぞれを対応するエッジリストの集合体に応じて修正する。具体的には、一方のヘッダ部分を前半のエッジリストの集合体に応じたものとし、他方のヘッダ部分を後半のエッジリストの集合体に応じたものとする。このような作業により、２つの分割データが生成される。
【００４６】
本変形例の中間コード画像データ生成部１５’は各バンドについて上述した処理を繰り返すことで、１ページ分の中間コード画像データの生成・格納を行う。その他の機能は中間コード画像データ生成部１５と同一であるので、その説明を省略する。
【００４７】
以上説明したことから明らかなように、本変形例では、１つの中間コード画像データを複数の分割データに分割できるので、固定された保持ブロックのサイズを超えたサイズの中間コード画像データを格納することができる。さらに、使用中の保持ブロックの空き領域を有効に利用できるように中間コード画像データを分割するようにしたため、使用中の保持ブロックの空き領域のサイズを超えたサイズの中間コード画像データを格納する場合にも、未使用領域の増加を抑制することができる。
【００４８】
５．補足
なお、上述した実施形態および変形例ではプリンタに適用する例を示したが、適用する対象はこれに限定されず、例えばファクシミリなど、コード画像データを展開して出力する装置に適用可能である。また、上述した実施形態および変形例では、動作プログラムをＲＯＭに格納する例を示したが、書き換え可能なメモリに格納し、フロッピーディスクなどの記録媒体あるいはネットワーク経由で動作プログラムを入手・更新できるようにしてもよい。
また、コード画像データは広い意味でのページ記述言語で記述されたデータであり、１ページ分の画像（線図、表、文字を含む）を表すデータであればよい。
また、保持ブロックのサイズを自動的に求める例を示したが、これに限らず、適宜、使用者が設定するようにしてもよい。
【００４９】
【発明の効果】
以上説明したように、本発明によれば、各分割単位について確保される保持ブロックのサイズを適切なサイズとすることができ、よって保持ブロックにおける総未使用領域を減少させることができる。
【図面の簡単な説明】
【図１】 本発明の一実施形態による画像処理装置１１の機能構成を示すブロック図である。
【図２】 同装置１１による処理の流れの一例を示すフローチャートである。
【図３】 同装置１１の動作を説明するための図である。
【図４】 同装置１１の変形例の動作を説明するための図である。
【図５】 同装置１１の変形例の動作を説明するための図である。
【図６】 同変形例の機能構成を示すブロック図である。
【図７】 同変形例による処理の流れの一例を示すフローチャートである。
【図８】 同装置１１の変形例の動作を説明するための図である。
【図９】 バンドバッファを用いた画像処理の様子を示す図である。
【符号の説明】
１１…画像処理装置、１２…上位処理部、１３…中間コード画像データブロックサイズ決定部、１４…中間コード画像データブロック管理部、１５，１５’…中間コード画像データ生成部、１６…展開部、１７…スケジュール管理部、１８…エラー処理部、１９…バンドバッファ（バンドバッファＡ〜Ｄから構成される）、２０…転送部、２１…プリンタエンジン
【発明の属する技術分野】
本発明は、１ページ分のラスタデータ保持用のメモリを持たず、入力されたコード画像データを中間コード画像データに変換して保持し、保持した中間コード画像データを展開してラスタデータを生成しつつ、このラスタデータを出力する画像処理装置および画像処理方法に関する。
【０００２】
【従来の技術】
従来より、ページプリンタのように、写真などのイメージデータや、線図、表、文字などをＰＤＬ（ページ記述言語）により記述して得られるコード画像データを入力し、当該コード画像データを解釈し、ラスタデータに展開してバッファに一旦格納し、印刷や送信などの出力動作に同期してラスタデータをバッファから読み出す画像処理装置が知られている。この種の画像処理装置では、コード画像データを展開して得られるラスタデータを一旦格納するバッファとして、フレームバッファを用いるものと、複数のバンドバッファを用いるものとがある。
【０００３】
前者を用いた装置では、フレームバッファに１ページ分のラスタデータを一旦格納し、格納したラスタデータを読み出して出力する処理が行われる。したがって、フレームバッファには１ページ分のラスタデータを格納可能な容量が要求され、コスト高を招致するという問題がある。また、複数ページにわたる画像を連続して出力する場合、各ページの出力は当該ページがフレームバッファに格納され終わるまで待たされることになり、コード画像データの入力からラスタデータの出力までにかかる時間が長いという欠点もある。
【０００４】
これに対して後者は、出力画像を副走査方向に帯状に分割した画像（バンド画像）を表すラスタデータをバンドバッファに一旦格納しつつ、格納が完了したラスタデータを順に読み出して出力する。具体的には、バンド画像を格納するバンドバッファを複数用意し、ＰＤＬで記述されたコード画像データを解釈し、バンド画像に対応するラスタデータを得るためのバンド（分割単位）毎の中間コード画像データに変換してメモリ上に一旦格納し、バンド毎の中間コード画像データを展開処理して得られるバンド画像のラスタデータをバンドバッファに一旦格納する作業を、対象バンドが変わる毎にバンドバッファを順に変更して行うとともに、複数のバンドバッファから順にラスタデータを読み出して出力する。
【０００５】
例えば、図９に示すように、出力画像を分割するバンド数が６４、バンドバッファ数が２の場合、バンド毎に生成された中間コード画像データは中間コード画像データ格納領域に格納される。この中間コード画像データ格納領域に格納された各中間コード画像データは、バンド毎に順に読み出されて展開され、バンド１に対するラスタデータがバンドバッファＡに、バンド２に対するラスタデータがバンドバッファＢに、バンド３に対するラスタデータがバンドバッファＡに、…という順序で交互に格納される。この格納作業に並行して、バンドバッファＡ，Ｂから交互にラスタデータを読み出すことにより、１ページ分のラスタデータを得ることが可能となる。
【０００６】
中間コード画像データ格納領域の容量は、バンドバッファＡ，Ｂと中間コード画像データ格納領域との総容量が１ページ分のラスタデータの容量未満となるよう設定されるので、必要となるメモリ容量はページバッファの容量未満となる。したがって、後者では、画像処理装置の製造コストを低減できるという利点がある。しかも、出力画像がカラー画像の場合、前者ではカラープレーンの数だけバッファ数を倍増させる必要があるが、後者では必ずしもその必要はない、という差異がある。さらに、後者では、ある程度のバンド画像に相当するラスタデータが得られた段階で出力段へのデータ供給を開始できるので、コード画像データの入力からラスタデータの出力までにかかる時間を短縮することができるとともに、出力段の処理がボトルネックとなりがちなプリンタに適用した場合には、印刷処理全体の所要時間を短縮することができる。
【０００７】
ここで、中間コード画像データ格納領域の具体的な管理方式について例を挙げて説明する。特開平３−１１４８５６号公報に開示されたプリンタデータ管理方式では、入力したコード画像データに対して複数のバンドが設定されると、まず、中間コード画像データを格納する上で必要な最小容量の基本ブロックをバンド毎に確保し、中間コード画像データが生成されると、当該中間コード画像データに対応したバンドの基本ブロックに当該中間コード画像データを格納し、当該バンドにおいて基本ブロックの容量を超えて中間コード画像データが生成されると、ある程度の中間コード画像データを保持可能な拡張ブロックをメモリから確保し、確保した拡張ブロックに中間コード画像データを格納し、中間データ管理テーブルによって、使用中の各ブロックと当該バンドと対応付けるようにしている。
【０００８】
【発明が解決しようとする課題】
ところで、特開平３−１１４８５６号公報に開示されたプリンタデータ管理方式では、基本ブロックはバンド毎に必ず確保されるブロックであり、その容量は固定的に定まっている。また、拡張ブロックの容量も固定的に定まっており、このことがメモリの利用効率の低下を招いている。ここでは、説明の繁雑化を回避するために、基本ブロックの容量と拡張ブロックの容量とを同一として、メモリの利用効率について検討する。
【０００９】
基本ブロックおよび拡張ブロック（以後、中間コード画像データ保持ブロック）の平均総未使用領域サイズは次式で表される。ただし、０．５は、各ブロックにおける平均利用効率である。
【００１０】
本発明は上述した事情に鑑みてなされたものであり、１ページ分のラスタデータ保持用のメモリを持たず、入力されたコード画像データを中間コード画像データに変換して保持し、保持した中間コード画像データを展開してラスタデータを生成しつつ、このラスタデータを出力する画像処理装置において、中間コード画像データを効率よく保持することができる画像処理装置および画像処理方法を提供することを目的とする。
【００１１】
【課題を解決するための手段】
上述した課題を解決するために、本発明に係る画像処理装置は、ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、コード画像データを変換して中間コード画像データを生成する変換手段と、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段とを備え、前記サイズ決定手段は、前記分割単位の数に基づいて、または、前記中間コード画像データの形式に基づいて、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定することを特徴としている。
上記画像処理装置によれば、サイズ決定手段によって、上記保持ブロックのサイズが、分割単位の数または中間コード画像データの形式に基づいて適切なサイズに決定され、保持ブロックにおいて使用されない未使用領域が減少する。
また、本発明の別の態様に係る画像処理装置は、ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、コード画像データを変換して中間コード画像データを生成する変換手段と、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段と、１つの中間コード画像データを分割して複数の中間コード画像データを生成する分割手段と、を備え、前記格納手段は、前記分割手段により生成された複数の中間コード画像データを、前記確保手段により確保された対応する分割単位の複数の保持ブロックに格納することを特徴としている。
上記画像処理装置によれば、上記分割手段によって１つの中間コード画像データが複数に分割され、その各々が上記確保手段によって確保された保持ブロックへ上記格納手段によって格納されるので、保持ブロックにおいて使用されない未使用領域が減少する。
また、本発明の別の態様に係る画像処理装置にあっては、ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、コード画像データを変換して中間コード画像データを生成する変換手段と、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段とを備え、前記確保手段は、前記変換手段により中間コード画像データが生成されない分割単位については、保持ブロックを確保しないことを特徴としている。
上記画像処理装置によれば、上記変換手段により中間コード画像データが生成されない分割単位については、上記確保手段による保持ブロックの確保は行われないので、保持ブロックにおける未使用領域が減少する。
【００１３】
また、上述した課題を解決するために、本発明に係る画像処理方法は、ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理方法において、前記分割単位の数あるいは中間コード画像データの形式に基づいて、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定ステップと、コード画像データを変換して中間コード画像データを生成する変換ステップと、前記サイズ決定ステップで決定されたサイズの保持ブロックを分割単位毎に確保する確保ステップと、前記確保ステップで確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納ステップとを有することを特徴としている。このため、サイズ決定ステップで決定される保持ブロックのサイズは適切なサイズとなり、各分割単位について確保される保持ブロックにおいて使用されない総未使用領域が減少する。
【００１４】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について説明する。
１：構成
図１は本発明の一実施形態による画像処理装置１１の機能構成を示すブロック図であり、この図に示す機能構成の画像処理装置１１は、実際には、動作プログラムを格納したＲＯＭ（Read Only Memory）、ＲＯＭに格納された動作プログラムを実行するＣＰＵ（中央処理装置）、ＣＰＵに読み書きされるＲＡＭ（Random Access Memory）、各種Ｉ／Ｏインタフェースとを備えている。この画像処理装置１１は、プリンタエンジン２１が接続されていることから明らかなように、コード画像データを入力し、これに対応した印刷出力を得るプリンタに適用されている。
【００１５】
図１の画像処理装置１１において、１２はＰＤＬで記述されたコード画像データを入力してその内容を解釈する上位処理部であり、コード画像データの特定部（例えばヘッダ）の解釈によって得られる用紙サイズと予め設定されたバンドバッファのサイズとに基づいてバンドの分割数を決定し、決定した分割数を後述する中間コード画像データブロックサイズ決定部１３へ通知するとともに、中間コード画像データブロックサイズ決定部１３に対して中間コード画像データ保持ブロック（以後、単に保持ブロック）のサイズの決定処理を行うよう指示する。また、上位処理部１２は、コード画像データの内容を解釈して、展開すべきコード画像データ中の描画データを後述する中間コード画像データ生成部１５へ供給して中間コード画像データを分割数に応じた単位であるバンド単位で生成するよう指示するとともに、分割数などを後述する展開部１６へ渡し、中間コード画像データ生成部１５にて生成される中間コード画像データをバンド単位で展開するよう指示する。
【００１６】
中間コード画像データブロックサイズ決定部１３は、上位処理部１２からの指示の入力を契機とし、上位処理部１２から供給された分割数とＲＡＭ上に設定された中間コード画像データ格納領域のサイズとに基づいて保持ブロックのサイズ（以後、ブロックサイズ）を決定し、決定したブロックサイズを後述する中間コード画像データブロック管理部１４へ供給するとともに、中間コード画像データブロック管理部１４に対して、当該ブロックサイズを単位とした中間コード画像データ格納領域の管理を開始するよう指示する。なお、中間コード画像データ格納領域のサイズは、各バンドバッファと中間コード画像データ格納領域との合計サイズが１ページ分の出力画像を表すラスタデータのサイズ未満となるよう予め設定されている。
【００１７】
展開部１６は、上位処理部１２からの指示に基づいて作動し、上位処理部１２から供給された分割数を中間コード画像データ生成部１５へ供給するとともに、中間コード画像データ生成部１５により生成された中間コード画像データを展開してバンド毎のラスタデータを生成し、生成したラスタデータをバンドバッファに書き込む処理を行う。
【００１８】
中間コード画像データ生成部１５は、上位処理部１２からの指示に基づいて、描画データをバンド毎に変換し、バンド毎の中間コード画像データを生成する。この中間コード画像データ生成部１５は、あるバンドの中間コード画像データの最初の生成時に、中間コード画像データブロック管理部１４へ当該バンドの識別情報（例えばバンド番号）を供給するとともに、当該バンドについての保持ブロックを確保するよう指示する。そして、中間コード画像データ生成部１５は、生成した中間コード画像データを、中間コード画像データブロック管理部１４から供給された情報（例えば、保持ブロックの開始および終了アドレス）で表される保持ブロックに格納する。また、中間コード画像データ生成部１５は、あるバンドについて生成した中間コード画像データの累計サイズが、現在使用中の保持ブロックの未使用領域サイズを超過した時に、中間コード画像データブロック管理部１４に対して、当該バンドの識別情報を供給するとともに当該バンドについての保持ブロックを新たに確保するよう指示する。
【００１９】
中間コード画像データブロック管理部１４は、中間コード画像データブロックサイズ決定部１３からの指示を契機とし、中間コード画像データブロックサイズ決定部１３で決定されたブロックサイズに基づいて、当該ブロックサイズによる中間コード画像データ格納領域の管理を開始する。また、中間コード画像データブロック管理部１４は、中間コード画像データ生成部１５からの指示および識別情報に基づいて保持ブロックを確保して管理するとともに、確保した保持ブロックを表す情報を中間コード画像データ生成部１５へ供給する。なお、ここでいう「管理」とは、保持ブロックのアドレスと識別情報および確保順序とを対応付けて記憶しておくことを意味する。また、中間コード画像データブロック管理部１４は、中間コード画像データ格納領域内の未使用保持ブロックの不足により保持ブロックを確保できなかった場合には、その旨の情報を中間コード画像データ生成部１５へ供給する。
【００２０】
また、展開部１６は、上位処理部１２による１ページあるいは１ジョブ分のコード画像データの解釈および中間コード画像データ生成部１５による変換処理が完了すると、保持ブロックに格納された中間コード画像データをバンド毎に読み出して展開することでバンド毎のラスタデータを生成し、これらをバンドバッファ１９に書き込む。バンドバッファ１９は同一容量のバンドバッファＡ，Ｂ，Ｃ，Ｄから構成されており、展開部１６は各バンドバッファに対してバンド毎に巡回的にラスタデータを書き込む。
【００２１】
また、中間コード画像データ生成部１５は重畳図形処理部を包含している。重畳図形処理部は中間コード画像データのデータ表現を簡素化する処理を行うものであり、中間コード画像データブロック管理部１４において新たな保持ブロックの確保に失敗した場合（例えば中間コード画像データ格納領域の全てを使い切ってしまった場合など）に、中間コード画像データのサイズを低減し、不要となった保持ブロックを回収して再利用可能とする目的で上記簡素化処理を行う。
【００２２】
ここでいう簡素化処理は周知の処理であり、例えば、同一バンド内で空間的に重なっている複数の図形を別々のコード群ではなく１つの図形を表す１つのコード群で表す処理などを言う。例えば、ＰＤＬの仕様が、複数の図形の重複部分の色を最後に描画された図形の色とするような仕様の場合には、背後に隠れてしまう部分のデータは冗長であり、この冗長部分を削除すればデータの簡素化を図ることができる、というのが上記簡素化処理の基本的思想である。この重畳図形処理部がバンド毎の中間コード画像データを簡素化することによって全領域が未使用となった保持ブロックは中間コード画像データブロック管理部１４により解放され、解放された領域は新たな保持ブロックとして確保可能な領域となる。
【００２３】
１７はスケジュール管理部であり、展開部１６から中間コード画像データへの変換が終了した旨の情報を受け取ると、コード画像データの展開処理とプリンタエンジン２１による出力処理との間のタイミング調整を行う。特に、本装置のようにバンドバッファ１９を用いる場合には、バンドバッファ２９へのラスタデータへの書き込みが間に合わないと、出力画像にいわゆる「白抜け」が発生してしまうため、スケジュール管理部１７は、各バンドの中間コード画像データを展開してバンドバッファ１９に書き込む処理にかかる時間（以後、処理時間）を展開部１６に問い合わせ、これに対応して展開部１６から各バンドの処理時間の予測値が渡されると、これらを出力順に並べたスケジュールとプリンタエンジン２１の出力速度とを比較し、バンドバッファ１９への書き込みが間に合わないバンドを抽出し、当該バンドの中間コード画像データに簡素化処理を施すよう指示する。ただし、簡素化処理を行うのは、バンドバッファ１９への書き込みが間に合わないバンドについて未だ簡素化処理が行われていない場合のみである。
【００２４】
また、スケジュール管理部１７は、バンドバッファ１９への書き込みが間に合わないバンドが存在しない場合には、展開部１６に対してバンドバッファ１９への書き込みを開始するよう指示するとともに、上記スケジュールに応じたタイミングでバンドバッファ１９からの読み出しを許可する旨の情報を後述の転送部２０へ供給する。なお、簡素化処理を行ってもバンドバッファ１９への書き込みが間に合わないバンドが存在する場合には、エラー処理部１８に対してその旨を表す情報を供給する。ただし、本装置１１では、バンドバッファの数を４としているので、展開部１６による展開処理の開始タイミングをプリンタエンジン２１による出力処理の開始タイミングよりも十分に早く設定することが可能であり、簡素化処理を行ってもバンドバッファ１９への書き込みが間に合わないバンドが存在する確率は極めて低い。なお、エラー処理部１８の処理内容は適用する装置（ここではプリンタ）に応じて適宜設計すべき事項であることから、ここではその説明を省略する。
【００２５】
一方、展開部１６は、スケジュール管理部１７から展開処理時間の問い合わせを受けると、中間コード画像データの形式に応じた方法により、各バンドの中間コード画像データの内容とバンドバッファ１９への中間コード画像データの書き込み速度とに基づいた計算処理を行って各バンドの展開処理時間を算出し、各処理時間をスケジュール管理部１７へ供給する。また、展開部６は、スケジュール管理部１７からバンドバッファ１９への書き込みが間に合わないバンドの中間コード画像データの簡素化を指示されると、当該中間コード画像データの簡素化処理を中間コード画像データ生成部１５内の重畳図形処理部に依頼する。さらに、展開部１６は、スケジュール管理部１７からの所定の指示を契機として、中間コード画像データをラスタデータへ展開しバンドバッファ１９に格納する展開処理を開始する。
【００２６】
転送部２０は、バンドバッファＡ，Ｂ，Ｃ，Ｄ，Ａ，Ｂ，…というように巡回的に対象バンドバッファを変更しつつ、対象バンドバッファから読み出したラスタデータをプリンタエンジン２１へ転送する。具体的には、転送部２０は、スケジュール管理部１７から対象バンドバッファからの読み出しを許可する情報が供給され、さらにプリンタエンジン２１による出力処理が可能となると、対象バンドバッファから１バンド分のラスタデータを読み出しプリンタエンジン２１へ転送し、この転送が終了すると、その旨の情報をスケジュール管理部１７へ渡すとともに、対象バンドバッファを次のバンドバッファとする。なお、転送部２０とスケジュール管理部１７とのやりとりを排し、転送部２０が予め設定されたタイミングで対象バンドバッファからのラスタデータの読み出しを行うようにしてもよい。
【００２７】
２：動作
次に、上述した構成の本装置１１の動作例について図２を参照して説明する。なお、以降の説明において、処理の主体については上述した構成の説明から明らかであることから、処理の主体の記載を省略することがある。
図２は本装置１１による処理の流れの一例を示すフローチャートであり、この例はコード画像データの解釈がバンド１〜バンド６４まで順に行われることを前提としている。この図に示す例では、本装置１１では、外部からＰＤＬで記述されたコード画像データが入力されると、まずブロックサイズが決定され（ステップＳＡ１）、最初のバンド（図９中ではバンド１）が以降の処理の対象バンドとなる（ステップＳＡ２）。
【００２８】
次に、対象バンドに未変換のコード画像データが存在するか否かが判定され（ステップＳＢ３）、存在する場合には未変換のコード画像データが中間コード画像データへ変換される（ステップＳＡ４）。そして、この変換により生成された中間コード画像データを格納するための保持ブロックを新たに確保する必要があるか否かが判定される（ステップＳＡ５）。各バンドについて、最初は保持ブロックが確保されていないことから、この判定結果は「ＹＥＳ」となり、４ＫＢの保持ブロックが新たに確保される（ステップＳＡ６）。ステップＳＡ６において保持ブロックの確保に成功した場合、ステップＳＡ４で生成された中間コード画像データが当該保持ブロックに格納され（ステップＳＡ７，ＳＡ８）、処理はステップＳＡ３に戻る。
【００２９】
以後、ステップＳＡ３以降の処理が繰り返されるが、保持ブロックを確保した直後であることから、通常は新たに保持ブロックを確保する必要はない。したがって、ステップＳＡ５の判定結果は「ＮＯ」となり、生成された中間コード画像データが保持ブロックに追記され（ステップＳＡ８）、ステップＳＡ３の処理に戻る。
【００３０】
なお、ステップＳＡ７での判定結果が「ＹＥＳ」となった場合、すなわち新たな保持ブロックの確保に失敗し、さらにステップＳＡ９での判定結果が「ＹＥＳ」となった場合、すなわち簡素化処理を施していないバンドが存在しないときには、エラー処理が行われてステップＳＡ３以降のループから脱出する。逆に、ステップＳＡ９での判定結果が「ＮＯ」となった場合、すなわち簡素化処理を施していないバンドが存在するときには、当該バンドの中間コード画像データに簡素化処理が施され、中間コード画像データ格納領域における空き領域の拡大が図られる（ステップＳＡ１０）。
【００３１】
対象バンドの全コード画像データの変換を終了し、ステップＳＡ３の判定結果が「ＮＯ」となると、処理はステップＳＡ１１へ進み、ここで次のバンドが存在するか否かが判定される。ここでは現在の対象バンドはバンド１であり、次のバンドはバンド２として存在することからステップＳＡ１１の判定結果は「ＹＥＳ」となり、次のバンド（ここではバンド２）が対象バンドとなり（ステップＳＡ１２）、ステップＳＡ３の処理に戻る。以後、対象バンドがバンド６４となるまで上述した処理が繰り返され、全てのバンド１〜６４についての中間コード画像データが生成・格納される。
【００３２】
全てのバンド１〜６４についての中間コード画像データが生成・格納されると、ステップＳＡ１１の判定結果が「ＮＯ」となり、スケジュールに無理があるか否か、すなわち「白抜け」が発生し得るか否かが判定される（ステップＳＡ１３）。なお、上記スケジュールは、前述したように、各バンドの中間コード画像データの内容とバンドバッファ１９へのデータの書き込み速度とに基づいて求められる。そして、ステップＳＡ１３の判定結果が「ＮＯ」の場合、中間コード画像データの展開処理およびプリンタエンジン２１による出力処理が上記スケジュールに従って開始される（ステップＳＡ１４）。
【００３３】
逆にステップＳＡ１３の判定結果が「ＹＥＳ」の場合、全てのバンドについて中間コード画像データの簡素化処理が施されたか否かが判定される（ステップＳＡ１５）。この判定結果が「ＹＥＳ」であれば簡素化処理を行っても無意味であり、スケジュールを調整することは不可能であることから、エラー処理が行われる。
【００３４】
逆にステップＳＡ１５の判定結果が「ＮＯ」であれば、簡素化処理を施されていないバンドの中間コード画像データについて簡素化処理が行われる（ステップＳＡ１６）。前述したように、簡素化処理を施すと、最終的なラスタデータに反映されない冗長部分のデータが削除される。このことは、バンドバッファ１９の各アドレスにデータを書き込む回数が１回に低減されることを意味している。中間コード画像データを展開してラスタデータを生成し、当該ラスタデータをバンドバッファ１９に書き込む展開処理においては、最も時間を要する処理がバンドバッファ１９へのデータの書き込み処理であることから、バンドバッファ１９上の各アドレスにデータを書き込む回数を１回に低減することにより、展開処理の所要時間を大幅に短縮することができる。
そして、ステップＳＡ１６において、簡素化されていない全てのバンドについて簡素化処理が行われると、処理はステップＳＡ１３に戻り、再度、スケジュールに無理があるか否かが判定される。以降の処理は上述したことから明らかであるので、その説明を省略する。
なお、コード画像データの解釈がバンド１〜バンド６４まで順に行われない場合には、未処理のコード画像データが存在するか否か判定し、存在する場合には、そのコード画像データに対応するバンドを特定し、当該バンドに対応する保持ブロックに中間コード画像データを格納するという処理となる。
【００３５】
３：平均総未使用領域サイズ
ここで、本装置１１における保持ブロックの平均総未使用領域サイズについて検討する。
前述のように、本装置１１では、保持ブロックのサイズを中間コード画像データ格納領域のサイズとバンド分割数とに基づいて自動的に設定している。すなわち、保持ブロックのサイズは可変となっている。本装置１１における保持ブロックのサイズは、バンド分割数に反比例し、中間コード画像データ格納領域のサイズの約数となるように設定され、例えば、図３に示すように、バンド分割数を６４、中間コード画像データ格納領域のサイズを４ＭＢの場合には、保持ブロックのサイズは１６ＫＢとなっている。
【００３６】
（１）式から明らかなように、保持ブロックの平均総未使用領域サイズは、バンド分割数と保持ブロックのサイズとの積に比例する。したがって、保持ブロックの平均総未使用領域サイズを低減するためには、保持ブロックのサイズを小さくした方がよいが、小さくし過ぎると保持ブロックの管理にかかるオーバーヘッドが増大してしまう。このような理由により、例えば、本装置１１では、上述の条件の下で保持ブロックのサイズを４ＫＢとする。このような条件下で（１）式により算出される保持ブロックの平均総未使用領域サイズは、保持ブロックのサイズを１６ＫＢに固定した場合における平均総未使用領域サイズの１／４となる。ここで、例えば、中間コード画像データ格納領域のサイズを４ＭＢとすると、未使用領域の割合が１／３２となることから、未使用領域が大幅に低減されていることが分かる。しかも、本装置１１では、格納すべき中間コード画像データが存在しないバンドについては保持ブロックを確保しないことから、保持ブロックの総未使用領域サイズの更なる低減が実現されている。
【００３７】
ところで、保持ブロックのサイズの最適値を設定する際に考慮する要素の１つとして、保持ブロックの管理にかかるオーバーヘッドを挙げたが、本装置１１では、中間コード画像データの形式をも考慮して保持ブロックのサイズの最適値を設定している。本装置１１が採用している中間コード画像データの形式は、ディスプレイリストにおける矩形や台形を表す形式であり、このような形式では、各図形は同一サイズのデータ群で表現される。例えば、矩形は、基準点の座標（Ｘ，Ｙ）、高さ（Ｈ）、および幅（Ｗ）の４要素によって表現可能であり、円は、中心点の座標（Ｘ，Ｙ）、半径（Ｒ）の３要素によって表現可能である。中間コード画像データは各図形単位で得られるのが普通であることから、保持ブロックには上記４要素を単位とした書き込みが行われることになる。ここで、各要素をそれぞれ１バイトで表現するものと仮定すると、円や矩形は４バイトのデータ群によって表現されることになり、保持ブロックを有効に使用するためには、４バイトの倍数となるように保持ブロックのサイズを設定することが望ましい。このことをも考慮して本装置１１では、保持ブロックのサイズを４ＫＢとしている。なお、後述するエッジリストの集合体の場合と異なり、各図形に対する中間コード画像データのサイズは固定されていることから、ある図形について生成された中間コード画像データが、対象保持ブロックの空き領域に収まりきらないケースの発生確率は低いので、保持ブロックのサイズを更に小さくすることも可能であるが、ここでは、保持ブロックの確保にかかるオーバーヘッドを考慮して４ＫＢとしている。
【００３８】
次に、中間コード画像データがエッジリストの集合体からなる場合について検討する。この場合には、１つの図形は複数のエッジリストによって表現される。エッジリストの集合体は、図形を走査して得られる平行な線分の集合体であり、各エッジリストは１つの線分を表すデータである。通常、各エッジリストのサイズは同一であるが、１つの図形に対するエッジリストの集合体のサイズ（すなわちエッジリストの数）は同一形状の図形であっても異なる場合がある。すなわち、中間コード画像データの格納単位のサイズは可変であり、保持ブロックのサイズを小さくし過ぎると、図４に示すように、対象保持ブロック内の空き領域に収まりきらない中間コード画像データが生成され、新しい保持ブロックを確保しなければならなる可能性が高くなる。
【００３９】
さらに、場合によっては、図５に示すように、新たに確保した保持ブロックに収まらないサイズの中間コード画像データが生成されることも考えられる。もちろん、あるバンドについて新たに確保する保持ブロックのサイズを既に確保した保持ブロックよりも大きくするようにすれば、このような問題をある程度は回避することができる。しかし、各保持ブロックのサイズが同一でないと、中間コード画像データ格納領域の管理が複雑化してしまうという問題がある。例えば、重畳図形処理部の処理により不要となった保持ブロックを解放した後に、解放された領域を新しい保持ブロックに使用する場合、両ブロックのサイズが一致していないとガベージコレクションのような複雑な領域管理が必要となる。
【００４０】
さらに、対象保持ブロック内の空き領域に収まりきらない中間コード画像データが生成された場合に新しい保持ブロックを確保するようにすると、使用中の保持ブロックの空き領域が未使用領域となってしまうという欠点もある（図４参照）。この欠点は、中間コード画像データがエッジリストの集合体で表されている場合のように、中間コード画像データのサイズが可変の場合に共通して存在する欠点である。
【００４１】
４：変形例
ここで、上述した問題および欠点を解決可能な変形例について説明する。なお、説明の繁雑化を回避する目的で、ここでは中間コード画像データがエッジリストの集合体で表される場合の変形例についてのみ例示するが、エッジリストに限らず、中間コード画像データが可変サイズであれば、容易に応用可能である。
本変形例の構成は図６に示す通りであり、中間コード画像データ生成部１５に代えて、中間コード画像データ生成部１５’を設けた点のみが異なっている。ここで、中間コード画像データ生成部１５’が１つのバンドについて行う処理を図７に示す。ただし、図７は、コード画像データの変換がバンド単位で順に行われることを前提としている。この図に示すように、中間コード画像データ生成部１５’は、１つの中間コード画像データを生成すると（ステップＳＢ１）、生成した中間コード画像データのサイズと対象保持ブロックの空き容量とを比較する（ステップＳＢ２）。そして、中間コード画像データを対象保持ブロックに格納可能であれば、前述の実施形態と同様、当該中間コード画像データが当該保持ブロックに追記される（ステップＳＢ３）。
【００４２】
逆に、ステップＳＢ２の比較により中間コード画像データを対象保持ブロックに格納できないことが判明した場合には、中間コード画像データが複数（例えば２つ）の中間コード画像データに分割され、分割によって得られた各中間コード画像データ（以後、分割データ）を格納するための新しい保持ブロックが確保され、これらの保持ブロックに各分割データが格納される（ステップＳＢ４）。
【００４３】
ステップＳＢ３およびＳＢ４に後続した処理がステップＳＢ５であり、ステップＳＢ５では、対象バンド内で未変換のコード画像データが存在するか否かが判定される。この判定結果が「ＹＥＳ」の場合にはステップＳＢ１以降の処理が次のコード画像データについて繰り返され、ステップＳＢ５の判定結果が「ＮＯ」となると、当該バンドについての処理は終了する。
【００４４】
上述したステップＳＢ４における分割方法は任意であるが、本変形例では、分割された中間コード画像データ（以後、分割データ）の１つのサイズが対象保持ブロックの空き容量に最も近い、あるいは一致したサイズとなり、他の分割データのサイズが新たに確保する保持ブロックの空き領域を最小とするサイズとなるように分割される。
【００４５】
ここで、中間コード画像データの分割例を図８に示す。この図に示す例では、生成した中間コード画像データを格納するために１つの新たな保持ブロックを確保する必要があり、対象保持ブロックの空き領域のサイズと中間コード画像データのヘッダ部のサイズとに基づいた適切な位置で中間コード画像データの内容部分、すなわちエッジリストの集合体が分割される。中間コード画像データのヘッダ部のサイズは固定的に定まっていることから、エッジリストの集合体の内容部分の分割位置は、実質的には、使用中の保持ブロックの空き領域のサイズに応じて定まる。そして、ヘッダ部分を複製し、それぞれを対応するエッジリストの集合体に応じて修正する。具体的には、一方のヘッダ部分を前半のエッジリストの集合体に応じたものとし、他方のヘッダ部分を後半のエッジリストの集合体に応じたものとする。このような作業により、２つの分割データが生成される。
【００４６】
本変形例の中間コード画像データ生成部１５’は各バンドについて上述した処理を繰り返すことで、１ページ分の中間コード画像データの生成・格納を行う。その他の機能は中間コード画像データ生成部１５と同一であるので、その説明を省略する。
【００４７】
以上説明したことから明らかなように、本変形例では、１つの中間コード画像データを複数の分割データに分割できるので、固定された保持ブロックのサイズを超えたサイズの中間コード画像データを格納することができる。さらに、使用中の保持ブロックの空き領域を有効に利用できるように中間コード画像データを分割するようにしたため、使用中の保持ブロックの空き領域のサイズを超えたサイズの中間コード画像データを格納する場合にも、未使用領域の増加を抑制することができる。
【００４８】
５．補足
なお、上述した実施形態および変形例ではプリンタに適用する例を示したが、適用する対象はこれに限定されず、例えばファクシミリなど、コード画像データを展開して出力する装置に適用可能である。また、上述した実施形態および変形例では、動作プログラムをＲＯＭに格納する例を示したが、書き換え可能なメモリに格納し、フロッピーディスクなどの記録媒体あるいはネットワーク経由で動作プログラムを入手・更新できるようにしてもよい。
また、コード画像データは広い意味でのページ記述言語で記述されたデータであり、１ページ分の画像（線図、表、文字を含む）を表すデータであればよい。
また、保持ブロックのサイズを自動的に求める例を示したが、これに限らず、適宜、使用者が設定するようにしてもよい。
【００４９】
【発明の効果】
以上説明したように、本発明によれば、各分割単位について確保される保持ブロックのサイズを適切なサイズとすることができ、よって保持ブロックにおける総未使用領域を減少させることができる。
【図面の簡単な説明】
【図１】 本発明の一実施形態による画像処理装置１１の機能構成を示すブロック図である。
【図２】 同装置１１による処理の流れの一例を示すフローチャートである。
【図３】 同装置１１の動作を説明するための図である。
【図４】 同装置１１の変形例の動作を説明するための図である。
【図５】 同装置１１の変形例の動作を説明するための図である。
【図６】 同変形例の機能構成を示すブロック図である。
【図７】 同変形例による処理の流れの一例を示すフローチャートである。
【図８】 同装置１１の変形例の動作を説明するための図である。
【図９】 バンドバッファを用いた画像処理の様子を示す図である。
【符号の説明】
１１…画像処理装置、１２…上位処理部、１３…中間コード画像データブロックサイズ決定部、１４…中間コード画像データブロック管理部、１５，１５’…中間コード画像データ生成部、１６…展開部、１７…スケジュール管理部、１８…エラー処理部、１９…バンドバッファ（バンドバッファＡ〜Ｄから構成される）、２０…転送部、２１…プリンタエンジン
Claims (6)
- ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、
コード画像データを変換して中間コード画像データを生成する変換手段と、
中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、
前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、
前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段と
を備え、
前記サイズ決定手段は、前記分割単位の数に基づいて、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定する
ことを特徴とする画像処理装置。 - ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、
コード画像データを変換して中間コード画像データを生成する変換手段と、
中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、
前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、
前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段と
を備え、
前記サイズ決定手段は、前記中間コード画像データの形式に基づいて、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定する
ことを特徴とする画像処理装置。 - ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、
コード画像データを変換して中間コード画像データを生成する変換手段と、
中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定手段と、
前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、
前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段と
１つの中間コード画像データを分割して複数の中間コード画像データを生成する分割手段と、
を備え、
前記格納手段は、前記分割手段により生成された複数の中間コード画像データを、前記確保手段により確保された対応する分割単位の複数の保持ブロックに格納する
ことを特徴とする画像処理装置。 - ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理装置において、
コード画像データを変換して中間コード画像データを生成する変換手段と、
中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイ ズに決定するサイズ決定手段と、
前記サイズ決定手段により決定されたサイズの保持ブロックを分割単位毎に確保する確保手段と、
前記確保手段により確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納手段と
を備え、
前記確保手段は、前記変換手段により中間コード画像データが生成されない分割単位については、保持ブロックを確保しない
ことを特徴とする画像処理装置。 - ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理方法において、
前記分割単位の数に基づいて、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定ステップと、
コード画像データを変換して中間コード画像データを生成する変換ステップと、
前記サイズ決定ステップで決定されたサイズの保持ブロックを分割単位毎に確保する確保ステップと、
前記確保ステップで確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納ステップと
を有することを特徴とする画像処理方法。 - ページ記述言語で記述された１ページ分のコード画像データを、１ページを複数に分割して得られる複数の分割単位毎に中間コード画像データへ変換してから出力する画像処理方法において、
中間コード画像データの形式に基づいて、中間コード画像データが一時的に格納される保持ブロックのサイズを１種類の固定サイズに決定するサイズ決定ステップと、
コード画像データを変換して中間コード画像データを生成する変換ステップと、
前記サイズ決定ステップで決定されたサイズの保持ブロックを分割単位毎に確保する確保ステップと、
前記確保ステップで確保された分割単位毎の保持ブロックに、対応する分割単位の中間コード画像データを格納する格納ステップと
を有することを特徴とする画像処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02603398A JP3713937B2 (ja) | 1998-02-06 | 1998-02-06 | 画像処理装置および画像処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP02603398A JP3713937B2 (ja) | 1998-02-06 | 1998-02-06 | 画像処理装置および画像処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11224172A JPH11224172A (ja) | 1999-08-17 |
| JP3713937B2 true JP3713937B2 (ja) | 2005-11-09 |
Family
ID=12182403
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP02603398A Expired - Fee Related JP3713937B2 (ja) | 1998-02-06 | 1998-02-06 | 画像処理装置および画像処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3713937B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6850338B1 (en) * | 2000-05-12 | 2005-02-01 | International Business Machines Corporation | Method, system, program, and data structure for generating raster objects |
| JP2016179504A (ja) * | 2015-03-23 | 2016-10-13 | ブラザー工業株式会社 | 切断装置 |
-
1998
- 1998-02-06 JP JP02603398A patent/JP3713937B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11224172A (ja) | 1999-08-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20010043725A1 (en) | Printing apparatus, information processing apparatus, data processing method for use in such an apparatus, and storage medium storing computer-readable program | |
| US5737501A (en) | Printer control unit and method | |
| JP4695815B2 (ja) | 描画処理装置および描画処理方法およびコンピュータが読み取り可能な記憶媒体およびプログラム | |
| JP2610993B2 (ja) | 情報処理装置及び方法 | |
| JP3713937B2 (ja) | 画像処理装置および画像処理方法 | |
| US6552816B1 (en) | Printing system and printer | |
| JPH03105687A (ja) | 画像合成方法 | |
| JPH06106810A (ja) | 画像形成方法及び装置 | |
| JPH11157146A (ja) | 印刷装置の画像処理方法および印刷装置 | |
| JP2500647B2 (ja) | プリンタシステム | |
| JPS63182150A (ja) | レ−ザプリンタ制御装置 | |
| JP3809284B2 (ja) | 画像生成装置及びその制御方法及び印刷装置 | |
| JPH03114856A (ja) | プリンタデータ管理方式 | |
| JPH09277616A (ja) | プリンタ及びその制御方法 | |
| JP2901824B2 (ja) | 画像記録装置および画像記録方法 | |
| JPH07172022A (ja) | 印刷制御装置 | |
| JPH0877371A (ja) | 画像形成装置 | |
| JP3695094B2 (ja) | 印刷処理システム、印刷処理方法、印刷処理制御プログラムが記録されたコンピュータ読み取り可能な記録媒体、及び印刷処理システムに用いられるデータ変換装置 | |
| JP3211711B2 (ja) | 描画装置、描画方法、プリンタおよび画像表示装置 | |
| JP3592921B2 (ja) | データ制御装置 | |
| JP2992049B2 (ja) | 画像編集装置 | |
| JPH10825A (ja) | 画像処理装置 | |
| JP3450958B2 (ja) | 印刷装置及び印刷方法 | |
| JP3483468B2 (ja) | 情報処理方法及び装置並びに記憶媒体 | |
| JP3414285B2 (ja) | データ登録装置およびデータ登録用プログラムを記憶した記憶媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040921 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041005 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041206 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050308 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050509 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050802 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050815 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090902 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100902 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110902 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120902 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120902 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130902 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |