JP2006268467A - 画像処理装置 - Google Patents

Abstract

【課題】印刷装置において、ＰＤＬデータのカスタマイズを容易にする機構であるプリントデータの変換（フィルタリング）を多重化する際の相互干渉を防止する。
【解決手段】フィルタリング（フィルタ挿入）可能な印刷装置において、ひとつのフィルタリング終了時に変換を行った文字列の前後に識別用タグを挿入する手段、別のフィルタリング時に識別用タグで指定された領域のフィルタリング作業を禁止する手段により構成される。
【選択図】 図１

Description

本発明は、プリンタ等の機能を有する画像処理装置に関するものである。

従来、画像処理装置のソフトウェアはリアルタイムオペレーティングシステム（ＯＳ）の上に静的かつ固定的ないわゆるファームウェアとして構築されることが主流であった。このようなファームウェアは内部的に複数のモジュールから構成されている場合でも全体が単一のロードモジュールに静的にリンクされた状態で装置の不揮発性メモリに記憶され、ファームウェアはシステムの起動時にハードディスクなどの不揮発性メモリからＲＡＭにロードされ実行されるか、または、ＲＯＭなどの不揮発性メモリ上で直接実行される。特に低価格な画像処理装置のような組み込みシステムを構成するファームウェアは一般に、その経済性や安全性などのために部分的なモジュールの動的なロードやリンクを行わないように構成されている。すなわち、ダイナミックリンクを実現するために必要なシンボルテーブルの記憶容量やシンボルのアドレスへの解決を行うための処理に関するオーバヘッドなどが、装置のコストパフォーマンスを悪化させ、また、追加してロードおよびリンクされるサブモジュールによってそのサブモジュールをリンクする以前には十分に評価され達成されていたシステム全体の品質やセキュリティが脅かされる危険があるためである。

そこで、特許文献１や特許文献２などにおいて開示されているように、組み込みシステムのファームウェアのリアルタイムＯＳ上にさらにもう一層のソフトウェア動作環境を設け、追加で設けたソフトウェア動作環境においてダイナミックローディングやダイナミックリンキングや動的なメモリ操作などのソフトウェアの動的な特性をサポートする画像処理装置が開発されている。追加で設けられたソフトウェア動作環境は、インタプリタとひとそろいのアプリケーションプログラミングインタフェース（ＡＰＩ）群やフレームワーク群から構成され、その上で動作するソフトウェアのために一種のＯＳあるいはコンピューティングプラットフォームというべきものを提供する。インタプリタは、所定の命令セットに含まれる命令からなる一連の命令列を逐次的に読み出し解釈し実行する。この命令セットをハードウェアのＣＰＵのための命令セットと同等の位置づけに捉える場合、インタプリタは特に仮想マシン（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）と呼ばれることもある。ひとそろいのＡＰＩ群およびフレームワーク群は、このソフトウェア動作環境の下層に内在する実際のリアルタイムＯＳが提供する資源やハードウェア資源を抽象化した各種の資源群に対するアクセスを、ソフトウェア動作環境上で動作するソフトウェアのために提供する。資源にはプロセッサによる命令実行コンテクストやメモリ、ファイルシステム、ネットワークインタフェースを含む各種入出力（Ｉ／Ｏ）などがある。特に、命令実行コンテクストは実際のＣＰＵとリアルタイムＯＳが提供するマルチタスク機構とは独立に、ソフトウェア動作環境が独自にインタプリタ上の命令実行コンテクストを管理できる。また、メモリも同様にソフトウェア動作環境が独自のメモリ管理を提供できる。

このようなソフトウェア実行環境上で動作するソフトウェアはインタプリタによって逐次的に読み込み解釈実行されるため、これらの処理の過程で命令列を監視しシステムに悪影響を与える動作を除外できる可能性がある。また、ソフトウェア実行環境上のソフトウェアから各種資源に対するアクセスは、ソフトウェア実行環境が提供するＡＰＩ群やフレームワーク群を経由して間接的に資源を操作するため、この過程でシステムに悪影響を与える動作を除外できる可能性がある。したがって、ファームウェア内部にインタプリタおよびＡＰＩ群とフレームワーク群からなるソフトウェア実行環境の階層を設けるアプローチは、基本的には静的かつ固定的に構成されるべき低コスト組み込みシステムのファームウェアにおいて、ソフトウェアの動的な特性を部分的に導入するために非常に有効である。

上記アプローチにおいて、ソフトウェア実行環境の階層を実現するためにインタプリタとしてＪａｖａ(登録商標)仮想マシンを採用し、Ｊａｖａ(登録商標)に関連するＡＰＩ群やフレームワーク群を採用することができる。本出願人は２００３年に、画像処理装置のファームウェア内部にＪａｖａ(登録商標)プラットフォームを内蔵した複合機であるＭＥＡＰを製品化している。

特許文献３では、内部にネットワークコンピュータを備えたアプリケーションダウンロード型プリンタを用い、コンピュータネットワークから、印刷すべきデータファイルと該データファイルに対応したアプリケーションとを上記プリンタ内にダウンロードし、上記ネットワークコンピュータ上で上記アプリケーションを立ち上げることにより該データファイルを開いてラスタイメージに変換し、印刷するネットワークコンピュータ内蔵プリンタおよびこれを備えたコンピュータネットワークシステムが開示されている。アプリケーションが「Ｊａｖａ(登録商標)アプレット」である場合も開示されている。アプリケーションは印刷データファイルとともにクライアントからプッシュされる場合も、プリンタがアプリケーションサーバなどからプルする場合も開示されている。

特許文献４では、複数の周辺機器および周辺機器を動作させるソフトウェアを搭載した複数の端末装置および少なくとも周辺装置を動作させるソフトウェアに関するデータベースを備えたサーバ装置を伝送路に接続させ、所定の通信プロトコルに基づいてネットワーク通信を行うネットワーク通信システムであって、周辺機器は、サーバ装置から周辺機器を動作させるソフトウェアの全部／一部、あるいはソフトウェアが使用するモジュールに対応する最新モジュール情報を要求・獲得するクライアント制御部と、獲得した最新モジュールを端末装置に配付するソフトウェア配信エージェントと、を備えたネットワーク通信システムが開示されている。周辺機器を操作するソフトウェアが使用するクライアント側モジュールとして、「ｊａｖａ(登録商標)アプレット」や「ｊａｖａ(登録商標)アプリケーション」が供給可能であることも開示されている。

特願２００４−０９３２１５号では、ページ記述言語（ＰＤＬ）プリンタにおいて、カスタマイズや障害回避などの個別対応が求められる場合に対応した事例である。物理的なプロセッサによって処理されるネイティブ命令に基づいて構築されたファームウェアであるネイティブ環境中で、独立に定義された命令セットに基づいて構築されたプログラムを動的にロードしてリンクして実行するインタプリタ環境を内蔵し、クライアントからの印刷要求データストリームを受信する印刷要求データストリーム受信手段と、前記印刷要求データストリームを解釈し画像形成を行うジョブを制御する印刷ジョブ制御手段と、インタプリタ環境上のプログラムであって、印刷要求データストリームをデータ処理して処理済の印刷要求データストリームを生成するフィルタ手段と、受信された印刷要求データストリームをフィルタ手段に引き渡す第１のインタフェース手段と、フィルタ手段が処理した処理済のデータストリームを印刷ジョブ制御手段に引き渡す第２のインタフェースを設ける事によりカスタマイズおよび障害回避を容易に行うための仕組みを提供している。
特開平１１−２８２６８４号公報 特開２００３−２５６２１６号公報 特開平１１−５３１３２号公報 特開平１１−３０６１０７号公報

