"所定の通信プロトコルに従いデータ処理装置からPDLデータを受信する受信手段と、マルチモードが設定されている場合はマルチタスクで、シングルモードが設定されている場合はシングルタスクで前記受信手段により受信されたPDLデータを解釈する解釈手段と、前記所定の通信プロトコルのタイプが問い合わせ命令に対し応答する必要があるタイプであるか否かを判別する判別手段と、前記判別手段により必要がないタイプであると判別された場合は、マルチモードの設定を切り替えず、前記判別手段により必要があるタイプであると判別された場合は、前記解釈手段にシングルタスクでPDLデータを解釈させるために、前記解釈手段に対して設定されているマルチモードの設定をシングルモードの設定へ切り替える制御手段と、を備えることを特徴とする画像処理装置。データ処理装置と双方向通信可能な画像処理装置であって、双方向通信で前記データ処理装置から受信するPDLデータを設定される動作モードに従いマルチタスクまたはシングルタスクで解釈処理可能な解釈手段と、前記データ処理装置との通信プロトコルが問い合わせ情報に対する応答情報を通知するタイプかどうかを判別する判別手段と、前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替える制御手段と、前記制御手段は、前記判別手段が前記問い合わせ情報に対する応答情報を通知するタイプでないと判断した場合、前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替えることを特徴とする画像処理装置。前記判別手段による判別がされた後、受信した前記PDLデータの中に当該画像処理装置が前記データ処理装置に対して応答すべき問い合わせ情報があるかどうかを判定する判定手段を備え、前記制御手段は、前記判定手段により前記問い合わせ情報があると判定された場合、前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替えることを特徴とする請求項2記載の画像処理装置。前記判定手段は、前記解釈手段による解釈処理を実行する前に、前記問い合わせ情報に対して前記画像処理装置が前記データ処理装置に対して応答すべき命令が含まれているかどうかを判定することを特徴とする請求項3記載の画像処理装置。前記制御手段は、前記判定手段が前記問い合わせ情報に対して前記画像処理装置が前記データ処理装置に対して応答すべき命令が含まれていないと判定した場合、前記解釈手段に対して設定されている動作モードをマルチモードからシングルモードへ切り替えることを特徴とする請求項3記載の画像処理装置。画像処理装置のデータ処理方法であって、所定の通信プロトコルに従いデータ処理装置からPDLデータを受信する受信工程と、マルチモードが設定されている場合はマルチタスクで、シングルモードが設定されている場合はシングルタスクで前記受信工程により受信されたPDLデータを解釈する解釈工程と、前記所定の通信プロトコルのタイプが問い合わせ命令に対し応答する必要があるタイプであるか否かを判別する判別工程と、前記判別工程により必要がないタイプであると判別された場合は、マルチモードの設定を切り替えず、前記判別工程により必要があるタイプであると判別された場合は、前記解釈工程にシングルタスクでPDLデータを解釈させるために、前記解釈工程に対して設定されているマルチモードの設定をシングルモードの設定へ切り替える制御工程と、を備えることを特徴とする画像処理装置のデータ処理方法。請求項6に記載の画像処理装置のデータ処理方法をコンピュータに実行させることを特徴とするプログラム。上記のように構成された画像処理装置において、第2のデータ処理装置との間で双方向通信を必要とするPDL解釈処理をマルチタスク処理で同時処理する場合、通信エラーが発生するという課題があった。具体的には、画像処理装置内でPDLデータにおけるマルチタスク処理が行われると、PDLデータを解釈するタスクも複数となる。よって、画像処理装置内でPDLデータ解釈結果も複数得られることになる。これはすなわち、双方向通信が必要となるPDL解釈処理においては、画像処理装置は1つのPDLデータに対して複数の通信処理が発生する可能性を意味している。この複数の通信処理をホスト側からみると以下のような課題がある。まず、PDLデータ処理に対して複数の通信上の応答を得るため、ホスト側で通信エラーが発生する。第2のデータ処理装置において、上記PostScript登録商標データを使った問い合わせに対して期待された応答を画像処理装置から得ることによって、フォントファイルに代表されるリソースを画像処理装置内にダウンロードする。このため、従来技術のマルチタスク処理と双方向通信を必要とするPDL解釈処理において、フォントファイルに代表されるリソースを画像処理装置内にダウンロードする処理を行うと通信エラーとなってしまう。このエラーの原因は以下のとおりである。画像処理装置内で行われるPDLデータ解釈がマルチタスク処理という並行処理が行われる。上記並行処理が行われることによって、データ解釈結果が並行して二つ得られる。上記並行して得られたデータ解釈結果は、双方向通信が必要となるPDL解釈処理において画像処理装置は1つのPDLデータに対して複数の通信処理が発生する可能性がある。ホスト側のデータ処理装置と画像処理装置との間においてこのような複数の通信処理が発生すると、ホスト側のデータ処理装置が1つの通信に対して、応答を複数受け取ることになるため、ホスト側のデータ処理装置において通信エラーが発生してしまう。本発明は、上記の課題を解決するためになされたもので、本発明の目的は、PDLデータを受信するデータ処理装置との通信に適応して、PDLデータ解釈処理中にデータ処理装置に正常に応答処理が行える動作モードを決定できる仕組みを提供することである。上記目的を達成する本発明の画像処理装置は以下に示す構成を備える。所定の通信プロトコルに従いデータ処理装置からPDLデータを受信する受信手段と、マルチモードが設定されている場合はマルチタスクで、シングルモードが設定されている場合はシングルタスクで前記受信手段により受信されたPDLデータを解釈する解釈手段と、前記所定の通信プロトコルのタイプが問い合わせ命令に対し応答する必要があるタイプであるか否かを判別する判別手段と、前記判別手段により必要がないタイプであると判別された場合は、マルチモードの設定を切り替えず、前記判別手段により必要があるタイプであると判別された場合は、前記解釈手段にシングルタスクでPDLデータを解釈させるために、前記解釈手段に対して設定されているマルチモードの設定をシングルモードの設定へ切り替える制御手段とを備えることを特徴とする。本発明によれば、PDLデータを受信するデータ処理装置との通信に適応して、PDLデータ解釈処理中にデータ処理装置に正常に応答処理が行える動作モードを決定できる。これにより、データ処理装置との間で通信エラーが発生する可能性が低減され、適正な印刷処理を行うことが可能になる。次に本発明を実施するための最良の形態について図面を参照して説明する。<システム構成の説明>第1実施形態図1は、本実施形態を示す画像処理システムの一例を示す図である。本例は、ネットワークを介してデータ処理装置と画像処理装置とが双方向通信可能に接続されたシステム例である。なお、画像処理装置の一例として、所定のPDLPageDescriptionLanguageデータを受信するプリンタ装置を例とする。本実施形態では、所定のPDLデータとして、PostScriptに準拠するPDLデータを想定して説明を行う。図1において、2500はデータ処理装置PCで、アプリケーションやミドルウェア、ドライバーソフトウェアを動作させ、PDLデータ1000を生成するデータ処理を行う。PC2500とプリンタ100は、ネットワーク300に代表される通信手段によって相互に接続されている。プリンタ100はネットワーク300に代表される通信手段を通じて得たPDLデータ1000を使い、紙400に代表される可視媒体上に可視像を形成する。なお、本実施形態ではPC2500はパーソナルコンピュータを想定するが、それ以外の以下のようなPDLデータ1000やそれに相当する画像データを生成し、転送することができる装置であれば、本発明を実施できることは言うまでもない。すなわち、ワークステーション、メインフレームコンピュータ、スマートフォンやデジタルカメラなどのであれば、本発明を実施できることは言うまでもない。また、本実施例では画像処理装置はプリンタを例にして説明している。しかしながらこれも同様に、それ以外のMFPマルチファンクションプリンターや、印刷機、ディスプレイ装置などとよばれている可視像を形成することができる装置一般でも、本発明を実施できることは言うまでもない。以下、PC2500とプリンタ100との接続技術および通信手段について図1を参照して説明する。まず、本実施形態に示す画像処理システムは、以下のような接続技術を前提としている。すなわち、プリンタとの接続はイーサネット登録商標ワークに代表される双方向通信可能なネットワーク300によって実現される。もちろん、それ以外のUSBインタフェース100-7、IEEE1284100-8などの双方向通信可能なインタフェース装置を用いたとしても本発明を実施できることは言うまでもない。次に、接続技術を介して、PDLデータ1000、特にPostScript登録商標を用いた通信方法について以下に説明する。まず、第一にPC2500はネットワーク300を介してPDLデータ1000をプリンタ100に送信する。このPDLデータ1000の送信は、たとえば以下のように実施される。本実施形態においては、PC2500はPOSIX登録商標規格に準拠したコンピュータである。よって、以下のようにホストコンピュータ上で実行することで、プリンタにPDLデータ1000を送ることができる。すなわち、たとえばtest.psというファイルをlp0というデバイスに接続されたプリンタに送る場合には以下のように実行する。[footest-ws~]cat/home/foo/test.ps>/dev/lp0この送信されたPDLデータは、ネットワーク300を介して、プリンタ100に送信される。プリンタ100はPDLデータ1000を受信し、これを処理することで、紙400上に可視像を形成する。または、プリンタ100はPDLデータ1000を受信し、これを処理することで、ホストに対して応答4000を行う。この、応答4000はPDLデータ1000を用いたホストからの問い合わせに返答するために行われる。以下にその応答処理の簡単な例を示す。例えば、PC2500がPostScript登録商標規格に従ったPDLデータ1000を使って、プリンタ100に以下のような問い合わせを行うことができる。/XXXXXX-Font/Fontresourcestatus==clearこのPDLデータ1000はプリンタ100内にXXXXXX-Fontというフォントリソースファイルが存在するかを問い合わせる命令である。このPDLデータ1000を受け取ったプリンタ100は、このPDLデータを解釈する。そのうえでプリンタ100は、このフォントリソースファイルがプリンタ100内に存在するかを確認する。プリンタ100は、このフォントリソースファイルが存在する場合には、以下のようなデータtrueを応答4000としてPC2500に応答する。また、もし上述したフォントリソースファイルがプリンタ100内に存在しなければ、プリンタ100は以下のようなデータfalseを応答4000としてPC2500に応答する。ここまで説明してきたように、本実施形態においてプリンタ100はPC2500と双方向に通信を行いながらPDLデータの解釈処理を行うことができる。なお、本実施例におけるPC2500はPOSIX登録商標規格に準拠したコンピュータである。しかしながら、それ以外の規格に従ったコンピュータであっても、マルチタスク処理及び双方向通信を実現するコンピュータであれば本発明を実施できることは言うまでもない。次に、本実施形態における上述したPDLデータ1000の構造について図2を参照して説明する。図2は、図1に示した画像処理装置が処理するPDLデータの構造を説明する図である。図2において、本実施形態において、PDLデータ1000はPostScript登録商標技術を採用したデータ構造を持つ。すなわち、PDLデータ1000はデータ内部に描画命令1000-1と問い合わせ命令1000-2とを少なくとも持つことができる。描画命令1000-1は以下の命令を持つことができる。すなわち、描画命令1000-1はストローク文字命令1000-1-1、文字描画命令1000-1-2を持つことができる。また加えて、描画命令1000-1は塗りつぶし描画命令1000-1-3、ラスタービットマップ描画命令1000-1-4を持つことができる。また、問い合わせ命令1000-2は以下の命令を持つことができる。すなわち、問い合わせ命令1000-2はファイルチェック命令1000-2-1、利用可能フォントリスト問い合わせ命令1000-2-2を持つことができる。また加えて、問い合わせ命令1000-2はプリンタ名の問い合わせ命令1000-2-3を持つことができる。もちろん、PDLデータ1000がこれ以外の描画命令1000-1や問い合わせ命令1000-2を持つことができたとしても本発明を実施できる。次に、本実施形態における中間データ2000の構造について図3を参照して説明する。図3は、本実施形態を示す画像処理装置で処理する中間データ2000の構造を説明する図である。図3において、中間データ2000は後述するRIPASIC1000-3が解釈可能なデータ構造を持つ。RIP-ASICは以下に示す中間データ2000に含まれる命令群2000-1,2000-2を解釈することで画像形成用ビットマップデータを生成することができる。すなわち、中間データ2000はデータ内部に塗りつぶし描画命令2000-1と、ラスタービットマップ描画命令2000-2とを少なくとも持つことができる。もちろん、中間データ2000はこれ以外の描画命令を持つことができたとしても本発明を実施できる。次に、データ処理装置から画像処理装置に送信される問い合わせ命令の例を以下に示す。図4、図5は、図1に示したデータ処理装置から画像処理装置に送信される問い合わせ命令の例を示す図である。なお、問い合わせ命令は非特許文献1に示されているDSC規格にしたがっており、本実施形態においては以下のような特徴持つ。1問い合わせジョブ開始は、ジョブ認識コメントPSAdobe30Queryで始まりEOFで終わる。2問い合わせ命令は2個のパーセント文字によって指定され、行頭に現れなければならない。3問い合わせ命令はBeginで始まる。4問い合わせ命令は、255文字までのテキスト文字列が続き、行の終わりを表す記号endoflineが続く。5行の終わりを表す記号endoflineは、ラインフィールドHex:0DかキャリッジリターンHex:0Aのどちらかである。6問い合わせ命令の終わりは、Endの後ろに1つ以上のキーワードが続く。7問い合わせ命令の終わりにさらにオプションでコロンが続き、問い合わせに対するデフォルトの値が続いた一連の並びで区切られている。8プリンタ100は、問い合わせを解析できなかった場合、またその問い合わせをサポートしていない場合に上記デフォルトの値を返す。9問い合わせジョブには複数の問い合わせを含ませることが可能である。後述するDSC処理部200-1は、上記規格にしたがい問い合わせ命令を抽出する。その上で、DSC処理部200-1は抽出された問い合わせ命令の種類を判別し、その判別にしたがいDSC処理を行う。このDSC処理部200-1が行うべき処理について、より具体的な例を示すために図4を参照して説明する。図4において、1000-3-0は問い合わせジョブの先頭を示す命令である。1000-3-1は問い合わせコメントの開始命令である。特にここで示されている命令はフォントリスト、すなわちプリンタにインストールされたフォントの一覧をPC2500からプリンタ100に問い合わせる命令である。DSC処理部200-1はこの命令を見つけると、HDD100-2ないしRAM100-1に保存されているフォントファイル一覧を取得する。次に、DSC処理部200-1はこのフォントファイル一覧を、PC2500にネットワーク300を通じて返答する処理を実行する。続く、1000-3-2は問い合わせコメントの終了命令である。本命令は、上記問い合わせコメントの開始命令1000-3-1と対をなし、問い合わせコメント命令1000-2のその命令の範囲を明確にする。また、DSC処理部200-1が行うべき処理について、より具体的なもう1つ例を示すために図5を参照して説明する。図5において、1000-3-5は問い合わせジョブの先頭を示す命令である。1000-3-6は問い合わせコメントの開始命令である。特にここで示されている命令はproduct、すなわちプリンタ100の名前をPC2500からプリンタ100に問い合わせる命令である。続いて、1000-3-8はPostScript登録商標規格に従った問い合わせ命令である。ここでは上記命令と同様にproduct、すなわちプリンタ100の名前をPC2500からプリンタ100に問い合わせる命令である。本実施例ではPDL解釈部200-2はこの命令を見つけると、HDD100-2ないしRAM100-1に保存されている商品名を取得する。次に、PDL解釈部200-2はこの商品名をPC2500にネットワーク300を通じて返答する処理を実行する。続く、1000-3-2は問い合わせコメントの終了命令である。本命令は、上記問い合わせコメントの開始命令1000-3-1と対をなし、問い合わせコメント命令1000-2のここの命令の範囲を明確にする。上述したように、DSC規格に従った命令中にPostScript登録商標規格に従った問い合わせ命令が含まれることがある。これはDSC規格の命令だけではないPostScript登録商標規格のデータを交えた問い合わせ命令に、以下のような利点があるためである。すなわち、PostScript登録商標特有の高度な言語解析を用いることで、複雑な問い合わせ命令を実現できるためである。PostScript登録商標特有の高度な言語解析の特徴として以下のものがある。procnameと呼ばれる値を設定することによって、PostScript登録商標規格に従うとはプリンタ100はあらかじめ固定的な処理、すなわちプロシージャーを登録することができる。また別の特徴としては以下のようなものがある。すなわちPostScript登録商標規格に従うと、プリンタ100は変数を用いた言語解析処理が可能となる。もちろん、これ以外にもPostScript登録商標の利点はあるが、本実施例はPostScript登録商標の詳細仕様を説明するものではないので割愛する。PostScript登録商標の詳細仕様は非特許文献1を参照されたい。次に、DSC処理部が処理を行う命令群と、命令とその処理の順にそれぞれ以下にいくつか説明する。BeginFileQuery:<filename>EndFileQuery:<default>上記命令はプリンタ100内で指定したファイルが利用可能かどうか。BeginFontListQueryEndFontListQuery:<default>上記命令はプリンタ100内で利用可能フォントのリストを問い合わせる命令である。BeginFontQuery:<fontname>...EndFontQuery:<default>プリンタ100内で指定したフォントが利用可能かどうかを問い合わせる命令である。BeginPrinterQueryEndPrinterQuery:<default>プリンタ100の製品名、バージョン番号とリビジョン番号を問い合わせる命令である。もちろん、上述した背景技術に示されているように、問い合わせ命令はこれ以外も定義されている。しかしながら本実施例は問い合わせ命令の詳細仕様を説明するものではないので、ここではこれ以上の説明を割愛する。詳細は非特許文献1を参照されたい。また、ここまで問い合わせ命令のデータフォーマットと命令に対する実行例を説明した。しかし、これ以外の規格にしたがっても、プリンタ100に対する問い合わせ命令を伝送するデータフォーマットであれば本発明を実施できることは言うまでもない。次に、上述したようなPDLデータ1000に対するプリンタ100内の画像処理装置が持つ諸装置について図6を使いながら以下に説明する。図6は、本実施形態を示す画像処理装置の構成を説明するブロック図である。図6において、100-7はUSBインタフェースであり、USB規格の外部装置を通じて外部からPDLデータ1000をプリンタ100に入力することを可能にしている。100-8はIEEE1284インタフェース装置であり、同様にIEEE1284規格のハードウェアを持つ外部装置を通じて外部からPDLデータ1000をプリンタ100に入力することを可能にしている。100-9はネットワーク装置であり、同様にネットワーク規格のハードウェアを持つ外部装置を通じて外部からPDLデータ1000をプリンタ100に入力することを可能にしている。上述したUSBインタフェース100-7、IEEE1284インタフェース装置100-8、ネットワーク装置100-9は後述する、通信制御部200-0の制御のもと上述したPDLデータ1000をプリンタ100内に受信することができる。100-0はCPUであって、下記RAM100-1に保存された命令を実行することで、後述するPDL解釈処理などを実現するソフトモジュール200を実行する。100-1はRAMであり、揮発性の記憶媒体である。このRAM100-1はPDLデータ1000やCPU100-0が実行すべき命令を保存することができる。またこのRAM100-1は、バス100-5を通じてPDLデータ1000やCPU100-0が実行すべき命令を、CPU100-0を含む諸装置に転送することができる。このRAM100-1は揮発性の記憶媒体であるから、プリンタ100の電源が落とされると、保存された命令やデータは消去される。100-2はHDDであり、不揮発性の記憶媒体である。このHDD100-2は、CPU100-0が処理すべき命令やデータを保存しておくことで、電源断によってRAM100-1上から失われるCPU100-0が処理すべき命令やデータを保存しておくことができる。また、本実施理においてはこのHDD100-2はRAM100-1より容量が大きい。よって、本実施例においては画像形成用ビットマップデータ3000に代表されるデータはこのHDD100-2に保存される。もちろん、本実施例では不揮発性の記憶媒体としてHDDを例に示しているが、HDDの代わりにフラッシュ型EEPROM、強誘電体メモリFeRAM、磁気抵抗メモリMRAMなどを用いても本発明を実施できることは言うまでもない。100-3はRIPASICであり、のちに説明する中間データを受け取ってビットマップデータ3000を生成することができる。100-4は電子写真エンジンであって、上記RIPASIC100-3が生成したビットマップデータ3000を用いて、紙に代表される可視媒体上に可視像を形成する。なお、本実施例では電子写真エンジンを使って可視媒体上に可視像を得ているが、下記に示すそれ以外の機構を用いても本発明を実施できることは言うまでもない。すなわち、液晶パネル、有機ELパネル、凸版印刷エンジン、オフセット印刷エンジン、インクジェット印刷エンジンなどを使っても本発明を実施できる。100-5はバスであり、上述した各々の装置を接続し、データや命令を相互にやり取りすることを可能にする。次に、上記CPU100-0上で動作するソフトモジュール200について図7を参照して説明する。図7は、本実施形態を示す画像処理装置のデータ処理モジュールの構成を説明するブロック図である。なお、以下に示す200-0~200-6はCPU100-0が実行するソフトウエアモジュールであり、説明上これらを総称する場合において、ソフトウエアモジュール群と呼ぶ場合がある。図7において、200-0は通信制御部であり、第一に上述したUSBインタフェース100-7、IEEE1284インタフェース装置100-8ないしネットワーク装置100-9を制御し、PC2500との通信コネクションを確立する。第二に、通信制御部200-2は、上述したUSBインタフェース100-7、IEEE1284インタフェース装置100-8ないしネットワーク装置100-9を制御することで、上述したPDLデータ1000を受信する。第三に通信制御部200-2は、受信したPDLデータ1000をRAM100-1に記憶することができる。200-1はDSC処理部であり、RAM100-1上に記憶されたのちに、PDLデータ1000に対する解釈処理を行う。特に、DSC処理部200-1は、PDLデータ1000に含まれる上述したDSC規格にしたがった問い合わせ命令1000-2を処理することができる。200-2はPDL解釈部であり、RAM100-1上に記憶された後、PDLデータ1000に対する解釈処理を行う。また、PDL解釈部200-2は、後述するOS200-5の制御のもと、複数のタスク内でPDL解釈処理を並列して行うことができる。また、PDL解釈部200-2は、後述するDSC処理部200-1が処理できなかった問い合わせ命令1000-2を処理することができる。200-3は画像生成部であり、上記PDL解釈部の処理結果とRIPASIC100-3を使うことで画像形成用ビットマップデータ3000を生成する。200-4はエンジン制御部であり、画像形成用ビットマップデータと電子写真エンジン100-4を使うことで、画像形成処理を行う。200-5はジョブコントローラであり、上述したそれぞれのソフトモジュールの処理フローの伝達を行う。また、ジョブコントローラは、後述するシングルタスクで実行するか、マルチタスクで実行するかを判断し、その結果をPDL解釈部200-2に対して通知する。200-6はOSであり、上述したすべてのソフトモジュール群200-0,200-1,200-2,200-3,200-4,200-5のタスク管理をおこなう。タスク管理とは、少なくとも従来技術特に非特許文献2で説明したマルチタスク処理を含む。すなわち、このOS200-6が提供するタスク管理機能によって、PDL解釈部200-2の並列処理が実現される。ここでは処理フロー詳細を説明する前に、図7に示したソフトウエアモジュール群200-0,200-1,200-2,200-3,200-4,200-5がどのような処理を行うかについて、図8を参照して説明する。図8は、本実施形態を示す画像処理装置のソフトウエアモジュールの処理を説明するブロック図である。以下、図1に示した画像処理装置において、双方向通信でデータ処理装置PC2500から受信するPDLデータを設定される動作モードに従いマルチタスクまたはシングルタスクで解釈処理するPDLデータ解釈処理を説明する。さらに、プリンタ100が受信したPDLデータの中に当該画像処理装置が前記データ処理装置に対して応答すべき問い合わせ情報があるかどうかを判定するDSC処理部200-1の処理を説明する。即ち、データ処理装置PC2500から受信したPDLデータに問い合わせ命令1000-2が含まれているか否かを、プリンタ100が有するDSC処理部200-1が判定する処理である。なお、後述する200-0~200-5はCPU100-0上で動作するモジュールとして構成される例を示す。また、DSC処理部200-1による判定処理結果に応じて、ジョブコントローラ200-5によるPDLデータ解釈部200-2に対して設定されている動作モードをマルチモードからシングルモードへ切り替える制御を説明する。本実施形態においては、図8に示したプリンタ100に入力される入力データはPDLデータ1000である。そして、プリンタ100内のソフトウエアモジュール群200-0,200-1,200-2,200-3,200-4,200-5は、このPDLデータ1000を処理する。この処理によって、プリンタ100はPDLデータ中の問い合わせ命令1000-2の結果4000と、画像形成用のビットマップデータ3000を得る。問い合わせ命令1000-2に対する応答4000を得るために、DSC処理部200-1ないし、PDL解釈部200-2がPDLデータ1000を解釈するS20-1,S20-2。また、PDL解釈部200-2のPDLデータ1000の解釈によって、中間データ2000が生成されるS20-2。この中間データ2000を画像生成部200-3の制御の下、RIPASIC100-3が解釈することによって、画像形成用のビットマップデータ3000が生成レンダリングされるS20-3。プリンタ100は、上記各ソフトモジュールを用いて以下に説明するPDLデータの画像形成処理をPDLデータ1000に対して行うことによって、本発明におけるモード切り替え制御を実行する。次に、上述したようなプリンタ100内の諸装置を使って行われる、PDLデータ1000に対する処理について図9を参照して説明する。図9は、本実施形態を示す画像処理装置のデータ処理方法を説明するフローチャートである。本例は、CPU100-0がRAM100-1に制御プログラム図7に示した各ソフトモジュール群をロードして実行することにより実現される。なお、PDLデータ解釈部200-2は、双方向通信でPC2500から受信するPDLデータを、設定される動作モードに従いマルチタスクまたはシングルタスクで解釈処理可能であることを前提とする。ここで、動作モードは、ジョブコントローラ200-5により、シングルモードとマルチモードのいずれかを切り替え設定可能に構成されている。また、DSC処理部200-1は、PC2500から受信するPDLデータにプリンタ100がPC2500に対して応答すべき応答情報が含まれているかどうかを判定する機能を備える。具体的には、DSC処理部200-1は、図8に示したように、PDLデータにPC2500に対して応答すべき応答すべき命令があるかどうかを判定する命令判定機能処理を後述するフローチャートに基づいて実行する。なお、AppleTalk登録商標に準拠する通信プロトコルを第1の通信プロトコルとし、TCP/IP等拠する通信プロトコルを第2の通信プロトコルとする。第1の通信プロトコルは、問い合わせ命令に対し応答が必要となるPDLデータを送信するための規格であり、双方向通信タイプの通信プロトコルである。一方、第2の通信プロトコルは応答を必要としない通信プロトコルであり、問い合わせ命令の内、応答を必要としない命令のみ処理を行う規格である。第2の通信プロトコルは、片方向通信タイプの通信プロトコルである。また、CPU100-0上で動作する上記200-0~200-5についてモジュールを主体として説明する。まず、ジョブコントローラ200-5は、第一にPDL動作モードをあらわす変数をマルチモードに設定するS10-0。この処理は、ジョブコントローラ200-5が、RAM100-1上に記録されているPDL動作モードをあらわす変数を書きかえることによって実行される。本実施例におけるPDLデータ解釈部200-2は、初期設定としてマルチモードが設定されており、マルチタスクでPDLデータの解釈処理を行う。なお、シングルモードが設定された場合、PDLデータ解釈部200-2はシングルタスクでPDLデータの解釈処理を行う。この変数がマルチモードに設定されていた場合、PDLデータ解釈部200-2は以下のように動作する。すなわち、OS200-6の制御のもと、二つ以上のタスクで起動する。そのうえでPDLデータ解釈部200-2は分割されたPDLデータ1000を使い、二つ以上のタスクで並行してPDLデータ1000に対する解釈処理を行う。また、この変数がシングルモードに設定されていた場合にはPDLデータ解釈部200-2は以下のように動作する。すなわち、OS200-6の制御のもと、一つのタスクで起動する。そのうえでPDLデータ解釈部200-2は一つのPDLデータ1000を使い、1タスクでPDLデータ1000に対する解釈処理を行う。その際、2つのPDLデータ解釈部200-2の内、解釈処理を行わないPDLデータ解釈部200-2に対し停止命令が出される。なお、このマルチモードおよびシングルモードの動作に関しては下記の処理フロー説明でも説明する。次に、通信制御部200-1は、PC2500からの通信に応じて、上述したUSBインタフェース100-7ないしIEEE1284インタフェース装置100-8ないしネットワーク装置100-9を制御することでPC2500との通信コネクションを確立させるS10-1。次に、通信制御部200-1は、上記S10-1で確立したコネクションの通信プロトコルのタイプが第1の通信プロトコルであるかどうかを判定するS10-2。この判定によって、通信制御部200-1は双方向通信が必要なコネクションが確立したかを判定することができる。次に、ジョブコントローラ200-5は上記判定に基づき通信プロトコルのタイプが第1の通信プロトコルであればS10-3の処理を行うようにPDL解釈部200-2に通知する。また一方で、CPU100-0上で動作するジョブコントローラ200-5は上記判定に基づき通信プロトコルが第1の通信プロトコルでなければ、DSC処理部200-1およびPDL解釈部200-2に従来マルチタスク処理で中間データを生成するように通知するS10-14、S10-15、S10-16、S10-17、S10-18。この判断は以下のような技術的背景がある。つまり従来技術で説明したように、第1の通信プロトコルが双方向通信を必要としている。よって、プリンタ100は通信プロトコルが第1の通信プロトコルである場合には、PC2500に対して応答をしなければならない可能性がある。もちろん、第1の通信プロトコル以外に双方向通信が必要な通信に対応したプリンタ100を実施するために、上記判定S10-2条件に第1の通信プロトコル以外の判定を追加しても本発明を実施できることは言うまでもない。次に、S10-2で、第1の通信プロトコルではないと判断された場合の処理を以下に説明する。まず、通信制御部200-1は、PDLデータ1000の受信処理を行うS10-14。この処理は、上述したUSBインタフェース100-7ないしIEEE1284インタフェース装置100-8ないしネットワーク装置100-9を制御することでPDLデータ1000を受信する。その上で、通信制御部200-1は、PDLデータ1000をRAM100-1に記憶させることで実行される。次に、DSC処理部200-1は、DSC解釈処理行うS10-15。この処理は、第一にDSC処理部200-1がRAM100-1に記憶されたPDLデータ1000の中からDSC規格のデータを抽出する。次に、DSC処理部200-1は上述した問い合わせ命令1000-2の処理を行う。ただし、ここでの処理は上記S10-2で双方向通信が必要ないと判断されたので、DSC処理部200-1はホストに対する応答を伴わない命令のみを実行すればよい。よって、DSC処理部200-1はホスト側に対して応答処理を行う必要がない。続いて、ジョブコントローラ200-5は、PDLデータ1000の分割処理を行うS10-16。この処理は第一に、ジョブコントローラ200-5がRAM100-1に記憶されているPDLデータ1000を、後述するPDLデータのマルチタスク処理でPDLデータ1000の解釈処理を行うために、データを二つ以上に分割する処理である。次に、CPU100-0上で動作するPDL解釈部200-2は、マルチタスク処理を用いたPDL解釈処理を行うS19-17。この処理は、二つ以上のタスク内でPDL解釈部200-2がRAM100-1上に分割された状態で保存されたPDLデータ1000を読み込む。続いて、二つ以上のタスク内でPDL解釈部200-2はPDLデータ1000中の描画命令1000-1および問い合わせ命令1000-2に対する解釈処理を行う。分割の際は、PDLデータをページ毎に分割し、各PDL解釈部200-2の付加状況に応じて処理ページを適正に割り振る。本実施形態ではPDL解釈部200-2はPostScript登録商標規格に従い、上記命令群を解析する。ただし、上述したようにここでの処理は上記S10-2で双方向通信が必要ないと判断されたので、PDL解釈部200-2はホスト側に対する応答を伴わない命令のみをよりすればよい。よって、PDL解釈部200-2はホスト側への応答処理を行う必要がない。次に、PDL解釈部200-2は、上記解釈処理の描画命令1000-1のみを使って中間データ2000を生成してS10-18、S10-11へ進む。一方、上記S10-2で、第1の通信プロトコルであると判断した場合の処理を以下に説明する。まず、通信制御部200-1は、PDLデータ1000の受信処理を行うS10-3。この処理は、上述したUSBインタフェース100-7ないしIEEE1284インタフェース装置100-8ないしネットワーク装置100-9を制御することでPDLデータ1000を受信する。その上で本処理S10-3は、通信制御部200-1は、PDLデータ1000をRAM100-1に記憶させることで実行される。次に、ジョブコントローラ200-5はPDL動作モードの変数がマルチモードかを判定するS10-4。この処理は、CPU100-0がRAM100-1上に保存されている変数の真偽値を判定することで実行される。次に、上記S10-4でマルチモードであると判定された場合には、CPU100-0上で動作するDSC処理部200-1は、DSC解釈処理を行うS10-5。この解釈処理において、DSC処理部200-1は、PDLデータ1000中に問い合わせ命令があるかどうかを判定するS10-6。この判定S10-6で、問い合わせ命令があるとDSC処理部200-1が判定した場合には、DSC処理部200-1は問い合わせ命令の解析にはPDLデータ解釈処理部200-2によるPDL解釈処理が必要かを判定するS10-7。この判定S10-7で、PDLデータ解釈処理部200-2によるPDL解釈処理が必要であるとDSC処理部200-1が判定した場合には、CPU100-0上で動作するジョブコントローラ200-5は、PDL動作モード変数をシングルモードに書き換えるS10-8。その上で、ジョブコントローラ200-5は1つのタスク内でPDL解釈処理をするようにPDL解釈部200-2に指示する。この指示のもと、PDL解釈部200-2がシングルタスク内でPDLデータの解析を実行する。次に、PDL解釈部200-2は、上記解釈処理の描画命令1000-1のみを使って中間データ2000を生成するS10-9。一方で、上記S10-6で、問い合わせ命令がないとDSC処理部200-1が判定した場合には、ジョブコントローラ200-5は、上述したPDLデータ1000の分割処理を行うS10-16。以下のS10-17、S10-18に示された処理は上述した通りなのでその説明を省略する。また一方で、上記S10-7で、PDLデータ解釈処理部200-2によるPDL解釈処理が必要ないとDSC処理部200-1が判定した場合には以下の処理を行う。すなわち、DSC処理部200-1はDSC解釈処理によって必要となった問い合わせ命令に対する返答処理を、DSC処理部200-1で行うS10-10。次に、ジョブコントローラ200-5は、上述したPDLデータ1000の分割処理を行うS10-16。以下のS10-17、S10-18に示された処理は上述した通りなのでその説明を省略する。なお、PDLデータを終端まで処理した後、シングルモードの設定をマルチモードの設定に切り替えるよう制御する。これにより、次に来るPDLデータが、例えば、PostScriptでなければ、高速に処理することが可能になる。また、第1通信プロトコルでPostScriptが送信されれば、図9に示すフローを実行することになり、適正なPDLデータ処理を行うことが可能になる。上述した、S10-9およびS10-18の処理の後、CPU100-0上で動作するジョブコントローラ200-5は、PDLデータ1000を末端まで読み込んだかを判定するS10-15。この処理は、ジョブコントローラ200-5が以下の処理を行うことで実現される。すなわち、第一にジョブコントローラ200-5はRAM100-1上にまだ読み込んでいないPDLデータ1000がないことを調べる。また加えて、ジョブコントローラ200-5は通信制御部200-0に対して通信コネクションが閉じられたかを問い合わせることによって通信コネクションが閉じられたかを判定する。上記二つの判定がともに真である場合に、ジョブコントローラ200-5はPDLデータ1000を終端まで読み込んでいると判定するS10-11。この判定S10-15において、もしPDLデータ1000を終端まで読み込んでいないとジョブコントローラ200-5が判定した場合には、CPU100-0はS10-3で示す処理に戻り、再びデータ入力から処理を開始する。一方で、上記S10-15で、もしジョブコントローラ200-5がPDLデータ1000を終端まで読み込んでいると判定した場合には以下の処理を行う。すなわちジョブコントローラ200-5は画像形成用ビットマップデータ3000を生成するように画像生成部200-3に命令するS10-16。この処理は、以下の処理によって実現される。第一に上述したPDLデータ1000の解釈処理によって生成された中間データ2000を画像生成部200-3の制御の元、RIPASIC100-3が画像形成用ビットマップデータ3000を生成する。この処理は一般にレンダリング処理と呼ばれるものである。第二にRIPASIC100-3が生成した画像形成用ビットマップデータをHDD100-2に保存する。次に、ジョブコントローラ200-5は、エンジン制御部200-4に対して上記生成された画像形成用ビットマップデータ3000を使って画像形成するように命令してS10-17、本処理を終了する。なお、S10-13の処理は、エンジン制御部200-4の制御の元、電子写真エンジン100-4が上述した画像形成用ビットマップデータを使って、紙に代表される可視媒体400上に可視像を形成することによって実現される。なお、本実施形態では画像形成用ビットマップデータはHDD100-2に保存することによって実施されるが、HDD100-2に保存される代わりに、RAM100-1やその他記憶装置に保存されたとしても、本発明を実施できることは言うまでもない。以上説明したように、図9に示す処理において、問い合わせ命令があると判定されS10-6、且つPDLデータ解釈処理部200-2によるPDL解釈処理が必要と判定された場合には以下のように処理をしている。すなわち、PDL解釈部200-2を1つのタスク内で動作させ、PDL解釈処理を行う。これによって、PDL解釈処理中に必要な問い合わせ命令に対する返答処理が、二つのタスクから行われなくなる。これにより、本処理に従えば、上記第1の通信プロトコルでPC2500と通信する際であって、マルチタスクモードが設定されていた場合であっても、PDLデータの解釈処理時にPC2500との間で通信エラーが発生することがなくなる。また、本実施形態では、図9に示す処理において、問い合わせ命令があると判定されS10-6、且つPDLデータ解釈処理部200-2によるPDL解釈処理が必要と判定された場合には以下のように処理をしている。すなわち、PDL解釈部200-2を1のタスク内で動作させ、PDL解釈処理を行う。これによって、PDL解釈処理中に必要な問い合わせ命令に対する返答処理をPDL解釈部による返答処理が必要な場合にのみ、シングルタスクで処理可能である。これにより、課題で示した様なパフォーマンスが低下するのを防ぎ、結果マルチタスク処理によるパフォーマンスを向上させることができる。また、上記実施形態では、画像処理装置としてプリンタの例を示すが、画像処理装置が複合機等で構成されていてもよい。さらに、PC2500がクラウドコンピューティング環境のサーバ装置で構成されていてもよい。本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエアプログラムをパソコンコンピュータ等の処理装置CPU、プロセッサにて実行することでも実現できる。本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形各実施形態の有機的な組合せを含むが可能であり、それらを本発明の範囲から除外するものではない。本実施形態では、1つのCPUで2つのPDL解釈部を実現した。しかしながら、例えば、2つのCPUで2つのPDL解釈部を実現しても良い。これを、マルチCPUを用いた解釈処理と称する。この場合、各CPUにPDL解釈部を1つずつ実現することが考えられる。なお、CPUの数、およびPDL解釈部の数は上述に限られない。"