JP5790143B2 - 情報処理装置及びプログラム - Google Patents

Description

本発明は、プリンタに印刷要求を行う情報処理装置及びプログラムに関する。

Ｗｉｎｄｏｗｓ（登録商標）の印刷システムでは、ランゲージモニタと呼ばれるプログラムモジュールが利用される。ランゲージモニタは、印刷データがスプールされるスプーラと、印刷データをプリンタに送信するポートモニタとの間に位置する。すなわち、スプーラにスプールされた印刷データは、ランゲージモニタに入力される。ランゲージモニタは、入力された印刷データに関して処理を実行し、当該印刷データをポートモニタに出力する。

ランゲージモニタは、例えば、プリンタのベンダ等が自由に実装することができる。すなわち、スプーラにスプールされた印刷データがポートモニタによって送信されるまでの間において、印刷データの加工、ログの記録、プリンタとの双方向の通信等、独自の実装を行うことができる。したがって、新たな機能が実装されたランゲージモニタをインストールすることにより、印刷システムの機能拡張を比較的容易に図ることができる。

しかしながら、ランゲージモニタは、スプーラのプロセスの起動時にロードされ、終了時にアンロードされるＤＬＬ（Dynamic Link Library）である。すなわち、スプーラのプロセスが停止されない限り、ランゲージモニタは、ＯＳ（Operating System）の起動直後からシャットダウンまでの間ロードされたままとなる。したがって、新たな機能が実装された新しいランゲージモニタをインストールし、当該ランゲージモニタの機能を有効とするためには、当該ランゲージモニタのインストール後に、スプーラのプロセスを再起動しなければならないという問題があった。

スプーラの再起動が実行されると、スプーラに蓄積されていた印刷データが破棄されてしまう可能性がある。特に、多数のクライアントＰＣからの印刷データを処理するプリントサーバのスプーラに蓄積されていた印刷データの破棄は、多数のユーザに影響が及ぶ。このような理由等から、ランゲージモニタを利用したプリンタドライバの導入（すなわち、係るプリンタドライバが対応するプリンタの導入）が敬遠されかねない。

本発明は、上記の点に鑑みてなされたものであって、スプーラの再起動を回避しつつランゲージモニタの更新を有効化することのできる情報処理装置及びプログラムの提供を目的とする。

そこで上記課題を解決するため、情報処理装置は、所定の関数インタフェースを介してスプーラからの印刷データに関する要求を受け付ける要求受付手段と、前記要求に応じた処理を実行する少なくとも１つの処理実行手段と、前記要求受付手段は、前記要求を受け付ける際に、前記処理実行手段に対して当該受け付けた要求に応じた処理を実行させる。

本発明によれば、スプーラの再起動を回避しつつランゲージモニタの更新を有効化することができる。

第一の実施の形態における印刷システムの構成例を示す図である。 第一の実施の形態における情報処理装置のハードウェア構成例を示す図である。 第一の実施の形態における情報処理装置のソフトウェア構成例を示す図である。 情報処理装置の起動時に実行される処理手順の一例を説明するためのシーケンス図である。 ＯｐｅｎＰｏｒｔＥｘ（）の呼び出しに応じてランゲージモニタインタフェースが実行する処理の処理手順の一例を説明するためのフローチャートである。 第一の実施の形態においてスプーラからの関数呼び出しに応じてランゲージモニタ等が実行する処理手順の一例を説明するためのシーケンス図である。 第一の実施の形態のフィルタ構成情報の管理形態及びフィルタ構成情報の一例を示す図である。 第一の実施の形態においてフィルタリストの取得要求に応じてフィルタマネージャが実行する処理手順の一例を説明するためのフローチャートである。 第二の実施の形態においてフィルタリストの取得要求に応じてフィルタマネージャが実行する処理手順の一例を説明するためのフローチャートである。 第二の実施の形態のフィルタ構成情報の一例を示す図である。 第二の実施の形態においてスプーラからの関数呼び出しに応じてランゲージモニタ等が実行する処理手順の一例を説明するためのシーケンス図である。 フィルタの有効性を設定させる画面の一例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態における印刷システムの構成例を示す図である。同図において、一以上の情報処理装置１０と一以上のプリンタ２０とは、ＬＡＮ（Local Area Network）等のネットワーク３０（有線又は無線の別は問わない。）を介して通信可能に接続されている。