ページ記述言語（ＰＤＬ）プリンタにおいて、カスタマイズや障害回避などの個別対応が求められる事例に対する解決手段として前節のような提案がみられる。

しかしながら、前記のフィルタ技術を用いて複数の多段に用いる場合において、複数の独立したサードパーティから様々な効果のフィルタが供給された場合には、相互の互換性が十分に行えない場合がある。そのような場合に、複数のフィルタをインストールして使用すると、お互いの変換結果が干渉しあい意図しない作用が発生する事がある。

本発明は、上記に鑑みてなされたものであって、フィルタが複数のフィルタを多段に用いた場合に生じる前記不都合を解消し、且つ相互のフィルタの干渉作用によって、使用者の意図しない動作を防止し、ＰＤＬプリンタのカスタマイズの生産性を向上させる事ができる。

上記の目的を達成するために本発明は以下の手段を持つことを特徴とする。

物理的なプロセッサによって処理されるネイティブ命令に基づいて構築されたファームウェアであるネイティブ環境中にあって前記ネイティブ命令とは独立に定義された命令セットに基づいて構築されたプログラムを動的にロードしてリンクして実行するインタプリタ環境を内蔵した画像処理装置において、前記ネイティブ環境中にあって、クライアントからの印刷要求データストリームを受信する印刷要求データストリーム受信手段と、前記ネイティブ環境中にあって、前記印刷要求データストリームを解釈し画像形成を行うジョブを制御する印刷ジョブ制御手段と、前記インタプリタ環境上のプログラムであって、前記印刷要求データストリームをデータ処理して処理済の印刷要求データストリームを生成するフィルタ手段と、前記印刷要求データストリーム受信手段が受信した前記印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェース手段と、前記フィルタ手段が処理した前記処理済のデータストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェース手段とから構成されることを特徴とする画像処理装置において、
前記フィルタ手段が互いに別の機能を持つ第１から第Ｎのサブフィルタにより構成され、前記第一から第Ｎに含まれる第ｎのサブフィルタ手段が、第２ｎ−１の文字列を第２ｎの文字列に変換する第ｎの文字列変換手段を有し、前記第一から第Ｎに含まれる前記第ｎの文字列を識別する文字列識別記号を挿入する第ｎの文字列識別記号挿入手段と、前記第一から第Ｎに含まれる第ｍのサブフィルタ手段が、前記文字列識別記号を判定する第ｍの文字列識別記号判定手段と、前記第ｍの文字列識別記号判定手段の結果に基づいて、第ｍのサブフィルタ手段の文字列変換手段を禁止する第ｍの文字列変換禁止手段と、前記第一から第Ｎに含まれる第ｐのサブフィルタ手段が、前記文字列識別記号を除去する文字列識別記号除去手段を有する。

プリンタが受信したＰＤＬデータストリームに対する解釈前の前処理を行うフィルタ部を柔軟かつ拡張可能なソフトウェアとして実装し、安定性が求められるプリンタファームウェアのその他の部分の実装と明確に分離することによって、ＰＤＬプリンタのカスタマイズの生産性を向上できた。

以下本発明を実施するための最良の形態を、実施例により詳しく説明する。

図１は画像処理装置のハードウェア構成を説明するブロック図である。

１０００はプリンタで、内部でプリンタコントローラ１６００からなる異なる制御系を司る機器で構成されている。

１はネットワークプリントサーバ用ＣＰＵで、書き換え可能なＦｌａｓｈＲＯＭ３に記憶された制御プログラムに基づいてシステムバス４に接続されるネットワークコントローラ（ＬＡＮＣ５）を介してローカルエリアネットワーク（ＬＡＮ２０００）に接続されたホストコンピュータ等の複数の外部装置（不図示）と所定のネットワーク通信プロトコルを用いて、前記外部装置から送られる印刷データやプリンタ制御命令等の各種データ送受信要求を統括的に制御する。またＲＯＭ９に記憶された制御プログラム等あるいはディスクコントローラ（ＤＫＣ１５）を介して接続された外部メモリ１０に記憶された制御プログラムやリソースデータ（資源情報）等に基づいてシステムバス１１に接続される各種デバイスとのアクセスを統括的に制御し、受信される印刷データを基にラスタコントローラ１２によって出力画像情報を生成し、マーキングエンジン１６に対して画像信号を出力する。

ＲＡＭ２はＣＰＵ１の主メモリ、ワークエリア等の一時記憶領域をして用いられる。

ＬＥＤ６はコントローラの動作状態を示す表示部として用いられており、例えばネットワークコントローラ（ＬＡＮＣ５）とローカルエリアネットワーク（ＬＡＮ２０００）の電気的な接続状態（ＬＩＮＫ）やネットワーク通信モード（１０Ｂａｓｅや１００Ｂａｓｅ、全二重、半二重）等の各種動作状態をＬＥＤの点滅パターンや色で示すこと可能となっている。

１８は操作パネル（操作部）でプリンタ１０００の動作モード等の設定や印刷データの取り消し等の操作を行なうためのボタンや液晶パネルに重ねあわされたタッチパネル、およびプリンタ１０００の動作状態を示す液晶パネルやＬＥＤ等の表示部が配されている。

なお、本図で示したマーキングエンジン１６は既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式（レーザービーム方式）やインクジェット方式、昇華方（熱転写）方式等が挙げられる。

図２は画像処理装置コントローラのソフトウェア構造を示す階層図である。

図において上位のモジュールは下位のモジュールに依存していることを示す。また特に線によって接続したモジュール間には依存関係が存在することを示す。

２０１はネイティブコード部である。この部分は画像処理装置のファームウェアを構成する標準部分であり、ハードウェアであるＣＰＵによって直接実行されるネイティブコードである。この部分はファームウェアとして、装置の開発時に単一のロードモジュールにスタティックリンクされ、生産時に装置の持つ不揮発性メモリに格納されている。ファームウェアは装置の起動時に不揮発性メモリからＲＡＭに展開され、装置の稼働中はＣＰＵがＲＡＭからコードを逐次的に読み出して解釈実行を行うが、実行時のダイナミックリンクは行わない。あるいは、ＲＯＭのようなＣＰＵが直接読み出しアクセス可能な不揮発性メモリにファームウェアを格納して、ＲＡＭへの展開は行わずにＣＰＵがＲＯＭからコードを逐次的に読み出して解釈実行するように構成してもよい。

２０２はプリントアプリケーションである。プリンタとしての画像処理装置の中心機能を提供するための組み込みアプリケーションであり、クライアントからの要求に呼応してプリントサービスを提供する。プリントアプリケーション２０２は制御ＡＰＩ２０４によって、クライアントから要求されたプリントジョブの実行を行う。

