JP5777375B2 - 画像処理装置、画像処理装置のデータ処理方法、及びプログラム - Google Patents

Description

本発明は、マルチタスクで印刷情報を並列処理可能な画像処理装置、画像処理装置のデータ処理方法、及びプログラムに関するものである。

近年、画像処理装置において、プロセッサ技術の向上に伴って、マルチタスク処理を使ったＰＤＬ高速化処理が提案されている。

従来の画像処理におけるページ記述言語（以下ＰＤＬ）データを解釈し画像形成用ビットマップデータを作成するシステムは以下のような特徴があった。つまり、画像形成処理はＰＤＬデータを解釈し、グラフィック処理を行った上でディスプレイリスト（ＤＬ）などと呼ばれる中間データを作成する。そのうえでこの中間データからレンダリングなどと呼ばれる画像形成用ビットマップデータの生成処理を行うのが一般的である（特許文献１）。

また、マスタープロセスとよばれる制御部が、ＰＤＬが並行に動作するようにＰＤＬデータストリームを二つに分ける。その上で、二つのタスクで動くサブプロセスはＰＤＬデータ解釈処理を行う（特許文献２）。画像処理装置がＰＤＬデータの解釈処理を並列処理することで、ＰＤＬデータ解釈処理のパフォーマンスを向上さることが可能になる。

また、画像処理装置が一つのＰＤＬデータを複数のタスク内でＰＤＬ解釈処理を並行して行うことで、高速なＰＤＬ解釈処理を実現する技術である。より詳細には、この並行処理は、ＰＤＬデータをページ単位で分割し、複数に分割されたページ範囲を複数のタスクに処理を分配することによって実現される。このような処理分割方法によって、画像形成処理装置内のＣＰＵに代表される複数のリソースを使いながら、並行してＰＤＬ解釈処理を実行することを可能にする。よって、画像形成処理装置は、この並列処理によってリソースの使用効率が向上し、ＰＤＬ解釈処理をより高速に処理することができる。
ここで、画像処理装置とホスト側との通信処理について説明する。

従来、画像処理システムを構成するホスト側のデータ処理装置のデータ通信は、オペレーティングシステム（ＯＳ）に依存したものとなる。ここで、現在データ処理装置にインストールされているＯＳとして、ｗｉｎｄｏｗｓ（登録商標）系と、ＭａｃＯＳ系が実用化されてシステムが構築されている。

このようなシステム環境において、画像処理装置側とのデータ通信処理のプロトコルとして、ｗｉｎｄｏｗｓ（登録商標）系に対応する第１のデータ処理装置では、ＴＣＰ／ＩＰ等の通信プロトコルを用いて通信処理を行う。また、ＭａｃＯＳ系に対応する第２のデータ処理装置では、ＡｐｐｌｅＴａｌｋ等の通信プロトコルを用いて通信処理を行う。ここで、第１、第２のデータ処理装置から印刷情報として、ページ記述言語に基づく印刷情報、例えばＰＳ（ＰｏｓｔＳｃｒｉｐｔ（登録商標））を用いた印刷処理において、以下のような通信処理が実行されている。
例えば第１のデータ処理装置では、ＰＳに基づく印刷情報を片方向通信で画像処理装置へ送信した後、画像処理装置からの応答処理を行わない。
一方、第２のデータ処理装置では、ＰＳに基づく印刷情報（ＰＤＬデータ）を双方向通信で画像処理装置へ送信した後、画像処理装置からの応答を受信する場合がある。

特開２００４−２６８５５３号公報 特開平８−２９７５６０号公報

http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf Programming With Threads, Steve Kleiman, Devang Shah, Bart Smaalders, ISBN-13: 978-0131723894

上記のように構成された画像処理装置において、第２のデータ処理装置との間で双方向通信を必要とするＰＤＬ解釈処理をマルチタスク処理で同時処理する場合、通信エラーが発生するという課題があった。

具体的には、画像処理装置内でＰＤＬデータにおけるマルチタスク処理が行われると、ＰＤＬデータを解釈するタスクも複数となる。よって、画像処理装置内でＰＤＬデータ解釈結果も複数得られることになる。これはすなわち、双方向通信が必要となるＰＤＬ解釈処理においては、画像処理装置は１つのＰＤＬデータに対して複数の通信処理が発生する可能性を意味している。
この複数の通信処理をホスト側からみると以下のような課題がある。

まず、ＰＤＬデータ処理に対して複数の通信上の応答を得るため、ホスト側で通信エラーが発生する。第２のデータ処理装置において、上記ＰｏｓｔＳｃｒｉｐｔ（登録商標）データを使った問い合わせに対して期待された応答を画像処理装置から得ることによって、フォントファイルに代表されるリソースを画像処理装置内にダウンロードする。このため、従来技術のマルチタスク処理と双方向通信を必要とするＰＤＬ解釈処理において、フォントファイルに代表されるリソースを画像処理装置内にダウンロードする処理を行うと通信エラーとなってしまう。このエラーの原因は以下のとおりである。
画像処理装置内で行われるＰＤＬデータ解釈がマルチタスク処理という並行処理が行われる。上記並行処理が行われることによって、データ解釈結果が並行して二つ得られる。上記並行して得られたデータ解釈結果は、双方向通信が必要となるＰＤＬ解釈処理において画像処理装置は１つのＰＤＬデータに対して複数の通信処理が発生する可能性がある。ホスト側のデータ処理装置と画像処理装置との間においてこのような複数の通信処理が発生すると、ホスト側のデータ処理装置が１つの通信に対して、応答を複数受け取ることになるため、ホスト側のデータ処理装置において通信エラーが発生してしまう。
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、ＰＤＬデータを受信するデータ処理装置との通信に適応して、ＰＤＬデータ解釈処理中にデータ処理装置に正常に応答処理が行える動作モードを決定できる仕組みを提供することである。

上記目的を達成する本発明の画像処理装置は以下に示す構成を備える。
所定の通信プロトコルに従いデータ処理装置からＰＤＬデータを受信する受信手段と、マルチモードが設定されている場合はマルチタスクで、シングルモードが設定されている場合はシングルタスクで前記受信手段により受信されたＰＤＬデータを解釈する解釈手段と、前記所定の通信プロトコルのタイプが問い合わせ命令に対し応答する必要があるタイプであるか否かを判別する判別手段と、前記判別手段による判別がされた後、受信した前記ＰＤＬデータの中に当該画像処理装置が前記データ処理装置に対して応答すべき問い合わせ情報があるかどうかを判定する判定手段を備え、前記判別手段により問い合わせ命令に対し応答する必要がないタイプであると判別された場合は、マルチモードの設定を切り替えず、前記判別手段により問い合わせ命令に対し応答する必要があるタイプであると判別された場合で、さらに、前記判定手段により前記問い合わせ情報があると判定された場合は、前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替えることを特徴とする。