プリンタ２０は、いわゆるプリンタである。本実施の形態において、プリンタ２０は、情報処理装置１０より転送される印刷データに関して印刷を行う。なお、複合機のように、プリンタ以外の機能を有する機器がプリンタ２０として用いられてもよい。

情報処理装置１０は、プリンタ２０に対して印刷データを転送する（印刷要求を行う）コンピュータである。情報処理装置１０は、ユーザごとに設置され、ユーザによって直接操作されるＰＣ（Personal Computer）であってもよいし、プリントサーバとして機能するコンピュータであってもよい。本実施の形態では、ユーザによって直接操作されるＰＣであるとする。

図２は、第一の実施の形態における情報処理装置のハードウェア構成例を示す図である。図２の情報処理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

情報処理装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って情報処理装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。

図３は、第一の実施の形態における情報処理装置のソフトウェア構成例を示す図である。同図において、情報処理装置１０は、アプリケーション１１、ＧＤＩ１２、プリンタドライバ１３、スプーラ１４、ランゲージモニタ１５、フィルタ構成情報記憶部１６、及びポートモニタ１７等を有する。アプリケーション１１、ＧＤＩ１２、一以上のプリンタドライバ１３、スプーラ１４、ランゲージモニタ１５、及びポートモニタ１７は、それぞれに実装された処理をＣＰＵ１０４に実行させることにより、それぞれの機能を実現する。

アプリケーション１１は、例えば、ユーザによる対話的な操作に応じ、印刷対象とされる文書データを生成するプログラムである。ＧＤＩ１２は、いわゆるＧＤＩ（Graphic Device Interface）であり、非図示のＯＳ（例えば、Ｗｉｎｄｏｗｓ（登録商標））によって提供されるグラフィック関数の集合である。アプリケーション１１は、印刷指示の入力に応じ、ＧＤＩ１２を介して、プリンタドライバ１３への印刷要求を入力する。例えば、ＧＤＩ１２は、プリンタドライバ１３が備えるＤＤＩ（Device Driver Interface）と呼ばれるインタフェースを介して、アプリケーション１１からの印刷要求に応じたコマンドをプリンタドライバ１３に入力する。

プリンタドライバ１３は、ＵＩドライバ１３１、グラフィックドライバ１３２等を含む。これら各構成要素は、例えば、それぞれが独立したプログラムモジュール（例えば、ＤＬＬ（Dynamic Link Library））であってもよい。

ＵＩドライバ１３１は、印刷設定情報（印刷条件又は印刷属性等とも呼ばれる）を設定させるための画面等を表示装置１０６に表示させ、印刷設定情報の設定を受け付ける。

グラフィックドライバ１３２は、ＤＤＩを介して入力されるコマンド及びＵＩドライバ１３１が受け付けた印刷設定情報に応じた印刷データ（ＲＡＷデータ）を生成する。グラフィックドライバ１３２によって生成された印刷データは、スプーラ１４に入力される。

本実施の形態のプリンタドライバ１３は、更に、一以上のフィルタ１３３を含む。一つのフィルタ１３３は、ＤＬＬ等、動的にロード及びアンロードが可能であって、かつ、動的にリンク可能なプログラムモジュールである。フィルタ１３３には、ランゲージモニタ１５に実行させたい処理が実装される。すなわち、本実施の形態において、ランゲージモニタ１５に実行させたい処理の実体は、フィルタ１３３に実装される。具体的には、フィルタ１３３は、ランゲージモニタ１５としての関数インタフェース（ＡＰＩ（Application Program Interface））と同様の関数インタフェースを一以上有し、当該関数インタフェースに対する実装を有する。

スプーラ１４は、それ自体が一つのプロセスとして起動されるプログラムである。スプーラ１４は、グラフィックドライバ１３２によって生成された印刷データを、補助記憶装置１０２を用いて一時的に保持する。その後、スプーラ１４は、印刷データをランゲージモニタ１５に入力する。

ランゲージモニタ１５は、スプーラ１４から利用されるＤＬＬであり、スプーラ１４の起動時にロードされる。本実施の形態のランゲージモニタ１５は、ランゲージモニタインタフェース１５１及びフィルタマネージャ１５２等を含む。ランゲージモニタインタフェース１５１は、ランゲージモニタとしての関数インタフェースを有し、当該関数インタフェースを介してスプーラ１４からの要求を受け付ける。但し、ランゲージモニタインタフェース１５１自体は、当該要求に応じた処理は実行せずに、当該処理の実行をフィルタ１３３に委譲する。

