次に本発明を実施するための最良の形態について図面を参照して説明する。
<システム構成の説明>
以下添付図面を参照して本発明の好適な実施形態について詳細に説明する。
図1は、本発明の第1実施形態を示すデータ処理装置を適用可能な印刷処理システムの構成を説明するブロック図である。
なお、特に断らない限り、本発明の機能が実行されるのであれば、単体の機器であっても、複数の機器からなるシステムであっても本発明を適用できることは言うまでもない。また、LAN,WAN等のネットワークを介して接続が為され処理が行われるシステムであっても本発明を適用できることは言うまでもない。
図1において、3000はホストコンピュータで、システムバス4に接続される各デバイスをCPU1が総括的に制御する。CPU1は、ROM3のプログラム用ROMあるいは外部メモリ11に記憶された文書処理プログラム等に基づいて図形、イメージ、文字、表(表計算等を含む)等が混在した文書処理を実行する。
また、このROM3のプログラム用ROMあるいは外部メモリ11には、CPU1の制御プログラムであるオペレーティングシステムプログラム(以下OS)等を記憶する。また、ROM3のフォント用ROMあるいは外部メモリ11には上記文書処理の際に使用するフォントデータ等を記憶する。さらに、ROM3のデータ用ROMあるいは外部メモリ11には上記文書処理等を行う際に使用する各種データを記憶する。
2はRAMで、CPU1の主メモリ、ワークエリア等として機能する。5はキーボードコントローラ(KBC)で、キーボード(KB)9や不図示のポインティングデバイスからのキー入力を制御する。6はCRTコントローラ(CRTC)で、CRTディスプレイ(CRT)10の表示を制御する。
7はディスクコントローラ(DKC)で、外部メモリ11とのアクセスを制御する。外部メモリ11には、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタ制御コマンド生成プログラム(以下プリンタドライバ)等を記憶する。外部メモリ11は、ハードディスク(HD)、フレキシブルディスク(FD)等で構成される。
8はプリンタコントローラ(PRTC)で、所定の双方向性インタフェース21を介してプリンタ1500に接続されて、プリンタ1500との通信制御処理を実行する。なお、CPU1は、例えばRAM2上に設定された表示情報RAMへのアウトラインフォントの展開(ラスタライズ)処理を実行し、CRT10上でのWYSIWYGを可能としている。
また、CPU1は、CRT10上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウインドウを開き、種々のデータ処理を実行する。ユーザは印刷を実行する際、印刷の設定に関するウインドウを開き、プリンタの設定や、印刷モードの選択を含むプリンタドライバに対する印刷処理方法の設定を行える。
プリンタ1500において、12はプリンタCPUで、ROM13のプログラム用ROMに記憶された制御プログラムに基づいてシステムバス15に接続される印刷部(プリンタエンジン)17に出力情報としての画像信号を出力する。
また、プリンタCPU12は、外部メモリ14に記憶された制御プログラム等に基づいてシステムバス15に接続される印刷部(プリンタエンジン)17に出力情報としての画像信号を出力する。
また、このROM13のプログラムROMには、CPU12の制御プログラム等を記憶する。ROM13のフォント用ROMには上記出力情報を生成する際に使用するフォントデータ等を記憶する。また、ROM13のデータ用ROMにはハードディスク等の外部メモリ14がないプリンタの場合には、ホストコンピュータ上で利用される情報等を記憶している。
CPU12は入力部18を介してホストコンピュータとの通信処理が可能となっており、プリンタ内の情報等をホストコンピュータ3000に通知可能に構成されている。
19は前記CPU12の主メモリ、ワークエリア等として機能するRAMで、図示しない増設ポートに接続されるオプションRAMによりメモリ容量を拡張することができるように構成されている。
なお、RAM19は、出力情報展開領域、環境データ格納領域、NVRAM等に用いられる。前述したハードディスク(HD)、ICカード等の外部メモリ14は、ディスクコントローラ(DKC)20によりアクセスを制御される。外部メモリ14は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、1501は前述した操作パネルで、操作のためのスイッチおよびLED表示器等が配されている。
また、前述した外部メモリは1個に限らず、少なくとも1個以上備え、内蔵フォントに加えてオプションフォントカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。さらに、図示しないNVRAMを有し、操作パネル1501からのプリンタモード設定情報を記憶するようにしてもよい。
さらに、本実施形態では、OSとして、マクロソフト社のWINDOWS(登録商標)に適用する例について説明するが、当該OS以外のOSであっても、本発明を適用できる。
図2は、図1に示したRAM2のメモリマップの一例を示す図である。本例は、所定のアプリケーションおよび印刷処理関連プログラムを起動して、ホストコンピュータ3000上のRAM2にロードされた状態のRAM2のメモリマップを示している。
図2において、RAM2には、図示の如く、BIOS206、OS205をはじめ、アプリケーショ201、印刷処理関連プログラム204、および関連データ203がロードされており、さらに空きメモリ領域(空きメモリ)202も確保されている。
これにより、アプリケーション201および印刷処理関連プログラム204は実行可能状態にある。
図3は、図1に示したホストコンピュータ3000のプリンタドライバの拡張システムの一例を示すブロック図である。本例は、プリンタドライバ307にプラグインモジュールを追加した場合のUIに関する構成を示している。以下、本実施形態におけるプリンタドライバ307の拡張システムについて説明する。
図3において、プラグインモジュールは、UIドライバ1103の拡張機能を有するUIプラグイン1104と、グラフィックスドライバ1105の拡張機能を有するグラフィックスプラグイン1106から構成されている。以下、それぞれのプラグインモジュールについて説明する。
UIプラグイン1104は、プリンタドライバ307が利用者に提供する印刷設定シート(UI)に新たなシートを加える場合に用いる。また、UIドライバ1103で処理しているインストール時の処理などのUIドライバ1103に実装されている様々なイベント処理をカスタマイズする場合に用いる。
UIドライバ1103は、システムに対してエクスポートしているDDI(Device Driver Interface)がコールされた際に、UIプラグイン1104が公開しているインタフェースを取得する。UIドライバ1103が取得したUIプラグイン1104のインタフェースを用いて、UIプラグイン1104と通信することで、UIドライバ1103に実装されたカスタマイズ処理が実行される。
一方、グラフィックスプラグイン1106は、GDI(Graphics Device Interface)1102とグラフィックスドライバ1105とのインタフェースであるDDIの処理を横取りする場合に用いる。または特定のタイミングで処理を追加する場合や、印刷データのスプール処理を横取りする場合に用いる。
グラフィックスドライバ1105がエクスポートしているDDIは、ジョブを生成するためにGDI1102から適宜コールされる。そして、その初期化のタイミングで、グラフィックスドライバ1105は、グラフィックスプラグイン1106が公開しているインタフェースを取得し、RAM2に保持する。
ここで取得したインタフェースを用いて、DDIがコールされるタイミングにそのDDIに対応したグラフィックスプラグイン1106の処理を呼び出す。
呼び出されたグラフィックスプラグイン1106は、プラグイン内に実装された処理を実行し、処理を再びグラフィックスドライバ1105に返す。
ここで、グラフィックスプラグイン1106が処理を横取りしている場合、DDIはそこで処理を終了し、追加処理を実装している場合には、そのまま後続する処理を続ける。
グラフィックスプラグイン1106がグラフィックスドライバ1105の印刷データのスプール処理を横取りする場合は、グラフィックスドライバ1105内の印刷データをスプールする直前にグラフィックスプラグイン1106のインタフェースをコールする。そして、コールされたグラフィックスプラグイン1106は、スプールされるデータを取得し、特定の処理を実行する。その後、再度グラフィックスドライバ1105のスプール処理関数をコールすることで、グラフィックスドライバ1105に特定の処理を施したデータを渡す。
そして、データを受け取ったグラフィックスドライバ1105は、実際にシステムスプーラ1107にスプールする処理を実行する。このようにプラグインモジュールに拡張機能を実装することで、プリンタドライバ307の拡張システムを実現している。
次に、印刷処理関連プログラム(プリンタドライバ)がホストコンピュータ3000上のRAM2にロードされ実行可能となった状態のメモリマップについて説明する。
図2は、印刷処理関連プログラム(プリンタドライバ)がホストコンピュータ3000上のRAM2にロードされ実行可能となった状態のメモリマップ例を示す図である。
図2に示すように、RAM2には、アプリケーション201、空きメモリ202、関連データ203、印刷処理関連プログラム(以下、プリンタドライバとする)204、OS205及びBIOS206から構成されるメモリマップが形成される。
図4は、図1に示したホストコンピュータ3000の各種のモジュールのプリント処理例を示す概念ブロック図である。本例は、プリンタドライバ307に複数の追加機能である第1のプラグインモジュールセット310および第2のプラグインモジュールセット313がインストールされている状態の各モジュール間の構成を示す例である。
図4に示すように第1のプラグインモジュールセット310には第1のプラグインモジュール309と、第1のプラグインモジュール309独自のコンフリクト処理ルール308が同梱されている。
同様に、第2のプラグインモジュールセット313においても第2のプラグインモジュール312と、第2のプラグインモジュール312独自のコンフリクト処理ルール311が同梱されている。
また、プラグイン前のプリンタドライバ307は、コンフリクト処理ルール301、推論エンジン302、コンフリクトマネージャ303、状態変数リスト304、内部構造体305及びドライバ管理部306から構成されていた。
また、本実施形態のプリンタドライバ307は、第1のプラグインモジュール309および第2のプラグインモジュール312を組み込むことにより、それぞれ新たにスタンプ機能と製本印刷機能とを有する場合を示した。しかし、プラグインモジュールにより追加される機能はこれに限定されるものではない。
第一のプラグインとして、ドキュメント管理プラグインが考えられる。地紋プラグインによって地紋印刷が新たにプリンタドライバに入力可能となり、ドキュメント管理プラグインにより、サーバ装置(図示省略)へのドキュメントが登録される(ストアモード)。
一般に複写機には、原稿の微小なドットを読み取る入力解像度や微小なドットを再現する出力解像度に依存した再現能力の限界が存在する。
地紋画像の背景部のドットが、複写機で再現できるドットの限界より小さく形成され、潜像部のドット塊が限界より大きく形成されている場合、複写により地紋画像の大きなドット塊による画像は再現される。そして、小さなドットによる画像は再現されず、潜像が顕在化される。
また、複写によって分散した小さなドットが完全に消えなくとも、集中したドット塊と比較して複写後の濃度がより低い場合でも、潜像は相対的により顕著に認識できる。このように画像が浮かび上がる画像は顕像と呼ばれる。禁複写のような顕像を埋め込むことにより、複写牽制のための印刷として機能する。
地紋印刷が設定されている場合に、文書管理モジュールにおいて外部コンピュータに対する印刷データの登録を行うストア印刷の設定を許すと、セキュリティが低下する恐れがある。
よって、第1のプラグインモジュール309および第2のプラグインモジュール312において、地紋印刷が設定されている場合に、ストア印刷を禁止するようなルールを記憶させることが考えられる。
第1のプラグインモジュール309および/又は第2のプラグインモジュール312からこのコンフリクトルールをコンフリクトマネージャ303が取得する(307−15)。この取得したルールに基づき、コンフリクトマネージャ303は、地紋印刷が設定されている場合に、ストア印刷を禁止するように制御する(307−27)。
301はコンフリクト処理ルールであり、プラグインする前のプリンタドライバ307における各設定間の不整合を防ぐためのルールが定義されている。尚、コンフリクト処理ルールの具体例については後述する。
303はコンフリクトマネージャであり、状態変数リスト304及び内部構造体305内のデータが一致するよう管理する。
ここで、状態変数リスト304とは、プリンタドライバ307で設定可能な設定項目(例えば、グループ、ステイプル、ソート)に対応する状態変数(例えば、Group、Staple、Collate)とその値(設定項目のオン/オフ)のリストである。
また、内部構造体305内のデータとはプリンタドライバ307で設定可能な設定項目(例えばグループ、ステイプル、ソート)に対応する変数であるメンバ(例えばcGroup、cStaple、cCollate)とその値(オン=1、オフ=0)である。
302は推論エンジンであり、コンフリクト処理ルール301及び第1のプラグインのコンフリクト処理ルール308、第2のプラグインのコンフリクト処理ルール311をコンフリクトマネージャ303を介して読み込む。そして、コンフリクトチェック(ルールに応じた設定であるかの検査)を行い、その結果をコンフリクトマネージャ303へ返信する。
306はドライバ管理部であり、アプリケーション201からの印刷設定要求などに応じて、初期化処理や印刷設定を行うためのUIの表示制御や、プリンタドライバ307内の動作制御を行う。
また、ドライバ管理部306は、コンフリクトマネージャ303に各設定間の不整合が生じないようコンフリクト処理を依頼する。
また、ドライバ管理部306は第1のプラグインモジュール309および第2のプラグインモジュール312とのデータの授受も行う。
ここで、図4に示したコンフリクトマネージャ303及び推論エンジン302が、状態変数リスト304、内部構造体305及びコンフリクト処理ルール301を利用してどのようなコンフリクト処理を行うかを簡単な具体例を示して説明する。
図5は、図4に示したコンフリクトマネージャ303及び推論エンジン302におけるコンフリクト処理の例を示す図である。
なお、図5においては、コンフリクトマネージャ303が、変数リスト304及び内部構造体305を利用して、推論エンジン302がコンフリクト処理ルール301を利用していることを示す例である。このため、コンフリクトマネージャ303の枠内に状態変数リスト304及び内部構造体305を記載して、推論エンジン302の枠内にコンフリクト処理ルール301を記載している。
図5に示す具体例では、プリンタ機能名A,B,C…の設定に応じたコンフリクト処理の例を示している。
図5に示すように、内部構造体305には、プリンタ機能名A、B、C…に対応するメンバint cA、cB、cC…とその値「0」、「1」、「0」…が格納されている。
コンフリクトマネージャ303は、この内部構造体305のメンバとその値を参照することで、状態変数A=OFF、状態変数B=ON、状態変数C=OFF、…という状態変数リスト304を生成する。
推論エンジン302は、この状態変数リスト304を参照するので、推論エンジン302内における、プリンタ機能名A、B、C…の状態値の初期値は、「OFF」、「ON」、「OFF」となる。
また、コンフリクト処理ルール301には、
A(ON)<−B(ON)、C(OFF)というルールが定義されていたとする。
これは、機能Bがオンかつ機能Cがオフの場合は機能Aをオンにするというルールを定義するものである。
推論エンジン302は、コンフリクト処理ルール301を、コンフリクトマネージャ303を介して読み込む。
ここで、推論エンジン302でコンフリクトチェックの推論が行われたとする。初期値がプリンタ機能名B=ON、プリンタ機能名C=OFFであるので、コンフリクト処理ルール301で定義されたルールA(ON)<−B(ON)、C(OFF)が成立する。
これにより、推論エンジン302は、左辺のプリンタ機能名Aの状態変数値をONに変更する。すなわち、推論エンジン302は、状態変数リスト304の状態変数A=ONに更新する。
推論エンジン302において、コンフリクトチェックの推論が終了した後、コンフリクトマネージャ303は変更された状態変数Aの値をプリンタドライバ307の内部構造体305の対応するメンバint cAに反映させる。
つまりint cAの値は上記ルールが成立した事によって「0」から「1」に変更される。
以上に示すような処理により、コンフリクトマネージャ303及び推論エンジン302は、設定間に不整合が生じないように、状態変数リスト304を更新する。そして、それを、ドライバ管理部306がUIに利用する内部構造体305内の設定情報(メンバcA、cB、…)に反映している。
なお、上述したコンフリクト処理ルール301で定義したルールは、簡単な具体例を示すためのものであり、本実施形態のコンフリクト処理ルール301は、例えば以下に示すようなルール例(1)〜(3)を定義している。
Collate(OFF)<−Group(ON) …(1)
Collate(OFF)<−Staple(ON) …(2)
Collate(ON)<−Group(OFF) …(3)
また、第1のプラグインのコンフリクト処理ルール308は、例えば以下に示すようなルール例(4)を定義している。
Poster(OFF)<−Stamp(ON) …(4)
さらに、第2のプラグインのコンフリクト処理ルール311は、例えば以下に示すようなルール例(5)を定義している。
Group(OFF)<−Booklet(ON) …(5)
ここで、Collateは、ソート機能を示し、Groupは、グループ機能を示し、Stapleは、ステイプル機能を示し、Stampは、スタンプ印刷機能を示し、Bookletは、製本印刷機能を示す。
次に、本実施形態のホストコンピュータ3000におけるプリンタドライバ307のUIに関する処理について説明する。
OS205管理の下で動作するアプリケーション201よりプリンタドライバ307の備える初期化処理が呼び出されると、OS205の管理の下、RAM2にプリンタドライバ307がロードされる。
プリンタドライバ307がRAM2にロードされると、ドライバ管理部306に備えられたプリンタドライバ307の初期化処理部が呼び出され、初期化処理が行われる。
図6〜図8は、本発明に係るデータ処理装置における第1のデータ処理手順の一例を示すフローチャートであり、図4に示したアプリケーション201からプリンタドライバ307のUIを開く際の初期化処理する手順に対応する。なお、(201−1)〜(201−5)はアプリケーション201が実行するステップに対応する。また、(307−1)〜(307−28)は図4に示すドライバ管理部306が実行するステップに対応する。さらに、(310−1)〜(310−10)は第1プラグインモジュールセット310が実行するステップに対応する。また、(313−1)〜(313−10)は第2のプラグインモジュールセット313が実行するステップに対応する。
尚、図6に示す第1のプラグインモジュール309は、図4に示したように、プリンタドライバ307にプラグインにより組み込まれたものである。
まず、アプリケーション201はプリンタドライバ307の内部構造体を格納するためのメモリ領域のサイズをプリンタドライバ307に問い合わせる(201−1)。
プリンタドライバ307は、ステップ(201−1)による問い合わせを受けると(307−1)、第1のプラグインモジュール309に対して、第1のプラグインモジュール309が必要な内部構造体のデータ領域のサイズを問い合わせる(307−2)。
第1のプラグインモジュール309がデータ領域のサイズの問い合わせを受けると(310−1)、必要な内部構造体の領域サイズを計算し(310−2)、計算された領域のサイズをプリンタドライバ307に返す(310−3)。
その後、プリンタドライバ307が第1のプラグインモジュール309より計算された領域のサイズを受けると(307−3)、第1のプラグインモジュール309に必要な内部構造体のサイズを取得する(307−4)。
本実施形態においては、2つのプラグインモジュール(第1のプラグインモジュール309、第2のプラグインモジュール312)がインストールされている状態を想定している。このため、次にプリンタドライバ307は、第2のプラグインモジュール312に対して、第2のプラグインモジュール312が必要な内部構造体305のデータ領域のサイズを問い合わせる(307−5)。
第2のプラグインモジュール312は、データ領域のサイズを問い合わせを受けると(313−1)、必要な内部構造体305の領域サイズを計算し(313−2)、計算された領域のサイズをプリンタドライバ307に返す(313−3)。
プリンタドライバ307は、第2のプラグインモジュール312に必要な内部構造体のサイズを受けると(307−6)、第2のプラグインモジュール312に必要な内部構造体のサイズを取得する(307−7)。その後、プリンタドライバ307に必要な内部構造体のサイズに、ステップ(307−4)、(307−6)で取得した2つのプラグインモジュールのサイズの合計を加えたデータサイズをアプリケーション201に返す(ステップ307−8)。
アプリケーション201は、プリンタドライバ307から返された値を受け取り(201−2)、プリンタドライバ307から返された値を取得し(201−3)、該取得したサイズ分のメモリ領域を空きメモリ202上に確保する(201−4)。
次に、ステップ(201−4)で確保したメモリ領域をプリンタドライバ307に渡して、プリンタドライバ307のUIを開くようにプリンタドライバ307に指示を出し(201−5)、処理を終了する。
この時の内部構造体305は例えば、図9に示すようなメモリマップ構成になっている。
図9は、図4に示したプリンタドライバ307が必要とする内部構造体305のメモリマップ構成例を示す図である。
図9に示すように、内部構造体305は、パブリック領域601を備える。また、プリンタドライバ307に必要なデータ領域サイズに応じたドライバプライベート領域602を備える。さらに、第1のプラグインモジュール309と第2のプラグインモジュール312の独自データ領域サイズに応じたプラグインプライベート領域603とから構成されている。
次に、プリンタドライバ307のUIを開く指示を受けると(307−9)、受け取った指示に基づき、プリンタドライバ307のインタフェース(Documennt Property)が呼び出される(307−10)。
そして、プリンタドライバ307は、第1のプラグインモジュールセット310に対して第1のプラグインモジュール309に同梱されている第1のコンフリクト処理ルール308の格納場所の問い合わせを行う(307−11)。
そして、第1のプラグインモジュール309が同梱されている第1のコンフリクト処理ルール308の格納場所の問い合わせを受ける(310−4)。そして、第1のプラグインモジュール309の設定値に関連する第1のコンフリクト処理ルール308が記述されているファイルの格納場所をプリンタドライバ307に返す(310−5)。
次に、該第1のプラグインモジュール309から格納場所を受ける(307−12)。次に、プリンタドライバ307は、第2のプラグインモジュール312に同梱されている第2のコンフリクト処理ルール311の格納場所の問い合わせを行う(307−13)。
そして、第2のプラグインモジュール312が同梱されている第2のコンフリクト処理ルール311の格納場所の問い合わせを受ける(313−4)。そして、第2のプラグインモジュール312は、第2のプラグインモジュール312の設定値に関連する第2のコンフリクト処理ルール311が記述されているファイルの格納場所をプリンタドライバ307に返す(313−5)。
そして、プリンタドライバ307が第2のコンフリクト処理ルール311が記述されているファイルの格納場所を受ける(307−14)。そして、推論エンジン302は、第1のPM309と同梱されているコンフリクト処理ルール308と、第2のPM312と同梱されているコンフリクト処理ルール311とを、コンフリクトマネージャ303を介して、RAM2中に読み込む。そして、その後、コンフリクト処理ルール301を読み込む(307−15)。
なお、図4で説明したように、コンフリクト処理ルール301、308、311に定義されている全てのプリンタ機能名については、状態変数リスト304として、図5に示すように各プリンタ機能名に対応した状態変数とその値を持っている。
図4でも示したように、状態変数リスト304の状態変数の値はプリンタドライバ307で使用される内部構造体305の対応するメンバの値と連動している。状態変数リスト304における全ての状態変数の初期値はその内部構造体305のメンバの値が初期値となる。
そして、プリンタドライバ307は、コンフリクトマネージャ303を介して第1のプラグインの状態変数の初期化処理を行う(307−16)。
まず、プリンタドライバ307は、第1のプラグインモジュール309の状態変数の初期化を指示すると、該指示を受ける(310−6)。そして、第1のプラグインモジュール309は、第1のプラグインモジュール独自の状態変数を初期化する(310−7)。その後、第1のプラグインモジュール309が初期化された状態変数をプリンタドライバ307に返す。
そして、第1のプラグインモジュール309より初期化された状態変数を受け取ると(307−17)、プリンタドライバ307はコンフリクトマネージャ303を介して状態変数リスト304に追加する。
同様に、プリンタドライバ307は、第2のプラグインモジュール312の状態変数の初期化を指示すると(307−18)、該指示を受ける(313−6)。その後、第2のプラグインモジュール312は、第2のプラグインモジュール独自の状態変数を初期化した後、初期化された状態変数をプリンタドライバ307に返す(313−7)。
そして、プリンタドライバ307が第2のプラグインモジュール312より初期化された状態変数を受け取ると(307−19)、プリンタドライバ307はコンフリクトマネージャ303を介して状態変数リスト304に追加する。
その後、プリンタドライバ307は、自身の状態変数を初期化する(307−20)。次に、プリンタドライバ307は、図10の(a),(b)に示すような第1のプラグインモジュール309独自のUIである設定シートを表示するために、第1のプラグイン独自設定シートの情報を問い合わせる(307−21)。
第1のプラグインモジュール309が第1のプラグイン独自設定シートの情報を問い合わせを受ける(310−8)。その後、第1のプラグインモジュール309は、独自設定シートを生成して(310−9)、生成した独自設定シートの情報をプリンタドライバ307に返し(310−10)、処理を終了する。
そして、第1のプラグインモジュール309より生成された独自設定シートの情報を受け取ると(307−22)、プリンタドライバ307は、第1のプラグインモジュール309独自の設定シート情報を取得する(307−23)。
同様に、図11の(a),(b)に示すような第2のプラグインモジュール312独自のUIである設定シートを表示するために、第2のプラグイン独自設定シートの情報を問い合わせる(307−24)。
第2のプラグインモジュール312が第2のプラグイン独自設定シートの情報を問い合わせを受ける(313−8)。その後、第2のプラグインモジュール312は、独自設定シートを生成して(313−9)、生成した独自設定シートの情報をプリンタドライバ307に返し(313−10)、処理を終了する。
そして、第2のプラグインモジュール312より生成された独自設定シートの情報を受け取ると(307−25)、プリンタドライバ307は、第2のプラグインモジュール312独自の設定シート情報を取得する(307−26)。
次に、プリンタドライバ307において、推論エンジン302によるコンフリクトチェック及び状態変数リスト304の更新を行う。また、コンフリクトマネージャ303による内部構造体305の更新などのコンフリクト処理が行われ、設定間に不整合があれば訂正される(307−27)。
次に、図10の(a)に示すような印刷設定UIを表示して(307−28)、処理を終了する。具体的には、プリンタドライバ307の設定シートとともに、ステップ(307−23),(307−26)で取得した第1のプラグインモジュール309と第2のプラグインモジュール312の設定シートを加えて印刷設定UIを表示する。
これにより、プリンタドライバ307に複数のプラグインモジュールを追加してシステム状態を変更した場合、プラグイン独自の印刷設定をプリンタドライバ本体の設定との間で不整合が起こることなく自動的に設定する。したがって、プラグインとして追加機能を付加するシステムを構築する場合に、システム変更前とシステム変更後による設定値の調整負担が大幅に軽減され、ユーザの利便性が向上する。
なお、本実施形態では、OS205が、例えばWINDOWS(登録商標)の場合には、後述する内部構造体として、DEVMODE構造体が生成されるものとする。そして、上記図6〜図8または後述する図12,図13に示すフローチャートは、アプリケーション201がDEVMODE構造体を生成するタイミングで実行されるものとする。
さらに、UI画面に対する設定変更の履歴をNVRAM等に記憶しておくことにより、プラグインのインストール等でUI制御が変更された旨を、オペレータやサービスマンが確認できるように構成してもよい。
図10,図11は、本発明に係るデータ処理装置における印刷設定シート例を示す図であり、図6等の処理によりプラグイン後のプリンタドライバ307が利用者に提供するUIである印刷設定シート例を示す。
図10の(a)に示すように、本来のプリンタドライバ307の設定シート(ページ設定、仕上げ)に「プラグイン1の設定」という第1のプラグインモジュール309の設定シート80が加わっている。また、図11の(B)に示すように「プラグイン2の設定」という第2のプラグインモジュール312の設定シート90が加わっている。
また、設定シート80,90は、利用者がスタンプ機能のオン/オフ、オン製本印刷機能のオン/オフを設定するためのチェックボックス(CB)81,91を有する。
なお、図10の(a)の設定シート80においては、チェックボックス81がチェックされていないので、スタンプ印刷機能はオフされている状態(状態変数が初期値の状態)である。また、図11の(a)の設定シート90においては、チェックボックス91がチェックされていないので、製本印刷機能はオフされている状態(状態変数が初期値の状態)である。
ここで、図10の(a)の設定シート80において、利用者がチェックボックス81を図10の(b)に示すようにチェックすることで、スタンプ印刷機能をオンしたこととなる。また、図11の(a)の設定シート90において、利用者がチェックボックス91を図11の(b)に示すようにチェックすることで、製本印刷機能をオンしたこととなる。
次に、図10の(b)に示すように、第1のプラグインの機能であるスタンプ印刷機能をオンした後、図11の(b)に示すように、第2のプラグインの機能である製本印刷機能をオンした場合のコンフリクト処理について説明する。
図12は、本発明に係るデータ処理装置における第2のデータ処理手順の一例を示すフローチャートである。本例は、図10(b),図11(b)に示すような第1、2のプラグインの機能であるスタンプ印刷機能、製本印刷機能をオンに変更した場合のコンフリクト処理手順に対応する。
なお、(3070−1)〜(3070−12)は図4に示すドライバ管理部306が実行するステップに対応する。
また、(3100−1)〜(3100−3)は第1プラグインモジュール(PM)310が実行するステップに対応する。
さらに、(3130−1)〜(3130−3)は第2のプラグインモジュール(PM)313が実行するステップに対応する。
まず、ユーザが、図1に示したCRT10上に表示される、例えば図10の(a)から図10の(b)のUI画面状態に示すように、CB81をチェックする操作に応じた、内部構造体305や状態変数リスト304の更新を行う(3070−1)。
次に、当該UI操作を受けて、図7に示したステップ(307−15)で読み込んだ第1のPM309のコンフリクト処理ルール308を適用する。また、図7に示したステップ(307−15)で読み込んだ第2のPM312のコンフリクト処理ルール311を適用する(3070−2)。
続いて、プリンタドライバ307本体が保持するコンフリクト処理ルール301を適用する処理を行う(3070−3)。これらのコンフリクト処理に応じて、状態変数リスト304の状態変数が更新される(3070−4)。ここで、ユーザが、図11の(a)に示すUI画面状態から図11の(b)に示すように、UI画面のチェックボックス91をチェックする操作に応じた処理についても同様に処理される。
尚、本実施形態においては、ステップ(3070−2),(3070−3)の処理ルールの適用は、図7に示したステップ(307−15)において読み込まれた順番に応じて適用している。
また、複数の処理ルールの適用順番に応じて、処理ルールの優先順位も定まり、本実施形態では、コンフリクト処理ルール308の方がコンフリクト処理ルール301よりも優先されている。また、コンフリクト処理ルール311の方がコンフリクト処理ルール308よりも優先されている。
コンフリクト処理ルール301を優先したい場合には、コンフリクト処理ルール308または、コンフリクト処理ルール311を先に適用する処理を行う。
この読み込み順序については、ここでは特に説明していないが、情報ファイル等にコンフリクト処理ルールの優先順位を記述しておいて、その情報に従ってコンフリクト処理ルールを読み込んでも良い。
ここで、具体例を示しながらコンフリクト処理について説明する。
例えば、図4に示す内部構造体305において、プリンタ機能に対応するメンバとしてcCollate、cGroup、cPoster、cStaple、cStamp、cBookletが有るとする。
そして、この各メンバのコンフリクト処理ルール適用前の値は、ステップ(3070−1)の直前において以下の通りとする。
cCollate=0
cGroup =1
cPoster =1
cStaple =0
cStamp =0
cBooklet=0
これにより、状態変数リスト304においては、上記各メンバに対応する状態変数Collate、Group、Poster Staple、Bookletと状態値は以下のとおりとなる。
Collate=OFF
Group =ON
Poster =ON
Staple =OFF
Stamp =OFF
Booklet=OFF
この時、プリンタドライバ307が提供するUIである仕上げの設定シート100の状態は、図14の(a)に示すように、ポスタ機能のチェックボタン104は選択されている。また、ソート機能のラジオボタン101は非選択、グループ機能のラジオボタン102は選択されている状態である。
尚、Stampは、図10の(b)となるような利用者の操作がまだ行われていない(ステップ(3070−1)の前である)ので、OFFのままである。
このような状態の時に、ステップ(3070−1)に応じて、プリンタドライバ307は、アプリケーション201からのスタンプ印刷機能の設定をオンへ変更する変更要求を受信する。
これにより、内部構造体305のメンバcStampは下記に示すように、「0」から「1」に更新される。
cCollate=0
cGroup =1
cPoster =1
cStaple =0
cStamp =0
cBooklet=0
次に、ドライバ管理部306はコンフリクトマネージャ303を呼び出し、状態変数リストにあるStampの状態変数をオフからオンに更新する。これにより、状態変数リスト304は、以下の通りとなる。
Collate=OFF
Group =ON
Poster =ON
Staple =OFF
Stamp =ON
Booklet=OFF
続いて、ステップ(3070−2)において、推論エンジン302がコールされて、コンフリクト処理ルールの適用が始まる。
まず、推論エンジン302内の各プリンタ機能名が状態変数リスト304の各状態変数の持つ値で初期化される。
続いて、ステップ(307−15)先に読み込まれたコンフリクト処理ルール308のルール例(1)が適用されて、状態変数Posterの状態値がONからOFFへと変化する。
尚、ルール例(1)とは、上述したとおり、Poster(OFF)<−Stamp(ON)で定義されるルールである。
これにより、状態変数リスト304の状態値も、
Collate=OFF
Group =ON
Poster =OFF
Staple =OFF
Stamp =ON
Booklet=OFF
に更新される。
コンフリクト処理ルール301,308,311内において、他に、適用されるルールが存在しないので、以上で推論エンジン302でのコンフリクト処理ルールの適用が終了する。
以上に示すように、ステップ(3070−1)〜(3070−3)の処理により、UI上で行われた設定の変更に応じて、コンフリクト処理が行われる。
ここで、図12のフローチャートに戻ると、ステップ(3070−4)でコンフリクト処理ルール301,308,311に応じて状態変数リスト304を更新する。その後に、コンフリクトマネージャ303は、更新した状態変数リスト304に応じて内部構造体305を更新する(3070−5)。
具体的には、メンバの値が以下のようになる。
cCollate=0
cGroup =1
cPoster =0
cStaple =0
cStamp =1
cBooklet=0
次に、プリンタドライバ307は、ステップ(3070−4)の処理において第1のプラグインモジュール309の状態変数が更新されているかどうかを判定する(3070−6)。
ここで、状態変数が更新されているとプリンタドライバ307が判定した場合(ステップ3070−6のYES)には、プリンタドライバ307は、第1のプラグインモジュール309を呼び出す(ステップ3070−7)。
一方、第1のプラグインモジュール309がプリンタドライバ307よりコールされると(3130−1)、プラグインモジュール309の独自設定シート内のコントロールを制御する(3130−2)。そして、プラグインモジュール309の独自設定シート内のコントロールを更新して(3130−3)、処理をプリンタドライバ307に戻す。
一方、ステップ(3070−6)で第1のプラグインモジュール309の状態変数が更新されていないと判断した場合(ステップ3070−6のNO)、プリンタドライバ307は、第2のプラグインの状態変数が更新されたかを判定する(3070−9)。
同様に、プリンタドライバ307は、第1のプラグインモジュール309より返信される更新終了を確認したら(ステップ3070−8)、プリンタドライバ307は、第2のプラグインの状態変数が更新されたかを判定する(3070−9)。
しかし、この場合、第2のプラグインの状態変数は更新されていないので、次のステップ(3070−11)に進む。そして、ステップ(3070−4)で更新された状態変数に応じてプリンタドライバ307本体の設定シート内のコントロールを制御して(3070−12)、本処理を終了する。
一方、ステップ(3070−9)で、第2のプラグインの状態変数が更新されていると判定した場合については、第2のプラグインモジュール312を呼び出す(3070−10)。なお、第2のプラグインモジュール312を呼び出された後のステップについては、後述する。
このようにステップ(3070−1)〜(3070−11),(3130−1)〜(3130−3)に示した設定変更に応じたコンフリクト処理を行う。これにより、コンフリクト処理ルールの適用前の仕上げ設定シート100は、図14の(a)に示すUI画面状態であったが、コンフリクト処理ルールの適用後、図14の(b)に示すUI画面状態に変化する。
すなわち、もともと"仕上げ"設定シート100でポスタ(内部構造体のメンバ名は"Poster")機能のチェックボタン104が選択されていたのが、コンフリクト処理ルールの適用により、チェックボタン104が選択されていない状態に変化している。
次に、第2のプラグイン機能である製本機能のシートをUI画面上でONにした際の処理を説明する。
この時点でプリンタドライバ307が提供するUIである仕上げの設定シート100の状態は、図11の(b)に示すように、ソート機能のラジオボタン101は非選択であり、グループ機能のラジオボタン102は選択されている状態である。
尚、Bookletは、図8の(b)となるような利用者の操作がまだ行われていない(ステップ3070−1の前である)ので、OFFのままである。
このような状態の時に、ステップ(3070−1)に応じて、プリンタドライバ307は、アプリケーション201からの製本印刷機能の設定をオンへ変更する変更要求を受信する。これにより、内部構造体305のメンバcBookletは下記に示すように、「0」から「1」に更新される。
cCollate=0
cGroup =1
cPoster =0
cStaple =0
cStamp =1
cBooklet=1
次に、ドライバ管理部306はコンフリクトマネージャ303を呼び出し、状態変数リストにあるBookletの状態変数をオフからオンに更新する。これにより、状態変数リスト304は、以下のとおりとなる。
Collate=OFF
Group =ON
Poster =OFF
Staple =OFF
Stamp =ON
Booklet=ON
続いて、ステップ(3070−2)において、推論エンジン302がコールされて、コンフリクト処理ルールの適用が始まる。
図7に示したステップ(307−15)で先に読み込まれたコンフリクト処理ルール311のルール例(2)が適用されて、状態変数Groupの状態値がONからOFFへと変化する。
尚、ルール例(2)とは、上述したとおり、Group(OFF)<−Booklet(ON)で定義されるルールである。
これにより、状態変数リスト304の状態値も、
Collate=OFF
Group =OFF
Poster =OFF
Staple =OFF
Stamp =ON
Booklet=ON
に更新される。
次に、ステップ(3070−1)において、コンフリクト処理ルール301のルール例(5)が適用され、状態変数Collateの状態値がOFFからONへと変化する。
尚、ルール例(5)とは、上述したとおり、Collate(ON)<−Group(OFF)で定義されるルールである。コンフリクト処理ルール301、308、311内において、他に、適用されるルールが存在しないので、以上で推論エンジン302でのコンフリクト処理ルールの適用が終了する。
これにより、状態変数リスト304の状態値も、
Collate=ON
Group =OFF
Poster =OFF
Staple =OFF
Stamp =ON
Booklet=ON
に更新される(3070−4)。
以上に示すように、ステップ(3070−1)〜(3070−4)の処理により、UI画面上で行われた設定の変更に応じて、コンフリクト処理が行われる。
図12に示すフローチャートに戻ると、ステップ(3070−4)でコンフリクト処理ルール301,308,311に応じて状態変数リスト304を更新する。その後に、コンフリクトマネージャ303は、更新した状態変数リスト304に応じて内部構造体305を更新する(3070−5)。具体的には、メンバの値が以下のようになる。
cCollate=1
cGroup =0
cPoster =0
cStaple =0
cStamp =1
cBooklet=1
次に、プリンタドライバ307は、第1のプラグインモジュール309の状態変数が更新されているかどうかを判定する(3070−6)。この場合、第1のプラグインモジュール309の状態変数は更新されていないので、次のステップ(3070−9)に進む。
プリンタドライバ307は、ステップ(3070−9)において第2のプラグインモジュール312の状態変数が更新されているかどうかを判定する。
ここで、状態変数が更新されているとプリンタドライバ307が判定した場合((3070−9)でYES)には、プリンタドライバ307は、第2のプラグインモジュール312を呼び出す(3070−10)。
一方、第2のプラグインモジュール312は、プリンタドライバ307によりコールする(3130−1)。そして、状態変数の変化に応じて第2のプラグインモジュール312の独自設定シート内のコントロールを制御する(3130−2)。そして、第2のプラグインモジュール312の独自設定シート内のコントロールを更新して(3130−3)、処理をプリンタドライバ307に戻して、処理を終了する。
これにより、プリンタドライバ307は、以下ステップ(3070−11)に示す処理を行う。
なお、ステップ(3070−9)で第2のプラグインモジュール312の状態変数が更新されていない場合(ステップ3070−9)のNOの場合)の処理は前の第1のプラグインモジュール309の説明と同様である。
プリンタドライバ307は、ステップ(3070−11)にて、ステップ(3130−3)で更新された第2のプラグインに対応する状態変数を受け取る。そして、該受け取った第2のプラグインに対応する状態変数に応じてプリンタドライバ307本体の設定シート内のコントロールを制御して(3070−12)、本処理を終了する。
なお、プリンタドライバ307は、ステップ(3070−12)において、プリンタドライバ307本体の設定シート内で制御しているコントロールを更新して、コンフリクト処理及びUIの処理を終了する。
以上、ステップ(3070−1)〜(3070−12)に示した設定変更に応じたコンフリクト処理を行う。これにより、コンフリクト処理ルールの適用前の仕上げ設定シート100は、図14の(b)に示すUI画面状態であったが、コンフリクト処理ルールの適用後、図14の(c)に示すUI画面状態に変化する。
すなわち、もともと"仕上げ"設定シート100でグループ(内部構造体のメンバ名は"Group")機能のラジオボタン102が選択されていた。しかし、コンフリクト処理ルールの適用により、ソート(内部構造体305のメンバ名は"Collate")機能のラジオボタン101が選択されてオンの状態に変化している。
以上のような処理は、アプリケーション201によってドライバ管理部306に備えられた終了処理が呼び出されるまで、繰り返し実行される。
アプリケーション201よりプリンタドライバ307の終了処理が呼び出されると、空きメモリ202に生成したコンフリクト処理ルール301,308,311の情報等を消去すると共に、その他の終了処理を行う。
これにより処理は全て終了し、本実施形態におけるプリンタドライバ307の処理も終了し、RAM2からはOS205の機能により消去される。
以上に説明したように、本実施形態におけるホストコンピュータ3000は、プリンタドライバ307に複数のPM309,312が組み込まれていても、プラグイン後のプリンタドライバ307における設定間の不整合が生じることを防ぐことができる。つまり、第1のPM309のコンフリクト処理ルール308と、第2のPMのコンフリクト処理ルール311を参照することで、プラグイン後のプリンタドライバ307における設定間の不整合が生じることを防ぐことができる。
すなわち、本実施形態におけるホストコンピュータ3000は、プリンタドライバにプラグイン形式で新たな機能を複数追加した環境下においても的確なコンフリクト処理を行うことが可能である。
また、このプラグインモジュールをアンインストールする際においては、プラグインモジュールとともに、該プラグインモジュールに対応したコンフリクト処理ルールファイルも削除される。
また、プラグインモジュールをインストールする際に、ホストコンピュータ3000で動作するOS上のレジストリ等に登録された該プラグインモジュールに関連した情報はすべて削除される。
また、本実施形態においては、2つのプラグインモジュールをインストールしたケースを説明したが、2つ以上のプラグインモジュールをインストールした場合においても適用されることは、言うまでもない。
尚、本実施形態においては、プリンタドライバ307を記録する媒体を外部メモリ11としているが、外部メモリ11としては、FD(フレキシブルディスク)、HDドライブ、CD−ROMやICメモリカード等を利用可能である。
更に、本プリンタドライバ307単独、もしくはOS205その他のホストコンピュータ3000上で動作するプログラムと共にROM3に記録しておき、これをメモリマップの一部となすように構成し、直接CPU1で実行することも可能である。
さらに、上述した実施形態では、ホストコンピュータ3000における種々の機能を実現する為のプログラムをメモリ(RAM)に読み込んでCPUが実行することによりその機能を実現させるものであった。
しかし、この限りではなく、各処理の全部または一部の機能を専用のハードウェアにより実現してもよい。
また、上述したメモリは、光磁気ディスク装置、フラッシュメモリ等の不揮発性のメモリや、CD−ROM等の読み出しのみが可能な記録媒体より構成されてもよい。また、RAM以外の揮発性のメモリ、あるいはこれらの組み合わせによるコンピュータ読み取り、書き込み可能な記録媒体より構成されてもよい。
以下、図15に示すメモリマップを参照して本発明に係るデータ処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
図15は、本発明に係るデータ処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報,作成者等も記憶され、かつ、プログラム読み出し側のOS等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
本実施形態における図6〜図8,図12,図13に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。
そして、その場合、CD−ROMやフラッシュメモリやFD等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等、プログラムの形態を問わない。
プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、MO、CD−ROM、CD−R、CD−RW、磁気テープ、不揮発性のメモリカード、ROM、DVDなどを用いることができる。
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。
つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるWWWサーバやftpサーバ等も本発明の請求項に含まれるものである。
また、本発明のプログラムを暗号化してCD−ROM等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでない。例えば、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行わせる。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形(各実施形態の有機的な組合せを含む)が可能であり、それらを本発明の範囲から排除するものではない。
また、ホストコンピュータ3000において各種処理を行う機能を実現する為のプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませる。そして、そのプログラムを実行することにより各処理を行っても良い。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
さらに「コンピュータ読み取り可能な記録媒体」とは、揮発メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。
具体的には、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発メモリ(RAM)である。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。
ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現する為のものであっても良い。
さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であっても良い。
また、上記のプログラムを記録したコンピュータ読み取り可能な記録媒体等のプログラムプロダクトも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体およびプログラムプロダクトは、本発明の範疇に含まれる。
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。
本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではなく、以下の実施態様も含まれることはいうまでもない。
例えば印刷処理関連プログラムにより実現可能な機能に更に複数の拡張機能を付与可能なデータ処理装置であって、
2つ以上の設定値の間で成立する依存関係に応じて定めた第1のコンフリクト処理ルール(図4に示すコンフリクト処理ルール308)として格納する第1のルール格納手段(例えば図1に示す外部メモリ11)と、
前記印刷処理関連プログラムの機能と、前記複数の拡張機能に入力される設定値の間で成立する依存関係に応じて定めた第2のコンフリクト処理ルール(図4に示すコンフリクト処理ルール311)として格納する第2のルール格納手段(例えば図1に示す外部メモリ11)と、
前記第1のルール格納手段及び前記第2のルール格納手段から、前記第1のコンフリクト処理ルール及び前記第2のコンフリクト処理ルールを読み込み、読み込んだ前記第1のコンフリクト処理ルール及び前記第2のコンフリクト処理ルールを基にして、前記複数の機能と前記複数の拡張機能とのいずれか2つの設定間に不整合が生じないよう設定値の調整処理を行う設定調整手段(図3に示すプリンタドライバ307のコンフリクトマネージャ303)とを具備することを特徴とするデータ処理装置。
これにより、印刷処理関連プログラム(プリンタドライバ)にプラグイン形式で新たな機能を複数追加したデータ処理環境下においても、各機能独自設定に伴う不整合状態を判別できる。そして、自動的、かつ的確なコンフリクト処理を実現して、各機能独自の設定が不整合状態であっても、正常な印刷を実行可能な印刷設定環境に自動調整できる。そして、追加される複数の機能に対する印刷設定を正常に行い、意図する印刷結果を正常に得られる印刷設定環境を自在に構築できる。
また、前記複数の拡張機能が付与されている場合に、前記第2のコンフリクト処理ルールが第2のルール格納手段に格納されているか否かを確認する確認手段(図3に示すプリンタドライバ307のコンフリクトマネージャ303)を設けても良い。
これにより、追加される拡張機能に対するプラグインモジュールに対応した第2のコンフリクト処理ルールを確実に読み込むことができる。
さらに、前記設定調整手段は、前記第1のコンフリクト処理ルール及び前記第2のコンフリクト処理ルールを優先度の高い順に適用して、前記複数の機能と前記複数の拡張機能とのいずれか2つの設定間に不整合が生じないよう設定の調整処理をしてもよい。
これにより、プリンタドライバの設定機能と追加される各拡張機能間での不整合な設定を自動的に調整できる。
また、種々の情報を表示する表示手段(図1に示すCRT10)と、
利用者が視覚的に前記複数の機能及び前記複数の拡張機能の設定状態を確認可能な設定状態画面を前記表示手段に表示する画面表示手段(図3に示すプリンタドライバ307)とを更に具備し、
前記画面表示手段が前記表示手段に表示する前記設定状態画面は、前記設定調整手段により設定の調整処理後の設定状態を示すものであってもよい。
これにより、複数の拡張機能とプリンタドライバとの設定とが調整された設定状態をユーザに変更された設定状態を確認させることができる。
さらに、前記画面表示手段が前記表示手段に表示する前記設定状態画面において、
前記複数の機能及び前記複数の追加機能の各設定は、利用者の操作により変更可能であり、利用者が一つまたは複数の機能または前記複数の追加機能の設定を変更した場合に、前記設定調整手段は、読み込んだ前記第1のコンフリクト処理ルール及び前記第2のコンフリクト処理ルールを基にして、変更後の複数の機能と複数の拡張機能とのいずれか2つの設定間に不整合が生じないよう設定の調整処理を行うこととしてもよい。
これにより、ユーザの設定に対して、プリンタドライバの設定と各機能設定との整合性を勘案して設定状態を調整して、ユーザから不整合となるような設定がなされても、不整合を回避する設定状態を表示することができる。