本発明によれば、ＰＤＬデータを受信するデータ処理装置との通信に適応して、ＰＤＬデータ解釈処理中にデータ処理装置に正常に応答処理が行える動作モードを決定できる。これにより、データ処理装置との間で通信エラーが発生する可能性が低減され、適正な印刷処理を行うことが可能になる。

画像処理システムの一例を示す図である。 画像処理装置が処理するＰＤＬデータの構造を説明する図である。 画像処理装置で処理する中間データの構造を説明する図である。 画像処理装置に送信される問い合わせ命令の例を示す図である。 画像処理装置に送信される問い合わせ命令の例を示す図である。 画像処理装置の構成を説明するブロック図である。 画像処理装置のソフトウエアモジュールの構成を示すブロック図である。 画像処理装置のソフトウエアモジュールの処理を示すブロック図である。 画像処理装置のデータ処理方法を説明するフローチャートである。

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

図１は、本実施形態を示す画像処理システムの一例を示す図である。本例は、ネットワークを介してデータ処理装置と画像処理装置とが双方向通信可能に接続されたシステム例である。なお、画像処理装置の一例として、所定のＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）データを受信するプリンタ装置を例とする。本実施形態では、所定のＰＤＬデータとして、ＰｏｓｔＳｃｒｉｐｔに準拠するＰＤＬデータを想定して説明を行う。

図１において、２５００はデータ処理装置（ＰＣ）で、アプリケーションやミドルウェア、ドライバーソフトウェアを動作させ、ＰＤＬデータ１０００を生成するデータ処理を行う。ＰＣ２５００とプリンタ１００は、ネットワーク３００に代表される通信手段によって相互に接続されている。プリンタ１００はネットワーク３００に代表される通信手段を通じて得たＰＤＬデータ１０００を使い、紙４００に代表される可視媒体上に可視像を形成する。

なお、本実施形態ではＰＣ２５００はパーソナルコンピュータを想定するが、それ以外の以下のようなＰＤＬデータ１０００やそれに相当する画像データを生成し、転送することができる装置であれば、本発明を実施できることは言うまでもない。すなわち、ワークステーション、メインフレームコンピュータ、スマートフォンやデジタルカメラなどのであれば、本発明を実施できることは言うまでもない。

また、本実施例では画像処理装置はプリンタを例にして説明している。しかしながらこれも同様に、それ以外のＭＦＰ（マルチファンクションプリンター）や、印刷機、ディスプレイ装置などとよばれている可視像を形成することができる装置一般でも、本発明を実施できることは言うまでもない。
以下、ＰＣ２５００とプリンタ１００との接続技術および通信手段について図１を参照して説明する。

まず、本実施形態に示す画像処理システムは、以下のような接続技術を前提としている。すなわち、プリンタとの接続はイーサネット（登録商標）ワークに代表される双方向通信可能なネットワーク３００によって実現される。もちろん、それ以外のＵＳＢインタフェース（１００−７）、ＩＥＥＥ１２８４（１００−８）などの双方向通信可能なインタフェース装置を用いたとしても本発明を実施できることは言うまでもない。
次に、接続技術を介して、ＰＤＬデータ１０００、特にＰｏｓｔＳｃｒｉｐｔ（登録商標）を用いた通信方法について以下に説明する。
まず、第一にＰＣ２５００はネットワーク３００を介してＰＤＬデータ１０００をプリンタ１００に送信する。このＰＤＬデータ１０００の送信は、たとえば以下のように実施される。

本実施形態においては、ＰＣ２５００はＰＯＳＩＸ（登録商標）規格に準拠したコンピュータである。よって、以下のようにホストコンピュータ上で実行することで、プリンタにＰＤＬデータ１０００を送ることができる。すなわち、たとえば「ｔｅｓｔ．ｐｓ」というファイルを「ｌｐ０」というデバイスに接続されたプリンタに送る場合には以下のように実行する。
［ｆｏｏ＠ｔｅｓｔ−ｗｓ 〜］＄ ｃａｔ ／ｈｏｍｅ／ｆｏｏ／ｔｅｓｔ．ｐｓ ＞ ／ｄｅｖ／ｌｐ０

この送信されたＰＤＬデータは、ネットワーク３００を介して、プリンタ１００に送信される。プリンタ１００はＰＤＬデータ１０００を受信し、これを処理することで、紙４００上に可視像を形成する。または、プリンタ１００はＰＤＬデータ１０００を受信し、これを処理することで、ホストに対して応答４０００を行う。この、応答４０００はＰＤＬデータ１０００を用いたホストからの問い合わせに返答するために行われる。以下にその応答処理の簡単な例を示す。
例えば、ＰＣ２５００がＰｏｓｔＳｃｒｉｐｔ（登録商標）規格に従ったＰＤＬデータ１０００を使って、プリンタ１００に以下のような問い合わせを行うことができる。
／ＸＸＸＸＸＸ−Ｆｏｎｔ ／Ｆｏｎｔ ｒｅｓｏｕｒｃｅ ｓｔａｔｕｓ ＝＝ ｃｌｅａｒ

このＰＤＬデータ１０００はプリンタ１００内に「ＸＸＸＸＸＸ−Ｆｏｎｔ」というフォントリソースファイルが存在するかを問い合わせる命令である。このＰＤＬデータ１０００を受け取ったプリンタ１００は、このＰＤＬデータを解釈する。そのうえでプリンタ１００は、このフォントリソースファイルがプリンタ１００内に存在するかを確認する。プリンタ１００は、このフォントリソースファイルが存在する場合には、以下のようなデータ「ｔｒｕｅ」を応答４０００としてＰＣ２５００に応答する。
また、もし上述したフォントリソースファイルがプリンタ１００内に存在しなければ、プリンタ１００は以下のようなデータ「ｆａｌｓｅ」を応答４０００としてＰＣ２５００に応答する。
ここまで説明してきたように、本実施形態においてプリンタ１００はＰＣ２５００と双方向に通信を行いながらＰＤＬデータの解釈処理を行うことができる。

なお、本実施例におけるＰＣ２５００はＰＯＳＩＸ（登録商標）規格に準拠したコンピュータである。しかしながら、それ以外の規格に従ったコンピュータであっても、マルチタスク処理及び双方向通信を実現するコンピュータであれば本発明を実施できることは言うまでもない。
次に、本実施形態における上述したＰＤＬデータ１０００の構造について図２を参照して説明する。
図２は、図１に示した画像処理装置が処理するＰＤＬデータの構造を説明する図である。

