(57)【要約】【課題】プロセス間通信処理コストを低減し、処理スループットの向上を図る。【解決手段】ＰＤＬの印刷データを解析し、印刷画像を分割した複数のバンド画像を生成する第１処理部と、複数のバンド画像を取得して印刷装置に転送する第２処理部と、一部のバンド画像を保存可能な容量を有する記憶部と、を備え、第１処理部と第２処理部とが並列で処理可能な印刷画像生成装置において、記憶部は、バンド画像を個別に記憶可能なｎ（ｎは３以上の整数）個の領域を有し、第１処理部は、ｍ（ｍは２以上、ｎ−１以下の整数）個の領域に、バンド画像を順次生成し、バンド画像の生成が完了したら、第２処理部に完了を通知する画像生成／通知処理を繰り返し実行し、第２処理部は、第１処理部から通知を受信したら、ｍ個の領域から、バンド画像を順次取得する画像取得処理を繰り返し実行する。【選択図】図４
2012196923.tif 000002
【特許請求の範囲】
【請求項１】
ページ記述言語で記述された印刷データから、印刷装置で出力可能な印刷画像を生成する印刷画像生成装置において、
前記印刷データを解析し、前記印刷画像の元となる複数の分割画像を生成する第１処理部と、
前記複数の分割画像を取得して加工し、前記印刷装置に転送する第２処理部と、
前記複数の分割画像の一部を保持可能な容量の記憶部と、
を備え、
前記第１処理部と前記第２処理部とは、並列で処理可能に構成され、
前記記憶部は、前記分割画像を個別に記憶するｎ（ｎは３以上の整数）個の領域を有し、
前記第１処理部は、ｍ（ｍは２以上、ｎ−１以下の整数）個の前記領域に前記分割画像を順次生成し、前記分割画像の生成が完了したら、前記第２処理部に通知する画像生成／通知処理を、１ページ分の前記分割画像の処理が終了するまで繰り返し実行し、
前記第２処理部は、前記第１処理部から前記通知を受信したら、ｍ個の前記領域から前記分割画像を順次取得する画像取得処理を、１ページ分の前記分割画像の処理が終了するまで繰り返し実行する、
ことを特徴とする印刷画像生成装置。
【請求項２】
１ページ分の前記分割画像の内、未処理の前記分割画像が、ｍ未満の所定数の場合、
前記第１処理部は、前記所定数の前記領域に前記分割画像を順次生成し、
前記第２処理部は、前記所定数の前記領域から前記分割画像を順次取得する、
ことを特徴とする請求項１に記載の印刷画像生成装置。
【請求項３】
ｎ個の前記領域には、前記分割画像を生成する順に、１からｎの番号が割り当てられており、
前記第１処理部は、ｎ番目の前記領域に前記分割画像を生成した後は、１番目の前記領域に戻って前記分割画像を生成する、
ことを特徴とする請求項１又は２に記載の印刷画像生成装置。
【請求項４】
ｍは、前記第１処理部がｎ−ｍ個の前記分割画像を生成する間に、前記第２処理部がｍ個の前記分割画像を前記記憶部から取得可能な値に設定される、
ことを特徴とする請求項１乃至３のいずれか一に記載の印刷画像生成装置。
【請求項５】
ページ記述言語で記述された印刷データを解析し、印刷装置で出力可能な印刷画像の元となる複数の分割画像を記憶部に生成する処理と、前記記憶部から前記複数の分割画像を取得して加工し、前記印刷装置に転送する処理と、を並列で実行可能な装置で動作する制御プログラムであって、
前記記憶部は、前記複数の分割画像の一部を保持可能な容量を持ち、前記分割画像を個別に記憶するｎ（ｎは３以上の整数）個の領域を有し、
前記装置を、
ｍ（ｍは２以上、ｎ−１以下の整数）個の前記領域に前記分割画像を順次生成し、前記分割画像の生成が完了したら、ｍ個の前記領域から前記分割画像を順次取得する第２処理部に通知する画像生成／通知処理を、１ページ分の前記分割画像の処理が終了するまで繰り返し実行する第１処理部、として機能させる、
ことを特徴とする制御プログラム。
【請求項６】
１ページ分の前記分割画像の内、未処理の前記分割画像が、ｍ未満の所定数の場合、
前記第１処理部は、前記所定数の前記領域に前記分割画像を順次生成し、
前記第２処理部は、前記所定数の前記領域から前記分割画像を順次取得する、
ことを特徴とする請求項５に記載の制御プログラム。
【請求項７】
ｎ個の前記領域には、前記分割画像を生成する順に、１からｎの番号が割り当てられており、
前記第１処理部は、ｎ番目の前記領域に前記分割画像を生成した後は、１番目の前記領域に戻って前記分割画像を生成する、
ことを特徴とする請求項５又は６に記載の制御プログラム。
【請求項８】
ｍは、前記第１処理部がｎ−ｍ個の前記分割画像を生成する間に、前記第２処理部がｍ個の前記分割画像を前記記憶部から取得可能な値に設定される、
ことを特徴とする請求項５乃至７のいずれか一に記載の制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷画像生成装置及び制御プログラムに関し、特に、印刷画像を分割したバンド画像を生成する処理と生成したバンド画像を転送する処理とを並列で実行する印刷画像生成装置及び当該印刷画像生成装置で動作する制御プログラムに関する。
【背景技術】
【０００２】
近年、プリンタコントローラ等の組込み機器において、Linux等の汎用ＯＳ（Operating System）をベースとし、組込み機器用にリアルタイム機能などを強化したＯＳが広く用いられつつある。このようなＯＳでは、メモリ管理上の特徴として、カーネル空間とユーザー空間が分離され、また各ユーザー空間も他のユーザー空間から分離されており、各プロセス間でデータの受け渡しを行う場合は、プロセス間通信を行う必要がある。プロセス間通信を行う場合、ＯＳレベルで見た内部処理として、データのユーザー空間／カーネル空間におけるコピー及びプロセスのコンテキストスイッチングが行われるため、その処理コストは比較的大きなものとなる。また、特に中高速プリンタ用コントローラにおいては、ハードウェアプラットフォームの主プロセッサ部にマルチコアプロセッサを採用したものが増加しつつある。
【０００３】
このようなＯＳやハードウェアをプラットフォーム構成要素として採用し、ソフトウェアによって、ＰＤＬ（Page Description Language）を解析して印刷画像を生成する処理や印刷画像を加工して印刷装置に転送する処理を実行する場合、全体処理を複数の処理単位に分割して並列処理することが、処理スループットを向上させるためのキーポイントとなる。
【０００４】
処理スループットを向上させる技術として、例えば、下記特許文献１には、複数プロセッサにより同一データを重複して処理する二度手間を軽減させ、キャッシュを効率良く使用する方法が開示されている。また、下記特許文献２には、印刷コマンドバッファ中の異なるコマンドの処理を複数プロセッサにより並行して行う方法が開示されている。また、下記特許文献３には、各描画要素のイメージング処理に要する負荷を考慮し、負荷が均一になるようプロセッサ割り当てを行う方式が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１３２０８２号公報
【特許文献２】特開２００３−０６７１５６号公報
【特許文献３】特開平１０−０５２９５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記並列処理の単位としては、ＯＳ的な見地から見ると「プロセス」と「スレッド」とが考えられる。後者のほうがより軽量でありパフォーマンス上の利点が大きいが、前者と比較すると１プロセスサイズが巨大化し易い。また、ＲＩＰ（Raster Image Processing）、暗号化、圧縮伸長、その他各種画像処理機能などに数種の外部ソースコードあるいは外部ライブラリを利用する場合、シンボル定義の重複、あるいは参照ライブラリバーション不一致等の理由により、単一モジュール生成が不可能となるケースなども考えられ、このような場合にはプロセス分割を行うことが不可避となる。また、スレッド分割が可能なケースにおいても、スレッド間の通信に要する処理コストは皆無となるわけではなく、通信削減の必要性は、相対的に小さいながらもやはり存在する。
【０００７】
また、印刷画像、特にフルカラー画像の保持方法を考えると、メモリ容量の制限により１ページ分の画像をオンメモリで保持することが困難となり、バンド分割処理が必要となる場合が多い。画像をバンド分割処理することは、キャッシュの有効活用の点からも利点がある。画像生成を行うにあたっては、格納メモリ中の同一アドレス値に対して複数回のアクセスを行うことが通常であるため、この点では、バンド分割を行い、さらにバンド幅（Band Height）をある程度狭くし、少なくとも全体がキャッシュに収まるサイズとすることは、画像生成処理速度の向上という点においてはプラス方向に働く。特に、共有メモリ型マルチプロセッサではメモリアクセスがボトルネックとなり易く、ＣＰＵ（Central Processing Unit）のローカルキャッシュの使用率向上は特に有効である。
【０００８】
しかしながら、バンド分割を細分化すると、バンド画像を生成する度に、プロセス間通信が発生するため、プロセス間通信処理コストの増大につながってしまうという問題点がある。
【０００９】
本発明は、上記問題点に鑑みてなされたものであって、その主たる目的は、プロセス間通信処理コストを低減し、処理スループットの向上を図ることができる印刷画像生成装置及び制御プログラムを提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明は、ページ記述言語で記述された印刷データから、印刷装置で出力可能な印刷画像を生成する印刷画像生成装置において、前記印刷データを解析し、前記印刷画像の元となる複数の分割画像を生成する第１処理部と、前記複数の分割画像を取得して加工し、前記印刷装置に転送する第２処理部と、前記複数の分割画像の一部を保持可能な容量の記憶部と、を備え、前記第１処理部と前記第２処理部とは、並列で処理可能に構成され、前記記憶部は、前記分割画像を個別に記憶するｎ（ｎは３以上の整数）個の領域を有し、前記第１処理部は、ｍ（ｍは２以上、ｎ−１以下の整数）個の前記領域に前記分割画像を順次生成し、前記分割画像の生成が完了したら、前記第２処理部に通知する画像生成／通知処理を、１ページ分の前記分割画像の処理が終了するまで繰り返し実行し、前記第２処理部は、前記第１処理部から前記通知を受信したら、ｍ個の前記領域から前記分割画像を順次取得する画像取得処理を、１ページ分の前記分割画像の処理が終了するまで繰り返し実行するものである。
【００１１】
また、本発明は、ページ記述言語で記述された印刷データを解析し、印刷装置で出力可能な印刷画像の元となる複数の分割画像を記憶部に生成する処理と、前記記憶部から前記複数の分割画像を取得して加工し、前記印刷装置に転送する処理と、を並列で実行可能な装置で動作する制御プログラムであって、前記記憶部は、前記複数の分割画像の一部を保持可能な容量を持ち、前記分割画像を個別に記憶するｎ（ｎは３以上の整数）個の領域を有し、前記装置を、ｍ（ｍは２以上、ｎ−１以下の整数）個の前記領域に前記分割画像を順次生成し、前記分割画像の生成が完了したら、ｍ個の前記領域から前記分割画像を順次取得する第２処理部に通知する画像生成／通知処理を、１ページ分の前記分割画像の処理が終了するまで繰り返し実行する第１処理部、として機能させるものである。
【発明の効果】
【００１２】
本発明の印刷画像生成装置及び制御プログラムによれば、マルチコアプロセッサやリアタイムLinuxＯＳ等を構成要素とするプリンタコントローラプラットフォームにおいて、マルチプロセスによる印刷画像生成／転送の並列処理を実現する場合、バッファの空き待ちが発生する頻度を極小化しつつ、プロセス間通信回数を削減し、これによって、印刷画像生成／転送速度を向上させ、高速印刷装置への対応度を向上させることができる。
【００１３】
その理由は、複数のバンド画像を生成してバンドバッファに記憶する第１処理部と、バンドバッファからバンド画像を読み出して加工し、印刷装置に転送する第２処理部とを備える印刷画像生成装置において、第１処理部は、ｎ（ｎは３以上の整数）個のバンドバッファの内、ｍ（ｍは２以上、ｎ−１以下の整数）個のバンドバッファ、すなわち、１以上のバンドバッファを残した複数のバンドバッファにバンド画像を生成した後、第２処理部に画像生成通知を行う動作を繰り返すため、画像生成通知の回数を削減することができると共に、第２処理部がバンド画像を転送してバンドバッファを空にしなくても次のバンド画像の生成を実行することができるからである。
【図面の簡単な説明】
【００１４】
【図１】印刷画像生成／転送処理の概要を説明する図である。
【図２】従来の印刷画像生成／転送処理方法を説明する図である。
【図３】プロセス間通信の削減に着目した印刷画像生成／転送処理方法を説明する図である。
【図４】本発明の一実施の形態に係る印刷画像生成／転送処理方法を説明する図である。
【図５】リングバッファにおけるバンドバッファの使用順序を説明する図である。
【図６】本発明の一実施例に係る印刷画像生成システムの構成を模式的に示す図である。
【図７】本発明の一実施例に係るプリンタコントローラの機能を示すブロック図である。
【図８】本発明の一実施例に係るＰＤＬ処理を概説する図である。
【図９】本発明の一実施例に係る印刷画像生成装置の動作（バンド画像生成／通知処理）を示すフローチャート図である。
【図１０】本発明の一実施例に係る印刷画像生成装置の動作（バンド画像取得処理）を示すフローチャート図である。
【発明を実施するための形態】
【００１５】
ＰＤＬを解釈し、ラスタライズして印刷画像を生成した後、印刷装置へ転送する機能（プリンタコントローラ機能）を実現するためのプラットフォームとして、Linux等の汎用ＯＳをベースとし、組込み機器用にリアルタイム機能などを強化したＯＳが広く用いられつつある。また、特に中高速プリンタ用コントローラにおいては、ハードウェアプラットフォームの主プロセッサ部にマルチコアプロセッサを採用したものが増加しつつある。
【００１６】
これらのものを構成要素として採用したプラットフォームにおいて、印刷画像生成／転送処理を、ハードウェア能力を生かす形で（つまり、処理並列化する形で）構築する場合の１つの典型的な形態として、印刷画像生成処理及び印刷画像転送処理をそれぞれ別プロセス化し、バンドバッファを各プロセスからアクセス可能とし、画像生成通知をプロセス間通信により行うという形態が考えられる。
【００１７】
上記処理モデルにおけるバンド分割の方法に注目すると、バンド分割を細分化することは、キャッシュメモリの有効利用の点からは利点がある。特に共有メモリ型マルチプロセッサにおいては、ローカルキャッシュを有効活用することが処理スループット向上のために重要である。しかしながら、バンド生成の都度、プロセス間通信が発生するような処理モデルでは、バンド分割の細分化は、プロセス間通信増加によるスループット低下の要因ともなり得る。
【００１８】
このようなジレンマを解決するための方法として、複数のバンド画像を一括生成し、その後にプロセス間通信により画像生成通知を行う方式が考えられる。しかしながら、確保しているバッファの全てを使用し、バンド画像の生成を行った後に画像生成通知を行い、その後に転送処理と次のバンド画像の生成を並列処理するような方法では、バッファに空きが生じるまで次のバンド画像を生成することができず、待ち時間が発生してしまい、スループットの向上が阻害されてしまう。
【００１９】
上記問題について、図面を参照して説明する。図１は、リアルタイムLinux等の汎用系ＯＳとマルチコアプロセッサを搭載したプラットフォームにおける印刷画像生成／転送処理を模式的に示す図である。
【００２０】
図１において、ＰＤＬ解析・画像生成処理を行う第１機能と、画像加工・印刷装置転送処理を行う第２機能は、それぞれ独立したプロセスであり、並列動作可能である。フレームバッファは、バンド画像を格納するバンドバッファ群より成る。メモリ制限により１ページ分の画像を保持することは出来ないが、複数のバンド画像の保持（図では、バンドバッファ１〜バンドバッファ７を利用した７つのバンド画像の保持）が可能であるものとする。なお、「バンド」という用語は、「ページ」を複数部分に分割したものを指し、バンド画像は、１ページの印刷画像の元となる分割画像を指す。
【００２１】
第１機能は、ＰＤＬで記述された印刷データを解析し、フレームバッファ中のバンドバッファのいずれかにバンド画像を生成する。その際、単純な方法として、図２に示すように、１バンド分のバンド画像を生成した後、第２機能に該当するプロセスに対して画像生成通知を発行し、その後、自らは次のバンド画像の生成処理に移る方法がある。この場合、基本的に、常にバンド画像生成処理と加工／転送処理が並列処理されていることになり、第２機能は第１機能に対して、１つ前のバンド画像に対する処理を行っていることになる。
【００２２】
この従来の方法は、比較的単純な方法であり、また、並列処理によりマルチコアプロセッサリソースを活用することができるが、バンド画像の生成処理毎にプロセス間通信（画像生成通知）が発生するため、プロセス間通信処理コストがスループットに悪影響を与えてしまうという欠点がある。
【００２３】
プロセス間通信処理コストを削減する方法として、図３に示すように、第１機能においてバンドバッファ数分（図では７つ）のバンド画像を生成した後に、第２機能に対して画像生成通知を行い、直後に第１機能は次のバンド群の生成を開始する方法、つまり、１バンド単位でなく、総バンドバッファ数に該当する７バンド単位で並列処理を行うことにより、プロセス間通信回数の削減を図る方法が考えられる。
【００２４】
しかしながら、この方式では、第１機能がバンド８以降のバンド画像の生成を開始した時点では、バンドバッファは全て使用中（印刷装置への転送が未完了）であり、少なくとも１つのバンドバッファが空き状態となるまで、バンド画像をバンドバッファに生成することができず、さらに、バンドバッファが空き状態となった時点での第２機能から第１機能への通知（図のバッファ使用可能通知）が必要となってしまい、スループット向上が阻害されてしまうこととなる。
【００２５】
そこで、本発明の一実施の形態では、全てのバンドバッファの中の少なくとも１つを空のバンドバッファとして残しながら、複数のバンドバッファをリングバッファ状に使用して行くという方式を採用し、これにより、プロセス間通信コストの削減とバンドバッファの空き待ち時間の極小化を合わせて実現する。
【００２６】
具体的には、図４に示すように、第１機能においては、バンドバッファの総数（ｎ＝７個）より、一定個数（ここでは２個とするが、実装時のデータ生成／取得処理の処理コストの比率に応じて適宜変更可能である。）を差し引いた個数（ｍ＝５個）に対して、順次バンド画像の生成を行い、その後、第２機能に対して画像生成通知を発行する。その直後、第１機能は６番目のバンドバッファ６を使用してバンド画像の生成を継続する。この時点でバンドバッファ６は空きバッファであるため、直ちにバンド画像の生成処理を進行することができる。
【００２７】
そして、第１機能は、バンド７のバンド画像をバンドバッファ７に生成し終わった後、バンド８のバンド画像のバンドバッファ１への出力を開始するが、この時点でバンドバッファ１内のバンド画像の転送は完了しており、バンドバッファの空き待ちが発生することはない。表現を変えると、バンドバッファの空き待ちが発生しないように、バッファ使用に余裕を持たせることが肝要であり、それが、この例では、７バンドバッファ中５バンドバッファを使用しながら並列処理を行うこととなる。バンドバッファの総数ｎとバンド画像を生成するバンドバッファ数ｍを用いて表現すると、ｍの値を、第１機能がｎ−ｍ個のバンド画像を生成する間に、第２機能がｍ個のバンド画像をバンドバッファから取得可能な値に設定することにより、バンドバッファの空き待ちが発生しないようにすることができる。
【００２８】
ここで、バンドバッファ数（＝７）に対し、１度の画像生成処理において生成するバンド画像の数（＝５）を「基本生成バンド数」と呼ぶことにし、後述の実施例における処理フロー（図９、図１０）においてもこの用語を使用する。また、バッファ使用において余裕を持たせる個数（＝２）も、上述したようにデータ生成／取得処理の処理コストの比率により適宜変更可能であるが、後述の実施例を含め、２個であることを前提として説明を行う。
【００２９】
図５は、本実施形態の方法において、いかなる順番でバンドバッファを使用するかを示しており、バンドバッファを２個ずつ余裕を持たせながらリングバッファ状に使用していく方式となっている。具体的には、１回目の処理で、バンドバッファ１〜５（１番目からｍ個のバンドバッファ）に対してバンド画像を生成し、２回目の処理で、バンドバッファ６と７（ｍ＋１番目からｎ−ｍ個のバンドバッファ）とバンドバッファ１〜３（１番目から２ｍ−ｎ個のバンドバッファ）に対してバンド画像を生成し、以下、同様に処理を繰り返す。
【００３０】
ここで、「リングバッファ」という用語は、バッファ（バンドバッファ）を、「最初はその先頭から使用し、その終端に達すると再度先頭から使用する」、すなわち、「線形のバッファ構造でありながら円環状のバッファ構造が実現されているかのような操作アルゴリズムによりアクセスする」という点に着目して用いる用語である。後述の実施例におけるバッファ操作アルゴリズム説明時には、特に説明上妥当と考えられる場合には「リングバッファ」の用語を使用して説明を行うが、実体としては「リングバッファ」＝「バンドバッファ」となる。
【実施例】
【００３１】
上記した本発明の実施の形態についてさらに詳細に説明すべく、本発明の一実施例に係る印刷画像生成装置及び制御プログラムについて、図６乃至図１０を参照して説明する。図６は、本発明の一実施例に係る印刷画像生成システムの構成を模式的に示す図である。また、図７は、プリンタコントローラの機能を示すブロック図であり、図８は、ＰＤＬ処理を概説する図である。また、図９及び図１０は、本実施例の印刷画像生成装置の動作を示すフローチャート図である。
【００３２】
［システム構成］
図６に示すように、本実施例の印刷画像生成システム１０は、印刷データ（本実施例では、再利用オブジェクトと一次利用オブジェクトを含むバリアブル印刷データ）を生成して印刷指示を行うクライアント端末２０と、印刷データの各ページをラスタライズして印刷画像を生成するプリンタコントローラ４０と、印刷画像に基づいて印刷を実行する印刷装置３０とで構成される。クライアント端末２０とプリンタコントローラ４０は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などのネットワークで接続されており、プリンタコントローラ４０と印刷装置３０は、専用のインターフェースで接続されている。
【００３３】
クライアント端末２０は、ＣＰＵ、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などのメモリ、ＨＤＤ（Hard Disk Drive）、ＮＩＣ（Network Interface Card）等から構成され、ＲＯＭやＨＤＤに記憶されたプログラム（ＯＳやアプリケーションソフト、プリンタドライバなど）をＲＡＭに展開し、ＣＰＵで実行する。
【００３４】
プリンタコントローラ４０は、ＣＰＵ（マルチコア構成の主プロセッサ）、ＲＯＭなＲＡＭなどのメモリ（主記憶装置）、ＨＤＤ（補助記憶装置）、ネットワークインターフェース（ＮＩＣやＶｉｄｅｏＩ／Ｆ）等から構成され、ＲＯＭやＨＤＤに記憶されたプログラム（ＰＤＬ解析・印刷画像生成処理や画像加工・印刷装置転送処理などを実行する制御プログラム）をＲＡＭに展開し、ＣＰＵで実行する。
【００３５】
印刷装置３０は、ネットワークプリンタや複合機（ＭＦＰ：Multi-Function Peripheral）などの画像形成装置である。
【００３６】
なお、図１では、プリンタコントローラ４０と印刷装置３０とを別々の装置としているが、プリンタコントローラ４０を基板として印刷装置３０に組み込んでもよい。また、図１では、印刷画像生成システム１０にクライアント端末２０を含めているが、プリンタコントローラ４０のＨＤＤやサーバなどに記憶されたデータを利用して印刷を実行する場合は、クライアント端末２０を省略することもできる。
【００３７】
上記構成の印刷画像生成システム１０の動作について概説すると、クライアント端末２０は、アプリケーションソフトあるいはプリンタドライバ等により、各種ＰＤＬのいずれかの形式で記述された印刷データを生成し、ＬＡＮケーブルなどを経由して、生成した印刷データをプリンタコントローラ４０に送信する。プリンタコントローラ４０は、印刷データを解読し、ラスタライズして印刷画像を生成し、専用のＶｉｄｅｏＩ／Ｆを経由して、生成した印刷画像を印刷装置３０に転送する。印刷装置３０は、電子写真方式等の印刷プロセスに基づき、印刷画像を紙媒体に出力する。
【００３８】
次に、本実施例の特徴であるプリンタコントローラ４０の詳細構成について説明する。プリンタコントローラ４０は、ハードウェア構成としてはマルチコア構成の主プロセッサ、主記憶装置、補助記憶装置、ＮＩＣ、ＶｉｄｅｏＩ／Ｆ等からなり、リアルタイムLinuxＯＳにより制御される。このようなプラットフォーム構成をベースとし、ＰＤＬ解析・印刷画像生成処理や画像加工・印刷装置転送処理を実行する機能がアプリケーション機能として実装されることになる。
【００３９】
図７は、プリンタコントローラ４０の機能を示すブロック図である。ＮＩＣ４９、ネットワークドライバ４６を経由して取り込まれたＰＤＬは、スプーラ４１により補助記憶装置５０へ格納される。ジョブスケジューラ４２により処理可能と判定されたＰＤＬは、ＰＤＬアナライザ４３によりその種別が判定され、対応する処理機能を持つＰＤＬプロセッサ４４へ渡される。ＰＤＬプロセッサ４４としては、各種ＰＤＬに対応するものが補助記憶装置５０に格納されており、ＰＤＬ処理対象と判定されたものがその都度ロードされ、実行されることになる。ＰＤＬの種別としては、PostScript／ＰＤＦ（Portable Document Format）、ＰＣＬ（Printer Control Language）ＸＬ／５、ＸＰＳ（XML Paper Specification）、ＰＰＭＬ（Personalized Print Markup Language）等がサポートされる。
【００４０】
原則的に主記憶装置５１上にロードされて実行されるＰＤＬプロセッサは、同時には１個のみであるが、ＰＤＬの種別が「ＰＰＭＬ」である場合は例外的であり、ＰＰＭＬ及びPostScript／ＰＤＦに対応するもの合計２個が同時に主記憶装置５１上に存在することになる。その理由は、ＰＰＭＬの部品画像に関しては、必ず内部機能を利用してPostScript形式に変換し、その後にPostScript部品画像のラスタライズ処理と、ラスタライズ済み画像同士の合成（ＰＰＭＬ処理）を繰り返しながら印刷画像を生成するからである。
【００４１】
さて、ＰＤＬプロセッサ４４は、ＰＤＬの解読を行い、印刷画像を分割したバンド画像を主記憶装置（共有メモリ）５１上に生成する。さらにＰＤＬプロセッサ４４は、この時、印刷画像の生成が完了したことを、プロセス間通信によりラスタ画像プロセッサ４５に通知する（図中点線の流れ）。ラスタ画像プロセッサ４５は、図に示した経路とは別の経路により、通知されたジョブ指示（ＰＤＬの部分情報）等に基づき、画像シフト／回転等の処理を行った後、ＶＩＦドライバ４７、VideoＩ／Ｆ５２を経由して、バンド画像を印刷装置３０へ転送する。
【００４２】
Linuxカーネル４８はＯＳ機能であり、アプリケーション機能よりハードウェア層の機能を利用する場合、また、ＰＤＬプロセッサ４４よりラスタ画像プロセッサ４５に対して画像生成通知を発行する場合のように、プロセス間通信によりアプリケーション機能同士で通信を行う場合等に、その機能が利用される。
【００４３】
次に、ＰＤＬプロセッサ４４及びラスタ画像プロセッサ４５の機能について説明する。図８は、ＰＤＬ種別が「ＰＰＭＬ」である場合の、ＰＤＬプロセッサ４４及びラスタ画像プロセッサ４５の機能の詳細を示している。
【００４４】
通常のＰＰＭＬでは、任意のＰＤＬ（通常はＰＤＦで記述されることが多い。）により記述された「部品画像」とＰＰＭＬ記述ファイルがＺＩＰアーカイブ化された形でクライアント装置２０より投入される。ＰＰＭＬ記述は、複数ページで参照される部品画像である「再利用オブジェクト」の記述、及び、単一ページで参照される部品画像である「一時利用オブジェクト」の記述を中心とする各種記述から成っている。再利用オグジェクトに関しては、ＰＰＭＬ言語の設計思想では、ラスタライズ後の画像を高速記憶装置にキャッシュし、ページ／バンドの画像生成の際、キャッシュ内の画像を使用して処理を高速化することが期待されており、本実施例もこのような処理モデルに沿ったものとなっている。なお、以下の説明では混乱を避けるため、ＰＤＬからラスタライズされた部品画像を生成する処理を、特に「ＲＩＰ」という用語を使用して示すこととする。
【００４５】
図８の一重実線は、入力ファイルを取得し、解凍及び形式変換を行う処理の流れを示している。ＰＤＬプロセッサ（ＰＰＭＬ）４４ｂにおける解凍・PostScript化機能は、ＰＤＬアナライザ４３より発行されたジョブ開始通知を受信すると、補助記憶装置５０よりＺＩＰ形式でアーカイブされた入力ファイルを読み出し、解凍する。解凍したものはＰＰＭＬファイルと部品画像ファイルに分かれ、いずれも再び補助記憶装置５０に格納される。なお、部品画像は必ずPostScriptに形式変換し、１ファイルにまとめた状態で格納する。
【００４６】
図８の点線は、PostScript形式の再利用オブジェクトファイルをＲＩＰし、主記憶装置５１内に格納（キャッシュ）する処理の流れである。再利用オブジェクトＲＩＰ機能は、補助記憶装置５０より部品画像ファイルを取得し、その中の再利用オブジェクト記述部を判別し、ＰＤＬプロセッサ（PostScript／ＰＤＦ）４４ａの機能を利用して当該再利用オブジェクトのＲＩＰ処理を行う。ＲＩＰ後の画像は、主記憶装置５１中の再利用オブジェクトキャッシュ領域に格納する。
【００４７】
図８の一点鎖線は、一次利用オブジェクトファイルをＲＩＰし、主記憶装置５１内にバッファリングする処理の流れである。一次利用オブジェクトＲＩＰ機能は、補助記憶装置５０より部品画像ファイルを取得し、その中の一次利用オブジェクト記憶部を判別し、ＰＤＬプロセッサ（PostScript／ＰＤＦ）４４ａの機能を利用して当該一次利用オブジェクトのＲＩＰ処理を行う。ＲＩＰ後の画像は、主記憶装置５１中のＲＩＰ後画像格納領域に格納する。
【００４８】
図８の二重実線は、キャッシュされた再利用オブジェクト画像及びバッファリングされた一次利用オブジェクト画像をバンドバッファ上に合成出力し、さらにその画像を取得する処理の流れである。バンド合成機能は、画像透過情報及びＺオーダー情報を考慮した上で再利用オブジェクトキャッシュ領域及びＲＩＰ後画像格納領域の画像を合成し、フレームバッファに出力する。また、バンド合成機能は、バンド合成完了時に、ラスタ画像プロセッサ４５に対して画像生成通知を発行する。ラスタ画像プロセッサ４５のバンド取得機能は、画像生成通知受信後、フレームバッファよりバンド画像を取得する。この後、バンド加工処理機能は、取得済みバンド画像に対してジョブ指示に基づく回転／シフト処理を施し、また、バンド転送処理機能は、加工済みバンド画像の印刷装置３０への転送を行う。
【００４９】
次に、本実施例の印刷画像生成装置４０の動作について、図９及び図１０のフローチャート図を参照して説明する。
【００５０】
［バンド画像生成／通知処理詳細］
まず、ＰＤＬプロセッサ４４の動作について説明する。図９は、バンド画像生成／通知処理の手順を示すフローチャートであり、１ページ分のバンド画像生成処理に該当している。
【００５１】
まず、Ｓ１０１において、「基本生成バンド数」変数に対して、主記憶装置（共有メモリ）に存在する総バンドバッファ数から２を減算した数を代入する。「基本生成バンド数」は、前述したように、プロセス間通信により画像生成通知を発行するための単位バンド数である。その後、Ｓ１０２において、バンド画像を保存する「カレントバンドバッファ」を、先頭のバンドバッファに設定する。
【００５２】
次に、「今回生成数」変数に対して、生成すべきバンド数を設定する。この変数を保持することは、ページの最終部分において基本生成バンド数に満たないバンド群の生成と通知を行う必要が生じる場合に対処する意味を持つ。具体的には、Ｓ１０４において、残りバンド数が基本生成バンド数より小さいか否かを判定し、小さい場合は、Ｓ１０５において、今回生成数に残りバンド数を設定し、等しいか又は大きい場合は、Ｓ１０６において、今回生成数に基本生成バンド数を設定する。
【００５３】
次に、「今回生成数」分のバンド画像をリングバッファに出力する処理を行う。まず、Ｓ１０８において、カレントバンドバッファに対する出力が可能か否かの判定を行い、ロックされており出力できない場合は、Ｓ１０９において一定時間待った後、再度Ｓ１０８の判定を行う。カレントバンドバッファに対して出力可能な場合は、Ｓ１１０において、１バンドの生成処理（１つのバンド画像をバンドバッファに保存する処理）を行い、さらにＳ１１１において、カレントバンドバッファのポインタに１を加算する。次に、Ｓ１１２において、この時点でカレントバンドバッファが終端のバンドバッファをオーバーしているか否かの判定を行い、オーバーしている場合は、Ｓ１１３において、カレントバンドバッファを先頭のバンドバッファに設定し直す。Ｓ１０７は、「今回生成数」分のバンド画像をリングバッファ出力し終わったか否かを判定する処理であり、「今回生成数」分の出力が終わっていない間は、Ｓ１０８〜Ｓ１１３の処理を繰り返す。
【００５４】
「今回生成数」分の出力が終わった場合は、Ｓ１１４において、ラスタ画像プロセッサ４５へ画像生成通知を発行する。そして、Ｓ１１５において、残りバンド数から今回生成数を減算し、その後、Ｓ１１６においてカレントバンドバッファのポインタに２を加算する。次に、Ｓ１１７において、この時点でカレントバンドバッファが終端のバンドバッファをオーバーしているか否かの判定を行い、オーバーしている場合は、Ｓ１１８において、カレントバンドバッファのポインタからオーバーしているバンドバッファ数を減算し、リングバッファ内の正しい位置を示すようにする。
【００５５】
その後、Ｓ１０３において、１ページ分全てのバンド画像生成／通知が終了したか否かの判定を行う。全てのバンド画像生成／通知が終了していない間は、Ｓ１０４〜Ｓ１１４を繰り返し、終了している場合は、そこで１ページ分の処理の終了となる。
【００５６】
［バンド画像取得処理詳細］
次に、ラスタ画像プロセッサ４５の動作について説明する。図１０は、１ページ分のバンド画像を取得する手順を示すフローチャート図であり、概ねバンド画像生成／通知処理と相似的なフローとなっている。
【００５７】
先ず、Ｓ２０１において、「基本取得バンド数」変数に対して、総バンドバッファ数から２を減算した数を代入し、その後、Ｓ２０２において、バンド画像を読み出す「カレントバンドバッファ」を、先頭バンドバッファに設定する。
【００５８】
次に、「今回取得数」変数に対して、取得すべきバンド数を設定する。具体的には、Ｓ２０４において、残りバンド数が基本取得バンド数より小さいか否かを判定し、小さい場合は、Ｓ２０５において、今回取得数に残りバンド数を設定し、等しいか又は大きい場合は、Ｓ２０６において、今回取得数に基本取得バンド数を設定する。次に、Ｓ２０７において、バンド画像生成通知を受信する。通知が行われていない場合は、当該事象の発生までブロックされた後、受信することとなる。
【００５９】
通知受信後は、「今回取得数」分のバンド画像をリングバッファから取得する処理を行う。まず、Ｓ２０９において、カレントバンドバッファから１バンド取得し、Ｓ２１０において、カレントバンドバッファのロックを解除した後、さらにＳ２１１において、カレントバンドバッファのポインタに１を加算する。次に、Ｓ２１２において、この時点でカレントバンドバッファのポインタが終端のバンドバッファをオーバーしているか否かの判定を行い、オーバーしている場合は、Ｓ２１３において、カレントバンドバッファを先頭バンドバッファに設定し直す。Ｓ２０８は、「今回取得数」分のバンド画像をバンドバッファから取得し終わったか否かを判定する処理であり、「今回取得数」分の取得が終わっていない間は、Ｓ２０９〜Ｓ２１３の処理を繰り返す。
【００６０】
「今回取得数」分の取得が終わった場合は、Ｓ２１４において、残りバンド数から今回取得数を減算し、その後、Ｓ２１５において、カレントバンドバッファのポインタに２を加算する。次に、Ｓ２１６において、この時点でカレントバンドバッファのポインタが終端のバンドバッファをオーバーしているか否かの判定を行い、オーバーしている場合は、Ｓ２１７において、カレントバンドバッファのポインタからオーバーしているバンドバッファ数を減算し、リングバッファ内の正しい位置を示すようにする。
【００６１】
その後、Ｓ２０３において、１ページ分全てのバンド画像取得が終了したか否かの判定を行う。全てのバンド画像取得が終了していない間は、Ｓ２０４〜Ｓ２１４を繰り返し、終了している場合は、そこで１ページ分の処理の終了となる。
【００６２】
最後に、図９のバンド画像生成／転送フロー及び図１０のバンド画像取得フローによる非同期処理において、バンド排他制御がいかに実現されているか、また、通信回数の削減及びバンドバッファの空き待ち発生の極小化がいかに具現化されているかを説明する。
【００６３】
先ず排他制御に関して、Ｓ１０８、Ｓ１０９において、カレントバンドバッファが使用中（ラスタ画像プロセッサ４５による取得が完了していない状態）である可能性があるため、ロック／アンロックの確認を行い、アンロックされるまで待ってＳ１１０のバンド生成処理へ進む方法をとっている。アンロックを実行する取得側の処理はＳ２１０である。取得側では、Ｓ２０７の画像生成通知受信をトリガとしてバンド取得処理が開始される。この時点で、バンドバッファ数−２個、つまり「基本取得数」分のバンド画像が生成されていることが保証されるため、取得側は無条件に取得を行い、終了するたびにバッファのロックを解除して行くことになる。
【００６４】
プロセス間通信については、画像生成通知の発行処理がＳ１１４、受信処理がＳ２０７であり、フローチャートから分かるように、複数バンド生成／取得後に送受信されており、発行回数が削減されている。バンドバッファの使用方法としては、生成側がＳ１１６〜Ｓ１１８、取得側がＳ２１５〜Ｓ２１７においてバンドバッファを２個飛ばしながらＲＥＡＤ／ＷＲＩＴＥを行うことにより、Ｓ１０９のバンドバッファの空き待ち処理の実際の発生頻度を極小化する仕組みを実現している。
【００６５】
このように、本実施例によれば、ＰＤＬプロセッサ４４は、ｎ（ｎは３以上の整数）個のバンドバッファの内、ｍ（ｍは２以上、ｎ−１以下）のバンドバッファにバンド画像を生成した後、ラスタ画像プロセッサ４５に画像生成通知を行う動作を繰り返し、ラスタ画像プロセッサ４５は、画像生成通知を受け取った後、順次バンドバッファからバンド画像を読み出して印刷装置３０に転送する動作を実行することにより、プロセス間通信処理コストを低減し、印刷処理の効率化を図ることができる。
【００６６】
なお、上記実施例は、上記実施例に限定されるものではなく、本発明の趣旨を逸脱しない限りにおいて、その構成や制御は適宜変更可能である、
【００６７】
例えば、上記実施例では、７つのバンドバッファの内、２つを残した５つのバンドバッファを使用する場合について説明したが、ｎ（ｎは３以上の整数）個のバンドバッファの内、ｍ（ｍは２以上、ｎ−１以下の整数）個のバンドバッファを使用する場合に対しても同様に適用することができる。
【００６８】
また、上記実施例では、再利用オブジェクトと一次利用オブジェクトを利用するバリアブル印刷について記載したが、通常の印刷に対しても同様に適用することができる。
【産業上の利用可能性】
【００６９】
本発明は、印刷画像を分割したバンド画像を生成する処理と生成したバンド画像を転送する処理とを並列で行う印刷画像生成装置及び当該印刷画像生成装置で動作する制御プログラムに利用可能である。
【符号の説明】
【００７０】
１０  印刷画像生成システム
２０  クライアント端末
３０  印刷装置
４０  プリンタコントローラ
４１  スプーラ
４２  ジョブスケジューラ
４３  ＰＤＬアナライザ
４４  ＰＤＬプロセッサ
４４ａ  ＰＤＬプロセッサ（PostScript／ＰＤＦ）
４４ｂ  ＰＤＬプロセッサ（ＰＰＭＬ）
４５  ラスタ画像プロセッサ
４６  ネットワークドライバ
４７  ＶＩＦドライバ
４８  Ｌｉｎｕｘカーネル
４９  ＮＩＣ
５０  補助記憶装置
５１  主記憶装置（共有メモリ）
５２  ＶｉｄｅｏＩ／Ｆ
【図１】
2012196923.tif 000003
【図２】
2012196923.tif 000004
【図３】
2012196923.tif 000005
【図４】
2012196923.tif 000006
【図５】
2012196923.tif 000007
【図６】
2012196923.tif 000008
【図７】
2012196923.tif 000009
【図８】
2012196923.tif 000010
【図９】
2012196923.tif 000011
【図１０】
2012196923.tif 000012