フィルタマネージャ１５２は、フィルタ構成情報記憶部１６を参照して、スプーラ１４から要求された処理の委譲先とするフィルタ１３３を判定する。フィルタマネージャ１５２は、また、処理の委譲先として判定されたフィルタ１３３について、メモリ装置１０３へのロード及びアンロードを実行する。

フィルタ構成情報記憶部１６は、関数インタフェースの関数名と、当該関数インタフェースに対する実装を有するフィルタ１３３との対応情報（以下、「フィルタ構成情報」という。）を記憶する。なお、フィルタ構成情報記憶部１６は、補助記憶装置１０２を用いて実現可能である。例えば、Ｗｉｎｄｏｗｓ（登録商標）において、各種の設定情報を保持するために利用されるレジストリ内にフィルタ構成情報が記録されてもよい。

ポートモニタ１７は、ランゲージモニタ１５（実際には、フィルタ１３３）によって処理された印刷データをプリンタ２０に送信する。

以下、情報処理装置１０の処理手順について説明する。図４は、情報処理装置の起動時に実行される処理手順の一例を説明するためのシーケンス図である。

ステップＳ１０１において、スプーラ１４は、ＯＳよりプロセスとして起動されると、ランゲージモニタインタフェース１５１が有する関数の一つであるＯｐｅｎＰｏｒｔＥｘ（）を呼び出す（Ｓ１０２）。ＯｐｅｎＰｏｒｔＥｘ（）は、スプーラ１４が起動時に呼び出すことになっている関数である。スプーラ１４は、情報処理装置１０において設定されている論理プリンタごとに当該論理プリンタの論理プリンタ名を引数に指定して、ＯｐｅｎＰｏｒｔＥｘ（）を呼び出す。なお、ランゲージモニタ１５は、スプーラ１４の起動に伴ってロードされ、利用可能（呼び出し可能）な状態となる。

情報処理装置１０の起動時以外において、例えば、論理プリンタが新たに追加された場合にも、スプーラ１４は、ランゲージモニタインタフェース１５１のＯｐｅｎＰｏｒｔＥｘ（）を呼び出す。この際、新たに追加された論理プリンタの論理プリンタ名が、ＯｐｅｎＰｏｒｔＥｘ（）の引数に指定される。

続いて、ＯｐｅｎＰｏｒｔＥｘ（）の呼び出しに応じてランゲージモニタインタフェース１５１が実行する処理（すなわち、ＯｐｅｎＰｏｒｔＥｘ（）に関してランゲージモニタインタフェース１５１に実装されている処理）の処理手順の一例について説明する。

図５は、ＯｐｅｎＰｏｒｔＥｘ（）の呼び出しに応じてランゲージモニタインタフェースが実行する処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ１１１において、ランゲージモニタインタフェース１５１は、論理プリンタ名を格納するための項目（メンバ変数）を有する構造体をメモリ装置１０３（ヒープ領域）に生成する。続いて、ランゲージモニタインタフェース１５１は、ＯｐｅｎＰｏｒｔＥｘ（）の引数に指定されている論理プリンタ名を、当該構造体において論理プリンタ名を格納するためのメンバ変数にコピーする（Ｓ１０２）。続いて、ランゲージモニタインタフェース１５１は、当該構造体の先頭のアドレス値を、ハンドル（識別子）としてスプーラ１４に返却する（Ｓ１０３）。以後、スプーラ１４からのランゲージモニタインタフェース１５１の関数の呼び出し時には、当該ハンドルが論理プリンタの識別子として指定される。

続いて、図４及び図５の初期化処理が行われた後に、スプーラ１４からの関数インタフェースの呼び出しに応じてランゲージモニタ１５等が実行する処理手順の一例について説明する。

図６は、第一の実施の形態においてスプーラからの関数呼び出しに応じてランゲージモニタ等が実行する処理手順の一例を説明するためのシーケンス図である。

ステップＳ２０１において、スプーラ１４は、ランゲージモニタインタフェース１５１の或る関数を呼び出す。同図では、ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ（）が呼び出された例が示されている。なお、当該関数の引数には、図５のステップＳ１１３においてスプーラ１４に対して返却されているハンドルが指定される。当該ハンドルは、論理プリンタごとに返却されている。したがって、スプーラ１４は、印刷ジョブの対象となっている論理プリンタに対応するハンドルを引数に指定する。