図２において、本実施形態において、ＰＤＬデータ１０００はＰｏｓｔＳｃｒｉｐｔ（登録商標）技術を採用したデータ構造を持つ。すなわち、ＰＤＬデータ１０００はデータ内部に描画命令１０００−１と問い合わせ命令１０００−２とを少なくとも持つことができる。描画命令１０００−１は以下の命令を持つことができる。すなわち、描画命令（１０００−１はストローク文字命令１０００−１−１、文字描画命令１０００−１−２を持つことができる。また加えて、描画命令１０００−１は塗りつぶし描画命令１０００−１−３、ラスタービットマップ描画命令１０００−１−４を持つことができる。

また、問い合わせ命令１０００−２は以下の命令を持つことができる。すなわち、問い合わせ命令１０００−２はファイルチェック命令１０００−２−１、利用可能フォントリスト問い合わせ命令（１０００−２）−２を持つことができる。また加えて、問い合わせ命令（１０００−２）はプリンタ名の問い合わせ命令（１０００−２）−３を持つことができる。もちろん、ＰＤＬデータ１０００がこれ以外の描画命令１０００−１や問い合わせ命令１０００−２を持つことができたとしても本発明を実施できる。
次に、本実施形態における中間データ２０００の構造について図３を参照して説明する。
図３は、本実施形態を示す画像処理装置で処理する中間データ２０００の構造を説明する図である。

図３において、中間データ２０００は後述するＲＩＰ ＡＳＩＣ１０００−３が解釈可能なデータ構造を持つ。ＲＩＰ−ＡＳＩＣは以下に示す中間データ２０００に含まれる命令群２０００−１，２０００−２を解釈することで画像形成用ビットマップデータを生成することができる。すなわち、中間データ２０００はデータ内部に塗りつぶし描画命令２０００−１と、ラスタービットマップ描画命令２０００−２とを少なくとも持つことができる。もちろん、中間データ２０００はこれ以外の描画命令を持つことができたとしても本発明を実施できる。
次に、データ処理装置から画像処理装置に送信される問い合わせ命令の例を以下に示す。

図４、図５は、図１に示したデータ処理装置から画像処理装置に送信される問い合わせ命令の例を示す図である。なお、問い合わせ命令は非特許文献１に示されているＤＳＣ規格にしたがっており、本実施形態においては以下のような特徴持つ。
１）問い合わせジョブ開始は、ジョブ認識コメント%!PS-Adobe-3.0 Queryで始まり%%EOFで終わる。
２）問い合わせ命令は２個のパーセント文字（%%）によって指定され、行頭に現れなければならない。
３）問い合わせ命令は%%?Beginで始まる。
４）問い合わせ命令は、255文字までのテキスト文字列が続き、行の終わりを表す記号（end-of-line）が続く。
５）行の終わりを表す記号（end-of-line）は、ラインフィールド（Hex：0D）かキャリッジリターン（Hex：0A）のどちらかである。
６）問い合わせ命令の終わりは、%%?Endの後ろに１つ以上のキーワードが続く。
７）問い合わせ命令の終わりにさらにオプションでコロン（:）が続き、問い合わせに対するデフォルトの値が続いた一連の並びで区切られている。
８）プリンタ１００は、問い合わせを解析できなかった場合、またその問い合わせをサポートしていない場合に上記デフォルトの値を返す。
９）問い合わせジョブには複数の問い合わせを含ませることが可能である。

後述するＤＳＣ処理部２００−１は、上記規格にしたがい問い合わせ命令を抽出する。その上で、ＤＳＣ処理部２００−１は抽出された問い合わせ命令の種類を判別し、その判別にしたがいＤＳＣ処理を行う。このＤＳＣ処理部２００−１が行うべき処理について、より具体的な例を示すために図４を参照して説明する。

図４において、１０００−３−０は問い合わせジョブの先頭を示す命令である。１０００−３−１は問い合わせコメントの開始命令である。特にここで示されている命令はフォントリスト、すなわちプリンタにインストールされたフォントの一覧をＰＣ２５００からプリンタ１００に問い合わせる命令である。ＤＳＣ処理部２００−１はこの命令を見つけると、ＨＤＤ１００−２ないしＲＡＭ１００−１に保存されているフォントファイル一覧を取得する。次に、ＤＳＣ処理部２００−１はこのフォントファイル一覧を、ＰＣ２５００にネットワーク３００を通じて返答する処理を実行する。続く、１０００−３−２は問い合わせコメントの終了命令である。本命令は、上記問い合わせコメントの開始命令１０００−３−１と対をなし、問い合わせコメント命令１０００−２のその命令の範囲を明確にする。
また、ＤＳＣ処理部２００−１が行うべき処理について、より具体的なもう１つ例を示すために図５を参照して説明する。

図５において、１０００−３−５は問い合わせジョブの先頭を示す命令である。１０００−３−６は問い合わせコメントの開始命令である。特にここで示されている命令はｐｒｏｄｕｃｔ、すなわちプリンタ１００の名前をＰＣ２５００からプリンタ１００に問い合わせる命令である。

続いて、１０００−３−８はＰｏｓｔＳｃｒｉｐｔ（登録商標）規格に従った問い合わせ命令である。ここでは上記命令と同様にｐｒｏｄｕｃｔ、すなわちプリンタ１００の名前をＰＣ２５００からプリンタ１００に問い合わせる命令である。

本実施例ではＰＤＬ解釈部２００−２はこの命令を見つけると、ＨＤＤ１００−２ないしＲＡＭ１００−１に保存されている商品名を取得する。次に、ＰＤＬ解釈部２００−２はこの商品名をＰＣ２５００にネットワーク３００を通じて返答する処理を実行する。

続く、１０００−３−２は問い合わせコメントの終了命令である。本命令は、上記問い合わせコメントの開始命令１０００−３−１と対をなし、問い合わせコメント命令１０００−２のここの命令の範囲を明確にする。

上述したように、ＤＳＣ規格に従った命令中にＰｏｓｔＳｃｒｉｐｔ（登録商標）規格に従った問い合わせ命令が含まれることがある。これはＤＳＣ規格の命令だけではないＰｏｓｔＳｃｒｉｐｔ（登録商標）規格のデータを交えた問い合わせ命令に、以下のような利点があるためである。
すなわち、ＰｏｓｔＳｃｒｉｐｔ（登録商標）特有の高度な言語解析を用いることで、複雑な問い合わせ命令を実現できるためである。ＰｏｓｔＳｃｒｉｐｔ（登録商標）特有の高度な言語解析の特徴として以下のものがある。