２０３は印刷要求受信モジュールであり、クライアントから投入されるプリントジョブを受信する。印刷要求受信モジュール２０３は、ＲＴＯＳ２０９を介してプロトコルスタック２１０に依存している。クライアントからの印刷要求は、物理的にはＥｔｈｅｒｎｅｔ(登録商標)などのネットワークやＵＳＢ、ＩＥＥＥ１３９４などの各種インタフェースを介してクライアントからプリンタに送信されるが、それぞれの接続形態に応じてプリント要求を行うためのアプリケーションプロトコルが規定されている。印刷要求受信モジュールはこのプリントのためのアプリケーションプロトコルのサーバ機能を実装している。プリントサービスのためのアプリケーションプロトコルには、たとえばネットワークプロトコルだけでもＬＰＲやＳＭＢ、ＰＡＰ、ＮｅｔＷａｒｅなど各種の仕様が存在し、その実現のためには膨大な開発コストと品質評価コストを要する。印刷要求受信モジュール２０３はこれら複数のインタフェースごとにそれぞれ各種存在するプリントサービスプロトコルからなるマルチプロトコルをサポートしている。印刷要求受信モジュール２０３は装置の記憶装置にプリントジョブの待ち行列を構成し、いわゆるスプール機能を実装するように構成してもよい。この場合、印刷要求受信モジュール２０３は他のジョブを実行している最中のようにジョブをただちに実行できないときにもクライアントからのプリントジョブ要求を受け付けて待ち行列に格納しクライアントを解放する。待ち行列に格納されたプリントジョブはプリントジョブが実行可能となった時にスケジューリングアルゴリズムに応じて逐次処理される。

２０４は制御ＡＰＩであり、画像処理装置が提供する装置サービスにアクセスするためのアプリケーションプログラミングインタフェースである。制御ＡＰＩを構成する主要なインタフェースのひとつはプリントジョブを実行したり制御したりするためのインタフェースである。

２０５はジョブ制御モジュールである。ジョブ制御モジュールは画像処理装置が提供する各種の画像処理ジョブを制御する。主要な画像処理ジョブはプリントジョブである。ジョブ制御モジュール２０５は、制御ＡＰＩ２０４を介して実行を要求されたプリントジョブのデータストリームを解釈して、プリントジョブの記述と、プリントされるべき印刷データの記述とを分離する。プリントジョブ記述は印刷データの解釈展開系の動作パラメータを指定する環境データや、プリントアウトに利用する転写紙の給紙の指定、両面プリントなどのプリントモードの指定、排紙トレイの指定、ソート（コレート）の指定、ステイプルや製本などのフィニッシングの指定などを含む。一方、印刷データはＰＤＬによって記述されており、主にページごとの描画が記述されている。ジョブ制御モジュール２０５はプリントジョブ記述に応じてトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８を制御する。またジョブ制御モジュール２０５は、印刷データストリームがトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８の順に流れ処理されるようにスケジュールする。

２０６はトランスレータである。トランスレータはＰＤＬによって記述された印刷データを解釈して、レンダリング処理に適した印刷用中間言語の記述に変換する。レンダリング処理に適した印刷用中間言語によるプリントデータの記述をディスプレイリストと呼ぶ。トランスレータ２０６は各種のＰＤＬ仕様ごとにそれぞれ異なる固有の実装を持ち、どのトランスレータもそれぞれのＰＤＬをレンダラに固有のディスプレイリストへと変換する。

２０７はレンダラである。レンダラはディスプレイリストをラスタ画像に展開する。レンダラ２０７はＲＴＯＳ２０９を介してレンダラドライバ２１２に依存している。

２０８はマーキングエンジン（ＭＥ）制御モジュールである。ＭＥ制御モジュールは画像処理装置において転写紙への画像形成を行うマーキングエンジンを制御する。ＭＥ制御モジュールはＲＴＯＳ２０９を介してＭＥドライバ２１３に依存している。なお、マーキングエンジンは既知の印刷技術を利用するものであり、好適な実施系として例えば電子写真方式（レーザービーム方式）やインクジェット方式、昇華（熱転写）方式などが挙げられる。

２０９はリアルタイムＯＳである。リアルタイムＯＳは、画像処理装置のネイティブコードファームウェアの実行環境を提供するプラットフォームである。リアルタイムＯＳは、その上で動作するソフトウェアのために、ソフトウェア構築のために利用する基本的なサービスや装置が持つハードウェア資源を抽象化したサービスを提供し、また、装置のハードウェアをソフトウェアから利用しやすいインタフェースに抽象化するためのデバイスドライバ構築のフレームワークも提供する。ＲＴＯＳ２０９が提供する機能には、ＣＰＵによる命令実行コンテクストを抽象化したタスク管理、複数の実行コンテクストを仮想的に同時動作させ並行処理（ｃｏｎｃｕｒｒｅｎｔ ｐｒｏｃｅｓｓｉｎｇ）を実現するマルチタスク機構、タスク間でメッセージのやり取りをしたり同期をとったりするためのタスク間通信（メッセージキューやセマフォなど）、各種のメモリ管理、タイマーやクロック、割り込み管理やＤＭＡの制御などがある。

２１０はプロトコルスタックである。プロトコルスタックはＲＴＯＳ２０９のフレームワークに組み込まれ、より下層の外部インタフェースドライバ２１１が制御する外部インタフェース上にトランスポート層以下のプロトコルを実装する。たとえばネットワークインタフェースの場合、ＴＣＰ／ＩＰやＵＤＰ／ＩＰなどのプロトコルを実現し、組み込みアプリケーション層に対してはＲＴＯＳ２０９を介してバークレイソケットなどのアプリケーションプログラミングのためのインタフェースを提供する。またたとえば外部インタフェースがＵＳＢの場合には１２８４．４などのプロトコルを実現する。

２１１は外部インタフェースドライバである。ネットワークインタフェースや、ＩＥＥＥ１３９４、ＵＳＢ、ＲＳ２３２Ｃ、セントロニクスなどの各種インタフェースへの接続を提供するハードウェアを駆動する。たとえばネットワークの場合、Ｅｔｈｅｒｎｅｔ(登録商標)などのネットワークに接続するためのネットワークインタフェースハードウェアを駆動して物理層のプロトコルを実現する。

２１２はレンダラドライバであり、レンダラを駆動する。レンダラはディスプレイリストをラスタ画像に展開するためのハードウェアである。レンダラはソフトウェアによって実現してもよい。

２１３はマーキングエンジンドライバであり、転写紙への画像形成を行うマーキングエンジンを駆動する。

２１４は操作パネルドライバである。画像処理装置が備える操作パネルの表示部への出力とキーやタッチパネルなどからの入力イベントを処理する。

２１５はインタプリタ環境である。各種のインタプリタ環境、ここではＪａｖａ(登録商標)プラットフォームのランタイム環境に基づき、それに画像処理装置固有のＡＰＩ群とフレームワーク群を追加して構成されているソフトウェアプラットフォームである。このソフトウェアプラットフォームは、その上で動作するインタプリタ言語で記述されたプログラムに対して動的なソフトウェア動作環境を提供する。インタプリタ環境は、ネイティブコードによって実装された部分（２０１に含まれる）と、そのインタプリタ言語で記述されたプログラムとして実装された部分（２２０に含まれる）とを含む。

２１６はインタプリタであり、所定の命令セットによって記述された命令列から逐次的に命令を読み出し解釈し実行する。ここではインタプリタはＪａｖａ(登録商標)仮想マシンによって構成され、命令セットはＪａｖａ(登録商標)のバイトコードである。