続いて、ランゲージモニタインタフェース１５１は、呼び出された関数（以下、「呼び出し関数」という。）の関数名（「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」）を示す文字列を指定して、フィルタマネージャ１５２に対してフィルタリストの取得要求を行う（Ｓ２０２）。フィルタリストとは、各フィルタ１３３における、呼び出し関数のアドレスの一覧情報をいう。

当該取得要求には、スプーラ１４から指定された引数がそのまま指定される。また、当該取得要求には、論理プリンタ名も引数として指定される。すなわち、ランゲージモニタインタフェース１５１は、ステップＳ２０１において指定されたハンドルに対応する構造体より論理プリンタ名を取得し、当該論理プリンタ名を当該取得要求に指定する。なお、ハンドルに対応する構造体とは、ハンドルが示すアドレスを先頭アドレスとする構造体をいう。

当該取得要求に応じ、フィルタマネージャ１５２は、フィルタ構成情報記憶部１６が記憶するフィルタ構成情報を読み込み、呼び出し関数の実装を有するフィルタ１３３を判定する（Ｓ２０３）。

図７は、第一の実施の形態のフィルタ構成情報の管理形態及びフィルタ構成情報の一例を示す図である。同図において、フィルタ構成情報は、論理プリンタごとに管理されている。具体的には、各フィルタ構成情報は、論理プリンタ名に関連付けられて管理されている。例えば、フィルタ構成情報がレジストリ内に管理される場合、論理プリンタ毎に生成されるレジストリキーの下のＰｒｉｎｔｅｒＤｒｉｖｅｒＤａｔａキーに対するデータとして、フィルタ構成情報が記録されてもよい。フィルタ構成情報は、論理プリンタの生成時等に、例えば、ＵＩドライバ１３１が記録する。

同図において、フィルタ構成情報Ｄ１ａは、論理プリンタＡ用のフィルタ構成情報である。フィルタ構成情報Ｄ１ａは、ＪＳＯＮ（JavaScript Object Notation）に準拠した形式で記述されているが、ＸＭＬ（eXtensible Markup Language）形式等、他の形式によって記述されてもよい。

フィルタ構成情報Ｄ１ａの定義５１及び定義５２は、論理プリンタＡに対応する各フィルタ１３３に関する定義である。すなわち、フィルタ構成情報Ｄ１ａには、二つのフィルタ１３３に関する定義が含まれている。当該定義の数は、論理プリンタＡに対応するフィルタ１３３の数に依存する。

定義５１内の記述５１１において、「"ｆｉｌｔｅｒ"＝」に続く文字列「ｄｒｖ１ｌｏｇ．ｄｌｌ」は、定義５１に対応するフィルタ１３３のパス名を示す。本実施の形態では、プリンタドライバ１３のインストールフォルダからの相対パスであるとする。

また、記述５１２において、「"ｅｘｐｏｒｔｓ"＝」に続く括弧内に列挙されている文字列は、当該フィルタ１３３に実装されており、エクスポートされている関数（エクスポート関数）の関数名を示す。エクスポートとは、ＤＬＬの外部から呼び出し可能な状態とされていることをいう。

定義５２においても、同様の形式によって、もう一つのフィルタ１３３のパス名及び実装されている関数名等が記述されている。

上記したステップＳ２０３において、指定された論理プリンタ名に係る論理プリンタが論理プリンタＡであるとする。この場合、フィルタマネージャ１５２は、「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」が実装されているフィルタ１３３のパス名を、フィルタ構成情報Ｄ１ａの定義５１及び定義５２を参照して特定する。ここでは、定義５１内に、「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」が含まれている。したがって、「ｄｒｖ１ｌｏｇ．ｄｌｌ」のパス名が特定される。

続いて、フィルタマネージャ１５２は、ステップＳ２０３においてそのパス名が特定されたフィルタ１３３（ｄｒｖ１ｌｏｇ．ｄｌｌ）をロードし、ロードされたフィルタ１３３内における、呼び出し関数「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」のアドレスを取得する（Ｓ２０４）。続いて、フィルタマネージャ１５２は、取得されたアドレスの一覧を、フィルタリストとしてランゲージモニタインタフェース１５１に返却する（Ｓ２０５）。但し、ここでは、呼び出し関数が実装されているフィルタ１３３は一つであるため、フィルタリストに含まれるアドレスは一つである。