ｐｒｏｃｎａｍｅと呼ばれる値を設定することによって、ＰｏｓｔＳｃｒｉｐｔ（登録商標）規格に従うとはプリンタ１００はあらかじめ固定的な処理、すなわちプロシージャーを登録することができる。また別の特徴としては以下のようなものがある。すなわちＰｏｓｔＳｃｒｉｐｔ（登録商標）規格に従うと、プリンタ１００は変数を用いた言語解析処理が可能となる。もちろん、これ以外にもＰｏｓｔＳｃｒｉｐｔ（登録商標）の利点はあるが、本実施例はＰｏｓｔＳｃｒｉｐｔ（登録商標）の詳細仕様を説明するものではないので割愛する。ＰｏｓｔＳｃｒｉｐｔ（登録商標）の詳細仕様は非特許文献１を参照されたい。
次に、ＤＳＣ処理部が処理を行う命令群と、命令とその処理の順にそれぞれ以下にいくつか説明する。
％％？ＢｅｇｉｎＦｉｌｅＱｕｅｒｙ： ＜ｆｉｌｅｎａｍｅ＞
％％？ＥｎｄＦｉｌｅＱｕｅｒｙ： ＜ｄｅｆａｕｌｔ＞
上記命令はプリンタ１００内で指定したファイルが利用可能かどうか。
％％？ＢｅｇｉｎＦｏｎｔＬｉｓｔＱｕｅｒｙ
％％？ＥｎｄＦｏｎｔＬｉｓｔＱｕｅｒｙ： ＜ｄｅｆａｕｌｔ＞
上記命令はプリンタ１００内で利用可能フォントのリストを問い合わせる命令である。
％％？ＢｅｇｉｎＦｏｎｔＱｕｅｒｙ： ＜ｆｏｎｔｎａｍｅ＞．．．
％％？ＥｎｄＦｏｎｔＱｕｅｒｙ： ＜ｄｅｆａｕｌｔ＞
プリンタ１００内で指定したフォントが利用可能かどうかを問い合わせる命令である。
％％？ＢｅｇｉｎＰｒｉｎｔｅｒＱｕｅｒｙ
％％？ＥｎｄＰｒｉｎｔｅｒＱｕｅｒｙ： ＜ｄｅｆａｕｌｔ＞
プリンタ１００の製品名、バージョン番号とリビジョン番号を問い合わせる命令である。

もちろん、上述した背景技術に示されているように、問い合わせ命令はこれ以外も定義されている。しかしながら本実施例は問い合わせ命令の詳細仕様を説明するものではないので、ここではこれ以上の説明を割愛する。詳細は非特許文献１を参照されたい。

また、ここまで問い合わせ命令のデータフォーマットと命令に対する実行例を説明した。しかし、これ以外の規格にしたがっても、プリンタ１００に対する問い合わせ命令を伝送するデータフォーマットであれば本発明を実施できることは言うまでもない。
次に、上述したようなＰＤＬデータ１０００に対するプリンタ１００内の画像処理装置が持つ諸装置について図６を使いながら以下に説明する。
図６は、本実施形態を示す画像処理装置の構成を説明するブロック図である。
図６において、１００−７はＵＳＢインタフェースであり、ＵＳＢ規格の外部装置を通じて外部からＰＤＬデータ１０００をプリンタ１００に入力することを可能にしている。

１００−８はＩＥＥＥ １２８４インタフェース装置であり、同様にＩＥＥＥ １２８４規格のハードウェアを持つ外部装置を通じて外部からＰＤＬデータ（１０００）をプリンタ１００に入力することを可能にしている。

１００−９はネットワーク装置であり、同様にネットワーク規格のハードウェアを持つ外部装置を通じて外部からＰＤＬデータ１０００をプリンタ１００に入力することを可能にしている。

上述したＵＳＢインタフェース１００−７、ＩＥＥＥ １２８４インタフェース装置（１００−８）、ネットワーク装置１００−９は後述する、通信制御部２００−０の制御のもと上述したＰＤＬデータ１０００をプリンタ１００内に受信することができる。１００−０はＣＰＵであって、下記ＲＡＭ１００−１に保存された命令を実行することで、後述するＰＤＬ解釈処理などを実現するソフトモジュール２００を実行する。

１００−１はＲＡＭであり、揮発性の記憶媒体である。このＲＡＭ１００−１はＰＤＬデータ１０００やＣＰＵ１００−０が実行すべき命令を保存することができる。またこのＲＡＭ１００−１は、バス１００−５を通じてＰＤＬデータ１０００やＣＰＵ１００−０が実行すべき命令を、ＣＰＵ１００−０を含む諸装置に転送することができる。このＲＡＭ（１００−１）は揮発性の記憶媒体であるから、プリンタ１００の電源が落とされると、保存された命令やデータは消去される。

１００−２はＨＤＤであり、不揮発性の記憶媒体である。このＨＤＤ１００−２は、ＣＰＵ１００−０が処理すべき命令やデータを保存しておくことで、電源断によってＲＡＭ１００−１上から失われるＣＰＵ１００−０が処理すべき命令やデータを保存しておくことができる。また、本実施理においてはこのＨＤＤ１００−２はＲＡＭ１００−１より容量が大きい。よって、本実施例においては画像形成用ビットマップデータ３０００に代表されるデータはこのＨＤＤ１００−２に保存される。もちろん、本実施例では不揮発性の記憶媒体としてＨＤＤを例に示しているが、ＨＤＤの代わりにフラッシュ型ＥＥＰＲＯＭ、強誘電体メモリ（ＦｅＲＡＭ）、磁気抵抗メモリ（ＭＲＡＭ）などを用いても本発明を実施できることは言うまでもない。１００−３はＲＩＰ ＡＳＩＣであり、のちに説明する中間データを受け取ってビットマップデータ３０００を生成することができる。

１００−４は電子写真エンジンであって、上記ＲＩＰ ＡＳＩＣ１００−３が生成したビットマップデータ３０００を用いて、紙に代表される可視媒体上に可視像を形成する。なお、本実施例では電子写真エンジンを使って可視媒体上に可視像を得ているが、下記に示すそれ以外の機構を用いても本発明を実施できることは言うまでもない。すなわち、液晶パネル、有機ＥＬパネル、凸版印刷エンジン、オフセット印刷エンジン、インクジェット印刷エンジンなどを使っても本発明を実施できる。１００−５はバスであり、上述した各々の装置を接続し、データや命令を相互にやり取りすることを可能にする。
次に、上記ＣＰＵ（１００−０）上で動作するソフトモジュール２００について図７を参照して説明する。