２１７は標準のＡＰＩライブラリとフレームワーク群である。ＲＴＯＳ２０９が提供する抽象化された各種コンピューティング資源をさらにインタプリタ環境固有のモデルによって抽象化して、この上で動作するプログラムのための実行環境を提供する。ここではＪａｖａ(登録商標)プラットフォームを構成する標準的なクラスライブラリ群と、ＯＳＧｉのフレームワークによって実現している。Ｊａｖａ(登録商標)プラットフォームはＲＴＯＳ２０９相当の抽象化された機能を提供し、たとえば仮想マシンによる命令実行コンテクストを抽象化したスレッド管理、複数の実行コンテクストを仮想的に同時動作させ並行処理を実現するマルチスレッド機構、スレッド間でメッセージのやり取りをしたり同期をとったりするためのスレッド間通信、高度に抽象化された各種のメモリ管理（コレクションなど）、タイマーやクロック、例外管理、ファイルシステムやネットワークのアクセス、外部入出力装置とのインタフェースなどがある。ＯＳＧｉフレームワークは単一のＪａｖａ(登録商標)仮想マシン上に複数のＪａｖａ(登録商標)アプリケーション（サービス）を動作させる。またアプリケーションのライフサイクルの管理やアプリケーション間通信機能などを提供する。ＯＳＧｉフレームワーク上には、複数のシステムサービスがプリインストールされている。システムサービスには、インタプリタ環境に新たなアプリケーションを追加したり更新したり削除したりするためのサービス管理サービスや、Ａｐｐｌｅｔインタフェースに従って実装されたＪａｖａ(登録商標)クラスを画像処理装置の操作パネルに表示して操作パネルから操作可能に動作させるためのＡｐｐｌｅｔビューアサービスや、Ｓｅｒｖｌｅｔインタフェースに従って実装されたＪａｖａ(登録商標)クラスをクライアントのブラウザから操作可能なＷｅｂアプリケーションとして動作させるためのＨＴＴＰサービスなどが用意されている。特にＡｐｐｌｅｔインタフェースに従って実装されたＪａｖａ(登録商標)アプリケーションは、ＡＷＴのＡＰＩなどを経由して間接的に操作パネルドライバ２１４とインタフェースすることができる。

２１８はジョブ制御ライブラリである。ジョブ制御ライブラリは制御ＡＰＩ２０４に依存して、インタプリタ環境上で動作するプログラムのために、画像処理ジョブの実行や制御を可能とするアプリケーションプログラミングインタフェースを提供する。

２１９はフィルタフレームワークである。フィルタフレームワークはプリントアプリケーション２０２と通信して、プリントジョブ要求の実行に際してインタプリタ環境上に実装したフィルタプログラムからのプリントデータストリームに対する介在を可能とする。

２２０はインタプリタコード部である。この部分はインタプリタが解釈できるインタプリタ言語によって記述されたソフトウェアとして実装され、インタプリタ環境を構成するＡＰＩライブラリ群やフレームワーク群の一部とインタプリタ環境上で動作するプログラムとを含む。ネイティブコード部２０１とインタプリタコード部２２０にまたがって位置づけられるソフトウェアはそれぞれの空間の間をインタフェースするためのモジュールをインタプリタ環境が規定する固有のフレームワークとプログラミングモデルに従ってコーディングする必要がある。ここではＪａｖａ(登録商標) Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ（ＪＮＩ）に従って境界部分のプログラミングを行っている。

２２１はフィルタである。２２１はインタプリタ環境上に実装されたプログラムであり、フィルタフレームワーク２１９の枠組みに従って実装されているためプリントアプリケーション２０２が処理するプリントデータストリームに対する処理を行うことができる。

図３は画像処理装置コントローラのソフトウェアモジュール間のデータの流れを示す図である。

前述のモジュールには同一の符号をつけて説明を省略する。

印刷要求受信モジュール２０３がクライアントから受信したプリントジョブデータストリームは、フィルタを介さない場合、３０１によってジョブ制御モジュール２０５に流れる。データストリーム３０１は、たとえばＲＴＯＳ２０８が提供するメッセージキューなどのタスク間通信機能によって引き渡される。ジョブ制御モジュールはプリントジョブデータストリームを逐次的に解釈し、データストリーム中のジョブ記述の解釈を行いそれに応じて制御パス３０２によってトランスレータ２０６、レンダラ２０７、ＭＥ制御モジュール２０８の制御を行う。一方データストリーム中の印刷データは一般にＰＤＬによって記述されたページ記述のコマンドシーケンスでありこれは３０３によってトランスレータ２０６に流れる。トランスレータ２０６は印刷データの解釈を行いディスプレイリストの生成を行う。生成されたディスプレイリストは３０４によってレンダラ２０７に流れる。レンダラ２０７はディスプレイリストの展開を行いラスタ画像データの生成を行う。ラスタ画像データはページ単位に生成される場合もあれば、ページを副走査方向に複数の領域に区切ったバンド単位に生成される場合もある。生成されたラスタ画像データは３０５によってＭＥ制御モジュール２０８に流れる。ＭＥ制御モジュールはラスタ画像データをマーキングエンジンに転送し、マーキングエンジンにおいて転写紙への画像形成が行われる。以上の処理はすべてネイティブコード部分２０１で実装されている。

一方、プリントジョブデータのストリームに対するフィルタ処理を施す場合には、印刷要求受信モジュール２０３がクライアントから受信したプリントジョブデータストリームは３０６によってフィルタフレームワーク２１９に流れる。データストリーム３０６は、たとえばＲＴＯＳ２０８が提供するメッセージキューなどのタスク間通信機能によって引き渡される。フィルタフレームワークのランタイムモジュール２１９はインタプリタ環境上に実装されたフィルタプログラム群を管理している。フィルタフレームワークはプリントジョブデータストリームを３０７によってフィルタ２２１に流す。データストリーム３０７は、たとえばインタプリタ環境２１９が提供するスレッド間通信機能によって引き渡される。複数のフィルタが配置されている場合には、それぞれのフィルタ間にもデータストリームが流れ、これらはインタプリタ環境２１９が提供するスレッド間通信機能によって引き渡される。フィルタの実装２２１は入力として受け取ったデータストリームに対して所定の処理を施して出力する。フィルタ２２１が出力したデータストリームは３０８によってフィルタフレームワーク２１９に流れる。データストリーム３０８は、たとえばインタプリタ環境２１９が提供するスレッド間通信機能によって引き渡される。フィルタフレームワーク２１９はフィルタ２１１から受け取ったデータストリームを３０９によってジョブ制御モジュール２０５に流す。データストリーム３０９は、たとえばＲＴＯＳ２０８が提供するメッセージキューなどのタスク間通信機能によって引き渡される。以下はフィルタを介さない場合と同様にデータが流れる。

３１０はフィルタフレームワーク２１９の状態に応じて印刷要求受信モジュール２０３からジョブ制御モジュール２０５にいたるデータストリームを制御するための制御パスである。フィルタフレームワーク２１９が管理するフィルタが有効な状態で配置されている場合はデータストリーム３０６が有効となりフィルタによる前処理が施される。フィルタフレームワーク２１９が有効なフィルタを配置していない場合には、データストリーム３０１が有効となり、クライアントから受信したデータストリームは直接ジョブ制御モジュール２０５に流れる。この場合、フィルタフレームワーク介在のオーバヘッドを避けられるため、フィルタによるカスタマイズをまったく行わない標準状態のプリンタのデータ処理性能を発揮できる。

図４はインタプリタ環境上に構築されるフィルタフレームワークのクラス図である。

ＦｉｌｔｅｒＭａｎａｇｅｒクラス４０１はフィルタフレームワークのランタイム環境を実現するオブジェクトのクラスである。ＦｉｌｔｅｒＭａｎａｇｅｒクラス４０１はひとつのＣｏｎｎｅｃｔｏｒクラス４０５のオブジェクトをコンポジション（ｃｏｍｐｏｓｉｔｉｏｎ）として持つ。また、複数（ｎ個）のＦｉｌｔｅｒクラス４０２のオブジェクトへの参照と、複数（ｎ−１個）のＰｉｐｅクラス４０６のオブジェクトへの参照とからなる順序付けられたリストを持つ。またフィルタフレームワークランタイムにインストールされた複数のＦｉｌｔｅｒクラスの具体クラスを管理するためのｉｎｓｔａｌｌｅｄＦｉｌｔｅｒ属性を備える。