続いて、ランゲージモニタインタフェース１５１は、返却されたフィルタリストに含まれているアドレスに基づいて、呼び出し関数を呼び出す（Ｓ２０６）。その結果、ｄｒｖ１ｌｏｇ．ｄｌｌ内の関数「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」が呼び出される。すなわち、関数「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」の処理の実行がｄｒｖ１ｌｏｇ．ｄｌｌに委譲される。ｄｒｖ１ｌｏｇ．ｄｌｌは、呼び出しに応じ、関数「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」に実装されている処理を実行する。

続いて、ランゲージモニタインタフェース１５１は、フィルタマネージャ１５２に対してフィルタ１３３の解放要求を行う（Ｓ２０７）。フィルタマネージャ１５２は、フィルタ１３３の解放要求に応じ、ステップＳ２０４においてロードされたフィルタ１３３（ｄｒｖ１ｌｏｇ．ｄｌｌ）をアンロード（解放）する（Ｓ２０８）。

なお、ＤＬＬの動的なロード又はアンロード、及びＤＬＬ内の関数のアドレスの取得等は、例えば、Ｗｉｎｄｏｗｓ（登録商標）ＡＰＩを用いて行うことができる。

ステップＳ２１１以降は、スプーラ１４が、ランゲージモニタインタフェース１５１のＷｒｉｔｅＰｏｒｔ（）という関数を呼び出した場合に実行される処理手順が示されている。当該関数の引数には、図５のステップＳ１１３においてスプーラ１４に対して返却されているハンドルが指定される。

この場合、ランゲージモニタインタフェース１５１は、呼び出し関数の関数名（「ＷｒｉｔｅＰｏｒｔ」）を示す文字列を指定して、フィルタマネージャ１５２に対してフィルタリストの取得要求を行う（Ｓ２１２）。当該取得要求には、スプーラ１４から指定された引数がそのまま指定される。また、当該取得要求には、ハンドルに対応する論理プリンタ名も引数として指定される。

続いて、フィルタマネージャ１５２は、指定された論理プリンタ名に対応するフィルタ構成情報Ｄ１ａを読み込み、呼び出し関数の実装を有するフィルタ１３３を判定する（Ｓ２１３）。ここで、フィルタ構成情報Ｄ１ａ（図７参照）において、「ＷｒｉｔｅＰｏｒｔ」が実装されているフィルタ１３３は、「ｄｒｖ１ｌｏｇ．ｄｌｌ」と「ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ」との二つである。そこで、フィルタマネージャ１５２は、「ｄｒｖ１ｌｏｇ．ｄｌｌ」及び「ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ」をロードし（Ｓ２１４ａ、Ｓ２１４ｂ）、ロードされた各フィルタ１３３における、呼び出し関数「ＷｒｉｔｅＰｏｒｔ」のアドレスを取得する。したがって、ここでは、二つのアドレスが取得される。

続いて、フィルタマネージャ１５２は、取得されたアドレスの一覧を、フィルタリストとしてランゲージモニタインタフェース１５１に返却する（Ｓ２１５）。なお、フィルタリストは、フィルタ構成情報Ｄ１ａにおける定義順が識別可能なように構成される。例えば、「ｄｒｖ１ｌｏｇ．ｄｌｌ」における「ＷｒｉｔｅＰｏｒｔ」のアドレスが先で、「ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ」内の「ＷｒｉｔｅＰｏｒｔ」のアドレスが後となるように、フィルタリストに含められる。

続いて、ランゲージモニタインタフェース１５１は、返却されたフィルタリストに含まれている順に、各アドレスに基づいて、呼び出し関数を呼び出す（Ｓ２１６ａ、Ｓ２１６ｂ）。したがって、ｄｒｖ１ｌｏｇ．ｄｌｌ内の関数「ＷｒｉｔｅＰｏｒｔ」が呼び出され、続いて、ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ内の関数「ＷｒｉｔｅＰｏｒｔ」が呼び出される。

このように、複数のフィルタ１３３に同一の関数が実装されている場合、各フィルタ１３３の関数は、フィルタ構成情報の定義順に呼び出される。フィルタ構成情報の定義順に呼び出されるのは、呼び出し順によって処理結果が変わる可能性があるからである。換言すれば、フィルタ構成情報には、所望の結果を得るための順番で、各フィルタ１３３の定義が記述される。