図７は、本実施形態を示す画像処理装置のデータ処理モジュールの構成を説明するブロック図である。なお、以下に示す２００−０〜２００−６はＣＰＵ１００−０が実行するソフトウエアモジュールであり、説明上これらを総称する場合において、ソフトウエアモジュール群と呼ぶ場合がある。
図７において、２００−０は通信制御部であり、第一に上述したＵＳＢインタフェース（１００−７）、ＩＥＥＥ １２８４インタフェース装置１００−８ないしネットワーク装置（１００−９）を制御し、ＰＣ２５００との通信コネクションを確立する。第二に、通信制御部２００−２は、上述したＵＳＢインタフェース１００−７、ＩＥＥＥ １２８４インタフェース装置１００−８ないしネットワーク装置１００−９を制御することで、上述したＰＤＬデータ１０００を受信する。第三に通信制御部２００−２は、受信したＰＤＬデータ１０００をＲＡＭ１００−１に記憶することができる。

２００−１はＤＳＣ処理部であり、ＲＡＭ１００−１上に記憶されたのちに、ＰＤＬデータ１０００に対する解釈処理を行う。特に、ＤＳＣ処理部２００−１は、ＰＤＬデータ１０００に含まれる上述したＤＳＣ規格にしたがった問い合わせ命令１０００−２を処理することができる。

２００−２はＰＤＬ解釈部であり、ＲＡＭ１００−１上に記憶された後、ＰＤＬデータ１０００に対する解釈処理を行う。また、ＰＤＬ解釈部２００−２は、後述するＯＳ２００−５の制御のもと、複数のタスク内でＰＤＬ解釈処理を並列して行うことができる。また、ＰＤＬ解釈部２００−２は、後述するＤＳＣ処理部２００−１が処理できなかった問い合わせ命令１０００−２を処理することができる。
２００−３は画像生成部であり、上記ＰＤＬ解釈部の処理結果とＲＩＰ ＡＳＩＣ １００−３を使うことで画像形成用ビットマップデータ３０００を生成する。２００−４はエンジン制御部であり、画像形成用ビットマップデータと電子写真エンジン１００−４を使うことで、画像形成処理を行う。

２００−５はジョブコントローラであり、上述したそれぞれのソフトモジュールの処理フローの伝達を行う。また、ジョブコントローラは、後述するシングルタスクで実行するか、マルチタスクで実行するかを判断し、その結果をＰＤＬ解釈部２００−２に対して通知する。

２００−６はＯＳであり、上述したすべてのソフトモジュール群２００−０，２００−１，２００−２，２００−３，２００−４，２００−５のタスク管理をおこなう。タスク管理とは、少なくとも従来技術（特に非特許文献２）で説明したマルチタスク処理を含む。
すなわち、このＯＳ２００−６が提供するタスク管理機能によって、ＰＤＬ解釈部２００−２の並列処理が実現される。

ここでは処理フロー詳細を説明する前に、図７に示したソフトウエアモジュール群２００−０，２００−１，２００−２，２００−３，２００−４，２００−５がどのような処理を行うかについて、図８を参照して説明する。

図８は、本実施形態を示す画像処理装置のソフトウエアモジュールの処理を説明するブロック図である。以下、図１に示した画像処理装置において、双方向通信でデータ処理装置（ＰＣ２５００）から受信するＰＤＬデータを設定される動作モードに従いマルチタスクまたはシングルタスクで解釈処理するＰＤＬデータ解釈処理を説明する。
さらに、プリンタ１００が受信したＰＤＬデータの中に当該画像処理装置が前記データ処理装置に対して応答すべき問い合わせ情報があるかどうかを判定するＤＳＣ処理部２００−１の処理を説明する。即ち、データ処理装置（ＰＣ２５００）から受信したＰＤＬデータに問い合わせ命令（１０００−２）が含まれているか否かを、プリンタ１００が有するＤＳＣ処理部２００−１が判定する処理である。なお、後述する２００−０〜２００−５はＣＰＵ１００−０上で動作するモジュールとして構成される例を示す。
また、ＤＳＣ処理部２００−１による判定処理結果に応じて、ジョブコントローラ２００−５によるＰＤＬデータ解釈部２００−２に対して設定されている動作モードをマルチモードからシングルモードへ切り替える制御を説明する。
本実施形態においては、図８に示したプリンタ１００に入力される入力データはＰＤＬデータ１０００である。そして、プリンタ１００内のソフトウエアモジュール群２００−０，２００−１，２００−２，２００−３，２００−４，２００−５は、このＰＤＬデータ１０００を処理する。この処理によって、プリンタ１００はＰＤＬデータ中の問い合わせ命令１０００−２の結果４０００と、画像形成用のビットマップデータ３０００を得る。

問い合わせ命令１０００−２に対する応答４０００を得るために、ＤＳＣ処理部２００−１ないし、ＰＤＬ解釈部２００−２がＰＤＬデータ１０００を解釈する（Ｓ２０−１，Ｓ２０−２）。

また、ＰＤＬ解釈部２００−２のＰＤＬデータ１０００の解釈によって、中間データ２０００が生成される（Ｓ２０−２）。この中間データ２０００を画像生成部２００−３の制御の下、ＲＩＰ ＡＳＩＣ１００−３が解釈することによって、画像形成用のビットマップデータ３０００が生成（レンダリング）される（Ｓ２０−３）。

プリンタ１００は、上記各ソフトモジュールを用いて以下に説明するＰＤＬデータの画像形成処理をＰＤＬデータ１０００に対して行うことによって、本発明におけるモード切り替え制御を実行する。次に、上述したようなプリンタ１００内の諸装置を使って行われる、ＰＤＬデータ１０００に対する処理について図９を参照して説明する。

