(57)【特許請求の範囲】
【請求項１】
操作を受け付ける操作受け付け手段と、
前記操作受け付け手段が印刷開始又は送信開始の指示を受け付けた後、印刷又は送信の設定条件を表示し変更を受け付ける設定受け付け手段と、
文書データ提供手段から印刷対象又は送信対象の文書データを取得して前記設定条件に基づき印刷装置の印刷データに変換する画像処理手段と、を有する情報処理装置であって、
印刷開始又は送信開始の指示によりオペレーティングシステムが生成した印刷処理又は送信処理の識別情報を取得した前記設定受け付け手段が、オペレーティングシステムを介して前記識別情報をキーに前記設定条件を記憶させるLanguageMonitor、を有し、
オペレーティングシステムから前記識別情報を取得した前記画像処理手段が、前記識別情報をキーにオペレーティングシステムを介して前記LanguageMonitorから前記設定条件を読み出し、該設定条件に基づき文書データを印刷装置の印刷データに変換する、
ことを特徴とする情報処理装置。
【請求項２】
前記設定受け付け手段が、印刷開始又は送信開始の指示を受け付けた後、印刷又は送信の設定条件を表示する場合、前記設定受け付け手段はオペレーティングシステムの所定のＡＰＩ関数をコールすることで、前記画像処理手段から前記設定条件を取得する、
ことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記設定受け付け手段は、印刷又は送信の前記設定条件を表示した後、前記操作受け付け手段が受け付けた印刷実行若しくは送信実行、又は、印刷中止若しくは送信中止の操作結果を取得し、前記設定条件と共に前記LanguageMonitorに記憶し、
前記画像処理手段が、前記LanguageMonitorから読み出した前記操作結果が印刷中止若しくは送信中止である場合、文書データの印刷データへの変換を中止する、
ことを特徴とする請求項１又は２記載の情報処理装置。
【請求項４】
前記設定受け付け手段は、オペレーティングシステムの所定のＡＰＩ関数をコールすることで、前記LanguageMonitorに前記識別情報をキーにして前記設定条件を記憶する、
ことを特徴とする請求項１〜３いずれか１項記載の情報処理装置。
【請求項５】
前記画像処理手段は、オペレーティングシステムの所定のＡＰＩ関数をコールすることで、前記識別情報をキーにして前記LanguageMonitorから前記設定条件を読み出す、
ことを特徴とする請求項４記載の情報処理装置。
【請求項６】
オペレーティングシステムは、前記操作受け付け手段が印刷開始又は送信開始の指示を受け付ける毎に、当該情報処理装置内で一意の前記識別情報としてJobIDを生成する、
ことを特徴とする請求項１〜５いずれか１項記載の情報処理装置。
【請求項７】
オペレーティングシステムは、異なる前記文書データ提供手段が提供した文書データの印刷処理又は送信処理に対し一意の前記識別情報を生成し、
同じ前記文書データ提供手段が提供した異なる文書データの印刷処理又は送信処理に対し一意の前記識別情報を生成し、
同じ前記文書データ提供手段が提供した同じ文書データの異なる印刷処理又は送信処理に対し一意の前記識別情報を生成する、
ことを特徴とする請求項６記載の情報処理装置。
【請求項８】
前記操作受け付け手段が印刷開始又は送信開始の指示を受け付けた後、オペレーティングシステムが印刷装置に依存しない中間印刷データを生成するまでに、前記設定受け付け手段が、前記識別情報をキーにして前記設定条件を前記LanguageMonitorに記憶しておき、
オペレーティングシステムが前記文書データ提供手段を印刷処理又は送信処理から開放した後、
オペレーティングシステムに呼び出された前記画像処理手段が、前記識別情報をキーに前記LanguageMonitorから前記設定条件を読み出す、
ことを特徴とする請求項１〜７いずれか１項記載の情報処理装置。
【請求項９】
第１の情報処理装置、第２の情報処理装置、及び、印刷装置がネットワークを介して接続されたシステムにおいて、
操作を受け付ける操作受け付け手段と、
前記操作受け付け手段が印刷開始又は送信開始の指示を受け付けた後、印刷又は送信の設定条件を表示し変更を受け付ける設定受け付け手段と、
文書データ提供手段から印刷対象又は送信対象の文書データを取得して前記設定条件に基づき印刷装置の印刷データに変換する画像処理手段と、
印刷開始又は送信開始の指示により前記第２の情報処理装置のオペレーティングシステムが生成した印刷処理又は送信処理の識別情報を取得した前記設定受け付け手段が、前記第１の情報処理装置及び前記第２の情報処理装置のオペレーティングシステムを介して前記識別情報をキーにして前記設定条件を記憶させる、前記第２の情報処理装置に設けられたLanguageMonitorと、を有し、
前記第２の情報処理装置のオペレーティングシステムから前記識別情報を取得した前記画像処理手段が、少なくとも前記第２の情報処理装置のオペレーティングシステムを介して前記識別情報をキーに前記LanguageMonitorから前記設定条件を読み出し、該設定条件に基づき文書データを印刷装置の印刷データに変換する、
ことを特徴とするシステム。
【請求項１０】
前記操作受け付け手段、前記設定受け付け手段、及び、前記画像処理手段を前記第１の情報処理装置が有し、前記第１の情報処理装置は印刷データを前記第２の情報処理装置に送信する、ことを特徴とする請求項９記載のシステム。
【請求項１１】
前記操作受け付け手段、及び、前記設定受け付け手段を前記第１の情報処理装置が有し、前記画像処理手段を前記第２の情報処理装置が有し、
前記第１の情報処理装置は、前記第１の情報処理装置のオペレーティングシステムが文書データから変換した印刷装置に依存しない中間印刷データを前記第２の情報処理装置に送信し、
前記画像処理手段は、前記識別情報をキーに前記第２の情報処理装置の前記LanguageMonitorから前記設定条件を読み出し、該設定条件に基づき中間印刷データを印刷装置の印刷データに変換する、
ことを特徴とする請求項９記載のシステム。
【請求項１２】
操作を受け付ける操作受け付け手段、を有する情報処理装置に、
前記操作受け付け手段が印刷開始又は送信開始の指示を受け付けた後、印刷又は送信の設定条件を表示し変更を受け付ける設定受け付けステップと、
印刷開始又は送信開始の指示によりオペレーティングシステムが生成した印刷処理又は送信処理の識別情報を設定モジュールが取得する識別情報受け付けステップと、
オペレーティングシステムを介して、前記識別情報をキーにして前記設定条件をLanguageMonitorに記憶させるステップと、
オペレーティングシステムから画像処理モジュールが前記識別情報を取得するステップと、
前記画像処理モジュールが、前記識別情報をキーにオペレーティングシステムを介して前記LanguageMonitorから前記設定条件を読み出すステップと、
前記画像処理モジュールが、文書データ提供手段から提供された印刷対象又は送信対象の文書データを、前記LanguageMonitorから読み出した前記設定条件に基づき印刷装置の印刷データに変換するステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷対象又は送信対象の文書データを取得して印刷装置に送出する情報処理装置に関する。
【背景技術】
【０００２】
ユーザがコンピュータで文書作成ソフトや表計算ソフト、画像編集ソフト等の各種アプリケーションプログラム（以下単に「アプリケーション」という）を実行して、印刷したりＦＡＸ送信することがしばしば行われる。この場合、オペレーティングシステム（ＯＳ）上で印刷装置やＦＡＸ装置を制御するためのドライバ（プログラム）を実行することにより、印刷装置やＦＡＸ装置の制御に必要な処理をアプリケーションから切り離している。
【０００３】
プリンタドライバ・PC-FAXドライバの印刷・ＦＡＸ送信は、次のような手順で行われる。
１．ユーザがアプリケーションの印刷メニューから印刷設定画面を表示し、印刷設定を決定する
２．ユーザがアプリケーションに印刷開始指示を行う
プリンタドライバは、１.で決定した印刷設定を２.で受け取ることにより、印刷設定に基づいて、アプリケーションから受け取る文書データをプリンタが解釈可能な印刷データに変換する。プリンタはそれを取得して印刷やＦＡＸ送信を実行する。
【０００４】
ところが、このような動作シーケンスでは、ユーザによる印刷開始指示後に印刷設定を変更して印刷を実行することはできないとされていた。そこで、印刷開始指示後にユーザが印刷設定を変更することを可能にする技術が提案されている（例えば、特許文献１参照。）。
【０００５】
Ａ．従来技術の説明のため、まず、Windows（登録商標、以下（R）と略す）の印刷アーキテクチャについて説明する。Windows（R）の印刷アーキテクチャでは、アプリケーションからの印刷設定・印刷開始指示はＡＰＩを使ってＯＳのＧＤＩに対して命令を通知する。このＧＤＩはＯＳの一部である。
【０００６】
ＧＤＩから、プリンタドライバ・PC-FAXドライバに対して、印刷設定・印刷開始指示の命令がＤＤＩで通知される。ＤＤＩはI/Fのみ定義されているので、ＤＤＩ内の実装方法は各メーカ(各プリンタドライバ・PC-FAXドライバ)で自由である。印刷中にコールされるＤＤＩの実装で、ダイアログを表示することもできる。この印刷中にコールされるＤＤＩ名は「DrvDocumentEvent()」である。
【０００７】
ＤＤＩを利用することで、ユーザによる印刷開始指示後、プリンタにデータを送信する前にダイアログを表示することが可能となる。このような技術は、印刷の度にパスワードを入力させたり、ＦＡＸの宛先指定を行わせることをユーザに強制させたい場合に利用されている。
【０００８】
以下、具体例としてプリンタドライバに搭載された機密印刷機能と、PC-FAXドライバに搭載された宛先確認機能を例にして説明する。
【０００９】
図１は、プリンタドライバの機密印刷機能の画面例を示す図である。印刷開始指示後、機密印刷機能により、ユーザＩＤとパスワードの入力が要求される。ユーザは、ユーザＩＤとパスワードを入力しないと、ＯＫボタン５０１を押下できない。ユーザがユーザＩＤとパスワードを入力してＯＫボタン５０１を押下すると、ユーザＩＤとパスワードがプリンタに送信される。プリンタ本体側にはユーザＩＤとパスワードの組が予め登録されており、この組み合わせが一致しないとプリンタは印刷しない。この機密印刷機能では、よりセキュリティを高めるために、印刷ごとにパスワードを毎回入力させるようにすることも可能である。なお、ユーザがキャンセルボタン５０２を押下すると、印刷が中止される。
【００１０】
図２は、PC-FAXドライバの宛先確認機能の画面例を示す図である。印刷開始指示後、PC-FAXドライバは図示するダイアログを表示して、ユーザにFAXの宛先（ＦＡＸ番号）の入力を要求する。ＦＡＸ送信においては、宛先が送信毎ごとに異なることが多いため、PC-FAXドライバは、誤送信を防ぐためにこのような画面を表示する。
【００１１】
ユーザがＦＡＸ番号を入力し、送信ボタン５０３を押下すると、画像データがＦＡＸ装置に送信され、ＦＡＸ装置がＦＡＸを送信する。なお、ユーザがキャンセルボタン５０４を押下すると、ＦＡＸ送信が中止される。
【００１２】
ところで、Windows（R）の印刷時の仕組みとして、プリンタドライバの印刷では、ＲＡＷスプール形式とＥＭＦスプール形式といった２つのスプール形式が存在する。ＲＡＷスプール形式では、アプリケーションのプロセスで、アプリケーションからプリンタドライバが取得した文書データをプリンタが解釈可能なＲＡＷデータに変換する印刷処理を行う。ユーザから見ると印刷処理が完了するまでアプリケーションの操作ができない。
【００１３】
ＥＭＦスプール形式では、アプリケーションのプロセスで、アプリケーションからＯＳが取得した文書データをプリンタに依存しないＥＭＦデータ形式に変換しスプールする。そして、スプーラプロセスでスプールされたＥＭＦデータをプリンタドライバが、プリンタが解釈可能なＲＡＷデータに変換する印刷処理を行う。ユーザから見ると、アプリケーションのプロセスでＥＭＦデータへの変換が終了した時点で、アプリケーションを操作できるようになる。
【００１４】
いずれの仕組みでも、ＤＤＩの実装方法として、印刷開始後にダイアログを表示して印刷設定画面を表示できるようにすることは可能である。
【００１５】
しかし、ユーザが変更した印刷設定を印刷データに反映する仕組みが、ＯＳから呼び出されるＤＤＩだけでは実現することができない。プリンタドライバは、ユーザとのやりとりによって印刷設定を決定するＵＩドライバと、アプリケーションから受け取った文書データを印刷設定にもとづき、プリンタが解釈可能なデータ形式の印刷データに変換する描画ドライバとを有している。
【００１６】
描画ドライバは、ＯＳのシステム権限で動作するため、ダイアログの表示をすることはＯＳに対する親和性を低下させてしまう。そのため、印刷開始指示後(印刷中)に印刷設定を変更するようにするためには、ＵＩドライバがもつＤＤＩのDrvDocumentEvent()を利用しダイアログを表示する。このＤＤＩは描画ドライバが印刷を行っている間にコールされるＵＩドライバのＤＤＩである。ＵＩドライバであれば、アプリケーションと同等の権限で動作するためＯＳとの親和性は低下しない。
【００１７】
しかし、描画ドライバとＵＩドライバは別モジュールであり、直接通信して情報のやりとりをすることはできない。基本的にドライバはＯＳからＤＤＩとして呼ばれるだけだからである。
【００１８】
Windows（R）の印刷の処理手順は上記のようになっているため、ユーザによる印刷開始指示後、プリンタに出力されるまでの間にダイアログを表示し、印刷設定に変更を加えたい場合、それを反映することが困難になっている。
【００１９】
特許文献１では、上記のような問題を解決するために、印刷開始後に変更した情報を一時ファイルに出力するという手法を使い、実現している。
【００２０】
Ｂ．次に、プリンタドライバ又はPC-FAXドライバのインストール方式と、印刷開始後の印刷設定の関係について説明する。Windows（R）のプリンタドライバではPoint&Printというインストール形式が存在する。
【００２１】
図３は、Point&Printの概略を説明する図の一例である。ネットワークにプリンタ、サーバＰＣ及びクライアントＰＣが接続されている。サーバＰＣ及びクライアントＰＣにWindows（R）系のＯＳ(サーバはサーバ用)がインストールされている。
【００２２】
クライアントＰＣは、このサーバＰＣをプリントサーバとして、プリンタに対して印刷要求することができる。このようなシステムでは、クライアントＰＣにはサーバＰＣと同じプリンタドライバがインストールされている必要がある。ネットワーク上の個々のクライアントＰＣに、管理者などがプリンタドライバをインストールするには非常にコストがかかってしまう。
【００２３】
Point&Printではこの不都合を解決する手段として、サーバＰＣからクライアントＰＣにプリンタドライバをダウンロードしてインストールすることを可能にしている。これは、Windows（R）系OS標準の機能である。なお、Point&Printによる印刷手順においても、印刷時にはＲＡＷスプール形式とＥＭＦスプール形式が存在する。
【００２４】
Point&Printによりインストールされたプリンタドライバは（ＥＭＦスプールの場合）、描画処理（レンダリングともいい、上記の描画ドライバによる処理）をクライアントＰＣが行うかサーバＰＣが行うかをユーザが変更することができる。クライアントＰＣ側で描画処理を行うことを「クライアントサイドレンダリング」という。サーバＰＣ側で描画処理を行う「サーバサイドレンダリング」という。
【発明の概要】
【発明が解決しようとする課題】
【００２５】
しかしながら、一時ファイルを使う手法では、プリンタドライバが動作しているタイミングやユーザの権限レベルによって、プリンタドライバが一次ファイルに確実に出力できるとは限らないという問題がある。また、仮に、一時ファイルに出力できたとしても複数アプリケーションが動いている環境では設定が上書きされてしまう可能性がある。
【００２６】
図４は、複数アプリと一時ファイルの関係を模式的に説明する図の一例である。アプリケーション１，２は一台のＰＣで動作している、それぞれ文書データを印刷可能なアプリケーションである。
(i)アプリケーション１の要求を受けてＵＩドライバが一時ファイルに設定を書き込む。
(ii)アプリケーション２の要求を受けてＵＩドライバが一時ファイルに設定を書き込む。
(iii) アプリケーション１の要求を受けて描画ドライバが一時ファイルの設定を読み込む際には、一時ファイルの内容が書き換わっている。
【００２７】
この問題を解決するために、印刷設定を保存する場所を一時ファイルとするのでなく、印刷設定保持用モジュールを利用して、そこに印刷設定を保持させる方法を用い、上記の問題を解消することは可能であった。
【００２８】
しかし、この方法でも解消できないケースが２つある。
Ａ.について：ＥＭＦスプールでの印刷シーケンスのケース
Ｂ.について：Point&Printインストールしたプリンタドライバでの印刷シーケンスのケース
Ａ.について
印刷設定保持用モジュールを使用した方法は、印刷時のＤＤＩコールシーケンスを利用しており、ＲＡＷスプールの時は実現可能である。しかし、スプール形式が異なると、ＯＳから呼ばれるＤＤＩコールシーケンスが変化する。ＥＭＦスプールでは、アプリケーションからの文書データをＥＭＦデータに変換する処理と、ＥＭＦデータをプリンタが解釈可能な描画データに変換する処理とがある。このため、ＯＳ内部の動作として、２回の印刷処理シーケンスが動作する。この結果、ＤＤＩコールシーケンスがＲＡＷスプールよりも複雑になってしまうため、期待するタイミングで印刷設定の受け渡しができない。
【００２９】
Ｂ.について
印刷設定保持用モジュールを使用した方法は、ローカル環境で、ユーザが使用するＰＣにプリンタドライバをインストールした場合は実現可能である。しかし、Point&Printというインストール形式では、ユーザの設定によってＵＩドライバと描画ドライバが動作する場所が異なるようにすることができる（サーバサイドレンダリング）。
【００３０】
クライアントサイドレンダリングでは、ＵＩドライバ、描画ドライバともにクライアントＰＣ側で動作するが、サーバサイドレンダリングでは、ＵＩドライバはクライアントＰＣ側で動作し、描画ドライバはサーバＰＣ側で動作をする。このサーバサイドレンダリングでは、そもそも動作するＰＣが物理的に別であるため、印刷設定保持モジュールがクライアントＰＣ側にしか存在しない状況になる。この場合、サーバの描画ドライバは印刷設定保持モジュールから印刷設定を取得できない。
【００３１】
図５は、従来技術における、印刷開始後の印刷設定の変更の実現可否状況を一覧にした図の一例である。上記のように、インストール環境がローカルでスプール形式がＥＭＦスプールの場合、及び、インストール環境がPoint＆Printでスプール形式がＥＭＦスプールでレンダリング場所がサーバの場合、印刷開始後の印刷設定の変更が困難である。
【００３２】
本発明は、上記課題に鑑み、印刷開始後の印刷設定を、スプール形式の違いやプリンタドライバのインストール環境に関係なく可能とする情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００３３】
本発明は、操作を受け付ける操作受け付け手段と、前記操作受け付け手段が印刷開始又は送信開始の指示を受け付けた後、印刷又は送信の設定条件を表示し変更を受け付ける設定受け付け手段と、文書データ提供手段から印刷対象又は送信対象の文書データを取得して前記設定条件に基づき印刷装置の印刷データに変換する画像処理手段と、を有する情報処理装置であって、印刷開始又は送信開始の指示によりオペレーティングシステムが生成した印刷処理又は送信処理の識別情報を取得した前記設定受け付け手段が、オペレーティングシステムを介して前記識別情報をキーに前記設定条件を記憶させるLanguageMonitor、を有し、オペレーティングシステムから前記識別情報を取得した前記画像処理手段が、前記識別情報をキーにオペレーティングシステムを介して前記LanguageMonitorから前記設定条件を読み出し、該設定条件に基づき文書データを印刷装置の印刷データに変換する、ことを特徴とする。
【発明の効果】
【００３４】
印刷開始後の印刷設定を、スプール形式の違いやプリンタドライバのインストール環境に関係なく可能とする情報処理装置を提供することができる。
【図面の簡単な説明】
【００３５】
【図１】プリンタドライバの機密印刷機能の画面例を示す図である。
【図２】PC-FAXドライバの宛先確認機能の画面例を示す図である。
【図３】Point&Printの概略を説明する図の一例である。
【図４】複数アプリと一時ファイルの関係を模式的に説明する図の一例である。
【図５】従来技術における、印刷開始後の印刷設定の変更の実現可否状況を一覧にした図の一例である。
【図６】プリンタドライバの概略的な特徴を説明する図の一例である。
【図７】印刷システムの概略構成図の一例を示す図である。
【図８】ＰＣ及びプリンタドライバの機能ブロック図の一例である。
【図９】LanguageMonitorの動作を説明する図の一例である
【図１０】Windows（R）印刷アーキテクチャにおける、描画ドライバとＵＩドライバについて説明する図の一例である。
【図１１】ＲＡＷスプールにおける、Windows（R）プリントアーキテクチャの流れを説明する図の一例である（従来図）。
【図１２】図１１のWindows（R）プリントアーキテクチャのシーケンス図の一例である（従来図）。
【図１３】ＥＭＦスプールにおける、Windows（R）プリントアーキテクチャの流れを説明する図の一例である（従来図）。
【図１４】図１３のWindows（R）プリントアーキテクチャのシーケンス図の一例である（従来図）。
【図１５】ExtEscape()関数の書式を説明する図の一例である。
【図１６】DrvDocumentEvent()関数の書式、SendRecvBidiDataFromPort()の書式を説明する図の一例である。
【図１７】PBIDI_REQUEST_CONTAINER構造体の書式、BIDI_REQUEST_DATA 構造体の書式を示す図の一例である
【図１８】OSが付与するJobIDを模式的に説明する図の一例である。
【図１９】LanguageMonitorに記憶されるJobIDと印刷設定を模式的に説明する図の一例である。
【図２０】ＲＡＷスプールのWindows（R）プリントアーキテクチャのシーケンス図の一例である。
【図２１】ＥＭＦスプールのWindows（R）プリントアーキテクチャのシーケンス図の一例である。
【図２２】Point＆Print環境を備えた印刷システムの概略構成図の一例を示す。
【図２３】Point&Print環境におけるLanguageMonitorの位置づけを説明する図の一例である。
【図２４】Point&Print環境におけるJobIDについて説明する図の一例である。
【図２５】Point&Print環境におけるＲＡＷスプールの印刷手順を模式的に説明する図の一例である。
【図２６】Point&Print環境におけるＥＭＦスプール（クライアントサイドレンダリング）の印刷手順を模式的に説明する図の一例である。
【図２７】Point&Print環境におけるＥＭＦスプール（サーバサイドレンダリング）の印刷手順を模式的に説明する図の一例である。
【発明を実施するための形態】
【００３６】
以下、本発明を実施するための形態について図面を参照しながら説明する。
図６は、本実施形態のプリンタドライバの概略的な特徴を説明する図の一例である。ＰＣ（Personal Computer）がWindows（R）系のＯＳ上でアプリケーションを実行している。Windows（R）系の印刷アーキテクチャでは、図示するようなソフトウェア階層により、アプリケーションの文書データがプリンタにより印刷される。ここではスプール形式を区別していない。
【００３７】
Windows（R）系ＯＳのクライアント系には、Windows（R）NT、Windows（R）98、Windows（R）2000、Windows（R）Me、Windows（R）XP、Windows（R）Vista、Windows（R）７及びこれ以降のバージョンのＯＳが含まれる。サーバ系には、Windows（R） 2000 Server、2003 Server、2008 Server及びこれ以降のバージョンのＯＳが含まれる。
１．アプリケーション印刷処理開始
２．アプリケーションが ＯＳのＧＤＩ ＡＰＩ を呼び出す（プリンタデバイスコンテキストの確保）。
３．プリンタドライバ３０が描画データを生成する
４．LanguageMonitor３２が必要な処理を行う
５．ポートモニタ３３が、プリンタ ポートの種類 (USB, TCP/IP etc) に合わせて出力処理を行う
６．プリンタに描画データが送信される
本実施例では、このような印刷アーキテクチャにおいて、ＯＳ１０が生成するJobIDとLanguageMonitor３２を利用する。ＯＳ１０は印刷ジョブの１つ１つにJobIDを付与する。JobIDはプリンタドライバ３０に通知される。
【００３８】
Windows（R）系OSでは、プリンタドライバ３０は、ＯＳ１０が提供するLanguageMonitor３２を使用してもメーカ（プリンタメーカ、FAXメーカ等）が提供するLanguageMonitor３２を使用してもよいとされている。本実施形態では、LanguageMonitor３２を単にポートモニタ３３とのインタフェースとするのでなく、印刷設定とJobIDを対応づけて記憶する手段として利用する。
【００３９】
プリンタドライバ３０のＵＩドライバは、アプリケーションから取得した印刷設定と共にJobIDをLanguageMonitor３２に通知する。LanguageMonitor３２は印刷設定とＯＳが生成したJobIDを対応づけて記憶する。LanguageMonitor３２はJobIDをキーに印刷設定を管理するので、他のアプリケーションが印刷設定を上書きするようなことはない。
【００４０】
また、描画ドライバが印刷設定を読み出す際、JobIDを指定することでＵＩドライバが生成した印刷設定を、LanguageMonitor３２から取得することができる。このように、描画ドライバは一意に印刷設定を特定できる。
【００４１】
また、LanguageMonitor３２は、Windows（R）系ＯＳの機能なので、Point＆Print環境のサーバＰＣ上で利用可能である。このため、ＵＩドライバはサーバＰＣのLanguageMonitor３２にアクセスできるし、サーバＰＣの描画ドライバが描画処理する際も、LanguageMonitor３２からJobIDで指定した印刷設定を取得することができる。このように、本実施形態の印刷設定の管理手法は、Point＆Print環境においてもローカルインストールされたプリンタドライバと同様に有効である。
【００４２】
したがって、本実施形態の印刷設定の管理方法は、スプール形式及びインストール環境に関係なく、印刷開始後の印刷設定の変更が可能である。
【実施例１】
【００４３】
〔構成例〕
図７（ａ）は印刷システム４００の概略構成図の一例を、図７（ｂ）はＰＣ１００のハードウェア構成図の一例をそれぞれ示す。ＰＣ１００とプリンタ２００がネットワーク３００を介して接続されている。プリンタ２００は１台のみあればよい。
【００４４】
ＰＣ１００がユーザの操作を受け付け、文書作成ソフトなどのアプリケーションが、ＧＤＩ、ＤＤＩ及びプリンタドライバ等を利用して印刷を要求する。プリンタドライバ３０は、後述する手順で印刷データを作成してプリンタ２００に送信する。プリンタ２００は画像形成機能を有していれば、コピー機、複写機、ＦＡＸ装置などその呼称は問われない。また、プリンタ２００は電子写真方式の画像形成機能又はインクジェット方式の画像形成機能のどちらの機能を有していてもよい。また、ＰＣ（Personal Computer）１００とプリンタ２００はＵＳＢケーブルなどで直接接続されていてもよい。
【００４５】
ＰＣ１００は、それぞれバスで相互に接続されているＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、外部Ｉ／Ｆ１４、通信装置１５、入力装置１６、表示制御部１７及び記憶装置１８を有する。ＣＰＵ１１は、ＯＳ（Operating  System）１０、アプリケーション３１、及び、プリンタドライバ３０を記憶装置１８から読み出して、ＲＡＭ１０３を作業メモリにして実行する。
【００４６】
アプリケーション３１は、プリンタ２００に印刷要求するものであればよく、例えば、文書作成ソフト、ブラウザソフト、プレゼン資料作成ソフト等、種々のものがある。印刷対象となる文書データを、作成、編集、表示、管理などして、印刷可能なアプリケーションであればどのようなものでもよい。なお、文書データは、文字や記号、数値だけを含むものではなく、画像、写真など種々の印刷対象物を含む。
【００４７】
ＲＡＭ１３は必要なデータを一時保管する作業メモリ（主記憶メモリ）になり、ＲＯＭ１２にはＢＩＯＳや初期設定されたデータ、スタートプログラム等が記憶されている。
【００４８】
外部Ｉ／Ｆ１４はＵＳＢケーブル等のケーブルや、可搬型の記憶媒体２０を装着するインタフェースである。通信装置１５は、ＬＡＮカードやイーサネット（登録商標）カードであり、ＣＰＵ１１からの指示によりプリンタ２００にパケットデータ（本実施形態では主に印刷データ）を送信する。
【００４９】
入力装置１６は、キーボード、マウスなど、ユーザの様々な操作指示を受け付けるユーザインターフェイスである。タッチパネルや音声入力装置を入力装置とすることもできる。表示制御部１７は、アプリケーション３１が指示する画面情報に基づき所定の解像度や色数等でディスプレイ１９の描画を制御する。ディスプレイ１９は、液晶や有機ＥＬなどのＦＰＤ（Flat  Panel  Display）である。
【００５０】
記憶装置１８は、ＨＤＤ（Hard  Disk  Drive）やフラッシュメモリなどの不揮発メモリを実体とし、ＯＳ１０、プリンタドライバ３０、及び、アプリケーション３１を記憶している。
【００５１】
記憶媒体２０は、例えば、ＳＤカードやＵＳＢメモリなど不揮発性のメモリである。ＯＳ１０、アプリケーション３１、及び、プリンタドライバ３０は、記憶媒体２０に記録された状態又は不図示のサーバからダウンロードされる態様で配布される。
【００５２】
図８は、ＰＣ１００及びプリンタドライバ３０の機能ブロック図の一例である。ＰＣ１００は、Windows（R）系ＯＳ上で動作する、アプリケーション３１、プリンタドライバ３０、LanguageMonitor３２、及び、ポートモニタ３３を有する。このうち、LanguageMonitor３２、及び、ポートモニタ３３がＯＳ１０により提供されため、広義ではＯＳ１０の一部である。この他のＧＤＩ、スプーラ、プリンタプロセッサなどは省略したが、ＯＳ１０と共にＰＣ１００にインストールされている。
【００５３】
プリンタドライバ３０は、ＵＩドライバ３８と描画ドライバ３９を有している。さらにＵＩドライバ３８は表示部３８１を有する。ＵＩドライバ３８の表示部３８１は、ユーザがアプリケーションに対して文書の印刷操作を入力することで、印刷設定画面（印刷ダイアログと呼ばれることがある）をディスプレイ１９に表示する。ユーザは、印刷設定画面に対し、部数や両面などといった設定、「集約」「製本」「変倍」等の設定を行うことができる。また、ＵＩドライバ３８の表示部３８１は、ユーザが印刷開始指示を入力した後も、印刷設定画面をディスプレイ１９に表示して、印刷設定の変更を受け付けることができる。印刷設定は、DEVMODE構造体（以下、DEVMODEという）という構造体（データテーブル）に格納される。DEVMODEはＯＳ上で動作する各種のプリンタドライバ３０に対して印刷条件を共通に設定するためのメンバ変数が定義されたデータ構造である。
【００５４】
描画ドライバ３９は、DEVMODEを参照して、アプリケーション３１によって印刷対象の文書データから印刷設定を反映した印刷データを作成する。なお、印刷データには描画データ（例えばＰＤＬデータ）と制御データ（例えばＰＪＬの印刷コマンド）が含まれる。
【００５５】
LanguageMonitor３２はプリンタドライバ３０との結合性が高いモジュールである。LanguageMonitor３２は、ポートモニタ３３に送信する印刷データをフィルタリングすることができる。本実施例のLanguageMonitor３２は、データ保持部３２１と通信部３２２を有する。このうち、通信部３２２は、プリンタドライバ３０がポートモニタ３３に印刷データを送信する際に、通信を制御するものであり、従来のLanguageMonitor３２が有している。通信部３２２はプリンタ２００からのメッセージを受信することもできる。これに対し、データ保持部３２１は、JobIDをキーに印刷設定を対応づけて記憶する。データ保持部３２１は、LanguageMonitor３２の機能を利用してプリンタドライバ３０により実現される。このため、ＯＳ１０の変更は必要ないか、あったとしてもわずかである。データ保持部３２１については後述する。
【００５６】
図９は、LanguageMonitor３２の動作を説明する図の一例である。LanguageMonitor３２はプリントプロセッサ４１から送信された印刷データを受け取り、ポートモニタ３３に送信する。ポートモニタ３３は、通信プロトコルに基づく処理を行い、ポートドライバ４３に印刷データを送信する。ポートドライバ４３は、プリンタ２００とＰＣ１００との接続インタフェース（USB,NIC等）を制御して、印刷データをプリンタ２００に送信する。
【００５７】
〔従来のWindows（R）系ＯＳの印刷アーキテクチャ〕
図１０は、Windows（R）系ＯＳの印刷アーキテクチャにおける、描画ドライバ３９とＵＩドライバ３８について説明する図の一例である。
【００５８】
ＯＳ１０のＧＤＩ３４はＤＤＩコールによりプリンタドライバ３０のＵＩドライバ３８と描画ドライバ３９を呼び出す。ＵＩドライバ３８と描画ドライバ３９は、直接相互にやりとりをすることができない。しかし、ＯＳ１０からのドライバの呼び出しI/FであるＤＤＩの引数にDEVMODEがあることにより、双方がDEVMODEを参照することができる。
・ＯＳ１０から呼び出されたＵＩドライバ３８は、ユーザの印刷設定を受け付けDEVMODEに保存する
・DEVMODEは印刷準備開始時にＯＳ１０から描画ドライバ３９に渡される
すなわち、ＵＩドライバ３８は、「印刷設定」を決定し、描画ドライバ３９は「印刷設定」を印刷準備開始時に受け取り、印刷設定に基づき印刷コマンドや描画データを生成する。これがWindows（R）系ＯＳの印刷アーキテクチャの基本的な印刷シーケンスとなる。描画ドライバ３９は、ＵＩドライバ３８に続いて処理するので、一般的なプリンタドライバ３０では、ユーザの印刷開始指示後に印刷設定を変更することはできない。
【００５９】
図１１は、ＲＡＷスプールにおける、Windows（R）系ＯＳの印刷アーキテクチャの流れを説明する図の一例である。
（１）ユーザが、ＵＩドライバ３８が提供する印刷ダイアログ（ＧＵＩ）によって印刷設定を変更する（すでに登録されている初期値を変更する）。
（２）ユーザがアプリケーションに印刷開始指示の操作を行う。
（３）アプリケーションはＵＩドライバ３８と印刷設定が入っているDEVMODEをやりとりして、ユーザの印刷設定を受け取る。
（４）アプリケーションはＧＤＩ３４に印刷命令とDEVMODEをＧＤＩコールとして伝える。
（５）ＧＤＩ３４はＧＤＩコールをＤＤＩコールに変換して描画ドライバ３９に伝える。
（６）描画ドライバ３９は、プリンタが理解できる言語に変換したＲＡＷデータをスプーラ３５に送出する。
（７）スプーラ３５は、描画ドライバ３９から受け取ったＲＡＷデータをプリンタ２００に送信する。
【００６０】
図１２は、図１１のWindows（R）系ＯＳの印刷アーキテクチャのシーケンス図の一例である。なお、実際にはＧＤＩ３４とＵＩドライバ３８、又は、ＧＤＩ３４と描画ドライバ３９の間では、不図示の通信が行われているが省略している。ＧＤＩ３４からＵＩドライバ３８へのメッセージはＵＩ系のＤＤＩ関数で、描画ドライバ３９へのメッセージは描画系ＤＤＩ関数でそれぞれ通知される。
【００６１】
この図１２のS1までにＵＩドライバ３８はユーザが設定した印刷設定を受け付けており、ユーザが印刷開始を操作するとアプリケーション３１がDEVMODEに格納された印刷設定を取得する。
S1: アプリケーション３１はまず、ＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーションはCreateDC()関数で印刷設定（DEVMODE）を引数にしてＧＤＩ３４をコールする。
S1.1:ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に印刷設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）印刷設定を参照することができる。
S2:ＧＤＩ３４が印刷準備完了をアプリケーションに通知すると、アプリケーションはＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーションはStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。
S2.1:ＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPRE()をＵＩドライバ３８に送出する。
S2.2:ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。ＯＳ１０は、CreateDC()関数により所定のタイミングでJobIDを生成している。ＧＤＩ３４はDrvStartDoc()関数の引数にJobIDを設定するので、描画ドライバ３９はJobIDを参照できるようになる。
S2.3: 同様にＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()をＵＩドライバ３８に送出する。ＧＤＩ３４はこの関数の引数にJobIDを設定するので、ＵＩドライバ３８はJobIDを参照できるようになる。
S3: ＧＤＩ３４が印刷開始完了をアプリケーションに通知すると、アプリケーションはページ単位の処理を繰り返す。まず、アプリケーションはＧＤＩ３４に新しいページの印刷データを受け入れるよう指示する。具体的には、アプリケーションはStartPage()をＧＤＩ３４に送出する。
S3.1:ＧＤＩ３４はDrvStartPage()を描画ドライバ３９に送出する。
S4:アプリケーションは、描画ドライバ３９から応答を取得すると、描画関数（文書データ）をＧＤＩ３４に送出する。
S4.1:ＧＤＩ３４は、描画関数（文書データ）を描画ドライバ３９に送出する。描画ドライバ３９は印刷設定に従って文書データを印刷データに変換する。
S5: ＧＤＩ３４が１ページ分の描画処理の完了をアプリケーションに通知すると、アプリケーションは１ページ分の書き込みが終了したことをＧＤＩ３４に通知する。具体的には、アプリケーションはEndPage()をＧＤＩ３４に送出する。
S5.1:ＧＤＩ３４は描画ドライバ３９に１ページ分の書き込みが終了したことを通知する。具体的には、ＧＤＩ３４はDrvSendPage()を描画ドライバ３９に送出する。
S6:アプリケーションは、全てのページの描画処理が終了すると、印刷ジョブの終了をＧＤＩ３４に通知する。具体的には、アプリケーションはEndDoc()をＧＤＩ３４に送出する。
S6.1:ＧＤＩ３４は印刷ジョブの終了を描画ドライバ３９に送出する。具体的には、ＧＤＩ３４はEndDoc()を描画ドライバ３９に送出する。
S6.2: ＧＤＩ３４は印刷ジョブの終了をＵＩドライバ３８に送出する。具体的には、ＧＤＩ３４はDrvDocumentEvent()DOCUMENTEVENT_ENDDOCPOST()をＵＩドライバ３８に送出する。
この後、デバイスコンテキストが消去され、描画ドライバ３９は印刷設定を参照できなくなる（描画ドライバ３９にDrvDisablePDEV()のＤＤＩコールが通知される）。
【００６２】
図１３は、ＥＭＦスプールにおける、Windows（R）系ＯＳの印刷アーキテクチャの流れを説明する図の一例である。
（１）ユーザが、ＵＩドライバ３８が提供する印刷ダイアログ（ＧＵＩ）によって印刷設定を変更する（すでに登録されている初期値を変更する）。
（２）ユーザがアプリケーションに印刷開始指示の操作を行う。
（３）アプリケーションはＵＩドライバ３８と印刷設定が入っているDEVMODEをやりとりして、ユーザの印刷設定を受け取る。
（４）アプリケーションはＧＤＩ３４に印刷命令をＧＤＩコールとして通知する。
（５）ＧＤＩ３４はＥＭＦデータをスプールデータとしてスプーラ３５に渡す。
（６）アプリケーションの印刷データが一通りスプールされると、スプーラ３５がプリントプロセッサ４１にデスプールすることを伝え、スプールデータを渡す。
（７）プリントプロセッサ４１は、スプールデータをページごとに編集することで、集約・逆順・製本の機能を実現し、編集した内容をＧＤＩ３４にＧＤＩコールとして通知する。
（８）ＧＤＩ３４はＧＤＩコールをＤＤＩコールに変換して描画ドライバ３９に通知する。
（９）描画ドライバ３９は、プリンタが理解できる言語に変換したＲＡＷデータをスプーラ３５に送出する。
（１０）スプーラ３５は、描画ドライバ３９から受け取ったＲＡＷデータをプリンタに送信する。
【００６３】
図１４は、図１３のWindows（R）系ＯＳの印刷アーキテクチャのシーケンス図の一例である。なお、実際にはＧＤＩ３４とＵＩドライバ３８、又は、ＧＤＩ３４と描画ドライバ３９の間では、不図示の通信が行われているが省略している。また、ＥＭＦスプールでは、アプリケーションプロセスとスプーラプロセスが分かれている。
【００６４】
なお、この図１４のS1までにＵＩドライバ３８はユーザが設定した印刷設定を受け付けており、ユーザが印刷開始を操作するとアプリケーションがDEVMODEに格納された印刷設定を取得する。
S1: アプリケーションはまず、ＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーションはCreateDC()関数で印刷設定を引数にしてＧＤＩ３４をコールする。
S1.1:ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に印刷設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）印刷設定を参照することができる。
S2:ＧＤＩ３４が印刷準備完了をアプリケーションに通知すると、アプリケーションはＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーションはStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。
S2.1:ＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOC()をＵＩドライバ３８に送出する。
S2.2: ＧＤＩ３４はＵＩドライバ３８にJobIDを送出する。具体的にはDrvDocumentEvent()DOCUMENT_STARTDOCPOST()をＵＩドライバ３８に送出する。ＧＤＩ３４はこの関数の引数にJobIDを設定するので、ＵＩドライバ３８はJobIDを参照できるようになる。この時点では描画ドライバ３９はJobIDを取得していない。
S3: ＧＤＩ３４が印刷開始完了をアプリケーション３１に通知すると、アプリケーションページ単位の処理を繰り返す。まず、アプリケーションはＧＤＩ３４に新しいページの印刷データを受け入れるよう指示する。具体的には、アプリケーションはStartPage()をＧＤＩ３４に送出する。StartPage()によりスプーラプロセスが開始される。
S4:アプリケーション３１は、描画関数（文書データ）をＧＤＩ３４に送出する。ＧＤＩ３４は、印刷設定に基づきＥＭＦデータを作成する。
S5:アプリケーション３１は１ページ分の書き込みが終了したことをＧＤＩ３４に通知する。具体的には、アプリケーションはEndPage()をＧＤＩ３４に送出する。
S6:アプリケーション３１は、全てのページの描画処理が終了すると、印刷ジョブの終了をＧＤＩ３４に通知する。具体的には、アプリケーションはEndDoc()をＧＤＩ３４に送出する。
【００６５】
このように、アプリケーションのプロセスが終了すると、印刷が完了していなくてもアプリケーションは印刷を終了したように見える。この後、スプーラプロセスで再度印刷処理がかかり、ここでＥＭＦデータからＲＡＷデータへ変換される。
【００６６】
ＯＳ１０はアプリケーション３１とＧＤＩ３４の通信を監視して、所定のタイミングになると（例えばStartPage()の後）、スプーラ３５にスプーラプロセスを開始させる。
S7:スプーラ３５は、プリントプロセッサ４１に印刷準備開始を指示する。
S7.1:プリントプロセッサ４１はＧＤＩ３４に印刷準備開始を指示する。
S7.1.1:ＧＤＩ３４は描画ドライバ３９に印刷設定を送出する。具体的には、CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）印刷設定を参照することができる。
S7.1.2:ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。ＯＳ１０は、CreateDC()関数により所定のタイミングでJobIDを生成している。ＧＤＩ３４はDrvStartDoc()関数の引数にJobIDを設定するので、描画ドライバ３９はJobIDを参照できるようになる。
S7.2:以降、プリントプロセッサ４１はページ単位の処理を繰り返す。まず、プリントプロセッサ４１はＧＤＩ３４に新しいページの印刷データを受け入れるよう指示する。具体的には、プリントプロセッサ４１はGdiStartPageＥＭＦ()をＧＤＩ３４に送出する。
S7.2.1:ＧＤＩ３４はDrvStartPage()を描画ドライバ３９に送出する。
S7.2.2:ＧＤＩ３４は、描画関数（文書データ）を描画ドライバ３９に送出する。描画ドライバ３９は印刷設定に従って文書データを印刷データに変換する。
S7.2.3:ＧＤＩ３４は描画ドライバ３９に１ページ分の書き込みが終了したことを通知する。具体的には、ＧＤＩ３４はDrvSendPage()を描画ドライバ３９に送出する。
【００６７】
以降は、ページ単位の繰り返しになる。
【００６８】
〔本実施形態のWindows（R）系OSの印刷アーキテクチャ〕
まず、本実施形態の印刷アーキテクチャで使用するＡＰＩ等について説明する。
図１５（ａ）はExtEscape()関数の書式を説明する図の一例である。ExtEscape()関数は、モジュール（シーケンス図や機能ブロック図の各ブロック）がＧＤＩ経由ではアクセスできない特定のモジュールにアクセスするためのＡＰＩである。アプリケーションがＧＤＩ３４を関与させずにドライバにデータを送信する場合、モジュールからＧＤＩ３４を関与させずにデータを取得する場合に利用されることがある。
・hdcはデバイスコンテキストのハンドルである。
・nEscapeはExtEscape()関数の機能をチェックしたり設定するための引数になる。
・cbInputは、ExtEscape()関数で送信する構造体のサイズである。
・lpszInDataは、ExtEscape()関数で送信する構造体のポインタである。
・cbOutputは、ExtEscape()関数で送信される構造体を受け取る構造体のサイズである。
・lpszOutDataは、ExtEscape()関数で送信される構造体を受け取る構造体のポインタである。
【００６９】
ExtEscape()関数は、CreateDC()により取得されたデバイスコンテキストに対して、コール可能なＡＰＩである。よって、ＵＩドライバ３８等はシーケンス処理中のデバイスコンテキストがある範囲でExtEscape()関数をコールすることができる。
【００７０】
図１５（ｂ）は、アプリケーションがExtEscape()をコールした場合のシーケンス図の一例を示す。
(i)アプリケーションがＧＤＩ３４に対しExtEscape()をコールする。
(ii)ＧＤＩ３４はExtEscape()をDrvEscape()というＤＤＩコールに変換して描画ドライバ３９に通知する。
【００７１】
また、この逆に描画ドライバ３９又はＵＩドライバ３８がExtEscape()をコールすることも可能である。ExtEscape()はCreateDC()〜DeleteDC()間であれば、各モジュールがコールできるので、図１５（ｂ）のシーケンスは、図１２，１４の従来のシーケンス図の任意の場所に入れることができる。
【００７２】
図１６（ａ）は、DrvDocumentEvent()関数の書式を説明する図の一例である。DrvDocumentEvent()関数は、文書データの印刷に関連する特定のイベントを処理するＤＬＬである。
・hPrinterは、プリンタのハンドルである。
・hdcは、デバイスコンテキストのハンドルである。
・iEscは、呼び出し元のモジュールが提供する、処理対象のイベントを識別するためのエスケープコードである。
・cbInはpvInで送信されるデータのサイズである。
・pvInは送信されるデータのポインタである。
・cbOutは、iEscがDOCUMENTEVENT_ESCAPEの場合は、ExtEscape()のcbOutputパラメータとして関数が指定した値が格納される。iEscがDOCUMENTEVENT_QUERYFILTERの場合、受け取り側が受け取る構造体pvOutのサイズが格納される。
・pvOutは、受け取り側が受け取る構造体pvOutのポインタである。
【００７３】
本実施例では、DrvDocumentEvent()関数は、CreateDC()以降の印刷中、ＧＤＩ３４等が描画ドライバ３９を呼び出すＤＤＩコールの間に、適宜、コールされる。DrvDocumentEvent()は単独の処理を行うためのＤＤＩなので、前後のDrvDocumentEvent()間でデータの共有はできない。この点で、描画ドライバ３９を呼び出すＤＤＩとは異なる。ＵＩ系のＤＤＩなのでダイアログ表示をすることも可能である。
【００７４】
また、引数にデバイスコンテキスト（ｈｄｃ）があるため、DrvDocumentEvent()のＤＤＩコールの後、モジュールがデバイスコンテキストを必要とするＡＰＩをコールすることができる。例えば、ＵＩドライバ３８がデバイスコンテキストを引数に描画系ＡＰＩをコールすると、対応している描画ドライバ３９に対して描画命令を通知することができる。
【００７５】
図１６（ｂ）は、SendRecvBidiDataFromPort()の書式を説明する図の一例である。SendRecvBidiDataFromPort()関数は、LanguageMonitor３２に実装される関数である。プリンタドライバ３０と同じようにLanguageMonitor３２にもＯＳ１０によって決められたI/Fが存在する。SendRecvBidiDataFromPort()関数は、その１つであり、アプリケーションとプリンタ間、アプリケーションとプリントサーバ間の双方向通信をサポートする。
・hPortは、呼び出し元のモジュールによって与えられるポートのハンドルである。
・dwAccessBitは、呼び出し元のモジュールによって与えられ、プリンタ又はプリントサーバへのアクセスを許可するACCESS_MASK構造体である。
・pActionは、呼び出し元のモジュールによって与えられるリクエストアクションである。
・pReqDataは、リクエストデータを有しているPBIDI_REQUEST_CONTAINER構造体のポインタである。
・ppResDataは、レスポンスデータを有しているBIDI_RESPONSE_CONTAINER構造体のアドレスを受け取るメモリ領域へのポインタである。
【００７６】
図１７（ａ）はPBIDI_REQUEST_CONTAINER構造体の書式を示す図の一例である。PBIDI_ RESPONSE _CONTAINER構造体についてもほぼ同様である。PBIDI_REQUEST_CONTAINER構造体は、「bidi requests」のリストを格納するコンテナであり、PBIDI_ RESPONSE _CONTAINER構造体は「bidi RESPONSE」のリストを格納するコンテナである。
【００７７】
Windows（R）系のＯＳ１０は「Bidi Request and Response Schemas」として、プリンタとアプリケーションの間で双方向通信のために使用可能な、問い合わせと応答の組を提供するデータベースのスキーマを提供している。このRequestとResponseに、JobIDと印刷設定を登録すれば、ＯＳ１０の仕組みを利用してモジュールがJobIDをキーに印刷設定を取得できる。
・versionは、スキーマのバージョンであり現在は１である。
・Flagsは、システム（ＯＳ１０）により予約されたフラグのセットでありゼロでなければならない。
・Countは、aDataメンバーにおける「bidi requests」の数である。
・aData[]は、BIDI_REQUEST_DATA 構造体の配列であり、各要素が１つの「bidi request」を有している。
【００７８】
図１７（ｂ）はBIDI_REQUEST_DATA 構造体の書式の一例を示す図である。BIDI_REQUEST_DATA構造体は、１つの「bidi request」を格納している。
・dwReqNumberは、リクエストのインデックスであり、マルチリクエストによる操作のリクエストと応答を適合させるために使用される。
・pSchemaは、スキーマ文字列の最初の１バイトがあるメモリ配置へのポインタである。
・dataは、スキーマに従ったBIDI_DATA 構造体である。
【００７９】
＜LanguageMonitorへのJobIDと印刷設定の格納＞
従来から、ＯＳ１０は印刷開始命令を受け付けた順にシステムで一意のID（JobID）を生成している。ＲＡＷスプールとＥＭＦスプールのいずれでも、描画ドライバ３９及びＵＩドライバ３８がJobIDを取得するステップがある。すなわち、
描画ドライバ３９は、DrvStartDoc()の引数で受け取ることができる。
ＵＩドライバ３８は、DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()の引数で受け取ることができる。
【００８０】
図１８は、ＯＳ１０が付与するJobIDを模式的に説明する図の一例である。アプリケーションＡ及びアプリケーションＢが任意に印刷開始命令１〜３を発行する。ＯＳ１０は、
アプリケーションＡの印刷開始命令１にJobID1を付与し、
アプリケーションＢの印刷開始命令２にJobID2を付与し、
アプリケーションＡの印刷開始命令３にJobID3を付与している。
【００８１】
描画ドライバ３９及びＵＩドライバ３８はこれらのJobIDを取得するので、描画ドライバ３９及びＵＩドライバ３８が取得するJobIDも一意性が保証される。
【００８２】
本実施形態では、このJobIDをキーにしてLanguageMonitor３２に印刷設定を記憶させる。
図１９は、LanguageMonitor３２に記憶されるJobIDと印刷設定を模式的に説明する図の一例である。アプリケーションＡ,Ｂは、以下のように印刷開始を指示している。印刷開始が指示された順に、ＯＳ１０によってJobIDが振られる。
1. アプリケーションＡが印刷開始指示
2. アプリケーションＢが印刷開始指示
3. アプリケーションＡが印刷開始指示
ＵＩドライバ３８は、印刷開始後に印刷設定画面を表示し印刷設定を受け付ける。そして、その印刷設定を、JobIDをキーにしてLanguageMonitor３２に設定（set）する。図の例だと、LanguageMonitor３２は、JobIDと印刷設定の組み合わせをテーブル状に保持する。
【００８３】
描画ドライバ３９は、印刷データの生成に印刷設定が必要になると、JobIDをキーとしてLanguageMonitor３２に印刷設定を問い合わせる（getする）。
【００８４】
このように、ＯＳ１０によって印刷ジョブに一意のキーが振られ、そのキーを利用して情報を保持する仕組みをLanguageMonitor３２が有する。このため、複数のアプリケーションが任意に複数の印刷ジョブを開始しても、プリンタドライバ３０は印刷ジョブ毎に印刷設定を管理できる。
【００８５】
LanguageMonitor３２への設定及び問い合わせにSendRecvBidiDataFromPort()関数が使用される。プリンタドライバ３０がSendRecvBidiDataFromPort()にてLanguageMonitor３２を呼び出すことで、LanguageMonitor３２を保存場所として使うことが可能となる。すなわちLanguageMonitor３２とSendRecvBidiDataFromPort()関数によりデータ保持部３２１が実現される。
【００８６】
上記のように、LanguageMonitor３２はメーカが開発しなくとも、標準のLanguageMonitor３２がＯＳ１０と共に利用可能である。メーカが開発しない場合はそのLanguageMonitor３２が動作する。メーカは決められたI/Fに合わせ、LanguageMonitor３２を開発すれば、独自の機能を追加することができる。本実施形態では、SendRecvBidiDataFromPort()というI/Fを利用することによりプリンタドライバ３０等はLanguageMonitor３２とのデータのやりとりが可能となる。
【００８７】
ＵＩドライバ３８は、「pAction」に設定を意味する定数を設定し、「pReqData 」にJobIDを設定し、「ppResData」に印刷設定が記憶されたアドレスへのポインタを設定する。LanguageMonitor３２は、BIDI_REQUEST_DATA 構造体の配列の要素の１つであるaData[]にJobIDを格納し、BIDI_RESPONSE_DATA 構造体の配列の要素の１つであるaData[]に印刷設定（へのポインタ）を格納する。これにより、図１９のようにJobIDと印刷設定が対応づけられる。
【００８８】
また、描画ドライバ３９は、「pAction」に読み出しを意味する定数を設定し、「pReqData 」にJobIDを設定し、不図示の戻り値を指定する。これによりLanguageMonitor３２は、「ppReqData」に対応する印刷設定が記憶されたアドレスのポインタを戻り値に格納して描画ドライバ３９に返す。
【００８９】
このようにＯＳ１０の機能を利用することで、LanguageMonitor３２におけるデータ保持部３２１のキーを印刷ジョブで重複しないJobIDとすることができる。
【００９０】
＜動作手順＞
図２０は、ＲＡＷスプールのWindows（R）系ＯＳの印刷アーキテクチャのシーケンス図の一例である。なお、実際にはＧＤＩ３４とＵＩドライバ３８、又は、ＧＤＩ３４と描画ドライバ３９の間では、不図示の通信が行われているが省略している。ＧＤＩ３４からＵＩドライバ３８へのメッセージはＵＩ系のＤＤＩ関数で、描画ドライバ３９へのメッセージは描画系ＤＤＩ関数でそれぞれ通知される。
【００９１】
この図２０のS1までにＵＩドライバ３８はユーザが設定した印刷設定を受け付けており、ユーザが印刷開始を操作するとアプリケーションがDEVMODEに格納された印刷設定を取得する。
S1: アプリケーションはまず、ＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーションはCreateDC()関数で印刷設定を引数にしてＧＤＩ３４をコールする。
S1.1:ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に印刷設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）印刷設定を参照することができる。
S2:ＧＤＩ３４が印刷準備完了をアプリケーションに通知すると、アプリケーションはＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーションはStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。
S2.1:ＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPRE()をＵＩドライバ３８に送出する。
S2.2:ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。ＯＳ１０は、CreateDC()関数により所定のタイミングでJobIDを生成している。ＧＤＩ３４はDrvStartDoc()関数の引数にJobIDを設定するので、描画ドライバ３９はJobIDを参照できるようになる。
S2.3: 同様にＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()をＵＩドライバ３８に送出する。ＧＤＩ３４はこの関数の引数にJobIDを設定するので、ＵＩドライバ３８はJobIDを参照できるようになる。
S2.3.1: ここでＵＩドライバ３８は、印刷設定に印刷開始指示後の印刷設定の変更を受け付ける設定があることを検出する。このため、ＵＩドライバ３８は、ポップアップ表示の処理を開始する。描画ドライバ３９と直接通信できないので、ＧＤＩ３４にExtEscape()を送出する。
S2.3.1.1:ＧＤＩ３４は描画ドライバ３９にDrvEscape()を通知する。描画ドライバ３９はＧＤＩ３４を介して保持している印刷設定をＵＩドライバ３８に送出する。
S2.4:ExtEscape()の処理によりＵＩドライバ３８は、印刷設定を取得できたことになる。印刷設定に、印刷開始指示後(印刷中)に印刷設定を変更するための印刷ダイアログの表示指示が設定される場合、ＵＩドライバ３８は図１、２のような印刷ダイアログを表示し、ユーザによる印刷設定の変更を受け付ける。
S2.3.2:ユーザが印刷ダイアログを閉じることで、ＵＩドライバ３８はSendRecvBidiDataFromPort()::setで、JobIDをキーとし、ユーザが変更した印刷設定をLanguageMonitor３２に送出する（「::」は"DOCUMENTEVENT"を省略したことを意味する）。これにより、LanguageMonitor３２はJobIDと印刷設定を対応づけて保持することができる。この時、ユーザがダイアログを"OK"又は"キャンセル"どちらで閉じたのかという内容も送出される。
S3: ＧＤＩ３４が印刷開始完了をアプリケーションに通知すると、アプリケーションはページ単位の処理を繰り返す。まず、アプリケーションはＧＤＩ３４に新しいページの印刷データを受け入れるよう指示する。具体的には、アプリケーションはStartPage()をＧＤＩ３４に送出する。
S3.1:ＧＤＩ３４はDrvStartPage()を描画ドライバ３９に送出する。
S3.1.1: 描画ドライバ３９は、一番最初のDrvStartPage()のＤＤＩコールを受けた時のみ、保持していたJobIDをキーとしてSendRecvBidiDataFromPort()::getでLanguageMonitor３２に印刷設定を要求する。ここで、LanguageMonitor３２には、S2.3.2でユーザが"OK"又は"キャンセル"のどちらで閉じたかの情報を保持している。描画ドライバ３９は、"OK"でユーザが閉じていれば、印刷設定に基づき印刷データを生成する。"キャンセル"で閉じていれば、プリンタやＦＡＸ装置にデータを送信しないようにする。
S4:アプリケーション３１は、描画ドライバ３９から応答を取得すると、描画関数（文書データ）をＧＤＩ３４に送出する。
S4.1:ＧＤＩ３４は、描画関数（文書データ）を描画ドライバ３９に送出する。描画ドライバ３９は印刷設定に従って文書データを印刷データに変換する。
以降の手順は従来と同様なので省略する。
【００９２】
このように描画ドライバ３９はLanguageMonitor３２から、JobIDにより一意に指定される印刷設定を取得することができる。すなわち、ＲＡＷスプールにおいて印刷開始後に印刷設定を変更しても、上書きされるようなおそれがない。
【００９３】
図２１は、ＥＭＦスプールのWindows（R）系ＯＳの印刷アーキテクチャのシーケンス図の一例である。なお、実際にはＧＤＩ３４とＵＩドライバ３８、又は、ＧＤＩ３４と描画ドライバ３９の間では、不図示の通信が行われているが省略している。
【００９４】
この図２１のS1までにＵＩドライバ３８はユーザが設定した印刷設定を受け付けており、ユーザが印刷開始を操作するとアプリケーションがDEVMODEに格納された印刷設定を取得する。
S1: アプリケーションはまず、ＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーションはCreateDC()関数で印刷設定を引数にしてＧＤＩ３４をコールする。
S1.1:ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に印刷設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）印刷設定を参照することができる。
S2:ＧＤＩ３４が印刷準備完了をアプリケーションに通知すると、アプリケーションはＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーションはStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。
S2.1:ＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOC()をＵＩドライバ３８に送出する。
S2.2: ＧＤＩ３４はＵＩドライバ３８にJobIDを送出する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()をＵＩドライバ３８に送出する。ＧＤＩ３４はこの関数の引数にJobIDを設定するので、ＵＩドライバ３８はJobIDを参照できるようになる。この時点では描画ドライバ３９はJobIDを取得していない。
S2.2.1: ここでＵＩドライバ３８は、印刷設定に印刷開始指示後の印刷設定の変更を受け付ける設定があることを検出する。このため、ＵＩドライバ３８は、ポップアップ表示の処理を開始する。ＵＩドライバ３８は、デバイスコンテキストを引数として、ＧＤＩ３４に対しExtEscape()をコールする。
S2.2.1.1:ＧＤＩ３４は、DrvEcape()のＤＤＩコールを描画ドライバ３９に送出することで、描画ドライバ３９が保持している印刷設定を要求する。描画ドライバ３９はＧＤＩ３４を介して保持している印刷設定をＵＩドライバ３８に送出する。
S2.4:ExtEscape()の処理によりＵＩドライバ３８は、印刷設定を取得できたことになる。印刷設定に、印刷開始指示後(印刷中)に印刷設定を変更するための印刷ダイアログの表示指示が設定される場合、ＵＩドライバ３８はユーザによる印刷設定の変更を受け付ける。
S2.2.2:ユーザが印刷ダイアログを閉じることで、ＵＩドライバ３８はSendRecvBidiDataFromPort()::setで、JobIDをキーとし、ユーザが変更した印刷設定をLanguageMonitor３２に送出する。これにより、LanguageMonitor３２はJobIDと印刷設定を対応づけて保持することができる。この時、ユーザがダイアログを"OK"又は"キャンセル"どちらで閉じたのかという内容も送出される。S3〜S6について従来と同様なので省略する。ここまででアプリケーションプロセスでの印刷(ＥＭＦデータの生成)が終了する。
【００９５】
この後、スプーラ３５のプロセスで再度印刷処理がかかり、ここでＥＭＦデータからＲＡＷデータへ変換される。ＯＳ１０はアプリケーションとＧＤＩ３４の通信を監視して、所定のタイミングになると（例えばStartPage()の後）、スプーラ３５にプロセスを開始させる。
S7:スプーラ３５は、プリントプロセッサ４１に印刷準備開始を指示する。
S7.1:プリントプロセッサ４１はＧＤＩ３４に印刷準備開始を指示する。
S7.1.1:ＧＤＩ３４は描画ドライバ３９に印刷設定を送出する。具体的には、CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）印刷設定を参照することができる。
S7.1.2:ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。ＯＳ１０は、CreateDC()関数により所定のタイミングでJobIDを生成している。ＧＤＩ３４はDrvStartDoc()関数の引数にJobIDを設定するので、描画ドライバ３９はJobIDを参照できるようになる。
S7.2:以降、プリントプロセッサ４１はページ単位の処理を繰り返す。まず、プリントプロセッサ４１はＧＤＩ３４に新しいページの印刷データを受け入れるよう指示する。具体的には、プリントプロセッサ４１はGdiStartPageEMF()をＧＤＩ３４に送出する。
S7.2.1:ＧＤＩ３４はDrvStartPage()を描画ドライバ３９に送出する。
S7.2.1.1: 描画ドライバ３９は、一番最初のDrvStartPage()のＤＤＩコールを受けた時のみ、保持していたJobIDをキーとしてSendRecvBidiDataFromPort()::getでLanguageMonitor３２に印刷設定を要求する。ここで、LanguageMonitor３２には、S2.2.2の印刷ダイアログをユーザが"OK"又は"キャンセル"のどちらで閉じたかの情報を保持している。描画ドライバ３９は、"OK"でユーザが閉じていれば、印刷設定に基づき印刷データを生成する。"キャンセル"で閉じていれば、プリンタやFAXにデータを送信しないようにする。
S7.2.2:ＧＤＩ３４は、描画関数（文書データ）を描画ドライバ３９に送出する。描画ドライバ３９は印刷設定に従って文書データを印刷データに変換する。
S7.2.3:ＧＤＩ３４は描画ドライバ３９に１ページ分の書き込みが終了したことを通知する。具体的には、ＧＤＩ３４はDrvSendPage()を描画ドライバ３９に送出する。
以降はページ単位の繰り返しとなる。
【００９６】
すなわち、ＥＭＦスプールにおいて印刷開始後に印刷設定を変更しても、上書きされるようなおそれがない。
【００９７】
なお、図２０，２１では、印刷のシーケンスがスプール形式によって異なるため、差異があるように見える。
しかし、描画ドライバ３９の
・DrvEnablePDEV()
・DrvStartDoc()
・DrvStartPage()
・DrvEscape()
ＵＩドライバ３８の
・DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()
LanguageMonitor３２の
・SendRecvBidiDataFromPort()::set
・SendRecvBidiDataFromPort()::get
の各関数内で、行っている処理は、ＲＡＷスプールでもＥＭＦスプールでも全く同じ処理である。したがって、本実施形態の印刷設定の管理方法はスプール形式によらず、実現可能であり、複数のアプリケーションが作動する環境でも、印刷開始後にユーザが印刷設定を変更することを可能にできる。
【実施例２】
【００９８】
本実施例では、Point＆Print環境においてLanguageMonitor３２を利用した印刷設定の管理方法について説明する。
【００９９】
図２２は、Point＆Print環境を備えた印刷システムの概略構成図の一例を示す。４台のクライアントＰＣがネットワークを介してサーバＰＣと接続されている。サーバＰＣ１１０にはプリンタ２００が接続されているが、プリンタ２００はネットワークに接続されていてもよい。
【０１００】
サーバＰＣ１１０にはプリンタドライバ３０が登録されており、サーバＰＣ１１０が各クライアントＰＣにプリンタドライバ３０をコピーして配布するので、ユーザはプリンタドライバ３０を容易にインストールすることができる。なお、以降は、クライアントＰＣ1がサーバＰＣ１１０に接続し、Point&PrintによりプリンタドライバＡをインストールしたものとする。
【０１０１】
Point＆Print環境のサーバサイドレンダリングでは、クライアントＰＣがユーザの印刷設定を受け付け、サーバＰＣ１１０が描画処理を行うため、印刷設定などを共有することが困難である。
【０１０２】
これに対し、本実施例ではＯＳ１０が提供する印刷アーキテクチャの内部のLanguageMonitor３２を利用してクライアントＰＣとサーバＰＣ１１０が印刷設定を交換するので、サーバＰＣ１１０はクライアントＰＣから印刷アーキテクチャ内の処理で印刷設定を取得できる。よって、ユーザは印刷開始後に印刷設定を変更しても、サーバＰＣ１１０は変更後の印刷設定に基づき描画処理できる。
【０１０３】
図２３は、Point&Print環境におけるLanguageMonitor３２の位置づけを説明する図の一例である。LanguageMonitor３２はWindows（R）系ＯＳの印刷アーキテクチャの中に組み込まれる一モジュールである。このため、Point&PrintによりクライアントＰＣ側がＵＩドライバ３８の処理を、サーバＰＣ側が描画ドライバ３９の処理を受け持ったとしても、LanguageMonitor３２はサーバＰＣ側で１つだけ機能する。このため、クライアントＰＣのプリンタドライバ３０とサーバＰＣ１１０のプリンタドライバ３０は1つのLanguageMonitor３２にアクセスする。すなわち、クライアントＰＣのＯＳ１０とサーバＰＣのＯＳ１０は、クライアントＰＣのＵＩドライバ３８がLanguageMonitor３２にアクセスする場合、クライアントＰＣとサーバＰＣ１１０の通信を確立する（例えば、ＲＰＣ（Remote Procedure Call）を利用する）。そして、ＵＩドライバ３８がクライアントＰＣのLanguageMonitor３２にアクセスしているように見せる。
【０１０４】
このようにクライアントＰＣとサーバＰＣ１１０が同じWindows（R）系のＯＳ１０をインストールしているので、Windows（R）系OSの印刷アーキテクチャのLanguageMonitor３２を共通に利用できる。このため、メーカ独自で開発したモジュールなどで生じやすいアクセス権限や通信エラーなどが起こりにくい。また、同様の理由で、ＯＳ１０との親和性も高い。
【０１０５】
なお、Point＆Printでもスプール形式にはＲＡＷスプールとＥＭＦスプールがあるが、ＲＡＷスプールの場合、サーバサイドレンダリングが存在しない。ＲＡＷスプールはアプリケーションのプロセスなので、レンダリング場所が制限されるためである。
【０１０６】
その他の場合、ＲＡＷスプールのクライアントサイドレンダリング、ＥＭＦスプールのクライアントサイドレンダリング、及び、ＥＭＦスプールのサーバサイドレンダリング、のいずれの場合も、図２３のようにLanguageMonitor３２が利用される。
【０１０７】
図２４は、Point&Print環境におけるJobIDについて説明する図の一例である。クライアントＰＣがＲＰＣでサーバＰＣ１１０と接続されている場合、クライアントＰＣからサーバＰＣ１１０のプリンタに対してハンドルを取得すると、セッションが確立される。サーバＰＣ１１０はセッションが確立されるとJobIDを生成し、クライアントＰＣに通知する。したがって、ＲＡＷスプールのクライアントサイドレンダリング、ＥＭＦスプールのクライアントサイドレンダリング、及び、ＥＭＦスプールのサーバサイドレンダリング、のいずれの場合もサーバＰＣ１１０がJobIDを生成する。なお、JobIDの生成タイミングは、実施例１と同様である。
【０１０８】
図２４では、
クライアントＰＣ１がアプリケーションＡを
クライアントＰＣ２がアプリケーションＡ、Ｂを
クライアントＰＣ３がアプリケーションＣを
それぞれ実行している。各アプリケーションは任意のタイミングで印刷開始を指示する。
印刷開始命令１：クライアントＰＣ２＋アプリケーションＡ
印刷開始命令２：クライアントＰＣ１＋アプリケーションＡ
印刷開始命令３：クライアントＰＣ３＋アプリケーションＣ
印刷開始命令４：クライアントＰＣ２＋アプリケーションＢ
サーバＰＣ１１０のＯＳ１０は、印刷開始命令１〜４に一意のJobID１〜４を付与する。すなわち、１台のクライアントＰＣが単一のアプリケーションから印刷を開始しても、１台のクライアントＰＣが複数のアプリケーションから印刷を開始しても、１台のクライアントＰＣが単一のアプリケーションから複数回印刷を開始しても、サーバＰＣ１１０は重複しないJobIDを付与する。
【０１０９】
実施例１と同様に、ＵＩドライバ３８は、クライアントＰＣがサーバＰＣ１１０から取得したJobIDを、ＧＤＩ３４のＤＤＩコールであるDrvStartDoc()の引数により受け取ることができる。描画ドライバ３９はＧＤＩ３４から送出されたDrvStartDoc()の引数でJobIDを受け取ることができる。
【０１１０】
図２５は、Point&Print環境におけるＲＡＷスプールの印刷手順を模式的に説明する図の一例である。Point&Print環境においてユーザがＲＡＷスプールに設定すると（サーバサイドレンダリングは設定できない）、クライアントＰＣで描画処理(ＲＡＷデータの生成)が行われる。
１．アプリケーションがＧＤＩ３４を呼び出す。この時、サーバＰＣ１１０がサーバにとって一意のJobIDを付与し、クライアントＰＣに返す。
２．ＧＤＩ３４がプリンタドライバ３０を呼び出す。
３．プリンタドライバ３０の描画ドライバ３９はＧＤＩ３４からDrvStartDoc()の引数によりJobIDを取得する。また、プリンタドライバ３０のＵＩドライバ３８はＧＤＩ３４からDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()によりJobIDを取得する。ＵＩドライバ３８が印刷ダイアログを表示すると、ユーザは印刷設定を変更することができる。ＵＩドライバ３８は描画ドライバ３９からDrvEscape()で取得した印刷設定を、LanguageMonitor３２にSendRecvBidiDataFromPort()::setする。その後、ページ単位の印刷が始まると、描画ドライバ３９はLanguageMonitor３２からSendRecvBidiDataFromPort()::getで印刷設定を取得する。
４．描画ドライバ３９は必要であれば描画処理を行い、スプーラ３５に印刷データを送出する。スプーラ３５は印刷データ（ＲＡＷデータ）をスプールする。
５．スプーラ３５はＲＰＣにより印刷データをサーバＰＣ１１０に送信する。
６．サーバＰＣ１１０の処理に移り、サーバＰＣ１１０のプリントプロセッサ４１は印刷データをスプールする。
７．スプーラはLanguageMonitor３２に印刷データを送出する。
８．LanguageMonitor３２とポートモニタ３３はプリンタに印刷データを送信する。この段階で、LanguageMonitor３２は特に処理は行わない。
【０１１１】
このように、JobIDがサーバＰＣ１１０にて生成される以外は、プリンタドライバ３０がローカルで動作した場合と同様である。したがって、シーケンス図も図２０と同じものになる。よって、LanguageMonitor３２を利用したJobIDと印刷設定の管理は、Point&Print環境でＲＡＷスプールした場合でも実現可能である。
【０１１２】
図２６は、Point&Print環境におけるＥＭＦスプール（クライアントサイドレンダリング）の印刷手順を模式的に説明する図の一例である。Point&Print環境においてユーザがＥＭＦスプールに設定すると、ユーザはレンダリングサイドを選択できる。クライアントサイドレンダリングを選択すると、クライアントＰＣで描画処理(ＲＡＷデータの生成)が行われる。
１．アプリケーションがＧＤＩ３４を呼び出す。この時、サーバＰＣ１１０がサーバにとって一意のJobIDを付与し、クライアントＰＣに返す。
２．ＧＤＩ３４がプリンタドライバ３０を呼び出す。プリンタドライバ３０のＵＩドライバ３８はＧＤＩ３４からDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()によりJobIDを取得する。ＵＩドライバ３８が印刷ダイアログを表示すると、ユーザは印刷設定を変更することができる。ＵＩドライバ３８は描画ドライバ３９からDrvEscape()で取得した印刷設定を、LanguageMonitor３２にSendRecvBidiDataFromPort()::setする。ＧＤＩ３４は文書データからＥＭＦデータを生成する。
３．スプーラ３５は印刷データ（ＥＭＦデータ）をスプールする。
４．プリントプロセッサ４１はＧＤＩ３４を呼び出す。
５．ＧＤＩ３４はプリンタドライバ３０を呼び出す。
６．プリンタドライバ３０の描画ドライバ３９はＧＤＩ３４からDrvStartDoc()の引数によりJobIDを取得する。また、ページ単位の印刷が始まると、描画ドライバ３９はLanguageMonitor３２からSendRecvBidiDataFromPort()::getで印刷設定を取得する。プリンタドライバの描画ドライバ３９はＥＭＦデータからＲＡＷデータを作成する。
７．スプーラ３５はＲＰＣにより印刷データ（ＲＡＷデータ）をサーバＰＣ１１０に送信する。
８．サーバＰＣ１１０の処理に移り、サーバＰＣ１１０のプリントプロセッサ４１は印刷データをスプールする。
９．スプーラは印刷データをLanguageMonitor３２に送出する。
１０．LanguageMonitor３２とポートモニタ３３はプリンタに印刷データを送信する。この段階で、LanguageMonitor３２は特に処理は行わない。
【０１１３】
このように、ＥＭＦスプールにおいても、JobIDがサーバＰＣ１１０にて生成される以外は、プリンタドライバ３０がローカルで動作した場合と同様である。クライアントＰＣとサーバＰＣ１１０とで処理する場所が別れたとしても、ＯＳ１０の機能によりクライアントＰＣのプリンタドライバ３０はLanguageMonitor３２がクライアントＰＣにあるかサーバＰＣ１１０にあるかに関係なくアクセスすることができる。また、印刷開始後にＵＩドライバ３８の印刷ダイアログで変更された印刷設定を描画ドライバ３９がLanguageMonitor３２経由で取得することが可能である。
【０１１４】
したがって、シーケンス図も図２１と同じものになる。よって、LanguageMonitor３２を利用したJobIDと印刷設定の管理は、Point&Print環境のＥＭＦスプール（クライアントサイドレンダリング）の場合でも実現可能である。
【０１１５】
図２７は、Point&Print環境におけるＥＭＦスプール（サーバサイドレンダリング）の印刷手順を模式的に説明する図の一例である。Point&Print環境においてユーザがＥＭＦスプールに設定すると、ユーザはレンダリングサイドを選択できる。サーバサイドレンダリングを選択すると、サーバＰＣ１１０で描画処理(ＲＡＷデータの生成)が行われる。
１．アプリケーションがＧＤＩ３４を呼び出す。この時、サーバＰＣ１１０がサーバにとって一意のJobIDを付与し、クライアントＰＣに返す。
２．ＧＤＩ３４がプリンタドライバ３０を呼び出す。プリンタドライバ３０のＵＩドライバ３８はＧＤＩ３４からDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()によりJobIDを取得する。ＵＩドライバ３８が印刷ダイアログを表示すると、ユーザは印刷設定を変更することができる。ＵＩドライバ３８は描画ドライバ３９からDrvEscape()で取得した印刷設定を、LanguageMonitor３２にSendRecvBidiDataFromPort()::setする。ＧＤＩ３４は文書データからＥＭＦデータを生成する。
３．スプーラ３５は印刷データ（ＥＭＦデータ）をスプールする。
４．スプーラ３５はＲＰＣにより印刷データ（ＥＭＦデータ）をサーバＰＣ１１０に送信する。
５．サーバＰＣ１１０の処理に移り、サーバＰＣ１１０のプリントプロセッサ４１はＧＤＩ３４を呼び出す。
６．ＧＤＩ３４はプリンタドライバを呼び出す。
７．プリンタドライバ３０の描画ドライバ３９はＧＤＩ３４からDrvStartDoc()の引数によりJobIDを取得する。また、ページ単位の印刷が始まると、描画ドライバ３９はLanguageMonitor３２からSendRecvBidiDataFromPort()::getで印刷設定を取得する。プリンタドライバの描画ドライバ３９はＥＭＦデータからＲＡＷデータを作成する。プリンタドライバは印刷データ（ＲＡＷデータ）をスプールする。
８．スプーラ３５はLanguageMonitor３２に印刷データを送出する。
９．LanguageMonitor３２とポートモニタ３３はプリンタに印刷データを送信する。この段階で、LanguageMonitor３２は特に処理は行わない。
【０１１６】
このように、ＥＭＦスプールにおいても、JobIDがサーバＰＣ１１０にて生成される以外は、プリンタドライバ３０がローカルで動作した場合と同様である。クライアントＰＣとサーバＰＣ１１０とで処理する場所が別れたとしても、ＯＳ１０の機能によりプリンタドライバ３０はLanguageMonitor３２がクライアントＰＣにあるかサーバＰＣ１１０にあるかに関係なくアクセスすることができる。また、印刷開始後にＵＩドライバ３８の印刷ダイアログで変更された印刷設定を描画ドライバ３９がLanguageMonitor３２経由で取得することが可能である。
【０１１７】
したがって、シーケンス図も図２１と同じものになる。よって、LanguageMonitor３２を利用したJobIDと印刷設定の管理は、Point&Print環境のＥＭＦスプール（クライアントサイドレンダリング）の場合でも実現可能である。
【符号の説明】
【０１１８】
３１        アプリケーション
３２        LanguageMonitor
３３        ポートモニタ
３４        ＧＤＩ
３５        スプーラ
３８        ＵＩドライバ
３９        描画ドライバ
１００      ＰＣ
２００      プリンタ
３２１      データ保持部
３２２      通信部
４００      印刷システム
【先行技術文献】
【特許文献】
【０１１９】
【特許文献１】特開２０１０−０６６８７６号公報
【図１】
0005857611.tif 000002
【図２】
0005857611.tif 000003
【図３】
0005857611.tif 000004
【図４】
0005857611.tif 000005
【図５】
0005857611.tif 000006
【図６】
0005857611.tif 000007
【図７】
0005857611.tif 000008
【図８】
0005857611.tif 000009
【図９】
0005857611.tif 000010
【図１０】
0005857611.tif 000011
【図１１】
0005857611.tif 000012
【図１２】
0005857611.tif 000013
【図１３】
0005857611.tif 000014
【図１４】
0005857611.tif 000015
【図１５】
0005857611.tif 000016
【図１６】
0005857611.tif 000017
【図１７】
0005857611.tif 000018
【図１８】
0005857611.tif 000019
【図１９】
0005857611.tif 000020
【図２０】
0005857611.tif 000021
【図２１】
0005857611.tif 000022
【図２２】
0005857611.tif 000023
【図２３】
0005857611.tif 000024
【図２４】
0005857611.tif 000025
【図２５】
0005857611.tif 000026
【図２６】
0005857611.tif 000027
【図２７】
0005857611.tif 000028