なお、同一の関数であっても、各フィルタ１３３における実装内容は異なりうる。例えば、ｄｒｖ１ｌｏｇ．ｄｌｌ内の関数「ＷｒｉｔｅＰｏｒｔ」には、「ＷｒｉｔｅＰｏｒｔ」が呼び出されたことのログ情報の記録処理が実装されており、ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ内の関数「ＷｒｉｔｅＰｏｒｔ」には、印刷データの圧縮処理が実装されているといった具合である。斯かる点において、同一の関数に関して各フィルタ１３３の実装を呼び出す意義が認められる。

続いて、ランゲージモニタインタフェース１５１は、フィルタマネージャ１５２に対してフィルタ１３３の解放要求を行う（Ｓ２１７）。フィルタマネージャ１５２は、フィルタ１３３の解放要求に応じ、ステップＳ２１４ａ又はＳ２１４ｂおいてロードされたフィルタ１３３（ｄｒｖ１ｌｏｇ．ｄｌｌ、ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ）をアンロード（解放）する（Ｓ２１８ａ、Ｓ２１８ｂ）。

続いて、ステップＳ２０２又はステップＳ２１２等のフィルタリストの取得要求に応じて、フィルタマネージャ１５２が実行する処理の詳細について説明する。

図８は、第一の実施の形態においてフィルタリストの取得要求に応じてフィルタマネージャが実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ２５１において、フィルタマネージャ１５２は、フィルタリストの取得要求に指定された論理プリンタ名に関連付けられているフィルタ構成情報を読み込む。例えば、フィルタ構成情報記憶部１６としてレジストリが用いられている場合、フィルタマネージャ１５２は、当該論理プリンタ名を指定して、ＯｐｅｎＰｒｉｎｔｅｒ（）を呼び出して、当該論理プリンタのハンドルを取得する。続いて、当該ハンドルと、レジストリ内におけるフィルタ構成情報に対応するキーの名前とを指定してＧｅｔＰｒｉｎｔｅｒＤａｔａ（）を呼び出すことで、当該論理プリンタのフィルタ構成情報を取得することができる。

続いて、フィルタマネージャ１５２は、読み込まれたフィルタ構成情報をパース（解読）して、フィルタ１３３ごとに、パス名とエクスポート関数名の一覧を取得する（Ｓ２５２）。続いて、ステップＳ２５２において取得された情報より、フィルタマネージャ１５２は、呼び出し関数の関数名（フィルタリストの取得要求に指定された関数名）をエクスポート関数名として含むフィルタ１３３のパス名を抽出（リストアップ）する（Ｓ２５３）。

続いて、フィルタマネージャ１５２は、抽出されたパス名に係るフィルタ１３３をロードし、ロードされたフィルタ１３３における、呼び出し関数のアドレスを取得する（Ｓ２５４）。

続いて、フィルタマネージャ１５２は、アドレスの一覧をフィルタリストとしてランゲージモニタインタフェース１５１に返却する（Ｓ２５５）。この際、アドレスの順序は、フィルタ構成情報の定義順に従う。

上述したように、第一の実施の形態によれば、スプーラ１４よりロードされるランゲーモニタ１５は関数インタフェースに応じた処理は実行せず、ランゲージモニタ１５からロード及びアンロードされるフィルタ１３３によって当該処理の実行が代行される。したがって、フィルタ１３３を置き換えることにより、ランゲージモニタ１５の機能を変更することができる。そして、フィルタ１３３は、ランゲージモニタ１５が、スプーラ１４より関数呼び出しを受けるたびに動的にロード及びアンロードされる。したがって、フィルタ１３３が置き換えられたとしても、スプーラ１４を再起動せずに、置き換えられたフィルタ１３３を有効とすることができる。

また、処理の委譲先となるフィルタ１３３は、フィルタ構成情報に基づいて特定される。したがって、フィルタ構成情報を編集することにより、処理の委譲先とするフィルタ１３３を容易に変更することができる。

更に、第一の実施の形態では、同一の関数に対して複数のフィルタ１３３を対応付けることができる。すなわち、同一の関数に応じた処理を複数のフィルタ１３３に実行させることができる。したがって、フィルタ１３３を効果的に部品化することにより、フィルタ１３３の組み合わせによって多様な機能を効率的に実現することができる。