図９は、本実施形態を示す画像処理装置のデータ処理方法を説明するフローチャートである。本例は、ＣＰＵ１００−０がＲＡＭ１００−１に制御プログラム（図７に示した各ソフトモジュール群）をロードして実行することにより実現される。なお、ＰＤＬデータ解釈部２００−２は、双方向通信でＰＣ２５００から受信するＰＤＬデータを、設定される動作モードに従いマルチタスクまたはシングルタスクで解釈処理可能であることを前提とする。ここで、動作モードは、ジョブコントローラ２００−５により、シングルモードとマルチモードのいずれかを切り替え設定可能に構成されている。また、ＤＳＣ処理部２００−１は、ＰＣ２５００から受信するＰＤＬデータにプリンタ１００がＰＣ２５００に対して応答すべき応答情報が含まれているかどうかを判定する機能を備える。具体的には、ＤＳＣ処理部２００−１は、図８に示したように、ＰＤＬデータにＰＣ２５００に対して応答すべき応答すべき命令があるかどうかを判定する命令判定機能処理を後述するフローチャートに基づいて実行する。
なお、Ａｐｐｌｅ Ｔａｌｋ（登録商標）に準拠する通信プロトコルを第１の通信プロトコルとし、ＴＣＰ／ＩＰ等拠する通信プロトコルを第２の通信プロトコルとする。第１の通信プロトコルは、問い合わせ命令に対し応答が必要となるＰＤＬデータを送信するための規格であり、双方向通信タイプの通信プロトコルである。一方、第２の通信プロトコルは応答を必要としない通信プロトコルであり、問い合わせ命令の内、応答を必要としない命令のみ処理を行う規格である。第２の通信プロトコルは、片方向通信タイプの通信プロトコルである。また、ＣＰＵ１００−０上で動作する上記２００−０〜２００−５についてモジュールを主体として説明する。
まず、ジョブコントローラ２００−５は、第一にＰＤＬ動作モードをあらわす変数をマルチモードに設定する（Ｓ１０−０）。この処理は、ジョブコントローラ２００−５が、ＲＡＭ１００−１上に記録されているＰＤＬ動作モードをあらわす変数を書きかえることによって実行される。本実施例におけるＰＤＬデータ解釈部２００−２は、初期設定としてマルチモードが設定されており、マルチタスクでＰＤＬデータの解釈処理を行う。なお、シングルモードが設定された場合、ＰＤＬデータ解釈部２００−２はシングルタスクでＰＤＬデータの解釈処理を行う。
この変数がマルチモードに設定されていた場合、ＰＤＬデータ解釈部２００−２は以下のように動作する。すなわち、ＯＳ２００−６の制御のもと、二つ以上のタスクで起動する。そのうえでＰＤＬデータ解釈部２００−２は分割されたＰＤＬデータ（１０００）を使い、二つ以上のタスクで並行してＰＤＬデータ１０００に対する解釈処理を行う。
また、この変数が「シングルモード」に設定されていた場合にはＰＤＬデータ解釈部２００−２は以下のように動作する。すなわち、ＯＳ２００−６の制御のもと、一つのタスクで起動する。そのうえでＰＤＬデータ解釈部２００−２は一つのＰＤＬデータ１０００を使い、１タスクでＰＤＬデータ１０００に対する解釈処理を行う。その際、２つのＰＤＬデータ解釈部２００−２の内、解釈処理を行わないＰＤＬデータ解釈部２００−２に対し停止命令が出される。
なお、このマルチモードおよびシングルモードの動作に関しては下記の処理フロー説明でも説明する。

次に、通信制御部２００−１は、ＰＣ２５００からの通信に応じて、上述したＵＳＢインタフェース１００−７ないしＩＥＥＥ １２８４インタフェース装置１００−８ないしネットワーク装置１００−９を制御することでＰＣ２５００との通信コネクションを確立させる（Ｓ１０−１）。
次に、通信制御部２００−１は、上記Ｓ１０−１で確立したコネクションの通信プロトコルのタイプが第１の通信プロトコルであるかどうかを判定する（Ｓ１０−２）。この判定によって、通信制御部２００−１は双方向通信が必要なコネクションが確立したかを判定することができる。
次に、ジョブコントローラ２００−５は上記判定に基づき通信プロトコルのタイプが第１の通信プロトコルであればＳ１０−３の処理を行うようにＰＤＬ解釈部２００−２に通知する。また一方で、ＣＰＵ１００−０上で動作するジョブコントローラ２００−５は上記判定に基づき通信プロトコルが第１の通信プロトコルでなければ、ＤＳＣ処理部２００−１およびＰＤＬ解釈部２００−２に従来マルチタスク処理で中間データを生成するように通知する（Ｓ１０−１４、Ｓ１０−１５、Ｓ１０−１６、Ｓ１０−１７、Ｓ１０−１８）。この判断は以下のような技術的背景がある。

つまり従来技術で説明したように、第１の通信プロトコルが双方向通信を必要としている。よって、プリンタ１００は通信プロトコルが第１の通信プロトコルである場合には、ＰＣ２５００に対して応答をしなければならない可能性がある。もちろん、第１の通信プロトコル以外に双方向通信が必要な通信に対応したプリンタ１００を実施するために、上記判定Ｓ１０−２条件に第１の通信プロトコル以外の判定を追加しても本発明を実施できることは言うまでもない。
次に、Ｓ１０−２で、第１の通信プロトコルではないと判断された場合の処理を以下に説明する。
まず、通信制御部２００−１は、ＰＤＬデータ１０００の受信処理を行う（Ｓ１０−１４）。この処理は、上述したＵＳＢインタフェース１００−７ないしＩＥＥＥ １２８４インタフェース装置１００−８ないしネットワーク装置１００−９を制御することでＰＤＬデータ１０００を受信する。その上で、通信制御部２００−１は、ＰＤＬデータ１０００をＲＡＭ１００−１に記憶させることで実行される。

次に、ＤＳＣ処理部２００−１は、ＤＳＣ解釈処理行う（Ｓ１０−１５）。この処理は、第一にＤＳＣ処理部２００−１がＲＡＭ１００−１に記憶されたＰＤＬデータ１０００の中からＤＳＣ規格のデータを抽出する。次に、ＤＳＣ処理部２００−１は上述した問い合わせ命令１０００−２の処理を行う。ただし、ここでの処理は上記Ｓ１０−２で双方向通信が必要ないと判断されたので、ＤＳＣ処理部２００−１はホストに対する応答を伴わない命令のみを実行すればよい。よって、ＤＳＣ処理部２００−１はホスト側に対して応答処理を行う必要がない。
続いて、ジョブコントローラ２００−５は、ＰＤＬデータ１０００の分割処理を行う（Ｓ１０−１６）。この処理は第一に、ジョブコントローラ２００−５がＲＡＭ１００−１に記憶されているＰＤＬデータ１０００を、後述するＰＤＬデータのマルチタスク処理でＰＤＬデータ１０００の解釈処理を行うために、データを二つ以上に分割する処理である。

次に、ＣＰＵ１００−０上で動作するＰＤＬ解釈部２００−２は、マルチタスク処理を用いたＰＤＬ解釈処理を行う（Ｓ１９−１７）。この処理は、二つ以上のタスク内でＰＤＬ解釈部２００−２がＲＡＭ１００−１上に分割された状態で保存されたＰＤＬデータ１０００を読み込む。続いて、二つ以上のタスク内でＰＤＬ解釈部２００−２はＰＤＬデータ１０００中の描画命令１０００−１および問い合わせ命令１０００−２に対する解釈処理を行う。分割の際は、ＰＤＬデータをページ毎に分割し、各ＰＤＬ解釈部２００−２の付加状況に応じて処理ページを適正に割り振る。