Ｆｉｌｔｅｒ抽象クラス４０２は各種のフィルタクラスを抽象化する抽象クラスである。Ｆｉｌｔｅｒ抽象クラス４０２はフィルタ名称を示すｎａｍｅ属性などを備える。また、ｉｎｐｕｔ属性としてＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承したクラスのオブジェクトへの参照を持ち、ｏｕｔｐｕｔ属性としてＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したクラスのオブジェクトへの参照を持つ。Ｆｉｌｔｅｒ抽象クラスの具体クラスたちはＲｕｎｎａｂｌｅインタフェースを実装しｒｕｎメソッドを持つ。ＦｉｌｔｅｒＭａｎａｇｅｒオブジェクトが、管理している各種のフィルタクラスのインスタンスを生成してデータストリームのフィルタ処理のために配置するとき、配置されるそれぞれのフィルタオブジェクトに対応してスレッドを生成し並行動作するスレッドの実行コンテクストでフィルタオブジェクトのｒｕｎメソッドを実行する（すなわち、コンストラクタのパラメータにフィルタオブジェクトを渡してｊａｖａ(登録商標)．ｌａｎｇ．Ｔｈｒｅａｄオブジェクトを生成し、ｓｔａｒｔする）。このようにして個々のフィルタオブジェクトは自律的に動作する。

ＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３はデータストリームの入力元の抽象クラスである。ＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３は、呼び出しのたびに逐次的にデータを読み出すことのできるｒｅａｄメソッドを備える。

ＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４はデータストリームの出力先の抽象クラスである。ＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４は、呼び出しのたびに逐次的にデータを書き込むことのできるｗｒｉｔｅメソッドを備える。

Ｃｏｎｎｅｃｔｏｒクラス４０５はインタプリタ環境のオブジェクトとネイティブコードとの間でデータストリームの交換を行うための接点を表現したオブジェクトのクラスである。Ｃｏｎｎｅｃｔｏｒクラス４０５はＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承した具体クラスであるＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍクラスのオブジェクトをコンポジションとして持ち、そのｒｅａｄメソッドによってネイティブコードの印刷要求受信モジュール２０３から流れたデータストリーム３０６を逐次的に読み出すことができる。また、Ｃｏｎｎｅｃｔｏｒクラス４０５はＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍクラスのオブジェクトもコンポジションとして持ち、そのｗｒｉｔｅメソッドによって逐次的に書き込んだデータストリームはネイティブコードのジョブ制御モジュール２０５へデータストリーム３０９として流れる。

Ｐｉｐｅクラス４０６はデータストリームに対して複数のフィルタリング処理を施す際にＦｉｌｔｅｒクラス４０２の一連のオブジェクト間を連結するために用いるオブジェクトのクラスである。Ｐｉｐｅクラス４０６はＯｕｔｐｕｔＳｔｒｅａｍ抽象クラス４０４を継承したＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍクラスとＩｎｐｕｔＳｔｒｅａｍ抽象クラス４０３を継承したＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍクラスのそれぞれのオブジェクトをコンポジションとして持つ。ＰｉｐｅオブジェクトのＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトとＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトは接続されており、スレッド間通信を実現する。すなわちあるＰｉｐｅオブジェクトに関して、あるＦｉｌｔｅｒオブジェクトがそのＰｉｐｅオブジェクトが持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへｗｒｉｔｅメソッドによって逐次的に書き込んだデータストリームは、別のＦｉｌｔｅｒオブジェクトがそのＰｉｐｅオブジェクトが持つＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトからｒｅａｄメソッドによって逐次的に読み出すことができる。

図５はインタプリタ環境上に構築されるフィルタフレームワークが管理するオブジェクトのインスタンス図である。

図５（ａ）は１つのサブフィルタが有効な状態のときフィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示している。

Ｃｏｎｎｅｃｔｏｒオブジェクト５０１はＣｏｎｎｅｃｔｏｒクラス４０５のオブジェクトである。

サブフィルタオブジェクト５０２はＦｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。サブフィルタオブジェクト５０２のｉｎｐｕｔ属性にはＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｅａｍオブジェクトの参照が保持されており、ｏｕｔｐｕｔ属性にもＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍオブジェクトの属性が保持されている。Ｆｉｌｔｅｒオブジェクトはｉｎｐｕｔの指すＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトからｒｅａｄしたデータストリームに対してフィルタ処理を施す。フィルタ処理を施したデータストリームをｏｕｔｐｕｔの指すＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへとｗｒｉｔｅする。

以上のようにして、プリントデータストリームのオブジェクト間での引き渡し（図の太い矢印）が実現される。

図５（ｂ）は２つのサブフィルタが有効な状態のときフィルタフレームワークのランタイムが管理しているオブジェクト間の関係を示している。

サブフィルタ１オブジェクト５０３はＦｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。サブフィルタ１オブジェクト５０３のｉｎｐｕｔ属性にはＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトの参照が保持されている。サブフィルタ１オブジェクト５０３はｉｎｐｕｔの指すＣｏｎｎｅｃｔｏｒＩｎｐｕｔＳｔｒｅａｍオブジェクトからｒｅａｄしたデータストリームに対してフィルタ処理を施す。サブフィルタ１オブジェクト５０３のｏｕｔｐｕｔ属性にはＰｉｐｅオブジェクト５０４が持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトの参照が保持されている。サブフィルタ１オブジェクト５０３はフィルタ処理を施したデータストリームをｏｕｔｐｕｔの指すＰｉｐｅｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトへとｗｒｉｔｅする。

Ｐｉｐｅオブジェクト５０４はＰｉｐｅクラス４０６のオブジェクトである。Ｐｉｐｅオブジェクト５０４は、ＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトとＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍオブジェクトを接続された状態で持つ。Ｐｉｐｅオブジェク５０４が持つＰｉｐｅｄＯｕｔｐｕｔＳｔｒｅａｍオブジェクトのｗｒｉｔｅメソッドの呼び出しによって引き渡されたデータストリームは、Ｐｉｐｅオブジェクト５０４が持つＰｉｐｅＩｎｐｕｔＳｔｒｅａｍオブジェクトのｒｅａｄメソッドの呼び出しによってデータストリームとして読み出すことができる。

サブフィルタ２オブジェクト５０５はＦｉｌｔｅｒ抽象クラス４０２を具体化した具体クラスのオブジェクトである。サブフィルタ２オブジェクト５０５のｉｎｐｕｔ属性にはＰｉｐｅオブジェクト５０４が持つＰｉｐｅｄＩｎｐｕｔＳｔｒｅａｍの参照が保持されている。サブフィルタ２オブジェクト５０５はｉｎｐｕｔの指すＰｉｐｅオブジェクト５０４からｒｅａｄしたデータストリームに対してフィルタ処理を施す。サブフィルタ２オブジェクト５０５のｏｕｔｐｕｔ属性にはＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍの参照が保持されている。サブフィルタ２オブジェクト５０５はフィルタ処理を施したデータストリームをｏｕｔｐｕｔの指すＣｏｎｎｅｃｔｏｒオブジェクト５０１が持つＣｏｎｎｅｃｔｏｒＯｕｔｐｕｔＳｔｒｅａｍへとｗｒｉｔｅする。