次に、第二の実施の形態について説明する。第二の実施の形態では、第一の実施の形態と異なる点について説明する。したがって、特に言及しない点については、第一の実施の形態と同様でよい。

図９は、第二の実施の形態においてフィルタリストの取得要求に応じてフィルタマネージャが実行する処理手順の一例を説明するためのフローチャートである。図９中、図８と同一ステップには、同一ステップ番号を付し、その説明は省略する。

図９では、ステップＳ２５１がステップＳ２５１ａに置き換わっている。第二の実施の形態では、読み込まれるフィルタ構成情報の形式の一部が第一の実施の形態と異なるからである。

図１０は、第二の実施の形態のフィルタ構成情報の一例を示す図である。図１０中、図７のフィルタ構成情報Ｄ１ａと同一部分に同一符号を付し、その説明は省略する。

図１０のフィルタ構成情報Ｄ２ａには、フィルタ１３３ごとに、「"ａｃｔｉｖｅ"＝」で始まる記述が追加されている。すなわち、定義５１には、記述５１３が追加されている。定義５２には、記述５２１が追加されている。

「"ａｃｔｉｖｅ"＝」で始まる記述は、それに続く値が、「ｔｒｕｅ」であれば、当該フィルタ１３３が有効であることを示し、「ｆａｌｓｅ」であれば、当該フィルタ１３３が無効であることを示す。すなわち、当該記述は、フィルタ１３３の有効性を示す情報の一例である。フィルタ構成情報Ｄ２ａでは、「ｄｒｖ１ｌｏｇ．ｄｌｌ」は有効であり、「ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ」は無効であることが定義されている。なお、フィルタ１３３が有効であるとは、当該フィルタ１３３が利用対象とされていることを意味する。フィルタ１３３が無効であるとは、当該フィルタ１３３が利用対象とされていないことを意味する。

そこで、図９のステップＳ２５３ａにおいて、フィルタマネージャ１５２は、有効なフィルタ１３３であって、かつ、呼び出し関数の関数名（フィルタリストの取得要求に関数名が指定された関数）をエクスポート関数名として含むフィルタ１３３のパス名を抽出する。

ステップＳ２５４以降は、第一の実施の形態で説明した通りである。

フィルタマネージャ１５２の振る舞いが図９に示されるように変わることにより、第一の実施の形態における図６の処理手順は、第二の実施の形態において図１１に示されるように変化する。

図１１は、第二の実施の形態においてスプーラからの関数呼び出しに応じてランゲージモニタ等が実行する処理手順の一例を説明するためのシーケンス図である。図１１中、図６と同一ステップには、同一ステップ番号を付し、その説明は省略する。

図１１において、スプーラ１４より呼び出された関数が「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」である場合の処理手順（Ｓ２０１〜Ｓ２０８）は、第一の実施の形態と同様である。「ＳｅｎｄＲｅｃｖＢｉｄｉＤａｔａＦｒｏｍＰｏｒｔ」は、ｄｒｖ１ｌｏｇ．ｄｌｌにしか実装されておらず、第二の実施の形態において、ｄｒｖ１ｌｏｇ．ｄｌｌは、有効なフィルタ１３３だからである。

一方、スプーラ１４より呼び出された関数が「ＷｒｉｔｅＰｏｒｔ」である場合、ステップＳ２１４ｂ、ステップＳ２１６ｂ、及びステップＳ２１８ｂは、実行されない。すなわち、ステップＳ２１４ｂ、ステップＳ２１６ｂ、及びステップＳ２１８ｂは、ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌに関するステップである。また、ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌは、第二の実施の形態において無効なフィルタ１３３である。したがって、ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌの「ＷｒｉｔｅＰｏｒｔ」のアドレスは、フィルタリストに含まれないからである。

なお、各フィルタ１３３の有効性は、ＵＩドライバ１３１が表示させる画面を介して設定可能としてもよい。

図１２は、フィルタの有効性を設定させる画面の一例を示す図である。同図に示される画面６１０は、ＵＩドライバ１３１が表示させる、論理プリンタＡのプロパティ画面の一つのタブが選択された状態を示す。

画面６１０には、チェックボタン６１１及び６１２が配置されている。チェックボタン６１１は、「ｄｒｖ１ｌｏｇ．ｄｌｌ」の有効性を設定させるためのチェックボタンである。チェックボタン６１２は、「ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ」の有効性を設定させるためのチェックボタンである。