本実施形態ではＰＤＬ解釈部２００−２はＰｏｓｔＳｃｒｉｐｔ（登録商標）規格に従い、上記命令群を解析する。ただし、上述したようにここでの処理は上記Ｓ１０−２で双方向通信が必要ないと判断されたので、ＰＤＬ解釈部２００−２はホスト側に対する応答を伴わない命令のみをよりすればよい。よって、ＰＤＬ解釈部２００−２はホスト側への応答処理を行う必要がない。
次に、ＰＤＬ解釈部２００−２は、上記解釈処理の描画命令１０００−１のみを使って中間データ２０００を生成して（Ｓ１０−１８）、Ｓ１０−１１へ進む。
一方、上記Ｓ１０−２で、第１の通信プロトコルであると判断した場合の処理を以下に説明する。

まず、通信制御部２００−１は、ＰＤＬデータ１０００の受信処理を行う（Ｓ１０−３）。この処理は、上述したＵＳＢインタフェース１００−７ないしＩＥＥＥ １２８４インタフェース装置１００−８ないしネットワーク装置１００−９を制御することでＰＤＬデータ１０００を受信する。その上で本処理（Ｓ１０−３）は、通信制御部２００−１は、ＰＤＬデータ１０００をＲＡＭ１００−１に記憶させることで実行される。
次に、ジョブコントローラ２００−５はＰＤＬ動作モードの変数がマルチモードかを判定する（Ｓ１０−４）。この処理は、ＣＰＵ１００−０がＲＡＭ１００−１上に保存されている変数の真偽値を判定することで実行される。
次に、上記（Ｓ１０−４）でマルチモードであると判定された場合には、ＣＰＵ１００−０上で動作するＤＳＣ処理部２００−１は、ＤＳＣ解釈処理を行う（Ｓ１０−５）。この解釈処理において、ＤＳＣ処理部２００−１は、ＰＤＬデータ１０００中に問い合わせ命令があるかどうかを判定する（Ｓ１０−６）。

この判定（Ｓ１０−６）で、問い合わせ命令があるとＤＳＣ処理部２００−１が判定した場合には、ＤＳＣ処理部２００−１は問い合わせ命令の解析にはＰＤＬデータ解釈処理部２００−２によるＰＤＬ解釈処理が必要かを判定する（Ｓ１０−７）。

この判定（Ｓ１０−７）で、ＰＤＬデータ解釈処理部２００−２によるＰＤＬ解釈処理が必要であるとＤＳＣ処理部２００−１が判定した場合には、ＣＰＵ１００−０上で動作するジョブコントローラ２００−５は、ＰＤＬ動作モード変数をシングルモードに書き換える（Ｓ１０−８）。その上で、ジョブコントローラ２００−５は１つのタスク内でＰＤＬ解釈処理をするようにＰＤＬ解釈部２００−２に指示する。この指示のもと、ＰＤＬ解釈部２００−２がシングルタスク内でＰＤＬデータの解析を実行する。次に、ＰＤＬ解釈部２００−２は、上記解釈処理の描画命令１０００−１のみを使って中間データ２０００を生成する（Ｓ１０−９）。
一方で、上記（Ｓ１０−６）で、問い合わせ命令がないとＤＳＣ処理部２００−１が判定した場合には、ジョブコントローラ２００−５は、上述したＰＤＬデータ１０００の分割処理を行う（Ｓ１０−１６）。以下のＳ１０−１７、Ｓ１０−１８に示された処理は上述した通りなのでその説明を省略する。
また一方で、上記（Ｓ１０−７）で、ＰＤＬデータ解釈処理部２００−２によるＰＤＬ解釈処理が必要ないとＤＳＣ処理部２００−１が判定した場合には以下の処理を行う。すなわち、ＤＳＣ処理部２００−１はＤＳＣ解釈処理によって必要となった問い合わせ命令に対する返答処理を、ＤＳＣ処理部２００−１で行う（Ｓ１０−１０）。次に、ジョブコントローラ２００−５は、上述したＰＤＬデータ１０００の分割処理を行う（Ｓ１０−１６）。以下のＳ１０−１７、Ｓ１０−１８に示された処理は上述した通りなのでその説明を省略する。なお、ＰＤＬデータを終端まで処理した後、シングルモードの設定をマルチモードの設定に切り替えるよう制御する。これにより、次に来るＰＤＬデータが、例えば、Ｐｏｓt Ｓｃｒｉｐｔでなければ、高速に処理することが可能になる。また、第１通信プロトコルでＰｏｓｔ Ｓｃｒｉｐｔが送信されれば、図９に示すフローを実行することになり、適正なＰＤＬデータ処理を行うことが可能になる。

上述した、Ｓ１０−９およびＳ１０−１８の処理の後、ＣＰＵ１００−０上で動作するジョブコントローラ２００−５は、ＰＤＬデータ１０００を末端まで読み込んだかを判定する（Ｓ１０−１５）。この処理は、ジョブコントローラ２００−５が以下の処理を行うことで実現される。
すなわち、第一にジョブコントローラ２００−５はＲＡＭ１００−１上にまだ読み込んでいないＰＤＬデータ１０００がないことを調べる。また加えて、ジョブコントローラ２００−５は通信制御部２００−０に対して通信コネクションが閉じられたかを問い合わせることによって通信コネクションが閉じられたかを判定する。上記二つの判定がともに真である場合に、ジョブコントローラ２００−５はＰＤＬデータ１０００を終端まで読み込んでいると判定する（Ｓ１０−１１）。

この判定（Ｓ１０−１５）において、もしＰＤＬデータ１０００を終端まで読み込んでいないとジョブコントローラ２００−５が判定した場合には、ＣＰＵ１００−０はＳ１０−３で示す処理に戻り、再びデータ入力から処理を開始する。
一方で、上記（Ｓ１０−１５）で、もしジョブコントローラ２００−５がＰＤＬデータ１０００を終端まで読み込んでいると判定した場合には以下の処理を行う。
すなわちジョブコントローラ２００−５は画像形成用ビットマップデータ３０００を生成するように画像生成部２００−３に命令する（Ｓ１０−１６）。
この処理は、以下の処理によって実現される。第一に上述したＰＤＬデータ１０００の解釈処理によって生成された中間データ２０００を画像生成部２００−３の制御の元、ＲＩＰ ＡＳＩＣ１００−３が画像形成用ビットマップデータ３０００）を生成する。この処理は一般にレンダリング処理と呼ばれるものである。第二にＲＩＰ ＡＳＩＣ１００−３が生成した画像形成用ビットマップデータをＨＤＤ１００−２に保存する。
次に、ジョブコントローラ２００−５は、エンジン制御部２００−４に対して上記生成された画像形成用ビットマップデータ３０００を使って画像形成するように命令して（Ｓ１０−１７）、本処理を終了する。なお、Ｓ１０−１３の処理は、エンジン制御部２００−４の制御の元、電子写真エンジン１００−４が上述した画像形成用ビットマップデータを使って、紙に代表される可視媒体４００上に可視像を形成することによって実現される。