以上のようにして、プリントデータストリームのオブジェクト間での引き渡し（図の太い矢印）が実現される。また、同様にして間にＰｉｐｅオブジェクトを挟みこみながらより多くのサブフィルタオブジェクトをデータストリーム処理のために配置することもできる。

図６はフィルタフレームワークを操作するためのユーザインタフェース例を示す図である。

フィルタフレームワーク操作のためのユーザインタフェースは、標準ライブラリとフレームワーク２１７に含まれるＨＴＴＰサービスによってＷｅｂアプリケーション（Ｓｅｒｖｌｅｔ）として実装されており、クライアントで動作するＷｅｂブラウザから操作される。あるいは、Ａｐｐｌｅｔ型サービスとして実装して、画像処理装置の持つ操作パネルから操作するように構成してもよい。

図６（ａ）は画像処理装置のフィルタフレームワークに新しいサブフィルタを追加インストールするためのユーザインタフェースを示している。

６０１はサブフィルタインストール画面の例である。

６０２はファイル名入力フィールドである。ユーザはこの欄にクライアントコンピュータのファイルシステムにあらかじめ格納されているインストールしたいフィルタクラスのクラスファイルのファイルパスを入力する。

６０３は参照ボタンである。ユーザがこのボタンをクリックすると、クライアントコンピュータのＷｅｂブラウザが提供するファイル選択ダイアログが開き、クライアントコンピュータのファイルシステム内をブラウズしてインストールしたいフィルタクラスのクラスファイルを選択することができる。ファイル選択ダイアログによってユーザが選択したファイルのファイルパスは自動的にファイル名入力フィールド６０２に入力される。

６０４はインストールボタンである。ユーザがこのボタンをクリックすると、クライアントコンピュータのＷｅｂブラウザによって、６０２に入力されたファイルパスのクラスファイルが画像処理装置上で待機している新規サブフィルタインストールのためのＷｅｂアプリケーションに送信される。クラスファイルを受信したＷｅｂアプリケーションは画像処理装置の不揮発性メモリに受信したクラスファイルを格納する。また、クラスファイルをインタプリタ環境に動的にロードしてオブジェクトインスタンスを生成し、生成したサブフィルタオブジェクトをフィルタフレームワークランタイムが管理する有効サブフィルタ列のリストの最下流に配置する（もし既に有効なＦｉｌｔｅｒオブジェクトがサブフィルタ列に存在すれば、新規Ｆｉｌｔｅｒオブジェクトを連結するために新たなＰｉｐｅオブジェクトの生成も行う）。

本ユーザインタフェースをＷｅｂアプリケーションとして実装している場合、フィルタの実装クラスを装置にアップロードする機構はＲＦＣによって定められたＨＴＭＬフォームに基づくファイルアップロードの仕様を利用して実装している。したがって、この場合６０２と６０３はクライアントコンピュータのＷｅｂブラウザによって表示されており、６０４はフォームのｓｕｂｍｉｔに対応している。

また、本ユーザインタフェースをＡｐｐｌｅｔ型のサービスとして実装する場合には、６０１は画像処理装置の操作パネルの表示部に表示される。６０２に指定されるファイルは、画像処理装置がリムーバブル記憶装置を備える場合はリムーバブル記憶メディア中のファイルパスを指定してもよいし、あるいは、ネットワーク経由で画像処理装置からＨＴＴＰやＦＴＰなどのファイル転送プロトコルによって読み出しアクセス可能な共有ファイルをＵＲＬなどによって指定するように構成してもよい。

図６（ｂ）は画像処理装置のフィルタフレームワークにインストールされているサブフィルタを配置するためのユーザインタフェースを示している。

６０５はサブフィルタ配置画面の例である。

６０６はフィルタフレームワークのランタイムにインストールされているサブフィルタ群を一覧するための表である。表の各行はインストールされているサブフィルタのそれぞれに対応している。表の「選択」列にはチェックボックスが並び、チェックされた行のサブフィルタが後述する操作の対象として選択される。表の「順序」列にはサブフィルタが無効状態にある場合には「無効」の表示と、有効状態にある場合にはそのデータストリーム処理の上流から下流にむけて昇順につけられた番号が表示される。表の「名称」列にはフィルタオブジェクトのｎａｍｅ属性に記述されたサブフィルタ名称が表示される。

６０７から６１０は選択サブフィルタに対する操作を指示するためのボタンであり、表６０６の選択列がチェックされた行のサブフィルタを対象とする操作を指示する。

６０７は詳細表示ボタンである。ユーザがこのボタンをクリックすると、選択されたサブフィルタに関する詳細情報が表示される。詳細情報としては、サブフィルタの名称やバージョン、説明、クラス名、インストール元のクラスファイル名（ファイルパスやＵＲＬ）、インストールされた日時などがある。

６０８は優先ボタンである。ユーザがこのボタンをクリックすると、選択されたサブフィルタのサブフィルタ列内における優先順位を高位に変更する。この時他のフィルタが高位に設定されていた場合には、通常のレベルへ変更する。

６０９は有効／無効のトグルボタンである。ユーザがこのボタンをクリックすると、選択されたサブフィルタが有効状態にある場合は無効状態に変更し、無効状態にある場合には有効状態に変更する。無効状態にされたフィルタオブジェクトは削除されるがフィルタクラスはインストールされた状態で残りフィルタフレームワークランタイムの管理下に留まる。

６１０はアンインストールボタンである。ユーザがこのボタンをクリックすると、選択されたサブフィルタのクラスファイルを画像処理装置のインタプリタ環境から削除する。

図７は本実施例に適用可能なフィルタが行う処理を説明する図である。

７０１は機能拡張フィルタクラスのオブジェクトであり、入力ストリームを読み出して、そのデータに応じて新たな機能を付加するためのデータ変換やデータ追加などの処理を施して、出力ストリームに書き込む。機能拡張の例として、顧客システムが専用のＰＤＬドライバを抱えていてそのドライバが新しい画像処理装置の両面印刷や各種フィニッシングなどの新しい能力に未対応のときに、そのドライバを変更することなく画像処理装置側のフィルタ対応によって装置の新機能を活かす例をとりあげる。

機能拡張フィルタ７０１は、そのフィルタが稼動している画像処理装置の新しい能力を活かすための印刷ジョブ設定をその属性として持つ。フィルタオブジェクトの属性値は装置の不揮発性メモリにも保存され、装置の電源が落とされて再起動された場合であってもオブジェクトの状態は保存される。ジョブ種類属性は「印刷」「セキュアプリント」などの値をとり、画像処理装置が備える各種ジョブのタイプを表す。部数属性は印刷物のコピーを何セット生成するかを表す。ページレイアウト属性は「１ページ／枚」「２ページ／枚」「４ページ／枚」など１枚の用紙に複数ページを面付けするための指定や「ポスター（２ｘ２）」「ポスター（３ｘ３）」など１ページを拡大して複数枚の用紙に分割印刷するための指定といった、ページレイアウト指定を表す。配置順属性は、「左上から右向き」「左上から下向き」「右上から左向き」「右上から下向き」などの値をとり、ページレイアウト時の各面の配置指定を表す。印刷方法属性は「片面印刷」「両面印刷」「製本印刷」などの値をとり、印刷方法を表す。とじ方向属性は「長辺とじ（左）」「長辺とじ（右）」「短辺とじ（上）」「短辺とじ（下）」などの値をとり、フィニッシング処理において複数枚の用紙を綴じる方向を表す。排紙方法属性は「指定しない」「ソート」「ステイプル」「パンチ穴」などの値をとり、フィニッシングの方法を表す。給紙属性は「自動」「手差しトレイ」「カセット」「デッキ」あるいは「普通紙」「厚紙」「色紙」「ＯＨＰ」などの値をとり、画像形成対象とする用紙（転写紙）の給紙指定を表す。

