以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。
[実施の形態1]
図1は、本実施の形態に係る画像処理装置1000のハードウェア構成を説明するブロック図である。
この画像処理装置1000は、画像処理装置コントローラ(以下、コントローラ)1600を有し、異なる制御系を司る機器で構成されている。本実施の形態における画像処理装置1000は、具体的には印刷装置を想定している。
CPU1は、書き換え可能なフラッシュ(Flash)メモリ3に記憶された制御プログラムに基づいて制御動作を実行する。このCPU1はまた、ローカルエリアネットワーク(LAN2000)に接続されたホストコンピュータ等の複数の外部装置(不図示)から送られる印刷データやプリンタ制御命令等の各種データの送受信要求を統括的に制御する。尚、LAN2000に接続された外部装置との通信は、所定のネットワーク通信プロトコルを用いて、システムバス4に接続されるネットワークコントローラ(LANC)5を介して行われる。また、CPU1は、システムバス4に接続される各種デバイスとのアクセスを統括的に制御している。この制御は、ROM9に記憶された制御プログラム等、或はディスクコントローラ(DKC)15を介して接続された外部メモリ10に記憶された制御プログラムやリソースデータ(資源情報)等に基づいて十区押される。これにより、受信した印刷データを基にラスタコントローラ12によって画像情報が生成され、その画像情報がマーキングエンジン(プリンタエンジン)16に出力される。
RAM2は、CPU1の主メモリ、ワークエリア等の一時記憶領域として用いられる。フラッシュメモリ3は書き換え可能な不揮発メモリで、ROM9とともに制御プログラムを記憶している。システムバス4は、このコントローラ1600を構成する機器間のデータのやりとりに使用される。
ネットワークコントローラ(LANC)5は、コントローラ1600をLAN2000に接続する。LED6は、このコントローラ1600の動作状態を示す表示部として用いられる。例えば、LED6は、LANC5とLAN2000との電気的な接続状態(LINK)やネットワーク通信モード(10Baseや100Base、全二重、半二重)等の各種動作状態をLED6の点滅パターンや色で示すことができる。外部メモリ10は、制御プログラムや各種データを保持し、DKC15を介してコントローラ1600に接続されている。一般的にはハードディスクドライブやUSBメモリなどが使用されている。ラスタコントローラ12は、受信した印刷データを基に、出力すべき画像情報を生成する。マーキングエンジン16は、ラスタコントローラ12から画像情報を受け取って印刷を行う。
操作パネル(操作部)18は、画像処理装置1000の動作モード等の設定や印刷データの取り消し等の操作を行なうためのボタンや、画像処理装置1000の動作状態を示す液晶パネルやLED等の表示部を配している。尚、操作部18には、液晶パネルに重ね合わせてタッチパネルが設けられているものとする。画像読み取り部19は、操作パネル18、或はローカルエリアネットワーク2000を介して画像情報の読み取りを指示することにより、その読み取った(スキャン)画像情報を画像処理装置1000に入力する。
なお、この図1に示したマーキングエンジン16は、既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式(レーザビーム方式)やインクジェット方式、昇華(熱転写)方式等が挙げられる。
図2は、本実施の形態に係るコントローラ1600のソフトウェア構造を示す階層図である。図において、上方に位置している上位モジュールは、下方に位置している下位モジュールに依存していることを示す。また特に線によって接続したモジュール間には依存関係が存在することを示す。
ネイティブコード部201は、画像処理装置1000のファームウェアを構成する標準部分で、CPU1によって直接実行される(ネイティブ環境で実行される)。このネイティブコード部201は、ファームウェアとして、装置の開発時に単一のロードモジュールに静的にリンクされ、この画像処理装置1000の不揮発性メモリ3に格納されている。このファームウェアは画像処理装置1000の起動時に不揮発性メモリ3からRAM2にロードされ、画像処理装置1000の稼働中はCPU1がRAM2からコードを逐次的に読み出して、そのコードを解釈して処理を実行する。但し、その処理の実行時にダイナミックリンクは行わない。尚、このファームウェアは、ROM9のようにCPU1が直接読み出しアクセス可能な不揮発性メモリに格納され、RAM2に展開せずに直接CPU1がROM9からコードを逐次的に読み出し、それを解釈して実行するようにしてもよい。
データ送受信モジュール202は、入力データストリームとして、クライアントからの処理要求データストリーム350(図3)を受信し、画像処理装置コントローラ1600内で生成された送信用データストリーム358(図3)をクライアントに送信する。このデータ送受信モジュール202は、RTOS(リアルタイムOS)214を介してプロトコルスタック223に依存している。クライアントとの間でのデータの送受信は、物理的にはイーサネット(Ethernet)(登録商標)などのネットワークやUSB,IEEE1394などの各種インターフェースを介して行われる。そし て、それぞれの接続形態に応じて処理要求を行うためのアプリケーションプロトコルが規定されている。また、このデータ送受信モジュール202は、アプリケーションプロトコルのサーバ機能を実装している。サービスのためのアプリケーションプロトコルには、例えばネットワークプロトコルだけでもLPRやSMB,PAP,NetWareなど各種の仕様が存在し、その実現のためには膨大な開発コストと品質評価コストを要する。データ送受信モジュール202は、これら複数のインターフェース毎に、それぞれ各種存在するサービスプロトコルからなるマルチプロトコルをサポートしている。データ送受信モジュール202は、データの送受信のために、画像処理装置1000のRAM2にジョブの待ち行列を構成し、いわゆるスプール機能を実装するように構成してもよい。この場合、データ送受信モジュール202は、他のジョブを実行している最中のようにジョブを直ちに実行できる場合にも、クライアントからのジョブ要求を受け付けて待ち行列に格納しクライアントを解放する。こうして待ち行列に格納されたジョブは、そのジョブが実行可能となった時にスケジューリングアルゴリズムに応じて逐次処理される。
組み込みアプリケーション203は、この画像処理装置1000の中心機能を提供するための組み込みアプリケーションであり、クライアントからの要求に呼応してサービスを提供している。クライアントがLAN2000を介したホスト上のアプリケーション及びドライバソフトの場合は、クライアントは処理要求データストリーム350(図3)を生成し、データ送受信モジュール202を介して組み込みアプリケーション203へ引き渡す。組み込みアプリケーション203は、この処理要求データストリーム350を装置制御指示データストリーム351(図3)と描画データストリーム352(図3)とに分割し、制御API204を介してジョブ制御モジュール205にそれぞれを引き渡す。或は、装置制御指示データストリーム351を解釈し、制御API204によってジョブ制御モジュール205に対して、クライアントから要求された処理を指示し、描画データストリーム352(図3)を引き渡す。
例えば、クライアントが画像処理装置1000の操作パネル18を介した指示であった場合は、組み込みアプリケーション203で、装置制御指示データストリーム351(図3)を生成し、制御API204を介してジョブ制御モジュール205に引き渡す。また、或は、ジョブ制御モジュール205に対して制御API204によってクライアントから要求された指示を行う。この装置の制御に関する記述部は、一般的にはJL(Job Language)と呼称される。JLは、描画データの解釈や展開系の動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート(コレート)の指定、ステイプルや製本などのフィニッシングの指定などを含む。一方、描画データストリームはPDLで記述されており、主にページごとの描画が記述されている。
制御API204は、この画像処理装置1000が提供するサービスにアクセスするためのアプリケーションプログラミング・インターフェースである。この制御API204を構成する主要なインターフェースの一つは以下の2つのインターフェースである。即ち、プリントジョブを実行したり制御するためのインターフェースと、装置制御指示データストリーム351(図3)と描画データストリーム352(図3)のジョブ制御モジュール205への引き渡しのためのインターフェースである。
ジョブ制御モジュール205は、画像処理装置1000が提供する各種の画像処理ジョブを制御する。この画像処理ジョブの一例であるプリントジョブの処理を以下に示す。
ジョブ制御モジュール205は、制御API204を介した指示に従って装置の制御を行う。或は、制御API204を介してジョブ制御モジュール205へ入力された装置制御指示データストリーム351(図3)を解釈することで動作を行う。ジョブ制御モジュール205は、制御API204を介した装置の制御に関する指示、或は装置制御指示データストリーム351の記載内容に応じて、トランスレータ206、レンダラ207、ME制御モジュール208、画像処理モジュール209、データ管理モジュール210を制御する。プリントジョブの場合は、ジョブ制御モジュール205により、描画データストリーム352(図3)がトランスレータ206によりディスプレイリスト355(図3)に変換される。このディスプレイリスト355(図3)は、更にレンダラ207により中間画像データストリーム356(図3)に変換される。そして、この中間画像データストリーム356は、画像処理モジュール209により最終画像データストリーム357(図3)に変換され、この最終画像データストリーム357がME制御モジュール208に送られて印刷されるようにスケジュールされる。
更なる一例として、組み込みアプリケーション203により提供される、画像データの読み取りと送信の動作について説明する。操作パネル18から画像データを読み取って送信するように指示された場合、組み込みアプリケーション203は、制御API204を介してジョブ制御モジュール205に対して、画像データの読み取りと送信指示を行う。この送信指示は、組み込みアプリケーション203が制御API204を介して直接ジョブ制御モジュール205に指示することにより実行される。或いは、組み込みアプリケーション203が装置制御指示データストリーム351を生成し、制御API204を介してジョブ制御モジュール205に引き渡すことにより実行される。ジョブ制御モジュール205は、画像読み取り部19から画像データを入力してRAM2に保持して画像処理モジュール209に引き渡す。これにより生成されたスキャン画像データストリーム360(図3)を、組み込みアプリケーション203に引き渡すようにスケジューリングする。この組み込みアプリケーション203は、この引き渡されたスキャン画像データストリーム360を、操作パネル18から指示された形式に変換して送信用データストリーム359(図3)を生成し、データ送受信モジュール202を介して送信する。或は、操作パネル18から指示された送信先が、内蔵されている外部メモリ10である場合は、組み込みアプリケーション203は、制御API204を介してジョブ制御モジュール205に対して、画像データの読み取りと保存の指示を行う。この指示は、組み込みアプリケーション203が制御API204を介して直接ジョブ制御モジュール205に指示することで実行される。或は、組み込みアプリケーション203が装置制御指示データストリーム351を生成し、制御API204を介してジョブ制御モジュール205に引き渡すことで実行される。ジョブ制御モジュール205は、画像読み取り部19から画像データを入力してRAM2に保持して画像処理モジュール209に引き渡す。そして、この画像処理モジュール209で生成されたスキャン画像データストリーム360(図3)をデータ管理モジュール210を介して外部メモリ10へ格納するようにスケジューリングする。
トランスレータ206は、PDL等の描画データストリーム352を解釈して、レンダリング処理に適した印刷用の中間言語に変換する。このレンダリング処理に適した印刷用中間言語によるプリントデータの記述をディスプレイリスト355(図3)と呼ぶ。トランスレータ206は、各種のPDLの仕様毎に、それぞれ異なる固有の実装を持ち、どのトランスレータもそれぞれのPDLをレンダラ207に固有のディスプレイリスト355へ変換する。
レンダラ207は、ディスプレイリスト355を中間画像データストリーム356(図3)に展開する。このレンダラ207はRTOS214を介してレンダラドライバ225に依存している。
マーキングエンジン(ME)制御モジュール208は、画像処理装置1000において転写紙への画像形成を行うマーキングエンジン16を制御する。このME制御モジュール208は、RTOS214を介してMEドライバ226に依存している。
画像処理モジュール209は、この画像処理装置1000の中間画像データストリーム356などの画像データに対して、ハーフトーニング、トラッピング、濃淡補正、カラーモノクロ変換など様々な画像処理を行う。
データ管理モジュール210は、この画像処理装置1000の中間画像データストリーム356(図3)や、最終画像データストリーム357(図3)などのデータストリームを外部メモリ10へ保存管理する。尚、画像データストリーム以外のデータストリームを保存及び管理可能にしても良い。レイヤI/F211は、この画像処理装置1000内のデータストリームを、インタプリタ環境215との間でやりとりする。このレイヤI/F211は、データストリームに対するフィルタリング処理のレベル付けのために、大きく内部レイヤI/F213と外部レイヤI/F212とに分かれる。
外部レイヤI/F212は、データ送受信モジュール202及び組み込みアプリケーション203から、処理要求データストリーム350、装置制御指示データストリーム351、描画データストリーム352、送信用データストリーム358,359を、インタプリタ環境215へ引き渡す。また、外部レイヤI/F212は、フィルタ221で処理された各データストリームをデータ送受信モジュール202、組み込みアプリケーション203、ジョブ制御モジュール205へ引き渡す。
内部レイヤI/F213は、ジョブ制御モジュール205が生成する、ディスプレイリスト355、中間画像データストリーム356、最終画像データストリーム357、スキャン画像データストリーム360をインタプリタ環境215への引き渡す。ジョブ制御モジュール205は、これらのリストやデータストリームを、トランスレータ206、レンダラ207、ME制御モジュール208、画像処理モジュール209、データ管理モジュール210、画像読み取り部19とやりとりすることで生成する。また、内部レイヤI/F213は、フィルタ221で処理されたジョブをジョブ制御モジュール205へ引き渡す。ここでジョブ制御モジュール205だけでなく、トランスレータ206、レンダラ207、ME制御モジュール208、画像処理モジュール209、データ管理モジュール210、画像読み取り部19とインタプリタ環境215の間でも前述のデータストリームのやりとりを行っても良いことはいうまでもない。
リアルタイムOS214は、画像処理装置1000のネイティブコードファームウェアの実行環境を提供するプラットフォームである。このリアルタイムOS214は、その上で動作するソフトウェアのために、ソフトウェア構築のために利用する基本的なサービスや、装置1000が持つハードウェア資源を抽象化したサービスを提供する。また、装置1000のハードウェアをソフトウェアから利用しやすいインターフェースに抽象化するためのデバイスドライバ構築のフレームワークも提供する。このRTOS(Real-Time OS)214が提供する機能には、CPU1による命令実行コンテクストを抽象化したタスク管理、複数の実行コンテクストを仮想的に同時に動作させる並行処理(concurrent processing)を実現するマルチタスク機構が挙げられる。更にRTOS214が提供する機能として、タスク間でメッセージのやり取りをしたり、同期をとったりするためのタスク間通信(メッセージキューやセマフォなど)、各種のメモリ管理、タイマーやクロック、割り込み管理やDMAの制御等が挙げられる。尚、セマフォとは並行して動作しているプロセス間で同期を取ったり割り込み処理の制御を行なう機構を意味する。
インタプリタ環境215は、各種のインタプリタ環境、ここではJava(登録商標)プラットフォームのランタイム環境に基づき、それに画像処理装置1000に固有のAPI群とフレームワーク群を追加して構成されているソフトウェアプラットフォームである。このソフトウェアプラットフォームは、その上で動作するインタプリタ言語で記述されたプログラムに対して動的なソフトウェア動作環境を提供する。このインタプリタ環境は、ネイティブコードによって実装された部分(ネイティブコード部201に含まれる)と、そのインタプリタ言語で記述されたプログラムとして実装された部分(図2のインタプリタコード部220に含まれる)とを含む。
インタプリタ216は、所定の命令セットによって記述された命令列から逐次的に命令を読み出し、それを解釈して実行する。ここでインタプリタ216は、Java(登録商標)仮想マシンによって構成され、命令セットはJava(登録商標)のバイトコードである。
標準のAPIライブラリとフレームワーク群217は、RTOS214が提供する抽象化された各種コンピューティング資源を更にインタプリタ環境固有のモデルによって抽象化して、このRTOS214上で動作するプログラムのための実行環境を提供する。ここではJava(登録商標)プラットフォームを構成する標準的なクラスライブラリ群と、OSGiのフレームワークによって実現している。Java(登録商標)プラットフォームは、RTOS214相当の抽象化された機能を提供する。例えば仮想マシンによる命令実行コンテクストを抽象化したスレッド管理、複数の実行コンテクストを仮想的に同時に動作させて並行処理を実現するマルチスレッド機構、スレッド間でメッセージのやり取りをしたり、同期を取るためのスレッド間通信、高度に抽象化された各種のメモリ管理(コレクションなど)、タイマやクロック、例外管理、ファイルシステムやネットワークのアクセス、外部入出力装置とのインターフェースなどを提供している。OSGiフレームワークは、単一のJava(登録商標)仮想マシン上に複数のJava(登録商標)アプリケーション(サービス)を動作させる。またアプリケーションのライフサイクルの管理や、アプリケーション間の通信機能などを提供する。このOSGiフレームワーク上には、複数のシステムサービスがプリインストールされている。システムサービスには、
・インタプリタ環境に新たなアプリケーションを追加、更新、削除するためのサービス管理サービスや、
・アプレット(Applet)インターフェースに従って実装されたJava(登録商標)クラスを画像処理装置の操作パネルに表示して操作パネル18から操作可能に動作させるためのAppletビューアサービスや、
・Servletインターフェースに従って実装されたJava(登録商標)クラスをクライアントのブラウザから操作可能なWebアプリケーションとして動作させるためのHTTPサービス等が用意されている。特にAppletインターフェースに従って実装されたJava(登録商標)アプリケーションは、AWTのAPIなどを経由して、間接的に操作パネルドライバ227とインターフェースすることができる。
尚、OSGiとはOpen Service Gateway Initiativeの略で、ここではOSGiの仕様に基いている事を意味する。
ジョブ制御ライブラリ218は、制御API204に依存して、インタプリタ環境上で動作するプログラムのために、画像処理ジョブの実行や制御を可能とするアプリケーションプログラミングインターフェースを提供する。
フィルタフレームワーク219は、組み込みアプリケーション203と通信して、ジョブの実行に際して、インタプリタ環境上に実装したフィルタプログラムからの画像処理装置1000の複数のデータストリームに対する介在を可能とする。
インタプリタコード部220は、インタプリタ216が解釈できるインタプリタ言語によって記述されたソフトウェアとして実装され、インタプリタ環境を構成するAPIライブラリ群やフレームワーク群の一部とインタプリタ環境上で動作するプログラムとを含む。ネイティブコード部201とインタプリタコード部220に跨って位置付けられるソフトウェアは、それぞれの空間の間をインターフェースするためのモジュールをインタプリタ環境が規定する固有のフレームワークとプログラミングモデルに従ってコーディングする必要がある。ここではJava(登録商標) Native Interface(JNI)に従って境界部分のプログラミングを行っている。
フィルタ221は、インタプリタ環境上に実装されたプログラムであり、フィルタフレームワーク219の枠組みに従って実装されているため、組み込みアプリケーション203が処理する処理要求データストリームに対する処理を行うことができる。プロトコルスタック223は、RTOS214のフレームワークに組み込まれ、より下層の外部インターフェースドライバ224が制御する外部インターフェース上にトランスポート層以下のプロトコルを実装する。例えば、ネットワークインターフェースの場合、TCP/IPやUDP/IPなどのプロトコルを実現する。そして、組み込みアプリケーション203に対しては、RTOS214を介してバークレイソケットなどのアプリケーションプログラミングのためのインターフェースを提供する。また例えば、外部インターフェースがUSBの場合にはIEEE1284.4などのプロトコルを実現する。
外部インターフェースドライバ224は、ネットワークインターフェースやIEEE1394、USB,RS232C、セントロニクスなどの各種インターフェースへの接続を提供するハードウェアを駆動する。例えばネットワークの場合、イーサネット(登録商標)などのネットワークに接続するためのネットワークインターフェースハードウェアを駆動して物理層のプロトコルを実現する。
レンダラドライバ225はレンダラ207を駆動する。レンダラ207は、図3のディスプレイリスト355を中間画像データストリーム356に展開するためのハードウェアである。レンダラ207はソフトウェアによって実現してもよいし、展開されるデータストリームは最終画像データストリーム357(図3)でもよい。マーキングエンジン(ME)ドライバ226は、転写紙への画像形成を行うマーキングエンジンを駆動する。操作パネルドライバ227は、この画像処理装置1000が備える操作パネル18の表示部への出力とキーやタッチパネルなどからの入力イベントを処理する。
また、レイヤI/F211はデータストリーム属性管理モジュール228を有する。ユーザは操作パネル18を介して、データストリーム属性管理モジュール228に対して画像処理装置1000におけるデータストリームの処理内容を指示することができる。
具体的には、データストリーム属性管理モジュール228は、処理要求データストリーム350がデータ送受信モジュール202において受信された場合、処理要求データストリーム350に対応するデータストリーム属性の管理を開始する。ネイティブ環境に存在する各モジュールは、必要に応じてデータストリーム属性管理モジュール228に問い合わせを行い、データストリームに対する処理内容を決定する。ここでネイティブ環境のモジュールとしては、データ送受信モジュール202、組み込みアプリケーション203、ジョブ制御モジュール205が挙げられる。また、更には、トランスレータ206、レンダラ207、ME制御モジュール208、画像処理モジュール209、データ管理モジュール210が挙げられる。また、上記各モジュールは、特定の情報が抽出された場合に、データストリーム属性管理モジュール228に通知を行う。この通知により、データストリーム属性管理モジュール228は、データストリーム属性を更新する。データストリーム属性管理モジュール228は、処理要求データストリーム350に対する処理が全て終了した旨の通知をジョブ制御モジュール205から受けることにより、処理要求データストリーム350に対するデータストリーム属性の管理を終了する。
或いは、スキャン画像データストリーム360がジョブ制御モジュール205において生成された場合、データストリーム属性管理モジュール228は、スキャン画像データストリーム360に対するデータストリーム属性の管理を開始する。そして、前述と同様にデータストリーム属性が管理される。データストリーム属性管理モジュール228は、スキャン画像データストリーム360に対する処理が全て終了した旨の通知をジョブ制御モジュール205から受けると、スキャン画像データストリーム360に対するデータストリーム属性の管理を終える。
上述したように、データストリーム属性管理モジュール228は、データ送受信モジュール202が処理要求データストリーム350を受信すると、そのデータストリーム属性の管理を開始する。ここで、データストリーム属性管理モジュール228は、インタプリタ環境に存在する各モジュールに対してそのデータストリーム属性を、制御APIを介して公開する。こうして前述と同様のデータストリーム属性に対する処理(データストリーム属性の管理開始。各モジュールからのデータストリーム管理モジュールへの問い合わせ。各モジュールからのデータストリーム管理モジュールへの通知。データストリーム管理モジュールによるデータストリーム属性の更新。データストリーム属性の管理終了処理)が可能となる。またデータストリーム属性により、インタプリタ環境のモジュールに対しては引き渡しそのものを行わないといった動作も実行可能となる。
図3は、本実施形態に係るコントローラ1600のソフトウェアモジュール間の基本的なデータの流れとそれぞれのモジュールにおいて存在するデータストリームを示す図である。図2に示すモジュールと共通するモジュールには同一の符号をつけて説明を省略する。
データ送受信モジュール202は、クライアントから受信した、処理要求データストリーム350を、フィルタ221を介さない場合に、経路301を介して組み込みアプリケーション203に流す。この経路301は、例えばRTOS214が提供するメッセージキュー等のタスク間通信機能によって実現される。その他のデータの受け渡しも同様である。尚、処理要求データストリーム350は、装置制御指示データストリーム351と描画データストリーム352からなる。
ここでクライアントが、LAN2000を介したホスト上のアプリケーション及びドライバソフトの場合、クライアントは処理要求データストリーム350を生成する。そして、その処理要求データストリーム350を、データ送受信モジュール202を介して組み込みアプリケーション203へ引き渡す。組み込みアプリケーション203は、処理要求データストリーム350を装置制御指示データストリーム351と描画データストリーム352とに分割し、制御API204を介してジョブ制御モジュール205にそれぞれを引き渡す。或は、装置制御指示データストリーム351を解釈し、制御API204によってジョブ制御モジュール205に対して、クライアントから要求された処理を指示し、描画データストリーム352を引き渡す。
一方、クライアントが画像処理装置の操作パネル18を介した指示の場合は、組み込みアプリケーション203で装置制御指示データストリーム351を生成し、制御API204を介してジョブ制御モジュール205に引き渡す。或はジョブ制御モジュール205に対して制御API204によってクライアントから要求された指示を行う。装置の制御に関する記述部は、一般的にはJL(Job Language)と呼ばれる。JLには、描画データの解釈及び展開に関する動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート(コレート)の指定、ステイプルや製本などのフィニッシングの指定などが含まれる。一方、描画データストリームはPDLによって記述されており、主にページ毎の描画が記述されている。
ジョブ制御モジュール205は、制御API204を介した指示に従って装置1000の制御を行う。或は、制御API204を介してジョブ制御モジュール205へ入力された装置制御指示データストリーム351を解釈して動作を行う。ジョブ制御モジュール205は、制御API204を介した装置1000の制御に関する指示、或は装置制御指示データストリーム351の記載内容に応じて、制御線390を介して、トランスレータ206、レンダラ207、ME制御モジュール208、画像処理モジュール209及びデータ管理モジュール210を制御する。プリントジョブの場合は、ジョブ制御モジュール205は次のようにスケジュールする。即ち、描画データストリーム352をトランスレータ206によりディスプレイリスト355に変換させ、ディスプレイリスト355をレンダラ207により中間画像データストリーム356に変換させる。そして、中間画像データストリーム356を画像処理モジュール209により最終画像データストリーム357に変換し、最終画像データストリーム357がME制御モジュール208に流れて印刷するようにする。
更なる一例として、組み込みアプリケーション203により提供される画像データの読み取りと送信の際の動作を示す。操作パネル18から画像データの読み取り及び送信指示が行われた場合、組み込みアプリケーション203は、制御API204を介してジョブ制御モジュール205に対して、画像データの読み取りと送信の指示を行う。この指示は組み込みアプリケーション203が制御API204を介して、直接ジョブ制御モジュール205に伝えられ、実行される。或は、この指示は、組み込みアプリケーション203が装置制御指示データストリーム351を生成し、制御API204を介してジョブ制御モジュール205に引き渡すことで実行される。ジョブ制御モジュール205は、画像読み取り部19で読み取られた画像データを入力してRAM2上に保持して画像処理モジュール209に引き渡す。こうして画像処理モジュール209で生成されたスキャン画像データストリーム360を組み込みアプリケーション203へ引き渡すようにスケジューリングする。組み込みアプリケーション203は、その引き渡されたスキャン画像データストリーム360を操作パネル18から指示された形式に変換して送信用データストリーム359を生成する。そして、この送信用データストリーム359を、データ送受信モジュール202を介して送信用データストリーム359として送信する。或は、操作パネル18から指示された送信先が、内蔵されている外部メモリ10の場合は、組み込みアプリケーション203は、制御API204を介してジョブ制御モジュール205に対して、画像データの読み取りと保存指示を行う。この指示は、組み込みアプリケーション203が制御API204を介して直接ジョブ制御モジュール205に渡され、実行される。或は、組み込みアプリケーション203がこの指示に基づく装置制御指示データストリーム351を生成し、制御API204を介してジョブ制御モジュール205に引き渡すことで実行される。ジョブ制御モジュール205は、390を介して、画像読み取り部19から画像データを入力してRAM2上に保持し、画像処理モジュール209に引き渡す。こうして生成されたスキャン画像データストリーム360をデータ管理モジュール210を介して外部メモリ10へ格納するようにスケジューリングする。
以上の処理は全てネイティブコード部分201に実装されている。
図4は、本実施の形態に係るコントローラ1600のソフトウェアモジュール間の基本的なデータの流れと、フィルタ処理時のデータの流れを説明する図である。各モジュールにおけるデータストリームは図3と同様であり、前述の図面と共通する部分は同じ記号で示している。
データ送受信モジュール202は、データストリームに対してフィルタ処理を施す場合には、処理されたデータストリームを、経路306を介して外部レイヤ212に流す。この経路306は、例えばRTOS214が提供するメッセージキューなどのタスク間の通信機能によって引き渡されるが、その他のデータの受け渡しでも良い。レイヤI/F211の中の外部レイヤI/F212は、各種データストリームをインタプリタ環境215へ引き渡す。データとストリームとしては、例えば、画像処理装置1000の外部からLAN2000等を介して受信するデータストリームである処理要求データストリーム350、この処理要求データストリーム350を画像処理装置1000内で分割して得られた装置制御指示データストリーム351と描画データストリーム352、組み込みアプリケーションにおいて変換・生成される送信用データストリーム359、データ送受信モジュール202から最終的に送信処理が行われる送信用データストリーム358が挙げられる。尚、これらのデータストリームは、データ管理モジュール210により外部メモリ10から取り出されたものでもよい。
外部レイヤI/F212は、その受け取ったデータストリームを経路307を介してフィルタフレームワーク219に流す。フィルタフレームワーク219のランタイムモジュールは、インタプリタ環境上215に実装されたフィルタプログラム群221を管理している。フィルタフレームワーク219は、そのデータストリームを、経路308を介してフィルタ221に流す。この経路308では、例えばインタプリタ環境215が提供するスレッド間の通信機能によって引き渡される。インタプリタ環境215内のデータのやりとりに関しても以下同様である。ここでフィルタ221が複数配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境215が提供するスレッド間の通信機能によって引き渡される。
尚、ランタイムモジュールとはプログラムを実行する際に必要となるソフトウェアモジュールを意味する。
フィルタ221は、入力として受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ221が出力したデータストリームは、経路309を介してフィルタフレームワーク219に流れる。フィルタフレームワーク219は、フィルタ221から受け取ったデータストリームを経路310を介して外部レイヤI/F212に引き渡す。これにより外部レイヤI/F212は、そのデータストリームを経路311を介して組み込みアプリケーション203に流す。また或は、外部レイヤI/F212が、経路370を介してデータ送受信モジュール202にデータストリームを流し、そのデータストリームを、前述のように経路301を介して組み込みアプリケーション203に流す構成をとってもよい。
制御パス312,372は、フィルタフレームワーク219の状態に応じて、データ送受信モジュール202から組み込みアプリケーション203に至るデータストリームを制御するためのパスである。フィルタフレームワーク219が管理するフィルタ221が有効な状態で配置されている場合は、前述の経路306,307が有効となり、フィルタ221による前処理が施される。一方、フィルタフレームワーク219が有効なフィルタ221を配置していない場合には、経路301が有効となり、データストリームは直接、データ送受信ストリーム202から組み込みアプリケーション203に流れる。この場合、フィルタフレームワーク219が介在することによるオーバヘッドが避けられるため、フィルタ221によるカスタマイズを全く行わない標準状態の画像処理装置1000のデータ処理性能を発揮できる。
組み込みアプリケーション203がデータストリームに対してフィルタ処理を施す場合には、データストリームは経路314を介して外部レイヤ212に流れる。この経路314は例えばRTOS214が提供するメッセージキューなどのタスク間通信機能によって引き渡されるが、その他のデータの受け渡しも同様である。外部レイヤ212は、前述したように、レイヤI/F211の中でも特に、基本的には画像処理装置1000の外部からLAN2000等を介して受信するデータストリームである処理要求データストリーム350、処理要求データストリーム350が画像処理装置1000内で分割された装置制御指示データストリーム351と描画データストリーム352、組み込みアプリケーションにおいて変換、生成される送信用データストリーム359、データ送受信モジュール202から最終的に送信処理が行われる送信用データストリーム358をインタプリタ環境215へ引き渡す。これらのデータストリームはデータ管理モジュール210により外部メモリ10から取り出されたものでもよい。外部レイヤ212は、受け取ったデータストリームを経路307を介してフィルタフレームワーク219に流す。フィルタフレームワーク219のランタイムモジュールは、インタプリタ環境215に実装されたフィルタ221を管理している。フィルタフレームワーク219は、受け取ったデータストリームを経路308を介してフィルタ221に流す。この経路308は、例えばインタプリタ環境215が提供するスレッド間通信機能によって実現される。インタプリタ環境215のデータのやりとりに関しても以下同様である。尚、ここでフィルタ221が複数配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境215が提供するスレッド間通信機能によって引き渡される。
フィルタ221は、受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ221が出力したデータストリームは、経路309よってフィルタフレームワーク219に流れる。フィルタフレームワーク219はフィルタ221から受け取ったデータストリームを経路310を介して外部レイヤ212に引き渡し、外部レイヤ212は、経路315を介して、そのデータストリームをジョブ制御モジュール205に流す。尚、ここで外部レイヤ212が、経路371を介して、そのデータストリームを組み込みアプリケーション203に流し、前述のように経路313を介してジョブ制御モジュール205に流す構成をとってもよい。
制御パス316,372は、フィルタフレームワーク219の状態に応じて組み込みアプリケーション203からジョブ制御モジュール204に至るデータストリームを制御するためのパスである。フィルタフレームワーク219が管理するフィルタ221が有効な状態で配置されている場合は、経路314,307が有効となりフィルタ221による前処理が施される。一方、フィルタフレームワーク219が有効なフィルタ221を配置していない場合には、経路313が有効となり、データストリームは直接ジョブ制御モジュール205に流れる。この場合、フィルタフレームワーク219が介在することによりオーバヘッドを避けられるため、フィルタ221によるカスタマイズを全く行わない標準状態の画像処理装置1000でのデータ処理性能を発揮できる。
次に、ジョブ制御モジュール205が、データストリームに対してフィルタ処理を施す場合を説明する。この場合、データストリームは、経路318を介して、内部レイヤI/F213に流れる。経路318は、例えばRTOS208が提供するメッセージキューなどのタスク間の通信機能によって引き渡される。その他のデータの受け渡しも同様である。内部レイヤI/F213は、レイヤI/F211の中でも特に、画像処理装置1600で生成されるディスプレイリストやデータストリームをインタプリタ環境215へ引き渡す。内部レイヤI/F211によって引き渡されるデータとしては、トランスレータ206が描画データストリーム352を処理することで生成するディスプレイリスト355、レンダラ207がディスプレイリスト355を処理することで生成する中間画像データストリーム、画像処理モジュール209が中間画像データストリーム356を処理することで生成する最終画像データストリーム357、画像読み取り部19から読み込まれたスキャン画像データストリーム360などが挙げられる。尚、これらのデータストリームは、データ管理モジュール210により外部メモリ10から取り出されたものでもよい。内部レイヤI/F213は、経路318を介して受け取ったデータストリームを、フィルタフレームワーク219に流す。フィルタフレームワーク219のランタイムモジュールはインタプリタ環境215に実装されたフィルタ221を管理している。このインタプリタコード部220におけるフィルタ処理は前述の処理と同じであるため、その説明を省略する。
フィルタフレームワーク219は、フィルタ221から受け取ったデータストリームを経路310を介して内部レイヤI/F213に引き渡す。内部レイヤI/F213は、そのデータストリームを経路319を介してジョブ制御モジュール205に流す。尚、内部レイヤI/F213が直接、トランスレータ206、レンダラ207、画像処理モジュール209、ME制御モジュール208、データ管理モジュール210へ引き渡す構成をとってもよい。
制御パス320,372は、フィルタフレームワーク219の状態に応じてデータストリームを制御するためのパスである。フィルタフレームワーク219が管理するフィルタ221が有効な状態で配置されている場合は、経路318,307が有効となり、フィルタ221による前処理が施される。一方、フィルタフレームワーク219が有効なフィルタ221を配置していない場合には経路317が有効となり、データストリームは直接ジョブ制御モジュール205がスケジューリングした次のモジュールに流れる。この場合、フィルタフレームワーク219が介在することによるオーバヘッドを避けられるため、フィルタ221によるカスタマイズを全く行わない標準状態の画像処理装置のデータ処理性能を発揮できる。
上記の構成において、本実施形態の画像処理装置にけるネイティブ環境にはデータストリーム属性管理モジュール228が存在する。データストリーム属性管理モジュール228は、図17に示されるような処理を実行する。
まず、ステップS21において、処理要求データストリーム350がデータ送受信モジュールから入力されると、データストリーム属性管理モジュール228は受信した処理要求データストリーム350の属性の管理を開始する。次に、ステップS22において、ステップS21で入力された処理要求データストリーム350を解析し、装置制御指示データストリーム351から当該処理要求データストリームのジョブ種類やPDL種別を判定する。これは、図10で後述するように、処理要求データストリーム801に含まれる装置制御指示データストリーム351に記述された「ジョブ種類」や「使用PDL」に基づいてなされる。
一方、本実施形態のフィルタ221には、複数のフィルタが登録されており、図7により後述するように処理要求データストリームや所望の中間データストリームに対して適用すべきフィルタ、或はフィルタの組み合わせが設定される。一方、図18により後述するように、各フィルタ或はフィルタの組み合わせに、適用条件が設定される。図18の例では、描画データストリームを対象としたフィルタ(或はフィルタの組み合わせ)について、フィルタを適用すべき条件としてPDL種別やジョブ種類を設定可能な様子が示されている。即ち、本実施形態では、各中間データに対して適用すべきフィルタ(或はフィルタの組み合わせ)が登録されると共に、実際にそのフィルタ処理を適用するか否かを判定するためのPDL種別やジョブ種類等が登録される。
従って、ステップS23ではチェック対象のフィルタ(或はフィルタの組み合わせ)を選択する。そしてステップS24において、入力した処理要求データストリームに記述されているPDL種別やジョブ種類と、登録されているフィルタ(或はフィルタの組み合わせ)に設定されているPDL種別やジョブ種類とを比較する。比較の結果、両者が一致した場合は、ステップS25において当該フィルタが、対象となる中間データストリームへ適用されるように、組み込みアプリケーション203或はジョブ制御モジュール205を設定する。一方、ステップS24における比較の結果、両者が一致しない場合は、ステップS26へ進み、対象となる中間データストリームの転送を禁止するよう、組み込みアプリケーション203或はジョブ制御モジュール205を設定する。以上のステップS23〜S26の処理を登録されているフィルタについて行なう(ステップS27)。
尚、上記処理では、データストリーム属性管理モジュール228は、処理要求データストリームを解析してフィルタの適用条件との対応を調べたが、これに限られるものではない。中間データストリーム(例えば、装置制御指示データストリーム351)を入力し、このデータストリームを解析することにより適用条件との対応をチェックするようにしてもよい。このようにすれば、例えば、装置制御指示データストリーム351を用いて描画データストリーム352にフィルタ機能を適用するか否かを判断する構成となる。
以上のような設定が組み込みアプリケーション203やジョブ制御モジュール205になされると、組み込みアプリケーション203やジョブ制御モジュール205は次のように動作する。即ち、生成されたた中間データストリーム(描画データストリーム352やディスプレイリスト355等)のうちフィルタ処理を適用すると設定された中間データストリームのみをレイヤI/F211に送るように動作する。このような制御により、中間データストリームの不要なフィルタ処理が禁止され、処理効率が向上する。
図5は、本実施の形態のインタプリタ環境220に構築されるフィルタフレームワーク219のクラスを説明する図である。
フィルタ管理(FilterManager)クラス401は、フィルタフレームワーク219のランタイム環境を実現するオブジェクトのクラスである。このフィルタ管理クラス401は一つのコネクタ(Connector)クラス405のオブジェクトをコンポジション(composition)として持つ。また複数(n個)のフィルタ(Filter)抽象クラス402のオブジェクトへの参照と、複数{(n−1)個}のパイプ(Pipe)クラス406のオブジェクトへの参照とからなる順序付けられたリストを持つ。またフィルタフレームワーク219のランタイムに、インストールされた複数のフィルタクラス402の具体クラスを管理するためのinstalledFilter属性410を備えている。
フィルタ抽象クラス402は、各種のフィルタクラスを抽象化する抽象クラスである。このフィルタ抽象クラス402は、フィルタ名称を示す「name」属性などを備える。また、入力(input)属性として、入力ストリーム(InputStream)抽象クラス403を継承したクラスのオブジェクトへの参照を有している。また出力(output)属性として、出力ストリーム(OutputStream)抽象クラス404を継承したクラスのオブジェクトへの参照を有している。フィルタ抽象クラス402の具体クラスは、Runnableインターフェース411を実装し「run」メソッドを有している。フィルタ管理クラス401のオブジェクトは、管理している各種のフィルタ抽象クラス402のインスタンスを生成してデータストリームのフィルタ処理のために配置する。この時、配置される各フィルタオブジェクトに対応してスレッドを生成し、並行して動作するスレッドの実行コンテクストでフィルタオブジェクトのrunメソッドを実行する。即ち、コンストラクタのパラメータにフィルタオブジェクトを渡してJava.lang.Threadオブジェクトを生成し、startする。このようにして個々のフィルタオブジェクトは自律的に動作する。
入力ストリーム抽象クラス403は、データストリームの入力元の抽象クラスで、呼び出しの度に、逐次的にデータを読み出すことができるreadメソッドを備える。
出力ストリーム抽象クラス404は、データストリームの出力先の抽象クラスで、呼び出しの度に、逐次的にデータを書き込むことのできるwriteメソッドを備える。
コネクタクラス405は、インタプリタ環境のオブジェクトとネイティブコードとの間でデータストリームを交換するための接点を表現したオブジェクトのクラスである。コネクタクラス405は、入力ストリーム抽象クラス403を継承した具体クラスであるConnectorInputStreamクラス412のオブジェクトをコンポジションとして持つ。そして、コネクタクラス405は、そのreadメソッドによって、ネイティブコード201のデータ送受信モジュール202から流れたデータストリーム306を逐次的に読み出すことができる。また、コネクタクラス405は、出力ストリーム(OutputStream)抽象クラス404を継承したConnectorOutputStreamクラス413のオブジェクトもコンポジションとして持つ。そして、コネクタクラス405は、そのwriteメソッドによって逐次的に書き込んだデータストリームは、ネイティブコード201のジョブ制御モジュール205へデータストリームとして流れる。
パイプ(Pipe)クラス405は、データストリームに対して複数のフィルタリング処理を施す際にフィルタクラス402の一連のオブジェクト間を連結するために用いるオブジェクトのクラスである。このパイプクラス405は、出力ストリーム抽象クラス404を継承したPipedOutputStreamクラス414と、入力ストリーム抽象クラス403を継承したPipedInputStreamクラス415のそれぞれのオブジェクトをコンポジションとして持つ。パイプオブジェクトのPipedOutputStreamオブジェクト414とPipedInputStreamオブジェクト415とは接続されていて、スレッド間通信を実現している。即ち、フィルタオブジェクトは、パイプオブジェクトが持つPipedOutputStreamオブジェクトへwriteメソッドによって逐次的にデータストリームを書き込む。すると、別のフィルタオブジェクトは、そのパイプオブジェクトが持つPipedInputStreamオブジェクトから、readメソッドによって、この書き込まれたデータストリームを逐次的に読み出すことができる。
図6は、インタプリタ環境215に構築されるフィルタフレームワーク219が管理するオブジェクトのインスタンス図である。図6(A)は、1つのフィルタが有効な状態のときの、フィルタフレームワーク219のランタイムが管理しているオブジェクト間の関係を示している。
コネクタ(Connector)オブジェクト501は、コネクタクラス405のオブジェクトである。フィルタオブジェクト502は、フィルタ抽象クラス402を具体化した具体クラスのオブジェクトである。フィルタオブジェクト502の入力属性には、コネクタオブジェクト501が持つConnectorInputSteamオブジェクトの参照が保持されている。また出力属性にも、コネクタオブジェクト501が有するConnectorOutputStreamオブジェクトの属性が保持されている。フィルタオブジェクト502は、「input」の指すConnectorInputStreamオブジェクトからreadしたデータストリームに対してフィルタ処理を施す。こうしてフィルタ処理を施したデータストリームを、「output」の指すConnectorOutputStreamオブジェクトへwriteする。
以上のようにして、プリントデータストリームのオブジェクト間での引き渡し(図の太い矢印)が実現される。
図6(B)は、2つのフィルタが有効な状態のときの、フィルタフレームワーク219のランタイムが管理しているオブジェクト間の関係を示している。
フィルタ1オブジェクト503は、フィルタ抽象クラス402を具体化した具体クラスのオブジェクトである。フィルタ1オブジェクト503の入力属性には、コネクタオブジェクト501が持つConnectorInputStreamオブジェクトの参照が保持されている。フィルタ1オブジェクト503は、inputの指すConnectorInputStreamオブジェクトからreadしたデータストリームに対してフィルタ処理を施す。フィルタ1オブジェクト503の出力属性には、パイプオブジェクト504が持つPipedOutputStreamオブジェクトの参照が保持されている。フィルタ1オブジェクト503はフィルタ処理を施したデータストリームをoutputの指すPipedOutputStreamオブジェクトへwriteする。
パイプオブジェクト504は、パイプクラス405のオブジェクトである。このパイプオブジェクト504は、PipedOutputStreamオブジェクトとPipedInputStreamオブジェクトとを接続された状態で持つ。パイプオブジェク504が持つPipedOutputStreamオブジェクトのwriteメソッドの呼び出しによってデータストリームはそのPipedOutputStreamオブジェクトへ引き渡される。そして、パイプオブジェクト504が持つPipeInputStreamオブジェクトのreadメソッドの呼び出しによって、PipeInputStreamオブジェクトからデータストリームとして読み出すことができる。
フィルタ2オブジェクト505は、フィルタ抽象クラス402を具体化した具体クラスのオブジェクトである。フィルタ2オブジェクト505の入力属性にはパイプオブジェクト504が持つPipedInputStreamの参照が保持されており、inputの指すパイプオブジェクト504からreadしたデータストリームに対してフィルタ処理を施す。また、このフィルタ2オブジェクト505の出力属性にはコネクタオブジェクト501が持つConnectorOutputStreamの参照が保持されている。フィルタ処理が施されたデータストリームは、outputの指すConnectorオブジェクト501が持つConnectorOutputStreamへwriteされる。
以上のようにして、プリントデータストリームのオブジェクト間での引き渡し(図の太い矢印)が実現される。また、同様にして間にパイプオブジェクト504を挟みこみながら、より多くのフィルタオブジェクトをデータストリーム処理のために配置することもできる。
図7(A)〜(C)は、本実施の形態に係るフィルタフレームワーク219を操作するためのユーザインターフェース例を説明する図である。このフィルタフレームワークを操作するためのユーザインターフェースは、標準ライブラリとフレームワーク217(図1)に含まれるHTTPサービスによってウエブ(Web)アプリケーション(Servlet)として実装されている。このユーザインターフェースは、クライアントで動作するWebブラウザから操作される。或は、Applet型サービスとして実装して、画像処理装置1000の操作パネル19から操作するように構成してもよい。
図7(A)は、この実施の形態の画像処理装置1000のフィルタフレームワーク219に新しいフィルタ221をインストールして追加するためのユーザインターフェースを示している。このフィルタインストール画面601は、ファイル名入力フィールド602、参照ボタン603及びインストールボタン604を備えている。
ユーザは、クライアントコンピュータのファイルシステムに予め格納されているインストールしたいフィルタクラス402のクラスファイルのファイルパスを、ファイル名入力フィールド602に入力する。
ユーザが、参照ボタン603をクリックすると、クライアントコンピュータのWebブラウザが提供するファイル選択ダイアログがオープンされる。ユーザは、このファイル選択ダイアログによりクライアントコンピュータのファイルシステム内をブラウズして、インストールしたいフィルタクラス402のクラスファイルを選択できる。このファイル選択ダイアログによってユーザが選択したファイルのファイルパスは、自動的にファイル名入力フィールド602に入力される。
次にユーザによるインストールボタン604のクリックが検出されると、指定されたフィルタが新規フィルタインストールのためのWebアプリケーションに送信される。即ち、クライアントコンピュータのWebブラウザによって、ファイル名入力フィールド602に入力されたファイルパスのクラスファイルが、この画像処理装置1000で待機している新規フィルタインストールのためのWebアプリケーションに送信される。こうしてクラスファイルを受信したWebアプリケーションは、この画像処理装置1000の不揮発性メモリ3に、その受信したクラスファイルを格納する。また、そのクラスファイルをインタプリタ環境215に動的にロードしてオブジェクトインスタンスを生成する。そして、その生成したフィルタオブジェクトを、フィルタフレームワークランタイムが管理する有効フィルタ列のリストの最下流に配置する。尚、このとき、既に有効なフィルタオブジェクトがフィルタ列に存在すれば、新規のフィルタオブジェクトを連結するために新たなパイプオブジェクトが生成される。
このようなユーザインターフェースをWebアプリケーションとして実装している場合には、フィルタの実装クラスの装置1000へのアップロードは、RFCによって定められたHTMLフォームに基づくファイルアップロードの仕様を利用している。従って、この場合、ファイル名入力フィールド602と参照ボタン603はクライアントコンピュータのWebブラウザによって表示されており、インストールボタン604はフォームのsubmitに対応している。
また、このユーザインターフェースをApplet型のサービスとして実装する場合には、この画面601は、画像処理装置1000の操作パネル18の表示部に表示される。ファイル名入力フィールド602で指定されるファイルは、画像処理装置1000がリムーバブル記憶メディアを備える場合は、そのリムーバブル記憶メディア中のファイルパスを指定しても良い。或は、ネットワーク経由で画像処理装置からHTTPやFTP等のファイル転送プロトコルによって読み出しアクセス可能な共有ファイルを、URLなどによって指定してもよい。
図7(B)は、本実施の形態に係る画像処理装置1000のフィルタフレームワーク219にインストールされているフィルタを配置するためのユーザインターフェースを説明する図である。
このフィルタ配置画面605において、表606は、フィルタフレームワーク219のランタイムにインストールされているフィルタ群を一覧表示している。この表606の各行は、インストールされているフィルタのそれぞれに対応している。また、この表606の「選択」列にはチェックボックスが並んでおり、ここでチェックされた行のフィルタが後述する操作の対象として選択される。表606の「順序」列には、そのフィルタが無効状態にある場合には「無効」が表示される。また有効状態にある場合には、そのデータストリーム処理の上流から下流に向かって昇順に付された番号が表示される。そして表606の「名称」列には、そのフィルタオブジェクトのname属性に記述されたフィルタ名称が表示される。
607〜611は、選択されたフィルタに対する操作を指示するためのボタンであり、表606の選択列でチェックされた行のフィルタを対象とする操作を指示する。ユーザが、詳細表示ボタン607をクリックすると、表606で選択されたフィルタに関する詳細情報が表示される。この詳細情報としては、フィルタの名称やバージョン、説明、クラス名、インストール元のクラスファイル名(ファイルパスやURL)、インストールされた日時などがある。
上へボタン608がクリックされると、選択されたフィルタのフィルタ列内における順序をデータストリーム処理の上流方向に一段階だけアップする。一方、下へボタン609がクリックされると、選択されたフィルタのフィルタ列内における順序が、データストリーム処理の下流方向に一段階だけダウンさせる。有効/無効のトグルボタン610がクリックされると、選択されたフィルタが有効状態にある場合は無効状態に変更され、無効状態にある場合には有効状態に変更される。無効状態にされたフィルタオブジェクトは削除されるが、フィルタクラス402はインストールされた状態で残って、フィルタフレームワークランタイムの管理下に留まる。アンインストールボタン611がクリックされると、選択されたフィルタのクラスファイルを画像処理装置1000のインタプリタ環境から削除する。決定ボタン621がクリックされると、当該設定画面605によって設定されたフィルタ配置が決定される。
図7(C)は、フィルタがデータストリームを対象としたものかを選択するユーザインターフェース例を示す図である。
フィルタインストール画面601やフィルタ配置画面605を表示する前段階で、この対象データストリームの選択画面612を表示してユーザに選択させることにより、ユーザがフィルタ処理に関するインストールや設定を望むデータストリームを決定できる。
リスト613は、画像処理装置1000内に存在するデータストリームをリスト形式で選択するためのユーザインターフェースである。フィールド614は、リスト613から選択されたデータストリームを表示する。決定ボタン615は、フィールド614で指定されているデータストリームに対するフィルタのインストールと、管理を行うように決定するためのボタンである。このボタン615が押下されると、該当するデータストリームのフィルタインストール画面601やフィルタ配置画面605が表示される。
尚、フィルタの処理対象となるデータストリームを選択する方法は上記に限られるものではない。例えば、フィルタ抽象クラス402にフィルタ属性を設け、フィルタのインストールやフィルタの管理時にフィルタ属性を参照することにより、フィルタ対象データストリームを特定するようにしても良い。以上のようなユーザインターフェースにより、入力データストリーム(処理要求データストリーム)や所望の中間データストリームに対して1つ又は複数のフィルタを配置することができる。又、このようにして配置されたフィルタ(或はフィルタの組み合わせ)は、図4に示されるようにレイヤI/F211を介して中間データストリームのデータパス中に配置されたことになる。
又、図17により上述したように、本実施形態では、中間データストリームに対して配置されたフィルタ(或はフィルタの組み合わせ)に関して、適用すべき「PDL種別」や「ジョブ種類」を設定できる。例えば、図7の(B)に示される適用条件ボタン620が押下されると、図18に示すユーザインターフェースが提示される。図18では、対象データストリームが「描画データストリーム」となっており、図7(C)の対象データストリームの選択において「描画データストリーム」が選択され、図7(B)において適用条件ボタン620が押下された場合の表示例が示されている。図18において、PDL種別設定リストボックス1501やジョブ種類設定リストボックス1502において、当該フィルタ(或はフィルタの組み合わせ)を適用すべきPDL種別やジョブ種類を設定する。そして、決定ボタン1503をクリックすることにより、その設定内容が確定される。この場合、処理要求データストリームがここで設定されたジョブ種類とPDL種別を持つ場合に、当該処理要求データストリームに含まれる描画データストリームが図7の(B)によって配置されたフィルタの処理を受けることになる。
尚、上記ではフィルタ処理を適用するか否かをPDL種別やジョブ種類により判断するが、これらは一例であり、これに限られるものではない。
図8は、本実施の形態に係るフィルタ処理の主要な手順を示すフローチャートである。
この手順は、具体的なフィルタクラスのrunメソッドとして実装されている。フィルタフレームワーク219は、有効なフィルタクラスのオブジェクトを生成し、その入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのrunメソッドを実行するためにスレッド(Threadオブジェクト)を割り当てる。これにより、フィルタフレームワーク219が管理する各フィルタオブジェクトにおいて、この手順がそれぞれ自律的に並行処理で実行される。
まずステップS1で、必要な前処理を行う。この前処理には、フィルタ221が内部的に利用する属性の初期化、パターンマッチングに使用するパターン記述に対する前処理、入力/出力ストリームをより使いやすくする機能を付加するための修飾クラスによってストリームをラップする処理などが含まれる。ここで、入力/出力ストリームをより使いやすくする機能としては、例えば入力ストリームを先読み可能にしたり、システムリソースを有効に利用するためにバッファリングを拡張したりすることが挙げられる。また、そのような機能を付加するための修飾クラスとしては、Java.io.FilterInputStreamやJava.io.FilterOutputStreamの具体クラスが挙げられる。次に、ステップS2で、入力属性にセットされている入力ストリームからパターンマッチング処理に必要な量のデータを読み出す。そしてステップS3で、入力したデータストリームから、このフィルタが操作するべきデータパターンの出現を発見するためにパターンマッチングを行う。このフィルタが操作するべきデータパターンは、固定のデータ列そのものでも良く、或は正規表現(regular expression)等の形式言語による記述でもよい。尚、パターン記述に合致するデータの出現をデータストリーム中から発見するための各種の実装は広く知られており、例えばgrep、sed、AWK、Perlなどが有名である。
パターンマッチングを効率良く行うためのアルゴリズムはよく研究されている。固定のパターン記述の場合には、まずパターン記述と部分データストリームのそれぞれのハッシュ関数を比較し、ハッシュ値が一致した場合のみ両者の完全一致を判定する方法や、Knuth-Morris-Prattの方法や、Boyer-Mooreの方法などが知られている。正規表現などによるパターン記述の場合も、有限オートマトンなどの形式言語理論を背景とする各種のアルゴリズムが知られている。比較的最近のJava(登録商標)プラットフォームでは、正規表現を扱うためのクラスライブラリが標準に備わってもいる(Java.util.regex)。尚、例えばデータストリームの上流のパターンに応じて状態が変化し、その変化した状態に従って下流のパターンの解釈を変えなければならない場合であって、正規表現等では却って記述が困難なほど複雑なパターンマッチングが必要とされる場合がある。そのような場合には、そのパターンの特徴そのものを評価するアルゴリズムをJava(登録商標)プログラムとして書き下してもよい。このようにして、どれほど複雑なパターンマッチングであっても素直に実装することができる。
次にステップS4で、パターンマッチングの結果を判定し、パターン記述に合致するデータをデータストリーム中に発見した場合はステップS5に進むが、そうでなければステップS6に進む。ステップS5では、パターン記述に合致したデータストリームの部分データ列に対してこのフィルタの目的に応じた操作を施し、その結果で置き換える。次にステップS6で、処理済の部分データ列(即ち、監視しているパターンが現れなかったデータ列、或は、監視しているパターンを含むデータ列に対してステップS5の処理を施したデータ列)を出力ストリームに書き込む。そしてステップS7で、入力ストリームが終了したかどうかを判定し、終端を迎えた場合は終了するが、そうでなければステップS2に戻って、上記の手順を繰り返す。
図9は、本実施の形態に係るフィルタ処理の手順の更なる一例を示すフローチャートである。
この手順は、具体的なフィルタクラスのrunメソッドとして実装されている。フィルタフレームワーク219は、有効なフィルタクラスのオブジェクトを生成し、その入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのrunメソッドを実行するためにスレッド(Threadオブジェクト)を割り当てる。これにより、フィルタフレームワークが管理する各フィルタオブジェクトにおいて、この手順がそれぞれ自律的に並行処理で動作することになる。
まずステップS11で、必要な前処理を行う。この前処理には、フィルタが内部的に利用する属性の初期化、パターンマッチングに使用するパターン記述に対する前処理、入力/出力ストリームを、より使いやすくする機能を付加するための修飾クラスによってストリームをラップする処理などが含まれる。尚、入力/出力ストリームを、より使いやすくする機能としては、例えば入力ストリームを先読み可能にしたりシステムリソースを有効に利用するバッファリングを拡張したりすることが挙げられる。また、そのような機能を付加するための修飾クラスとしては、例えば、Java.io.FilterInputStreamやJava.io.FilterOutputStreamの具体クラスが挙げられる。次にステップS12で、新たな部分データストリームを生成する。次にステップS13で、入力属性にセットされている入力ストリームから、予め定められた量のデータを読み出す。そしてステップS14で、その読み込まれたデータストリームに対して、ステップS12で生成された部分データ列を追加する。次にステップS15で、処理済の部分データ列を出力ストリームに書き込む。そしてステップS16で、入力ストリームに存在する残りデータを出力ストリームに書き込む。
図10は、本実施の形態に係る処理要求データストリームを説明する図である。
801は処理要求データストリームを示している。クライアントからの、この画像処理装置1000に対する処理の要求は、クライアントが処理要求データストリーム801を作成して画像処理装置1000に送信することにより行われる。そして、要求された処理の実行は画像処理装置1000が、その処理要求データストリーム801を処理することで実行される。この処理要求データストリーム801は、大きく装置制御指示データストリーム802(図3の351に相当)と描画データストリーム803(図3の352に相当)に分けることができる。
装置制御指示データストリーム部802では、この画像処理装置1000への、描画以外の処理要求に関する指示が記述されている。具体的には、以下のような指示を行うことが一般的に知られており、画像処理装置1000が備える機能により規定されている。1行目の「ジョブ種類」の属性は、「印刷」、「セキュアプリント」、「画像取得」等の値を取り得るもので、この画像処理装置1000が備える各種ジョブのタイプを表している。「画像取得」等のように描画指示を行わない処理要求の場合は、描画データストリーム803は一般的には、このような処理要求データストリーム801に含まれない。2行目の「部数」の属性は、印刷物のコピーを何セット生成するかを表している。3行目の「ページレイアウト」の属性は、ページレイアウト指定を表している。ページレイアウト指定には、「1ページ/枚」「2ページ/枚」「4ページ/枚」などのように、1枚の用紙に複数ページを面付けするための指定が含まれる。更に、ページレイアウト指定には、「ポスター(2×2)」、「ポスター(3×3)」などのように、1ページを拡大して複数枚の用紙に分割して印刷する指定も含まれる。4行目の「配置順」の属性は、「左上から右向き」、「左上から下向き」、「右上から左向き」、「右上から下向き」等の値を取り、ページレイアウト時の各面の配置指定を表す。5行目の「印刷方法」の属性は、「片面印刷」、「両面印刷」、「製本印刷」等の値を取り、これにより印刷方法を表す。6行目の「とじ方向」の属性は、「長辺とじ(左)」、「長辺とじ(右)」、「短辺とじ(上)」、「短辺とじ(下)」などの値をとり、フィニッシング処理において複数枚の用紙を綴じる方向を表す。7行目の「排紙方法」の属性は、「指定しない」、「ソート」、「ステイプル」、「パンチ穴」などの値をとり、フィニッシングの方法を表す。8行目の「給紙」属性は、「自動」、「手差しトレイ」、「カセット」、「デッキ」、或は「普通紙」、「厚紙」、「色紙」、「OHP」などの値をとり、画像形成の対象とする用紙(転写紙)の給紙指定を表す。9行目の「使用PDL」は、処理要求内容が描画指示である場合に使用され、描画データストリームに使用されるPDLの種別を表している。
描画データストリーム部803は、処理要求内容が描画指示である場合に使用され、描画データストリームは一般的にはPDLで構成される。
図11は、本実施の形態に係る描画データストリーム803に対するフィルタが行う処理を説明する図である。
互換化フィルタ901は、この描画データストリーム803のフィルタクラスのオブジェクトを示し、入力データストリームに現れる描画データストリーム803における互換性の問題を解決する処理を施して出力ストリームに書き込む。この描画データストリーム803における互換性の問題として、ここでは代表的なPDLの一つであるAdobeのPostScript仕様を、各社ベンダが実装した画像処理装置間におけるベンダごとの解釈の差異に基づく問題と、その解決の例を説明する。
あるベンダの画像処理装置は、PostScriptの「setpagedevice」が次のように解釈して実装されている。即ち、「setpagedevice」で「/DeferredMediaSelection」が真のときカスタム用紙扱いとして用紙要求をパネルに表示する。一方、偽の場合には、指定されたサイズから±5の範囲で定型用紙を検索し、定型にない場合はPostScriptのPolicyに従う。また別のベンダの画像処理装置では、PostScriptの「setpagedevice」が次のように解釈して実装されている。即ち、「/DeferredMediaSelection」が真の場合は、指定されたサイズそのもののサイズ(範囲なし)で定型用紙を検索し、定型にない場合はカスタム用紙扱いとする。一方、偽の場合には、±5の範囲で定型用紙を検索し、定型にない場合はPostScriptのPolicyに従う。
ここで、更に別のベンダが供給する基幹系システムのためのインフラストラクチャ環境が、上記の内の後者の解釈に基づく挙動を前提として構築されたとする。すると、印刷要求に対して前者の画像処理装置では、カスタム用紙扱いとなってしまい、「用紙なし」が操作パネルに表示されて印刷されない。従って前者の画像処理装置のベンダは、この互換性の問題に対して、できるだけ低コストでかつ速やかに解決することが求められる。このような要求に対しては、印刷要求データストリームに現れるsetpagedeviceの「/DeferredMediaSelection」パラメータを真(true)から偽(false)に変換することで、少なくとも暫定的に応えることができる。互換化フィルタ901は、このような問題を解決するために働くフィルタオブジェクトである。即ち、互換化フィルタ901は、入力データストリームから「/DefereedMediaSelection」が真(true)で指定されたsetpagedeviceに対するパターンマッチングを行い、マッチした場合は、偽(false)に置き換えた力データストリームを出力する。
902はフィルタへの入力データストリームの一例である、PostScriptのプリントデータである。2行目にパターンに合致する部分データが出現する。903は、入力データストリーム901がフィルタによりフィルタ処理されて出力された出力データストリーム例を示し、フィルタ処理されたPostScriptのプリントデータで示されている。この出力データストリーム903では、2行目のデータの中で「true」という文字列が「false」へ変更されている。
図12は、本実施の形態に係る描画データストリームに対してフィルタが実行するフィルタ処理を説明する図である。
上記の図11の例では、画像処理装置間の仕様の差異に基づく互換性の問題を解決するために、フィルタによるデータストリームのパターンマッチングと置換の技術を用いた。図12の例では、同様の技術を、画像処理装置の実装の不具合(ファームウェアのバグなど)を緊急回避するために用いている。例えば、ある画像処理装置のあるバージョンのリリースにおいて、LIPS(登録商標)言語の「イメージ領域確保命令(VDM)」に指定されるイメージの幅が8の倍数でなければ描画不正が発生するというバグがあったとする。
1001は障害回避フィルタを示し、例えば、LIPS(登録商標)データストリーム1002から障害を発現させるパターンを発見し、その障害を顕在化させず同等の機能を達成するためにデータストリームに変換する。例えば、障害回避フィルタ1001は、データストリーム1002から障害を発現させるパターンを発見(VDMのイメージ幅が「225」であり8の倍数でない)する。そして、発見されたパターンをVDMのイメージ幅を8の倍数に変換する(ここでは、「225」より大きい値である「232」)に変換する。
図13は、本実施の形態に係る描画データストリームに対する最適化フィルタが行う処理を説明する図である。
最適化フィルタ1101は、描画データストリームに対する最適化フィルタクラスのオブジェクトを示す。最適化フィルタ1101は、入力ストリームを読み出してデータストリーム中に現れる冗長に記述されたPDLデータを発見し、それをより効率の良い同機能のデータに変換して出力ストリームに書き込む。画像処理装置のドライバが生成するPDLデータストリームは、クライアントのプリント要求システムやアプリケーション側の都合によって、どうしても繰り返しなどの冗長な処理がパターンを含む傾向にある。このような冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換える。
1102は、フィルタ1101に入力される入力データストリームの一例を示す。この入力ストリーム1102では、1103で示すように、横長の長方形を塗りつぶすために3つの正方形の塗りつぶしを繰り返すように記述されている。1104は、この最適化フィルタ1101からの出力データストリームの一例を示している。ここではフィルタ1101は、冗長な繰り返しパターンを検出し、それを等価な1つの横長の矩形の塗りつぶし1105に書き換えている。
図14は、本実施の形態に係る装置制御指示データストリームに対する機能追加フィルタが行う処理を説明する図である。
1201は、装置制御指示データストリーム351に対する機能拡張フィルタクラスのオブジェクト例を示している。機能拡張フィルタ1201は、入力データストリーム1202を読み出して、その入力データストリームに応じて新たな機能を付加するためのデータ変換やデータ追加などの処理を施して、出力データストリームに書き込む。ここでは、機能拡張の例として、以下の例を挙げる。即ち、顧客システムが専用のPDLドライバを抱えていてそのドライバが新しい画像処理装置の両面印刷や各種フィニッシングなどの新しい能力に未対応であるとする。そのような場合に、そのドライバを変更することなく画像処理装置側のフィルタ対応によって装置の新機能を活かす。
機能拡張フィルタ1201は、そのフィルタが稼動している画像処理装置の新しい能力を活かすための装置制御指示設定をその属性として持つ。フィルタオブジェクトの属性値は、装置の不揮発性メモリにも保存され、装置の電源が落とされて再起動された場合であってもオブジェクトの状態は保存される。具体的には、前述のように画像処理装置が備える機能により規定されている。
入力データストリーム1202は、印刷データストリームの機能拡張フィルタ1201に入力されるデータストリームである。このデータストリーム1202は、旧来のアプリケーションが生成し、画像処理装置1000によって受信された処理要求データストリームが画像処理装置内で分割された装置制御指示データストリーム351である。或は、このデータストリーム1202は、画像処理装置1000のドライバが生成する処理要求データストリームが画像処理装置内で分割された装置制御指示データストリーム351である。
出力データストリーム1203は、この装置制御指示データストリームの機能拡張フィルタ1201が逐次処理を行って出力するデータストリームを示す。入力データに存在した単純な処理要求データストリームに加えて、画像処理装置1000の新機能を使いこなすための各種のプリントジョブ記述データが挿入されている。プリントジョブ記述は入れ子構造を表現できるようになっており、ジョブ単位、複数の文書をまとめたフィニッシングなどの処理単位、個々の文書単位のそれぞれの階層において、機能拡張フィルタ1201の属性のような各種属性の指定が可能である。
この出力データストリーム1203において、1行目の「JobStart」はジョブの開始を表す。2行目の「SetJob」は、ジョブ単位の設定の開始を表す。3行目の「ジョブ設定データ」は、この位置に各種のジョブ単位の設定データが存在することを示す。4行目の「BinderStart」は、複数文書をひとまとめにする単位の開始を表す。5行目の「SetBinder」は、複数文書をまとめた単位に対する設定の開始を表す。6行目の「文書束設定データ」は、この位置に複数文書をまとめた単位に対する設定データが存在することを示す。7行目の「DocumentStart」は文書の開始を表すデータである。8行目の「SetDocument」は、文書単位の設定の開始を表す。9行目の「文書設定データ」は、この位置に文書を単位とする設定データが存在することを示す。
図15は、機能拡張フィルタ1201を操作するためのユーザインターフェース例を示す図である。
フィルタ操作のためのユーザインターフェースは、標準ライブラリとフレームワーク217に含まれるHTTPサービスによって、Webアプリケーション(Servlet)として実装されており、クライアントで動作するWebブラウザから操作される。或は、Applet型サービスとして実装して、画像処理装置1000の持つ操作パネル18から操作するように構成してもよい。
1301は、機能拡張フィルタ1201の基本操作画面を示し、この画面を使用して、フィルタオブジェクト属性の確認や変更など操作できる。1302は、ジョブ種類の属性を操作するのに使用される。1312は、部数属性を設定するのに使用される。1303は、ページレイアウト属性を設定するのに使用される。1304は、配置順の属性を設定するのに使用される。1305は、印刷方法の属性を設定するのに使用される。1306は、とじ方向の属性を設定するのに使用される。1307は、排紙方法の属性を設定するのに使用される。1308は、給紙属性を設定するのに使用される。ヘルプボタン1309は、このフィルタの使い方、機能、属性の意味などの説明を表示するのに使用される。「標準に戻す」ボタン1310は、各種属性をデフォルト値に戻す場合に指示される。適用ボタン1311は、属性値の変更操作が適用され、新しい値を実際にフィルタオブジェクトの属性として設定するために使用される。1313はプレビューアイコンを示し、各種属性を画面上で確認するために、いくつかの重要な属性についてその値の状態に応じた模式図が表示される。
以上説明したように本実施の形態1によれば、以下のような効果がある。
(1)プリント要求受信サーバをファームウェアとして静的に実装し、その受信サーバで受信したデータストリームを、組み込みJava(登録商標)環境上に実装した動的ロードや動的リンク可能なフィルタソフトウェアに引き渡すインターフェースを設けた。これにより、安定部分と動的部分を明確に分離できるため、装置のファームウェア全体を動的で冗長なソフトウェアに置き換えるといった非効率な処理や、Java(登録商標)環境側に実装して二重に持ってしまうといった非効率も防止できる。これにより、コスト面でも、また開発の負荷の面でも合理性のあるフィルタフレームワークが実現できた。更に、納入済みの装置に対するフィルタの動的な追加や置き換えを容易にできるため、低いサポートコストでより迅速に顧客のニーズに対処できる。
(2)より洗練されたJava(登録商標)環境でフィルタを実装するため、通常、組み込みシステムでは困難な動的なメモリ管理が有効な高度なパターンマッチングアルゴリズムを容易に実装できる。また高度にモジュール化された再利用性の高いソフトウェアとして設計するため、オブジェクト指向パラダイムに基づくデザインパターンを容易に採用できる。その結果、生産性の高いフィルタ部の実装を実現できる。
(3)フィルタにより、パターンマッチングを用いて、入力データストリームから他の実装との互換性点で問題となるPDLデータを発見し、そのPDLデータを適正に変更することができる。これにより、互換性の問題や障害を低コストで解消できた。特に、顧客環境におかれたシステムや、アプリケーションや画像処理装置のドライバに影響を及ぼすことなく、画像処理装置側に閉じた対応だけで達成できる。また、フィルタを配置しない場合には、フィルタフレームワークが介在することによるオーバヘッドを回避できる構成であるため、フィルタを配置しない場合にも画像処理装置本来のデータ処理性能を維持できている。
(4)Java(登録商標)環境に柔軟に拡張可能なフィルタで、冗長な記述パターンを一種の「慣用表現」として認識し、それをより高効率の等価な表現に置き換えることができる。このため、PDLの処理システムの主要部には全く影響を与えずに印刷処理のパフォーマンスを改善できる。又、画像処理装置側で閉じて最適化処理を行うので、顧客環境のシステムやアプリケーションや画像処理装置ドライバを改造する必要もない。またフィルタの生産性が高く、インストールなどのメンテナンスも容易であるため、各顧客の利用形態に即した最適化を行うことができる。
(5)Java(登録商標)環境に柔軟に拡張可能なフィルタに、新機能を活かすために必要なデータを追加することで画像処理装置の新機能が利用可能となる。このため、画像処理装置の新機能に対応していない顧客環境のシステムやアプリケーションや画像処理装置ドライバと組み合わせる場合であっても新しい機能を使いこなすことが可能となる。
(6)Java(登録商標)環境がファームウェアの更にもう一層のソフトウェアプラットフォームとして、そのファームウェアで動作するフィルタのために、追加機能の設定を操作するためのユーザインターフェースをフィルタに設けた。これにより、顧客の利用形態に即して個別対応した機能拡張が提供できる。
(7)フィルタ処理を、装置の制御に関する指示命令で構成される装置制御データストリーム部、PDLなど描画に関する指示命令で構成される描画データストリーム部のそれぞれに対して最適なフィルタ処理が可能となった。
(8)夫々のデータストリーム処理の際に、データストリーム属性管理モジュール228を介することで、データストリーム処理を行うモジュールは、他のデータストリームで抽出された情報を用いてフィルタリング処理の適用を決定することが可能となった。具体的には、JL(Job Language)と呼称される装置制御データストリームに記載されている、ジョブ種類や、PDL種別に従って、描画データへのフィルタ処理の適用することが可能となった。
[実施の形態2]
図16は、本発明の実施の形態2に係る送信用データストリーム1401を説明する図で、この実施の形態2に係るハードウェア構成及びソフトウェア構成は前述の図1〜図4と同じであるため、その説明を省略する。
クライアントからの処理要求に応じて、画像処理装置1000は、クライアントが指定した先へ画像データなどを送信する。その際、画像処理装置1000は、この送信用データストリーム1401を生成し、データ送受信モジュール202より送信する。送信用データストリーム1401は、送信用データストリームのジョブ種類を記載しているデータストリーム部1402と、画像データストリーム1403に大別できる。このデータストリーム部1402には、画像データそのもの以外の情報が記述されている。このデータストリーム部1402のフォーマットは、画像処理装置1000が備える機能により規定されている。このデータストリーム部1402は、データ送信処理を行う際に、ジョブ制御モジュール205、或は組み込みアプリケーション203により画像データに付加され、送信用データストリームとしてデータ送受信モジュール202から送信される。画像データストリーム部1403は、画像読み取り部19から入力されたスキャン画像データストリーム360(図3)が画像処理モジュール209で処理されることで生成される。尚、ここで送信用データストリーム1401、データストリーム部1402、画像データストリーム1403は前述のように、それぞれフィルタ処理が可能である。
以上説明した実施の形態2によれば、画像処理装置内に存在するスキャン画像データストリーム360、画像データストリーム、送信用データストリーム359のそれぞれに対して最適なフィルタ処理が可能となった。
[他の実施の形態]
上記以外の画像処理装置内に存在するデータストリームとしては、PDLが処理されることで生成されるディスプレイリスト355、画像処理装置において最終的に生成される最終画像データストリーム357、最終画像データストリーム357を生成するために生成される中間画像データストリーム356などがある。それぞれのデータストリームは、画像処理装置が備える機能により形式が規定されている。前述と同様の構成により、それぞれのデータストリームに対して最適なフィルタ処理を行うことができる。
又、印刷データストリーム中の制御データでなく、印刷対象の文字データ列を扱うようにフィルタを構成してもよい。例えば、印刷対象の文字データ列中から特定の文字列パターンの出現を発見し、特定の文字列パターンに合致した場合に、その文字列に相当する制御データを生成して置換または挿入するような機能拡張フィルタを構成することもできる。例えば、顧客がワードプロセッサのようなアプリケーションを使用してテキストとして入力し、それを画像処理装置の通常のドライバ経由でプリントする際に、特定の文字列をベクタ描画命令などに変換するようにしてもよい。この場合、画像処理装置側のフィルタにおいて、例えば特定文字列を、それに対応する画像(ロゴやマークや透かしなど)を描画するためのベクタ描画命令などの命令列に変換するように構成することができる。
上記実施の形態では、ファームウェア内部のインタプリタ環境としてJava(登録商標)の仮想マシン環境を用いたが、本発明はこれに限定されるものではない。他のスクリプト言語などのインタプリタ環境をファームウェアに組み込んで構成した場合であっても、動的なフィルタ追加とファームウェア部分の分離など同様の効果が得られる。
また、オブジェクト指向など高効率の開発を可能とするインタプリタ環境は他にも多く存在し、これらを用いてもフィルタ生産性など同様の効果が得られる。特にパターンマッチングに基づくデータストリームの処理に関しては、sed,AWK,Perlなどの選択肢も適している。
[他の実施形態]
以上、本発明の実施の形態を詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、または一つの機器からなる装置に適用しても良い。
なお本発明は、前述した実施の形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが、その供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等、プログラムの形態を問わない。
プログラムを供給するための記憶媒体としては、例えば、フロッピー(登録商標)ディスク、ハードディスク、光ディスク、光磁気ディスク、MO、CD−ROM、CD−R、CD−RW、磁気テープ、不揮発性のメモリカード、ROM、DVD(DVD−ROM,DVD−R)などがある。その他のプログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるWWWサーバも、本発明のクレームに含まれるものである。
また、本発明のプログラムを暗号化してCD−ROM等の記憶媒体に格納してユーザに配布し、所定の条件を満足するユーザに対してインターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
またコンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているOSなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。