(57)【要約】【課題】バッファ容量が限られた画像形成装置における割込印刷中でも、印刷要求データに対する応答をホスト側に返せるようにする。【解決手段】ネットワークを介してホストから印刷要求データを受信すると、送受信バッファ５に格納し、描画部２で描画処理を行う。印刷処理中に割込印刷要求データを受信すると、割込印刷用である他の送受信バッファ５に格納し、割込印刷を行う。割込印刷中に印刷要求データを受信すると、応答用であるさらに他の送受信バッファ５に格納し、コマンドを解析して応答コマンドをホストに送信する。割込印刷中の印刷要求に対する応答用の送受信バッファ５を設けることにより、割込印刷中でも、印刷要求データを受信でき、コマンドを解釈してホスト側に応答を返すことができる。【選択図】図１
2008221831.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された情報処理装置から印刷データを受信する手段と、受信した通常の印刷データを保持するための第１のバッファと、受信した割込印刷データを保持するための第２のバッファと、割込印刷中にデータの保持が可能な第３のバッファと、受信した印刷データを解析する手段と、割込印刷中に受信され、前記第３のバッファに保持されている印刷データを解析した結果に応じた応答コマンドを前記情報処理装置に送信する手段とを備える画像形成装置。
【請求項２】
請求項１に記載の画像形成装置において、
前記解析する手段は、前記バッファ毎に設けられている画像形成装置。
【請求項３】
請求項１に記載の画像形成装置において、
前記応答コマンドを前記情報処理装置に送信する前に割込印刷が完了しているかどうか確認する手段を備える画像形成装置。
【請求項４】
請求項１に記載の画像形成装置において、
前記応答コマンドを送信した後すぐに前記第３のバッファを解放する手段を備える画像形成装置。
【請求項５】
請求項１に記載の画像形成装置において、
バッファ用のメモリの空きが少なくなった場合でも前記第３のバッファを確保するように制御する手段を備える画像形成装置。
【請求項６】
請求項１に記載の画像形成装置において、
割込印刷中に受信され、前記第３のバッファに保持されている印刷データを解析した結果、応答コマンドの不要な印刷データであった場合、前記第３のバッファのうち、前記情報処理装置に送信しないダミーデータを格納するための領域に、前記応答コマンドを保持させる手段を備える画像形成装置。
【請求項７】
ネットワークを介して接続された情報処理装置から印刷データを受信する工程と、受信した通常の印刷データを第１のバッファに格納する工程と、第１のバッファに格納した印刷データを基に描画処理を行う工程と、その描画処理中に割込印刷データを受信すると割込印刷用の第２のバッファに格納する工程と、第１のバッファに格納した印刷データに基にした描画処理を中断して、第２のバッファに格納した印刷データを基に描画処理を行う工程と、その描画処理中に印刷データを受信すると応答用の第３のバッファに格納する工程と、第３のバッファに格納した印刷データを解析する工程と、解析した結果に応じた応答コマンドを前記情報処理装置に送信する工程とを備える画像形成装置の印刷制御方法。
【請求項８】
請求項７に記載の画像形成装置の印刷制御方法において、
前記第３のバッファに格納した印刷データを解析する工程と前記応答コマンドを送信する工程との間に、前記第２のバッファに格納した印刷データを基にした描画処理が完了しているかどうか確認する工程を備え、その確認の結果を前記応答コマンドの内容に反映させるようにした画像形成装置の印刷制御方法。
【請求項９】
請求項７に記載の画像形成装置の印刷制御方法において、
前記応答コマンドを送信した後すぐに前記第３のバッファを解放する工程を備える画像形成装置の印刷制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像形成装置及びその印刷制御方法に関し、特に、ネットワーク接続された割込印刷可能な画像形成装置及びその印刷制御方法に関する。
【背景技術】
【０００２】
従来のネットワークプリンタでは、ネットワークに接続された多くのホストコンピュータ（以下、ホストと言う）で、ネットワークプリンタを共同使用している。この場合、１台のネットワークプリンタに対して、複数のホストが次々と印刷要求を行うことがある。そのとき、１つの印刷処理が終了するまで長時間を要すると、後の印刷処理を効率良く行うことができない。そこで、優先度の高い印刷要求については、印刷処理中に割込印刷を行うことによって、ユーザの待ち時間を減らす方法が採られている。割込印刷では、印刷データを一時的に退避するための退避用バッファを用意する。割込印刷の要求があると、退避用バッファに一旦印刷データを保存する。割込印刷のデータを、受信バッファに格納して印刷する。割込印刷が終った後に、退避用バッファから印刷データを読み出して、印刷を再開する。以下に、これに関連する従来技術の例を、いくつかあげる。
【０００３】
特許文献１に開示された「印刷実行順位を決定するプリンタ」は、ユーザの印刷の緊急性に応じて、プリンタが自動的に印刷の順番を判断して、必要性の高いものから順に印刷するものである。ネットワーク上で複数のユーザが共通して使用するプリンタである。印刷指令を出した順に関係なく、ユーザが設定した印刷優先順位に従って印刷を実行する。また、指定した時刻に印刷することもできる。更に、割込印刷信号に応答して、優先的に印刷を実行することや、予め登録された空き時間帯に印刷を実行することもできる。
【０００４】
特許文献２に開示された「割込印刷装置」は、割込印刷を行うことによって、後の印刷を希望するユーザの待ち時間を減らすものである。プリンタ装置の内部には、受信バッファと画像メモリと補助記憶画像メモリと受信バッファ待避エリア等がある。割込印刷の指示があると、受信バッファに格納した印刷データを、受信バッファ待避エリアに待避させ、割込印刷処理を実行する。割込印刷を先に実行して、効率よく印刷処理を行う。受信バッファ待避エリアに待避させた印刷データは、再度画像メモリに展開されるか、直接印刷処理に使用される。
【０００５】
特許文献３に開示された「画像形成装置」は、通常の印刷ジョブ実行中に他の印刷を行いたい場合に、総印刷部数と割込印刷部数とを入力できるようにし、割込印刷部数を割込印刷ジョブとして実行し、総印刷部数から割込印刷部数を引いた残りの部数は、予約印刷ジョブとして予約し、現印刷ジョブ実行後に実行するものである。通常印刷ジョブ実行中に、割込モードが選択され、かつ複数部数印刷が選択されると、印刷総部数と割込印刷部数を入力する。割込部数で指定された部数の印刷は、割込処理する。総部数から割込部数を引いた部数の印刷は、割込前の印刷ジョブ終了後に実行する。
【特許文献１】特開2000-272205号公報
【特許文献２】特開2001-246811号公報
【特許文献３】特開2001-320528号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、従来の割込印刷方法では、次のような問題がある。バッファの容量が十分あれば、すべての印刷要求を受信して処理できるが、バッファの容量が限られている場合は、２つ程度の印刷要求しか処理できない。割込印刷中にさらに次の印刷要求が来ると、バッファの空きがないので、受信も応答もできなくなり、ホスト側でプリンタの状態を知ることができなくなる。特に、ホストとプリンタとで双方向のやりとりが必要となるプロトコルを使って印刷する場合は、割込印刷が発生していてバッファが両方とも既に埋まっていると、プリンタ側で印刷データを受信できないため、それに含まれるコマンドを解釈できず、ホストに応答を返すことができない。そのような状態になると、プリンタ側のバッファが埋まっている間、タイムアウトするまでホスト側はずっと待ち状態になるので、ホストの操作者にプリンタがストールしているように思われる可能性がある。
【０００７】
この点について、図８を参照しながら説明する。図８は、応答が必要ないdiprintプロトコルで送られてきた印刷データを印刷中に、応答が必要なRHPP（Ricoh Host Print Protocol）で、優先度の高い印刷の要求が来て、割込印刷が発生し、その間にRHPPで印刷の要求が来た場合の説明図である。割込印刷は、「通常」に対して「優先度高」の１段階までとする。ここで、図８のＡ、Ｂは、それぞれ一時退避用バッファ、割り込み用送受信バッファを用いた場合の動作を示す。
【０００８】
図８Ａ、Ｂのいずれにおいても、割込印刷が発生しない場合は、通常用送受信バッファに順番に印刷データが格納され、受信順に印刷される。割込印刷要求が来ると、一時退避用バッファ（図８Ａの場合）又は割込用送受信バッファ（図８Ｂの場合）に印刷データを格納し、印刷中のジョブを一旦停止し、割込印刷を行う。割込印刷をするかどうかは、印刷データのパラメータに、そのジョブの優先度を決めるパラメータがあるので、通信Ｉ／Ｆ（インタフェース）がそれを見ることで判定できる。割込印刷中にさらに印刷要求が来ると、通常用送受信バッファも、一時退避用バッファあるいは割込用送受信バッファも使用中であるので、印刷データを受信できない。そのため、コマンドの解釈もできない。双方向のやりとりが必要なプロトコルの場合、ホストはプリンタからの応答を待ち続けることになる。
【０００９】
本発明の目的は、上記従来の問題を解決して、ネットワーク接続され、バッファ容量が限られた画像形成装置において、割込印刷中でも印刷要求に対する応答コマンドをホスト側に返せるようにすることである。
【課題を解決するための手段】
【００１０】
上記の課題を解決するために、本発明では、画像形成装置を、ネットワークを介して接続された情報処理装置から印刷データを受信する手段と、受信した通常の印刷データを保持するための第１のバッファと、受信した割込印刷データを保持するための第２のバッファと、割込印刷中にデータの保持が可能な第３のバッファと、受信した印刷データを解析する手段と、割込印刷中に受信され、前記第３のバッファに保持されている印刷データを解析した結果に応じた応答コマンドを前記情報処理装置に送信する手段とを備える構成とした。
また、データを解析する手段を送受信バッファ毎に設ける。さらに、応答コマンドを情報処理装置に送信する前に割込印刷が完了しているかどうか確認する手段と、応答コマンドを返した後すぐに応答用の送受信バッファを解放する手段と、バッファ用のメモリの空きが少なくなった場合でも応答用の送受信バッファを確保するように制御する手段を備える。
また、本発明では、画像形成装置の印刷制御方法を、ネットワークを介して接続された情報処理装置から印刷データを受信する工程と、受信した通常の印刷データを第１のバッファに格納する工程と、第１のバッファに格納した印刷データを基に描画処理を行う工程と、その描画処理中に割込印刷データを受信すると割込印刷用の第２のバッファに格納する工程と、第１のバッファに格納した印刷データに基にした描画処理を中断して、第２のバッファに格納した印刷データを基に描画処理を行う工程と、その描画処理中に印刷データを受信すると応答用の第３のバッファに格納する工程と、第３のバッファに格納した印刷データを解析する工程と、解析した結果に応じた応答コマンドを前記情報処理装置に送信する工程とを備える構成とした。
【発明の効果】
【００１１】
上記のように構成したことにより、バッファ容量が限られた画像形成装置における割込印刷中でも、印刷データを一旦受信して解釈でき、ホスト側に応答コマンドを返すことができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明を実施するための最良の形態について、図１〜図５を参照しながら詳細に説明する。
【００１３】
［第１の実施形態］
本発明の第１の実施形態は、割込印刷中に印刷データを受信すると、応答用の送受信バッファに格納して、印刷データ中のコマンドを解析し、ホストとの間で双方向のやりとりが必要なプロトコルを使用していると判断した場合、応答コマンドをホストに送信する画像形成装置である。
【００１４】
図１は、本発明の第１の実施形態における画像形成装置の構成を示すブロック図である。ここで、図１Ａはハードウェアの構成、図１Ｂは機能ブロックの構成を示す。図２は、割込印刷要求の到来状況を示す図である。図３は、割込印刷中にRHPPにて印刷データを受信したときのタイミングチャートである。図４は、ホストと画像形成装置で双方向にやりとりが必要なプロトコルを使った場合の処理手順を示す流れ図である。図５は、割込印刷中にRHPPにて印刷データを受信したときの処理手順を示す流れ図である。
【００１５】
図１Ａに示すように、画像形成装置の代表としてプリンタを例にして説明するが、コピー機や複合機などでも同様である。このプリンタ11は、操作パネル13と、コントローラ14と、エンジン15とを備えている。なお、これらのハードウェアの構成は基本的に従来の装置と同様であるので、簡単に説明する。
【００１６】
操作パネル13は、ボタンやタッチパネル、機器状態表示のためのインジケータ（ＬＥＤやＬＣＤ等の表示器）、液晶などの表示部、スピーカ等、ユーザとのマンマシンインターフェース部である。
【００１７】
エンジン15は、コントローラ14からの画像データ及び制御信号により、レーザビームを走査して感光体上に静電潜像を形成し、現像し、また給紙部より用紙を給紙し、転写及び定着し、画像を形成する。なお、エンジン15の画像形成方法は、ＬＥＤ方式、インクジェット方式等、どのような方式でもよい。
【００１８】
コントローラ14は、ホスト12からの印刷データに基づいてエンジン15を制御する制御機構の総称であり、バス16と、それぞれがバス16に接続されたホストI/F（インタフェース）17、ROM（Read Only Memory）18、HDD（ハードディスク）19、パネルI/F20、CPU（Central Processing Unit）21、RAM（Random Access Memory）22、NV（Non Volatile）-RAM23、エンジンI/F24、及びオプションRAM25を備えている。
【００１９】
ホストI/F17は、ホスト12からプリンタ11への印刷データ、及びプリンタ11からホスト12への応答信号などのインタフェースである。ROM18には、コントローラ14内のデータの管理や、図示されていない周辺モジュールを制御するためのプログラム、印字に用いるフォントなどが格納されている。HDD19には大容量のデータやファイルが格納される。パネルI/F20は、プリンタ11の状態、モード、フォントの切替えなどを行うための信号のインタフェースである。CPU21は、ROM22に格納されているプログラムに従って、ホスト12からの印刷データを処理する。RAM22は、CPU21が処理を行う時のワークメモリ、ホスト12からの印刷データを一時記憶するバッファ、バッファに記憶された印刷データから変換された画像データを記憶するビットマップメモリ等に使用される。NV-RAM23は、装置の電源をオフにしても保持したいデータを格納するための不揮発性メモリである。エンジンI/F24は、コントローラ14からエンジン15への制御信号、及びエンジン15からコントローラ14へのステータス信号のインタフェースである。オプションRAM25は、RAM22、NV-RAM23にそれぞれ記憶されるデータ以外のデータを記憶する拡張用のメモリである。
【００２０】
図１Ｂにおいて、データ処理部１は、図１ＡのCPU21と、ROM18内のプログラムなどにより、全体の制御と画像形成の制御などを行う手段である。描画部２は、PDL（Page Description Language）で記述された印刷データをビットマップ形式の画像データに変換する処理（描画処理）を行う手段である。描画バッファ３は、送受信バッファ５から読み出された印刷データを一時的に保持するメモリである。データ解釈部４は、送受信バッファ５に保持されているコマンドやデータを解釈する手段である。送受信バッファ５は、印刷データや応答コマンドを一時的に保持するメモリである。通信制御部６は、ネットワークを介してホスト12と通信する手段である。LAN７は、ホスト12と接続するためのネットワークである。印刷制御部８は、エンジン15を制御する手段である。
【００２１】
図１Ｂは、３つの送受信バッファ５と、それに対応する３つのデータ解釈部４を備えていることを示している。ここで、３つの送受信バッファ５は、通常印刷用の送受信バッファ、割込印刷用の送受信バッファ、及び応答用の送受信バッファである。ただし、３つの送受信バッファ５は機能的なものであり、必ずしも３つのハードウェアメモリを意味するものではない。また、割込印刷の優先レベルが複数の場合でも、複数の割込印刷用の送受信バッファ５を１つということにする。送受信用バッファ毎にデータ解釈部を設けたのは、１つのデータ解釈部が印刷データを解釈する場合よりも、設計が単純になるためである。３つのデータ解釈部４も機能的なものであり、１つの再入可能なモジュールを時分割で３つとして動作させるものでもよい。
【００２２】
以下、ホスト12とプリンタ11とで双方向にやりとりをしながら印刷を行うプロトコルとしてRHPPを使い、ホスト12とプリンタ11とで双方向にやりとりをせずに印刷を行うプロトコルとしてdiprintを使う例について説明する。diprintは、ホスト12とプリンタ11とで双方向にやりとりをする必要のないプロトコルである。RHPPは、ホスト12とプリンタ11とで双方向にやりとりをする必要のあるプロトコルである。印刷処理をする際に、ホスト12からの印刷データ中のコマンドを解析して、ページ毎に排紙完了をホストに応答コマンドで通知しながら印刷処理を行う。応答コマンドは、排紙完了の通知以外にも、装置獲得成功や描画完了など様々な種類がある。
【００２３】
プロトコルの区別は、プリンタ11が受信した印刷データにて指定されたポート番号から通信制御部６が判断する。特定のポート番号であれば、RHPPのプロトコルとして扱い、RHPPのコマンドを解釈するデータ解釈部４が、送受信バッファ５に存在する印刷データを解釈する。データ解釈部４は、RHPPで送られてきた印刷データを解釈し、応答コマンドを送受信バッファ５に書き込む。RHPPで送られてきた印刷データには、RHPPのコマンドが含まれるので、データ解釈部４と描画部２とでやりとりをする描画バッファ３には、RHPPのコマンドを抜いた印刷データを格納し、描画部２が解釈できるような印刷データとして渡す。描画部２では、その印刷データをもとに描画処理を行い、印刷制御部８を通してエンジン15に印刷を実行させる。描画部２の前にデータ解釈部４を置くことで、描画に必要ないRHPPのコマンドのデータを、描画部２が解析しなくてすむようになる。つまり、従来通りの動作でよいことになる。データ解釈部４では、応答コマンドの作成と、印刷データからRHPPのコマンドを抜いたデータを描画部２に渡す役割を担う。
【００２４】
割込印刷は、「通常」に対して「優先度高」の１段階までとする。割込印刷中の場合、これ以上割り込めないので、優先度の設定に関係なく、印刷の要求は受け付けない。ただし、RHPPの場合は、ホスト12に応答コマンドを返す必要があるので、応答用の送受信バッファ５に印刷データを格納する。その印刷データをデータ解釈部４が解釈し、ホスト12に返す応答コマンドを、応答用の送受信バッファ５に書き込み、通信制御部６を通してホスト12に応答コマンドを返す。データ解釈部４は、応答コマンドを書き込む前に、割込印刷用の送受信バッファ５をチェックし、割込印刷が終っているかどうか判定する。このとき、まだ印刷中であれば、ビジー状態を通知する応答コマンドを、応答用の送受信バッファ５に書き込む。印刷が終了しているなら、正常にコマンドを受け付けた旨の応答コマンドを、応答用の送受信バッファ５に書き込む。もし、優先度が高いのであれば、そのまま応答用の送受信バッファ５を使い、割込印刷を開始する。優先度が通常であれば、次の通信以降、通常用の送受信バッファ５に切り替えて印刷データを受信する。
【００２５】
なお、特定の１つの送受信バッファ５が、常に通常の印刷に使われるわけではない。他の送受信バッファ５についても同様に、割込印刷用バッファや応答用バッファとして固定されているわけではない。送受信バッファ５は、空いたものから割り当てられていくので、特定の送受信バッファ５が、常に応答用のバッファになるとは限らない。状況に応じて、ある送受信バッファ５を通常用に使い、割込印刷用に他の送受信バッファ５を使い、応答用にさらに他の送受信バッファ５を使うというように、適宜切り替えて使用する。通信制御部６が、それぞれの送受信バッファ５の使用状況を見て、どの送受信バッファ５をどの役割にするかを判断する。１つのメモリを適宜分割して各バッファとして使用する場合でも、通常印刷用のバッファにほとんどを使って、割込印刷用のバッファが不足する場合があることは許されても、応答用のバッファが不足して応答できなくなることは許されないので、応答用のバッファの領域は優先的に確保しておく。このようにして、少ないバッファ用メモリを有効に利用する。
【００２６】
次に、図２を参照しながら、割込印刷中に印刷データがきた場合の処理について説明する。図２Ａに示すように、diprintプロトコルで印刷データが送られてくると、通常用の送受信バッファ５に格納される。描画部２はその印刷データを通常用の送受信バッファ５から読み出し、描画処理する。その描画処理中に、図２Ｂに示すように、RHPPで、優先度の高い印刷データがくると、割込用の送受信バッファ５に格納される。データ解釈部４でコマンドを解釈して、割込印刷であるので、描画バッファ３に印刷データを書き込み、描画部２で描画処理する。その間に、図２Ｃに示すように、RHPPで印刷データがくると、応答用の送受信バッファ５に格納し、データ解釈部４でコマンドを解釈して、応答コマンドを応答用の送受信バッファ５に書き込む。
【００２７】
次に、図３を参照しながら、割込印刷中にRHPPにて印刷データを受信したときの処理手順を説明する。通信制御部６は、（１）で印刷データを受信すると、（２）で送受信バッファ５をチェックする。２つの送受信バッファ５に印刷データが書かれているか否かをチェックし、割込印刷中かどうかを判断する。割込印刷中であれば、（３）で応答用の送受信バッファ５に、印刷データを書き込み、（４）で印刷データを受信したことを、データ解釈部４に通知する。データ解釈部４は、（５）で送受信バッファ５から印刷データを読み込み、（６）で割込印刷中か否かをチェックする。ここで割込印刷が終っていたら、通常の印刷要求または割込印刷要求の処理となり、優先度の設定に従って処理を行う。割込印刷中であれば、データ解釈部４は、（７）で応答コマンドを応答用の送受信バッファ５に書き込む。通信制御部６は、（８）でホストへ通知する。
【００２８】
次に、図４を参照しながら、全体的な処理手順を説明する。RHPPを代表とする、ホスト12とプリンタ11で双方向にやりとりする必要のあるプロトコルを使った場合の例である。ホスト12とプリンタ11での双方向のやりとりが不要なプロトコルの場合は、印刷データをプリンタ11に送信するだけでよいので、割込印刷が発生しない場合は、全て通常用の送受信バッファ５に印刷データを格納する。割込印刷は１つのジョブだけとしているので、割込印刷用の送受信バッファ５には１つのジョブしか格納しない。通常用の送受信バッファ５は、その容量がいっぱいになるまでキューイングできる。また、解析した印刷データは、基本的には保存しておく必要はないので、解析が済んだ分だけすぐに空きができるようになる。応答用の送受信バッファ５に格納された印刷データは、応答コマンドを返した後すぐに消去して応答用の送受信バッファ５を解放して、いつでも次の印刷データを受信できるようにする。すぐに解放することで、少ないバッファ用メモリでも、常に応答することができる。
【００２９】
ステップ１で、印刷データを受信する。ステップ２で、ポート番号からプロトコルを判別する。ステップ３で、送受信バッファ５が３つとも空いているかどうか調べる。３つとも空いていれば、ステップ４で、通常用の送受信バッファ５に印刷データを格納する。１つか２つしか空いていなければ、ステップ５で、割込印刷をするかどうか調べる。割込印刷をしないのであれば、ステップ４で、通常用の送受信バッファ５に印刷データを格納する。割込印刷をするのであれば、ステップ６で、送受信バッファ５が２つ空いているかどうか調べる。２つ空いていれば、ステップ７で、割込印刷用の送受信バッファ５に印刷データを格納する。１つしか空いていなければ、ステップ８で、応答用の送受信バッファ５に印刷データを格納する。ステップス９で、印刷データを解析する。
【００３０】
次に、図５を参照しながら、割込印刷中にRHPPにて印刷データを受信したときの処理手順（図４のステップ６でNoとなったときの処理の詳細）を説明する。ステップ11で、応答用の送受信バッファ５に印刷データを格納する。データ解釈部４による読込みが終ったら、印刷データが残っているかどうかを判断できるように、送受信バッファ５の印刷データを、特定の値（例えば−１）で上書きする。ステップ12で、割込印刷が終っているかどうかを調べる。割込印刷が終っていれば、ステップ13で、通常通りコマンドを受け付けた旨の応答コマンドを、応答用の送受信バッファ５に書き込む。割込印刷が終っていなければ、ステップ14で、ビジー状態である旨の応答コマンドを、応答用の送受信バッファ５に書き込む。ステップ15で、ホスト12に応答コマンドを返す。
【００３１】
上記のように、本発明の第1の実施形態では、画像形成装置を、割込印刷中に印刷データを受信すると、応答用の送受信バッファ５に格納して、印刷データ中のコマンドを解析し、RHPPを使用している場合は、応答コマンドをホスト12に送信する構成としたので、割込印刷中でもコマンドを解釈してホスト12に応答できる。
【００３２】
［第２の実施形態］
図６は、本発明の第２の実施形態における画像形成装置のソフトウェアによる機能ブロックの構成を示す図である。この画像形成装置のハードウェアの構成は第１の実施形態と同じである。
【００３３】
図６に示すように、本実施形態の画像形成装置は、第１の実施形態の画像形成装置にデータ解析部９を付加したものである。データ解析部８は、PJL（Print Job Language）で記述されたコマンドを解析することで機器の情報を取得したり、印刷条件を設定したりする機能を持っている。
【００３４】
図示されていないホストから印刷データがLAN７を通して通信制御部６に入力される。通信制御部６は、受信した印刷データにて指定されたポート番号から、プロトコルを判断する。特定のポート番号であれば、RHPPのプロトコルとして扱い、RHPPのコマンドを解釈するデータ解釈部４が送受信バッファ５に存在するデータを解釈する。
【００３５】
データ解釈部４は、RHPPで送られてきた印刷データを解釈し、応答のコマンドを送受信バッファ５に書き込む。RHPPで送られてきた印刷データにはRHPPのコマンドが含まれているので、データ解釈部４と、データ解析部９、描画部２との間のやりとりをする描画バッファ３にはRHPPのコマンドを抜いたデータを格納し、データ解析部９、描画部２が解釈できるような印刷データとして渡す。
【００３６】
データ解析部９では、その印刷データをもとに印刷条件などを解析する。また、描画部２は、その印刷データをもとに描画を行い、印刷制御部８を通して、図示しないエンジンに印刷を実行させる。
【００３７】
前述したように、RHPPのコマンドを解析するデータ解釈部４も、PJLのコマンドを解析するデータ解析部９も同様な機能を持っている。基幹系システムなどで印刷の信頼性が求められる場合には、RHPPのようにホストとプリンタとで双方向にやりとりをし、状況を確認しながら印刷を行なうと信頼性が確保されやすくなる。一方、通常のオフィスなどでの運用では、PJLのみで十分であるため、わざわざRHPPを使うことはない。
【００３８】
また、データ解釈部４とデータ解析部９とは機能が重複するため、データ解析部９の機能を無効化してデータ解釈部４のみで運用することが考えられる。この場合、重複した機能を省略できるため、無駄が省ける。データ解析部９を無効化する方法としては、データ解析部９がデータを解析した結果を書き込むためのバッファをダミーのバッファとすることで、データ解析部９の処理に大きな変更を加えることなく、データ解析部９を無効化する方法が挙げられる。図７は、この方法を示す流れ図である。
【００３９】
図７に示すように、ステップ21で、解析するためのデータを通信制御部６が受信し、ステップ22で、RHPPが有効かどうか、即ちRHPPの印刷かどうかをデータ解釈部４が判断する。有効と判断された場合、ステップ23で、データ解釈部４は、データ解析部９による解析結果を書き込むためのダミー用の領域を描画バッファ３内に確保する。次に、ステップ24で、データ解釈部４は、データ解析部９による解析結果を書き込むための送受信バッファ５をダミー用の送受信バッファに変更する。
【００４０】
ステップ25で、データ解析部９がデータを解析し、ステップ26で、解析結果をダミー用の送受信バッファに書き込む。ダミー用の送受信バッファは、実際には使われないデータを書き込むためのバッファであるため、書き込まれたデータはホストに送信されない。
【００４１】
一方で、データ解析部９を残したままデータ解釈部４と共存させる運用方法を採ることもできる。この場合、データ解析部９のみのシステムをデータ解釈部４のシステムに置き換えようとした場合には、データ解析部９を残したままにしておくことで、データ解析部９の機能を併用しながら、段階的にRHPPのシステムの開発を行うことができるという利点がある。
【図面の簡単な説明】
【００４２】
【図１】本発明の第１の実施形態における画像形成装置の構成を示すブロック図である。
【図２】本発明の第１の実施形態における画像形成装置の割込印刷要求の到来状況を示す図である。
【図３】本発明の第１の実施形態における画像形成装置の割込印刷中にRHPPにて印刷データを受信したときのタイミングチャートである。
【図４】本発明の第１の実施形態における画像形成装置とホストの間で双方向のやりとりが必要なプロトコルを使った場合の処理の流れ図である。
【図５】本発明の第１の実施形態における画像形成装置の割込印刷中にRHPPにて印刷データを受信したときの処理の流れ図である。
【図６】本発明の第２の実施形態における画像形成装置の機能ブロックの構成を示す図である。
【図７】第２の実施形態におけるデータ解析部を無効化する方法の流れ図である。
【図８】従来の割込印刷の流れを示す図である。
【符号の説明】
【００４３】
１・・・データ処理部、２・・・描画部、３・・・描画バッファ、４・・・データ解釈部、５・・・送受信バッファ、６・・・通信制御部、７・・・LAN、８・・・印刷制御部、９・・・データ解析部。
【図１】
2008221831.tif 000003
【図２】
2008221831.tif 000004
【図３】
2008221831.tif 000005
【図４】
2008221831.tif 000006
【図５】
2008221831.tif 000007
【図６】
2008221831.tif 000008
【図７】
2008221831.tif 000009
【図８】
2008221831.tif 000010