７０２は機能拡張フィルタへの入力データストリーム例であり、その内容は旧来のアプリケーションや画像処理装置ドライバが生成する単にページごとの画像形成記述を中心とするＰＤＬやテキストからなる印刷データストリームである。

７０３は機能拡張フィルタが逐次処理を行って出力する出力データストリーム例である。入力データに存在した単純な印刷データストリームに加えて、画像処理装置の新機能を使いこなすための各種のプリントジョブ記述データが挿入されている。プリントジョブ記述は入れ子構造を表現できるようになっており、ジョブ単位、複数の文書をまとめたフィニッシングなどの処理単位、個々の文書単位のそれぞれの階層において機能拡張フィルタ７０１属性のような各種属性の指定が可能である。１行目はジョブの開始を表すデータである。２行目はジョブ単位の設定の開始を表すデータである。３行目はこの位置に各種のジョブ単位の設定データが存在することを示す。４行目は複数文書をひとまとめにする単位の開始を表すデータである。５行目は複数文書をまとめた単位に対する設定の開始を表すデータである。６行目はこの位置に複数文書をまとめた単位に対する設定データが存在することを示す。７行目は文書の開始を表すデータである。８行目は文書単位の設定の開始を表すデータである。９行目はこの位置に文書を単位とする設定データが存在することを示す。１０行目は文書記述データの開始を表すデータである。１１行目は文書そのものを表現する文書記述データがこの位置に存在し、ここでは入力データストリーム７０２に存在した印刷データストリームがこの位置に存在する。１２行目は文書の終了を表すデータである。１３行目は複数文書をまとめる単位の終了を表すデータである。１４行目はジョブの終了を表すデータである。

本実施例では、図７で示す構造を持つサブフィルタが複数インストールされた場合の画像処理装置の例について解説している。上記複数のサブフィルタに相矛盾する設定が為されている場合には、フィルタの適用順位によって結果が異なる場合がある。本発明では、図６を用いて説明したように各フィルタの優先順位を指定可能なユーザインタフェースを有しており、
図８は実施例のサブフィルタのフィルタ処理の主要な手順を示すフローチャートである。

この手順は具体的なフィルタクラスのｒｕｎメソッドとして実装されている。フィルタフレームワーク２１９は、有効なフィルタクラスのオブジェクトを生成しその入力ストリームと出力ストリームをセットアップした後に、このオブジェクトのｒｕｎメソッドを実行するためにスレッド（Ｔｈｒｅａｄオブジェクト）を割り当てる。これにより、フィルタフレームワークが管理する各フィルタオブジェクトにおいて本手順がそれぞれ自律的に並行処理で動作することになる。

ステップ８０１では、必要な前処理を行う。前処理には、フィルタが内部的に利用する属性の初期化や、パターンマッチングに使用するパターン記述に対する前処理、入力ストリームや出力ストリームをより使いやすくする機能を付け加える（たとえば入力ストリームを先読み可能にしたりシステムリソースを有効に利用するバッファリングを拡張したりする）ための修飾クラス（ｊａｖａ(登録商標)．ｉｏ．ＦｉｌｔｅｒＩｎｐｕｔＳｔｒｅａｍやｊａｖａ(登録商標)．ｉｏ．ＦｉｌｔｅｒＯｕｔｐｕｔＳｔｒｅａｍの具体クラス）によってストリームをラップする処理などが含まれる。

ステップ８０２では、ｉｎｐｕｔ属性にセットされている入力ストリームからパターンマッチング処理に必要な量のデータを読み出す。

ステップ８０３では、入力のデータストリームの中に特定の状態を示す識別記号の一つである置換禁止領域開始ＴＡＧが含まれるか否かを検出して、含まれている場合にはステップ８１１へ進む。

ステップ８０４では、入力のデータストリーム中からこのフィルタが操作するべきデータパターンの出現を発見するためにパターンマッチングを行う。フィルタが操作するべきデータパターンは固定のデータ列そのものでもよいし、正規表現（ｒｅｇｕｌａｒ ｅｘｐｒｅｓｓｉｏｎ）などの形式言語による記述でもよい。パターン記述に合致するデータの出現をデータストリーム中から発見する各種の実装が広く知られている（ｇｒｅｐ、ｓｅｄ、ＡＷＫ、Ｐｅｒｌなどが有名である）。パターンマッチングを効率よく行うためのアルゴリズムはよく研究されている。固定のパターン記述の場合には、まずパターン記述と部分データストリームのそれぞれのハッシュ関数を比較してハッシュ値が一致した場合のみ両者の完全一致を判定する方法や、Ｋｎｕｔｈ−Ｍｏｒｒｉｓ−Ｐｒａｔｔの方法や、Ｂｏｙｅｒ−Ｍｏｏｒｅの方法などが知られている。正規表現などによるパターン記述の場合も、有限オートマトンなどの形式言語理論を背景とする各種のアルゴリズムが知られている。比較的最近のＪａｖａ(登録商標)プラットフォームでは、正規表現を扱うためのクラスライブラリが標準に備わってもいる（ｊａｖａ(登録商標)．ｕｔｉｌ．ｒｅｇｅｘ）。たとえばデータストリームの上流のパターンに応じて状態が変化し変化した状態に従って下流のパターンの解釈を変えなければならない場合など、正規表現などではかえって記述が困難なほど複雑なパターンマッチングが必要とされる場合には、そのパターンの特徴そのものを評価するアルゴリズムをＪａｖａ(登録商標)プログラムとして書き下してもよい。どれほど複雑なパターンマッチングであっても素直に実装することができる。

ステップ８０５では、パターンマッチングの結果を判定しパターン記述に合致するデータをデータストリーム中に発見した場合はステップ８０６に進む。そうでなければステップ８０６に進む。

ステップ８０６では、パターン記述に合致したデータストリーム中の部分データ列に対してこのフィルタの目的に応じた操作を施しその結果で置き換える。

ステップ８０７では、このサブフィルタが優先指定されているか否かを判定して、優先指定されていればステップ８０８へ進み、そうでなければステップ８０９へ進む。

ステップ８０８では、置換後のデータの前方に置換領域開始ＴＡＧを追加し、後方に置換禁止領域終了ＴＡＧを追加する。

ステップ８０９では、処理済の部分データ列（すなわち、監視しているパターンが現れなかったデータ列、あるいは、監視しているパターンを含むデータ列に対してステップ８０８の処理を施したデータ列）を出力ストリームに書き込む。

ステップ８１０では、入力ストリームが終了したかどうかを判定し、終端を迎えた場合は終了する。そうでなければステップ８０２に戻り、上記の手順を繰り返す。

ステップ８１１では、入力ストリームから次のデータを読み出す。

ステップ８１２では、入力したデータに特定の状態を示す識別記号の一つである置換禁止領域終了ＴＡＧがあるか否かを判断する。置換禁止領域終了ＴＡＧが含まれるのであれば、ステップ８１３に進み、そうでなければステップ８１１に進む。

ステップ８１３では、入力ストリームが終了したかどうかを判定し、終端を迎えた場合は終了する。そうでなければステップ８１１に戻る。
以上が本サブフィルタの動作である。

次に、図９を用いて特定の状態を示す識別記号の一つである置換禁止領域開始ＴＡＧ及び置換禁止領域終了ＴＡＧを取り除く為の、特殊なフィルタの動作について説明する。これは通常その他の機能を持ったサブフィルタの最後に置かれる。