なお、本実施形態では画像形成用ビットマップデータはＨＤＤ１００−２に保存することによって実施されるが、ＨＤＤ１００−２に保存される代わりに、ＲＡＭ１００−１やその他記憶装置に保存されたとしても、本発明を実施できることは言うまでもない。

以上説明したように、図９に示す処理において、問い合わせ命令があると判定され（Ｓ１０−６）、且つＰＤＬデータ解釈処理部２００−２によるＰＤＬ解釈処理が必要と判定された場合には以下のように処理をしている。
すなわち、ＰＤＬ解釈部２００−２を１つのタスク内で動作させ、ＰＤＬ解釈処理を行う。これによって、ＰＤＬ解釈処理中に必要な問い合わせ命令に対する返答処理が、二つのタスクから行われなくなる。これにより、本処理に従えば、上記第１の通信プロトコルでＰＣ２５００と通信する際であって、マルチタスクモードが設定されていた場合であっても、ＰＤＬデータの解釈処理時にＰＣ２５００との間で通信エラーが発生することがなくなる。

また、本実施形態では、図９に示す処理において、問い合わせ命令があると判定され（Ｓ１０−６）、且つＰＤＬデータ解釈処理部２００−２によるＰＤＬ解釈処理が必要と判定された場合には以下のように処理をしている。
すなわち、ＰＤＬ解釈部２００−２を１のタスク内で動作させ、ＰＤＬ解釈処理を行う。
これによって、ＰＤＬ解釈処理中に必要な問い合わせ命令に対する返答処理をＰＤＬ解釈部による返答処理が必要な場合にのみ、シングルタスクで処理可能である。これにより、課題で示した様なパフォーマンスが低下するのを防ぎ、結果マルチタスク処理によるパフォーマンスを向上させることができる。
また、上記実施形態では、画像処理装置としてプリンタの例を示すが、画像処理装置が複合機等で構成されていてもよい。さらに、ＰＣ２５００がクラウドコンピューティング環境のサーバ装置で構成されていてもよい。

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

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。
本実施形態では、１つのＣＰＵで２つのＰＤＬ解釈部を実現した。しかしながら、例えば、２つのＣＰＵで２つのＰＤＬ解釈部を実現しても良い。これを、マルチＣＰＵを用いた解釈処理と称する。この場合、各ＣＰＵにＰＤＬ解釈部を１つずつ実現することが考えられる。なお、ＣＰＵの数、およびＰＤＬ解釈部の数は上述に限られない。

１００ プリンタ
２５００ ＰＣ

Claims (7)

1. 画像処理装置であって、
   所定の通信プロトコルに従いデータ処理装置からＰＤＬデータを受信する受信手段と、マルチモードが設定されている場合はマルチタスクで、シングルモードが設定されている場合はシングルタスクで前記受信手段により受信されたＰＤＬデータを解釈する解釈手段と、
   前記所定の通信プロトコルのタイプが問い合わせ命令に対し応答する必要があるタイプであるか否かを判別する判別手段と、
   前記判別手段による判別がされた後、受信した前記ＰＤＬデータの中に当該画像処理装置が前記データ処理装置に対して応答すべき問い合わせ情報があるかどうかを判定する判定手段を備え、
   前記判別手段により問い合わせ命令に対し応答する必要がないタイプであると判別された場合は、マルチモードの設定を切り替えず、前記判別手段により問い合わせ命令に対し応答する必要があるタイプであると判別された場合で、さらに、前記判定手段により前記問い合わせ情報があると判定された場合は、前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替えることを特徴とする画像処理装置。
2. データ処理装置と双方向通信可能な画像処理装置であって、
   双方向通信で前記データ処理装置から受信するＰＤＬデータを設定される動作モードに従いマルチタスクまたはシングルタスクで解釈処理可能な解釈手段と、
   前記データ処理装置との通信プロトコルが問い合わせ情報に対する応答情報を通知するタイプかどうかを判別する判別手段と、
   前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替える制御手段と、
   前記判別手段による判別がされた後、受信した前記ＰＤＬデータの中に当該画像処理装置が前記データ処理装置に対して応答すべき問い合わせ情報があるかどうかを判定する判定手段を備え、
   前記制御手段は、前記判別手段が前記問い合わせ情報に対する応答情報を通知するタイプであると判別した場合で、さらに、前記判定手段により前記問い合わせ情報があると判定された場合に、前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替える
   ことを特徴とする画像処理装置。
3. 前記判定手段は、前記解釈手段による解釈処理を実行する前に、前記問い合わせ情報に対して前記画像処理装置が前記データ処理装置に対して応答すべき命令が含まれているかどうかを判定することを特徴とする請求項１に記載の画像処理装置。
4. 前記判定手段は、前記解釈手段による解釈処理を実行する前に、前記問い合わせ情報に対して前記画像処理装置が前記データ処理装置に対して応答すべき命令が含まれているかどうかを判定することを特徴とする請求項２に記載の画像処理装置。
5. 前記制御手段は、前記判定手段が前記問い合わせ情報に対して前記画像処理装置が前記データ処理装置に対して応答すべき命令が含まれていると判定した場合、前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替えることを特徴とする請求項４に記載の画像処理装置。
6. 画像処理装置のデータ処理方法であって、
   所定の通信プロトコルに従いデータ処理装置からＰＤＬデータを受信する受信工程と、マルチモードが設定されている場合はマルチタスクで、シングルモードが設定されている場合はシングルタスクで前記受信工程により受信されたＰＤＬデータを解釈する解釈工程と、
   前記所定の通信プロトコルのタイプが問い合わせ命令に対し応答する必要があるタイプであるか否かを判別する判別工程と、
   前記判別工程による判別がされた後、受信した前記ＰＤＬデータの中に当該画像処理装置が前記データ処理装置に対して応答すべき問い合わせ情報があるかどうかを判定する判定工程を備え、
   前記判別工程により問い合わせ命令に対し応答する必要がないタイプであると判別された場合は、マルチモードの設定を切り替えず、前記判別工程により問い合わせ命令に対し応答する必要があるタイプであると判別された場合で、さらに、前記判定工程により前記問い合わせ情報があると判定された場合は、前記解釈工程に対して設定されている動作モードをマルチモードからシングルモードへ切り替えることを特徴とする画像処理装置のデータ処理方法。
7. 請求項６に記載の画像処理装置のデータ処理方法をコンピュータに実行させることを特徴とするプログラム。

Images