チェックボタン６１１又は６１２のチェック状態が更新され、ＯＫボタン６１３が押下されると、ＵＩドライバ１３１は、論理プリンタＡのフィルタ構成情報Ｄ２ａに対して、チェックボタン６１１及び６１２の状態に応じた値（ｔｒｕｅ又はｆａｌｓｅ）を書き込む。すなわち、チェックボタン６１１の状態に応じた値は、記述５１３（図１０参照）に書き込まれる。チェックボタン６１２の状態に応じた値は、記述５２１に書き込まれる。

なお、チェックボタン６１１には、「ランゲージモニタのログを収集する」という文字列が付加され、チェックボタン６１２には、「印刷データを圧縮する」という文字列が付加されている。これは、ユーザの利便性を考慮したものである。すなわち、仮に、チェックボタン６１１に対して「ｄｒｖ１ｌｏｇ．ｄｌｌ」という文字列が付加され、チェックボタン６１２に対して「ｄｒｖ１ｃｏｍｐｒｅｓｓ．ｄｌｌ」という文字列が付加された場合、ユーザによっては、各チェックボタンをチェックすることによりどのような機能が有効となるのかを容易に知ることができない。そこで、図１２では、各フィルタ１３３の機能の内容を示す文字列が、各チェックボタンに付加されているのである。

上述したように、第二の実施の形態によれば、フィルタ構成情報を編集することにより、各フィルタ１３３の有効性を簡便に変更することができる。その結果、ランゲージモニタ１５によって実行される処理内容を容易にカスタマイズすることができる。

なお、上記各実施の形態において、ランゲージモニタ１５は、要求受付手段の一例である。また、フィルタ１３３は、処理実行手段の一例である。また、フィルタ構成情報記憶部１６は、記憶手段の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 情報処理装置
１１ アプリケーション
１２ ＧＤＩ
１３ プリンタドライバ
１４ スプーラ
１５ ランゲージモニタ
１６ フィルタ構成情報記憶部
１７ ポートモニタ
２０ プリンタ
３０ ネットワーク
１３１ ＵＩドライバ
１３２ グラフィックドライバ
１３３ フィルタ
１５１ ランゲージモニタインタフェース
１５２ フィルタマネージャ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
Ｂ バス

特開２００７−０８００３６号公報

Claims (4)

1. 所定の関数インタフェースを介してスプーラからの印刷データに関する要求を受け付ける要求受付手段と、
   前記要求に応じた処理を実行する複数の処理実行手段と、
   前記処理実行手段ごとに、前記関数インタフェースの関数名を関連付けて記憶する記憶手段とを有し、
   前記要求受付手段は、前記要求の受け付けに応じ、当該要求に係る前記関数インタフェースの関数名に関連付けられている前記処理実行手段に当該要求に応じた処理を実行させ、前記関数名に関連付けられている前記処理実行手段が複数有る場合は、当該複数の前記処理実行手段に前記要求に応じた処理を実行させる情報処理装置。
2. 前記記憶手段は、前記処理実行手段の有効性を示す情報を記憶し、
   前記要求受付手段は、複数の前記処理実行手段の中で、前記情報に基づいて有効であると判定される前記処理実行手段に前記要求に応じた処理を実行させる請求項１記載の情報処理装置。
3. 所定の関数インタフェースを介してスプーラからの印刷データに関する要求を受け付ける要求受付手順と、
   複数の処理実行手段のそれぞれごとに前記関数インタフェースの関数名を関連付けて記憶する記憶手段を参照して、前記要求に係る前記関数インタフェースの関数名に関連付けられている前記処理実行手段に当該要求に応じた処理を実行させる処理委譲手順とをコンピュータに実行させ、
   前記処理委譲手順は、前記要求受付手順が前記要求を受け付ける際に、前記関数名に関連付けられている前記処理実行手段が複数有る場合は、当該複数の前記処理実行手段に前記要求に応じた処理を実行させるプログラム。
4. 前記記憶手段は、前記処理実行手段の有効性を示す情報を記憶し、
   前記処理委譲手順は、複数の前記処理実行手段の中で、前記情報に基づいて有効であると判定される前記処理実行手段に前記要求に応じた処理を実行させる請求項３記載のプログラム。

Images