ステップ９０１では、前述の必要な前処理を行う。

ステップ９０２では、ｉｎｐｕｔ属性にセットされている入力ストリームから必要な量のデータを読み出す。

ステップ９０３では、入力のデータストリーム中から除去対象の識別記号の出現を発見するために前述のパターンマッチング処理を行う。

ステップ９０４では、入力のデータストリームの中に特定の状態を示す識別記号の一つである置換禁止領域開始ＴＡＧが含まれるか否かを判断して、それが含まれている場合にはステップ９０５へ進む。

ステップ９０５では、検出された識別記号を除去する。

ステップ９０６では、処理済の部分データ列（すなわち、監視しているパターンが現れなかったデータ列、あるいは、監視しているパターンを含むデータ列に対してステップ９０８の処理を施したデータ列）を出力ストリームに書き込む。

ステップ９０７では、入力ストリームが終了したかどうかを判定し、終端を迎えた場合は終了する。そうでなければステップ９０２に戻り、上記の手順を繰り返す。

画像処理装置のハードウェア構成を説明するブロック図である。 画像処理装置コントローラのソフトウェア構造を示す階層図である。 画像処理装置コントローラのソフトウェアモジュール間のデータの流れを示す図である。 インタプリタ環境上に構築されるフィルタフレームワークのクラス図である。 インタプリタ環境上に構築されるフィルタフレームワークが管理するオブジェクトのインスタンス図である。 フィルタフレームワークを操作するためのユーザインタフェース例を示す図である。 本発明に適用可能なサブフィルタの例を示す図である。 本発明に適用可能なサブフィルタの動作を示すフローチャートである。 本発明の識別記号を除去するサブフィルタの動作を示すフローチャートである。

符号の説明

１ ＣＰＵ
２ ＲＡＭ
３ ＦｌａｓｈＲＯＭ
４ システムバス
５ ＬＡＮＣ
６ ＬＥＤ
１０ 外部メモリ
１１ システムバス
１２ ラスタコントローラ
１５ ＤＫＣ
１６ マーキングエンジン
１８ 操作パネル
１０００ プリンタ
１６００ プリンタコントローラ
２０００ ＬＡＮ

Claims (10)

1. 物理的なプロセッサによって処理されるネイティブ命令に基づいて構築されたファームウェアであるネイティブ環境中にあって前記ネイティブ命令とは独立に定義された命令セットに基づいて構築されたプログラムを動的にロードしてリンクして実行するインタプリタ環境を内蔵し、
   前記ネイティブ環境中にあって、クライアントからの印刷要求データストリームを受信する印刷要求データストリーム受信手段と、
   前記ネイティブ環境中にあって、前記印刷要求データストリームを解釈し画像形成を行うジョブを制御する印刷ジョブ制御手段と、
   前記インタプリタ環境上のプログラムであって、前記印刷要求データストリームをデータ処理して処理済の印刷要求データストリームを生成するフィルタ手段と、
   前記印刷要求データストリーム受信手段が受信した前記印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェース手段と、
   前記フィルタ手段が処理した前記処理済のデータストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェース手段とから構成されることを特徴とする画像処理装置において、
   前記フィルタ手段が互いに別の機能を持つ第１から第Ｎのサブフィルタにより構成され、
   前記第一から第Ｎに含まれる第ｎのサブフィルタ手段が、第２ｎ−１の文字列を第２ｎの文字列に変換する第ｎの文字列変換手段を有し、
   前記第一から第Ｎに含まれる前記第ｎの文字列を識別する文字列識別記号を挿入する第ｎの文字列識別記号挿入手段と、
   前記第一から第Ｎに含まれる第ｍのサブフィルタ手段が、前記文字列識別記号を判定する第ｍの文字列識別記号判定手段と、
   前記第ｍの文字列識別記号判定手段の結果に基づいて、第ｍのサブフィルタ手段の文字列変換手段を禁止する第ｍの文字列変換禁止手段と、
   前記第一から第Ｎに含まれる第ｐのサブフィルタ手段が、前記文字列識別記号を除去する文字列識別記号除去手段を有することを特徴とする画像処理装置。
2. 前記印刷要求データストリーム受信手段が受信した印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第３のインタフェース手段から構成されることを特徴とする請求項１に記載の画像処理装置。
3. 前記第１から第Ｎのサブフィルタ手段のデータ処理は、
   前記データストリーム中に現れる特定データパターンを発見するパターンマッチングと、
   パターンにマッチした部分データストリームに対応する新たな部分データストリームを生成し置換する処理を含むことを特徴とする請求項１に記載の画像処理装置。
4. 前記インタプリタ環境は、その上で動作するプログラムをユーザが操作するためのユーザインタフェース構築手段を備え、
   前記第１から第Ｎのサブフィルタ手段はそのデータ処理の処理パラメータを操作するために前記ユーザインタフェース構築手段によって構築されたユーザインタフェースを備えることを特徴とする請求項１に記載の画像処理装置。
5. 前記インタプリタ環境はその上で動作するプログラムのために命令の読み出し解釈実行をそれぞれ並行して処理するスレッド機構を提供し、
   前記フィルタ手段は前記インタプリタ環境が提供するスレッド機構による独立した実行コンテクストの下で自律的にそのデータ処理を実行することを特徴とする請求項１に記載の画像処理装置。
6. 前記インタプリタ環境はＪａｖａ(登録商標)プラットフォームに基づくことを特徴とする請求項１に記載の画像処理装置。
7. クライアントからの印刷要求データストリームを受信する印刷要求データストリーム受信手段と、
   前記印刷要求データストリームを解釈し画像形成を行うジョブを制御する印刷ジョブ制御手段と、
   前記印刷要求データストリームをデータ処理して処理済の印刷要求データストリームを生成するフィルタ手段と、
   前記印刷要求データストリーム受信手段が受信した前記印刷要求データストリームを前記フィルタ手段に引き渡す第１のインタフェース手段と、
   前記フィルタ手段が処理した前記処理済のデータストリームを前記印刷ジョブ制御手段に引き渡す第２のインタフェース手段と、
   ０個以上の前記第一から第Ｎのサブフィルタ手段を管理して、０個以上の前記第一から第Ｎのサブフィルタ手段を前記データストリームのデータパス中に配置し、配置された前記第一から第Ｎのサブフィルタ手段が逐次的に前記データストリームを処理するように制御するサブフィルタ管理手段とから構成されることを特徴とする画像処理装置。
8. 前記サブフィルタ管理手段に管理している０個以上の前記第一から第Ｎのサブフィルタ手段の中から０個以上のサブフィルタ手段を選択的に配置させる操作を行うサブフィルタ配置操作手段から構成されることを特徴とする請求項７に記載の画像処理装置。
9. 前記印刷要求データストリーム受信手段が受信した印刷要求データストリームを前記印刷ジョブ制御手段に引き渡す第３のインタフェース手段から構成され、
   前記サブフィルタ管理手段が前記サブフィルタを１つも配置していない場合には前記第３のインタフェース手段によって前記印刷要求データストリーム受信手段が受信した印刷要求データストリームが前記印刷ジョブ制御手段に直接引き渡されることを特徴とする請求項７に記載の画像処理装置。
10. 前記サブフィルタ手段を外部から装置内に導入して前記サブフィルタ管理手段の管理下に置くためのサブフィルタ導入手段から構成されることを特徴とする請求項７に記載の画像処理装置。

Images