(57)【特許請求の範囲】
【請求項１】
画像データの出力の設定条件を表示し、前記設定条件を受け付ける設定受付プログラムと、アプリケーションから文書データを取得し、前記設定受付プログラムにより受け付けられた設定条件に基づいて印刷データに変換する画像処理プログラムと、を有し、
前記設定受付プログラムは、所定のプログラムに基づいて動作する情報処理装置に、
前記所定のプログラムが生成した出力処理の識別情報を取得するステップと、
前記設定条件に所定の画像データの生成指示が設定されている場合、前記所定の画像データを生成するステップと、
前記取得された識別情報と前記生成された所定の画像データとを対応付けて、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力するステップと、を実行させ、
前記画像処理プログラムは、情報処理装置に、
前記アプリケーションから文書データを取得する際に、所定のプログラムから前記識別情報を取得するステップと、
前記所定のプログラムを介して、前記印刷データ処理プログラムから、前記取得された識別情報に対応付けられた所定の画像データを受け付けるステップと、
前記受け付けた所定の画像データと前記取得された文書データとを、前記設定条件に基づいて印刷データに変換するステップと、を実行させることを特徴とするプログラム。
【請求項２】
前記設定受付プログラムは、情報処理装置に、
前記設定条件を受け付けた後、前記画像データが生成される前に、前記設定条件を前記画像処理プログラムに送信するステップと、
所定のプログラムに対し、前記画像処理プログラムから前記設定条件を送信させるよう要求するステップと、を実行させ、
前記画像処理プログラムは、情報処理装置に、
所定のプログラムに対し前記設定条件を送信するステップを実行させ、
前記所定の画像データを生成するステップでは、前記設定受付プログラムが所定のプログラムから前記設定条件を取得する、ことを特徴とする請求項１記載のプログラム。
【請求項３】
前記所定の画像データを生成するステップでは、印刷開始の指示の後、前記画像処理プログラムが文書データを前記印刷データに変換する前に前記画像データを生成する、
ことを特徴とする請求項１又は２記載のプログラム。
【請求項４】
前記識別情報は、所定のプログラムが予め定められた印刷処理手順の中で生成する、印刷処理又は送信処理に一意のジョブＩＤである、
ことを特徴とする請求項１〜３いずれか１項記載のプログラム。
【請求項５】
前記設定受付プログラムは、情報処理装置に、
所定のプログラムの所定のＡＰＩ関数をコールするステップを実行させることで、前記印刷データ処理プログラムに前記識別情報をキーにして前記設定条件を記憶する、
ことを特徴とする請求項１〜４いずれか１項記載のプログラム。
【請求項６】
前記画像処理プログラムは、情報処理装置に、
所定のプログラムの所定のＡＰＩ関数をコールするステップを実行させることで、前記識別情報をキーにして前記印刷データ処理プログラムから前記設定条件を読み出す、
ことを特徴とする請求項１〜５いずれか１項記載のプログラム。
【請求項７】
前記所定の画像データを生成するステップでは、ファクシミリの送信先情報及び送信元情報が含まれる前記設定条件から、送付状の画像データを生成する、
ことを特徴とする請求項１〜６いずれか１項記載のプログラム。
【請求項８】
前記画像処理プログラムは、情報処理装置に、
前記画像データを、文書データから変換された前記印刷データの表紙に追加するステップ、又は、１ページ以上の前記印刷データの一部に配置することで前記印刷データに追加するステップを実行させる、
ことを特徴とする請求項１〜６いずれか１項記載のプログラム。
【請求項９】
画像データの出力の設定条件を表示し、前記設定条件を受け付ける設定受付手段と、
アプリケーションから文書データを取得し、前記設定受付手段により受け付けられた設定条件に基づいて印刷データに変換する画像処理手段と、を有し、所定のプログラムに基づいて動作する情報処理装置であって、
前記設定受付手段は、前記設定条件に所定の画像データの生成指示が設定されている場合、前記所定の画像データを生成する画像データ生成手段を有し、
前記所定のプログラムが生成した出力処理の識別情報と前記生成された所定の画像データとを対応付けて、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力し、
前記画像処理手段は、前記アプリケーションから文書データを取得する際に、所定のプログラムから前記識別情報を取得し、前記所定のプログラムを介して、前記印刷データ処理プログラムから、前記取得された識別情報に対応付けられた所定の画像データを受け付け、前記受け付けた所定の画像データと前記取得された文書データとを、前記設定条件に基づいて印刷データに変換する、ことを特徴とする情報処理装置。
【請求項１０】
前記設定受付手段は前記設定条件を受け付けた後、前記画像データが生成される前に、前記設定条件を前記画像処理手段に送信し、
前記画像データ生成手段は、所定のプログラムに、前記画像処理手段から前記設定条件を送信させるよう要求し、
前記画像処理手段は、所定のプログラムに対し、前記設定条件を送信し、
前記画像データ生成手段は、所定のプログラムから前記設定条件を取得する、
ことを特徴とする請求項９記載の情報処理装置。
【請求項１１】
前記画像データ生成手段は、印刷開始の指示の後、前記画像処理手段が文書データを前記印刷データに変換する前に、前記画像データを生成する、
ことを特徴とする請求項９又は１０記載の情報処理装置。
【請求項１２】
前記識別情報は、所定のプログラムが予め定められた印刷処理手順の中で生成する、印刷処理に一意のジョブIDである、ことを特徴とする請求項９〜１１いずれか１項記載の情報処理装置。
【請求項１３】
前記設定受付手段は、所定のプログラムの所定のＡＰＩ関数をコールすることで、前記印刷データ処理プログラムに前記識別情報をキーにして前記設定条件を記憶する、
ことを特徴とする請求項９〜１２いずれか１項記載の情報処理装置。
【請求項１４】
前記画像処理手段は、所定のプログラムの所定のＡＰＩ関数をコールすることで、前記識別情報をキーにして前記印刷データ処理プログラムから前記設定条件を読み出す、
ことを特徴とする請求項９〜１３いずれか１項記載の情報処理装置。
【請求項１５】
前記画像データ生成手段は、ファクシミリの送信先情報及び送信元情報が含まれる前記設定条件から、送付状の画像データを生成する、
ことを特徴とする請求項９〜１４いずれか１項記載の情報処理装置。
【請求項１６】
前記画像処理手段は、前記画像データを、文書データから変換された前記印刷データの表紙に追加する、又は、１ページ以上の前記印刷データの一部に配置することで前記印刷データに追加する、ことを特徴とする請求項９〜１４いずれか１項記載の情報処理装置。
【請求項１７】
請求項１〜８いずれか１項記載のプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に、印刷の設定条件を表示し、設定条件の設定を受け付けるステップと、文書データを印刷データに変換するステップと実行させるプログラムに関する。
【背景技術】
【０００２】
ＰＣ（Personal Compueter）上でアプリケーションが扱う文書データをファクシミリ装置で送信することができる。この時、アプリケーションはファクシミリ装置とデータをやり取りするプリンタドライバ（正確にはPC-FAXドライバであるが、動作に共通部が多いのでプリンタドライバと称す）を呼び出し、ユーザが宛先などを設定することができるようになっている。
【０００３】
そして、このプリンタドライバに送付状追加機能がある。送付状とは送信される文書データの送信者や宛先等を明示的に示す紙面であり、文書データとは独立に生成される。
【０００４】
図１は、送付状の一例を模式的に示す図の一例である。「Ｔｏ」の下の行に送信者の「会社名」「部門名」「氏名」等が、「Ｆｒｏｍ」の下の行に宛先の「会社名」「部門名」「氏名」「電話」「ＦＡＸ」などが表示されている。
【０００５】
プリンタドライバの送信設定に対し"送付状を追加する"と設定されている場合、プリンタドライバは、印刷開始（送信処理の開始）の後、かつ、１ページ目の文書データを印刷する前に送付状データの作成を行い、作成された送付状データを印刷してから文書データを印刷する。これにより、文書データの表紙として送付状が送信される。
【０００６】
ところが、ユーザによるＦＡＸ送信の開始操作後に、ユーザが宛先などを設定することは、従来は困難であるとされていた。そこで、ＦＡＸ送信の開始後に、ユーザが宛先などを設定することを可能にする技術がいくつか考えられている（例えば、特許文献１参照。）。
【０００７】
＜Windows系ＯＳの印刷時の仕組み＞
従来の技術を説明するために、まず、Windows（登録商標。以下、省略する）系のＯＳ（Operating  System）の印刷時の仕組みについて説明する。Windows系ＯＳの印刷時の仕組みとして、ＲＡＷスプール形式とＥＭＦスプール形式という２つのスプール形式が存在する。
【０００８】
ＲＡＷスプール形式では、アプリケーションのプロセスで、アプリケーションからの印刷データをプリンタが解釈可能なデータに変換する印刷処理を行う。ユーザからみると印刷処理が完了するまでアプリケーションの操作ができない。
【０００９】
ＥＭＦスプール形式では、アプリケーションのプロセスで、アプリケーションからの印刷データをデバイスに依存しないＥＭＦデータ形式（中間データ）に変換しスプールする。そして、スプーラプロセスでスプールされたＥＭＦデータをプリンタが解釈可能なデータに変換する印刷処理を行う。ユーザにしてみると、アプリケーションプロセスでＥＭＦデータへの変換が終了した時点でアプリケーションの操作ができるようになる。
【００１０】
＜Ｐｏｉｎｔ  ＆  Ｐｒｉｎｔ＞
Windows系ＯＳ上で動作するプリンタドライバでは、Point & Printというプリンタドライバのインストール形式が存在する。
【００１１】
図２は、Point & Printを模式的に説明する図の一例である。Point & Printは、ネットワークにプリンタと、サーバＰＣとクライアントＰＣが接続されたシステムにおいて、クライアントＰＣはサーバＰＣをプリントサーバとして、プリンタに対して印刷を行うことができる。
【００１２】
このようなシステムでは、クライアントＰＣにはサーバＰＣと同じプリンタドライバがインストールされている必要がある。ネットワーク上の個々のクライアントＰＣに、プリンタドライバをインストールすることは、多くの時間と労力を必要とする。
【００１３】
Point & Printは、この不都合を解決する手段であり、サーバＰＣからクライアントＰＣにプリンタドライバをダウンロードしてインストールする仕組みである。Point & Printは、Windows系ＯＳの標準の機能である。
【００１４】
Point & Print でクライアントＰＣにインストールされたプリンタドライバに対し、ユーザは描画処理をクライアントＰＣ側で行うのかサーバＰＣ側で行うのかを設定する（変更する）ことができる。クライアントＰＣ側で描画処理を行うことを「クライアントサイドレンダリング」といい、サーバＰＣ側で描画処理を行う「サーバサイドレンダリング」という。
【００１５】
Point & Printでインストールされたプリンタドライバにも、印刷時にはＲＡＷスプール形式とＥＭＦスプール形式が存在する。
【発明の概要】
【発明が解決しようとする課題】
【００１６】
以上のような背景に対し、ＦＡＸ送信の開始後に、ユーザが宛先などを設定することを可能にする３つの技術について説明する。しかし、これら３つの実現方法はそれぞれ問題がある。
１.  描画ドライバで送付状データを付加する方法
図３は、描画ドライバによる送付状データの付加を模式的に説明する図の一例である。ＵＩドライバは、印刷開始前に印刷条件の設定画面を表示し、また、ユーザによる印刷条件の設定（以下、ＦＡＸ送信に合わせ送信設定という）を受け付ける。描画ドライバは、送信設定を反映させた画像データを文書データから作成する。
【００１７】
描画ドライバで送付状データを付加することで、ＲＡＷスプール、ＥＭＦスプール、及び、Point & Printでインストールされたプリンタドライバによる印刷において、送付状追加可能である。つまり、描画ドライバに画面への表示を行う機能を追加する。
【００１８】
しかし、送付状データを付加するために描画ドライバは、TextOut（）などのＧＤＩ（Graphics Device Interface）コール（文字などを描画するＧＤＩ）をＯＳに対し要求する必要がある。描画ドライバが動作する時は、ＯＳのシステム権限で動作するため、ＧＤＩコールすることはＯＳに対する親和性が低下してしまう（システム権限のＧＤＩコールはＯＳが受け付けないおそれがある）。
２．そこで、ＵＩドライバが持つＤＤＩ（Device  Driver  Interface）のDrvDocumentEvnet()を利用して送付状データを付加する方法が考えられる。
【００１９】
図４は、ＵＩドライバによる送付状データの付加を模式的に説明する図の一例である。図４では、ＵＩドライバがDrvDocumentEvent()で送付状データを作成し、ファイルやメモリに保存しておき、描画ドライバでそのデータを印刷している。
【００２０】
ＵＩドライバのＤＤＩであるDrvDocumentEvent()を利用し、DrvDocumentEvent()内でＧＤＩをコールする。ＵＩドライバであればアプリケーションと同等の権限で動作するため親和性は低下しない。しかし、描画ドライバとＵＩドライバは別モジュールであり、直接通信して、情報のやりとりをすることはできない。基本的にドライバはＯＳからＤＤＩにより呼ばれるだけだからである。
【００２１】
そのため、ＵＩドライバと描画ドライバがデータを送受信するためには、一時ファイルを利用する。ＵＩドライバは作成した送付状データを一時ファイルに出力しておき、描画ドライバでその一時ファイルを読み込むことでＵＩドライバと描画ドライバ間のやり取りが可能となる。
【００２２】
しかし、一時ファイルを使う手法では、プリンタドライバが動作するタイミングやユーザの権限レベルによって、ファイルに確実に出力できるとは限らない。
【００２３】
図５は、一時ファイルに出力した場合の問題を説明する図の一例である。図５に示すように、複数のアプリケーションが動作している環境では、一時ファイルの設定が上書きされてしまう可能性がある。例えば、アプリケーション１の送付状データを一次ファイルに保存した後、それをＦＡＸ送信に使う前に、アプリケーション２が送付状データを上書きしてしまうおそれがある。アプリケーション１の文書データに対しＵＩドライバが保存した送付状データの一時ファイルを、アプリケーション１の文書データを送信するために描画ドライバが描画する前に、一時ファイルの内容が変わってしまう。
【００２４】
このような問題を解消するために、送付状データを保存する場所として、一時ファイルではなく、印刷設定保持用モジュール（例えば、DEVMODE構造体）を利用して、そこに送信設定を保持させる方法を用い、上記の問題を解消することは可能である。
【００２５】
しかし、この方法でも問題を解消できない場合が２つ挙げられる。
２−１．.ＥＭＦスプールでの印刷の場合
２−２．.Point & Printでインストールされたプリンタドライバによる印刷の場合
２−１.について、
印刷設定保持用モジュールを利用する方法は、印刷時のＤＤＩコールシーケンスに依存しており、ＲＡＷスプールの時は実現可能である。
【００２６】
しかし、ＥＭＦスプールではWindows系ＯＳから呼ばれるＤＤＩコールシーケンスが変化する。ＥＭＦスプールでは、アプリケーションからの印刷データをＥＭＦデータに変換する処理と、ＥＭＦデータをプリンタが解釈可能なデータに変換する処理とで、ＯＳ内部の動作として、２回の印刷処理シーケンスが動作する。このように、ＤＤＩコールシーケンスがＲＡＷスプールよりも複雑になってしまうため、期待するタイミングで送付状データの受け渡しができない。
【００２７】
２−２．について
印刷設定保持用モジュールを利用する方法は、ローカル環境で、ユーザが使用するＰＣにプリンタドライバをインストールした時は、実現可能である。
【００２８】
しかし、Point & Printでインストールされたプリンタドライバでサーバサイドレンダリングによりプリンタドライバが動作する場合、ＵＩドライバは、クライアントPC側で動作し、描画ドライバはサーバPC側で動作をする。
【００２９】
サーバサイドレンダリングでは、そもそも動作するPCが物理的に別であるため、印刷設定保持モジュールがクライアントPC側でしか存在しない状況になる。その場合、描画ドライバは印刷設定保持モジュールから送信設定を取得できないので、送付状データの受け渡しができない。
【００３０】
３．ＵＩドライバでDrvDocumentEvent()で受け取ったDeviceContextに対して送付状データを付加する方法
図６は、デバイスコンテキストに送付状データを添付する方法を説明する図の一例である。この方法は、ＵＩドライバがDrvDocumentEvent()で受け取ったDeviceContextに対して直接送付状データを付加するため、アプリケーションとしては実際の印刷文書の前にＵＩドライバに送付状データを付加してもらい、1ページ多い状態で印刷するようになる。
【００３１】
この方法では、ＵＩドライバと描画ドライバ間でのやり取りがないため、２のような問題は発生しない。
【００３２】
しかし、Windows系ＯＳが６４bitＯＳの場合に問題が生じる。図６（ｂ）に示すように、６４bitＯＳ上でも３２bitアプリは動作する。アプリケーションが３２bitで、ＯＳも６４bitＯＳの場合、Windows系ＯＳはＷＯＷ６４（Windows-On-Windows エミュレーション・サブシステム ）という仕組みで、３２bitアプリを動作させる。一方、デバイスドライバの一部はカーネルモードで動作するので、Windows系ＯＳと同様に６４bitで作成されている。Windows系ＯＳは印刷時にＷＯＷ６４の機能として、splwow64.exeというプロセスを実行する。
【００３３】
この場合、３２bitプロセスで動作するアプリが作成するDeviceContextと、ＵＩドライバがsplwow64.exeに対し書き込もうとするDeviceContextとは異なるものになる。このためＵＩドライバは送付状データを受け取ることができない。
【００３４】
以上のように、従来、存在した手法では、いずれも問題があった。
本発明は、ＯＳとの親和性を損なうことなく、スプール形式、インストール方式、及び、ＯＳの違い等に影響されずに、送付状を送信できるプログラムを提供することを目的とする。
【課題を解決するための手段】
【００３５】
本発明は、  画像データの出力の設定条件を表示し、前記設定条件を受け付ける設定受付プログラムと、アプリケーションから文書データを取得し、前記設定受付プログラムにより受け付けられた設定条件に基づいて印刷データに変換する画像処理プログラムと、を有し、前記設定受付プログラムは、所定のプログラムに基づいて動作する情報処理装置に、前記所定のプログラムが生成した出力処理の識別情報を取得するステップと、前記設定条件に所定の画像データの生成指示が設定されている場合、前記所定の画像データを生成するステップと、前記取得された識別情報と前記生成された所定の画像データとを対応付けて、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力するステップと、を実行させ、前記画像処理プログラムは、情報処理装置に、前記アプリケーションから文書データを取得する際に、所定のプログラムから前記識別情報を取得するステップと、前記所定のプログラムを介して、前記印刷データ処理プログラムから、前記取得された識別情報に対応付けられた所定の画像データを受け付けるステップと、前記受け付けた所定の画像データと前記取得された文書データとを、前記設定条件に基づいて印刷データに変換するステップと、を実行させる、ことを特徴とする。
【発明の効果】
【００３６】
ＯＳとの親和性を損なうことなく、スプール形式、インストール方式、及び、ＯＳの違い等に影響されずに、送付状を送信できるプログラムを提供することができる。
【図面の簡単な説明】
【００３７】
【図１】送付状の一例を模式的に示す図の一例である。
【図２】Point & Printを模式的に説明する図の一例である。
【図３】描画ドライバによる送付状データの付加を模式的に説明する図の一例である。
【図４】ＵＩドライバによる送付状データの付加を模式的に説明する図の一例である。
【図５】一時ファイルに出力した場合の問題を説明する図の一例である。
【図６】デバイスコンテキストに送付状データを添付する方法を説明する図の一例である。
【図７】本実施形態のプリンタドライバの概略的な特徴を説明する図の一例である。
【図８】印刷システムの概略構成図、クライアントＰＣのハードウェア構成図の一例をそれぞれ示す図である。
【図９】クライアントＰＣ及びプリンタドライバの機能ブロック図の一例である。
【図１０】LanguageMonitorの動作を説明する図の一例である。
【図１１】Windows系ＯＳの印刷アーキテクチャにおける、描画ドライバとＵＩドライバについて説明する図の一例である。
【図１２】ＲＡＷスプールにおける、Windows系ＯＳの印刷アーキテクチャの流れを説明する図の一例である。
【図１３】Windows系ＯＳの印刷アーキテクチャのシーケンス図の一例である（ＲＡＷスプール）。
【図１４】ＥＭＦスプールにおける、Windows系ＯＳの印刷アーキテクチャの流れを説明する図の一例である。
【図１５】Windows系ＯＳの印刷アーキテクチャのシーケンス図の一例である（ＥＭＦスプール）。
【図１６】ExtEscape()関数の書式、シーケンス図の一例を説明する図の一例である。
【図１７】DrvDocumentEvent()関数、SendRecvBidiDataFromPort()の書式を説明する図の一例である。
【図１８】PBIDI_REQUEST_CONTAINER構造体の書式、BIDI_REQUEST_DATA 構造体の書式の一例を示す図である。
【図１９】Windows系ＯＳが付与するJobIDを模式的に説明する図の一例である。
【図２０】LanguageMonitorに記憶されるJobIDと送信設定を模式的に説明する図の一例である。
【図２１】ＲＡＷスプールのWindows系ＯＳの印刷アーキテクチャのシーケンス図の一例である。
【図２２】ＥＭＦスプールのWindows系ＯＳの印刷アーキテクチャのシーケンス図の一例である
【図２３】Point＆Print環境を備えた印刷システムの概略構成図の一例を示す。
【図２４】Point & Print環境におけるLanguageMonitorの作用を説明する図の一例である
【発明を実施するための形態】
【００３８】
以下、本発明を実施するための形態について図面を参照しながら実施例を挙げて説明する。
【実施例１】
【００３９】
図７は、本実施形態のプリンタドライバの概略的な特徴を説明する図の一例である。本実施形態では、プリンタドライバの動作を例として説明するが、プリンタドライバとPC-FAXドライバは主にユーザインタフェースと一部の機能が異なるだけで、内部的な動作は共通である。両者はＭＦＰ（Multifunction Peripheral）のデバイスドライバであり、プリンタドライバをPC-FAXドライバと称しても差し支えない。以下、ＭＦＰを単にプリンタと言うが、このプリンタはＦＡＸ機能を有している。
【００４０】
ＰＣ（Personal Computer）がWindows系ＯＳ上でアプリケーションを実行している。Windows系ＯＳの印刷アーキテクチャでは、図示するようなソフトウェア階層により、アプリケーションの文書データがプリンタにより描画処理されプリンタに送信される。ここではスプール形式を区別していない。
【００４１】
なお、Windows系ＯＳのクライアント系には、WindowsNT、Windows98、Windows2000、WindowsMe、WindowsXP、WindowsVista、Windows７、Windows8及びこれ以降のバージョンのＯＳが含まれる。サーバ系には、Windows 2000 Server、2003 Server、2008 Server及びこれ以降のバージョンのＯＳが含まれる。本実施例では、Windows系ＯＳを好適例とするが、Windows系ＯＳと同等の機能を有するＯＳであれば、ＯＳを制限しない。
【００４２】
プリンタに送信されるまでの処理手順は以下のようになる。図示するように、本実施形態のプリンタドライバは、LanguageMonitorとJobIDを使用して、ＵＩドライバが描画ドライバに画像データを送信することに特徴の１つがある。
【００４３】
なお、本実施形態で使用する「印刷アーキテクチャ」「印刷開始」「印刷処理」などの"印刷"は、描画ドライバが描画処理することを意味しており、印刷ジョブ及びＦＡＸ送信ジョブのいずれでも使用される言葉である。よって、"印刷"は必ずしもプリンタによる用紙などへの印刷を意味しない。
【００４４】
１．ユーザが送信処理を開始すると、アプリケーションがWindows系ＯＳを介して、ＵＩドライバを呼び出す。ユーザは宛先を入力するなどの送信設定を行い、実行ボタンを押下する。
２．アプリケーションが Windows系ＯＳのＧＤＩ ＡＰＩ を呼び出す（プリンタデバイスコンテキストの確保）。
３．Windows系ＯＳは送信ジョブの１つ１つにJobIDを付与する。JobIDはプリンタドライバ３０に通知される。
４．ＵＩドライバは、送付状データを作成する。送付状データは画像データである。
５．ＵＩドライバは、アプリケーションから取得した送付状データ及び送信設定と共に、JobIDをLanguageMonitor３２に通知する。送信設定はDEVMODEに格納可能なため、必ずしもLanguageMonitor３２に格納しなくてもよい。
【００４５】
LanguageMonitor３２は送付状データ及び送信設定とWindows系ＯＳが生成したJobIDを対応づけて記憶する。LanguageMonitor３２はJobIDをキーに送付状データ及び送信設定を管理するので、他のアプリケーションが送付状データ及び送信設定を上書きするようなことはない。
６．描画ドライバが送信設定と送付状データを読み出す際、JobIDを指定することでＵＩドライバが生成した送信設定と送付状データを、LanguageMonitor３２から取得することができる。このように、描画ドライバは一意に送付状データを特定できる。
【００４６】
印刷アーキテクチャで、ＥＭＦスプールを使用した場合でも、２回の印刷処理シーケンスにおいてJobIDをキーにLanguageMonitorが参照されるので、確実に送信設定と送付状データを受け渡すことができる。
７．描画ドライバは文書データと送信設定から描画データを生成する（送付状データは作成済み）。
８．LanguageMonitor３２が必要な処理を行う
９．ポートモニタ４２が、プリンタ ポートの種類 (USB, TCP/IP etc) に合わせて出力処理を行う
１０．プリンタに描画データが送信される
LanguageMonitor３２は、Windows系ＯＳの機能なので、Point＆Print環境のサーバＰＣ上で利用可能である。このため、ＵＩドライバはWindows系ＯＳの機能を利用してサーバＰＣのLanguageMonitor３２にアクセスできるし、サーバＰＣの描画ドライバが描画処理する際も、LanguageMonitor３２からJobIDで指定した送付状データ（及び送信設定も）を取得することができる。このように、本実施形態の送付状データの管理手法は、Point＆Print環境においてもローカルインストールされたプリンタドライバ３０と同様に有効である。
【００４７】
また、Windows系ＯＳが６４bitＯＳであり、アプリケーションが３２bitアプリの場合、アプリケーションが印刷を実行することで、splwow64.exeのプロセスが動作するので、６４bitのＵＩドライバがLanguageMonitorを使用する。よって、６４bitの描画ドライバは送付状データ作成時のLanguageMonitorにアクセスできる。
【００４８】
したがって、本実施形態のプリンタドライバ３０は、Windows系ＯＳとの親和性を損なうことなく、スプール形式(ＲＡＷスプール、ＥＭＦスプール)、インストール方式(ローカルインストール、Point&Printインストール)、及び、ＯＳ(３２bitＯＳ、６４bitＯＳ)の違いに影響されずに、送付状を送信することができる。
【００４９】
なお、LanguageMonitor３２は、従来、単にポートモニタ４２とのインタフェースとして利用されている。Windows系ＯＳでは、プリンタドライバ３０は、Windows系ＯＳが提供するLanguageMonitor３２を使用しても、メーカ（プリンタメーカ、ＦＡＸメーカ等）が提供するLanguageMonitor３２を使用してもよいとされている。本実施形態においても、LanguageMonitor３２は汎用品とメーカ製のどちらも使用することができる。
【００５０】
〔構成例〕
図８（ａ）は印刷システム４００の概略構成図の一例を、図８（ｂ）はクライアントＰＣ１００のハードウェア構成図の一例をそれぞれ示す。クライアントＰＣ１００とプリンタ２００がネットワーク３００を介して接続されている。プリンタ２００は１台のみあればよい。
【００５１】
クライアントＰＣ１００がユーザの操作を受け付け、文書作成ソフトなどのアプリケーションが、ＧＤＩ、ＤＤＩ及びプリンタドライバ等を利用して印刷を要求する。プリンタドライバ３０は、後述する手順で印刷データを作成してプリンタ２００に送信する。プリンタ２００は画像形成機能を有していれば、コピー機、複写機、ＦＡＸ装置などその呼称は問われない。本実施形態では、プリンタ２００が少なくともＦＡＸ機能を有している。また、プリンタ２００は電子写真方式の画像形成機能又はインクジェット方式の画像形成機能のどちらの機能を有していてもよい。また、ＰＣ（Personal Computer）１００とプリンタ２００はＵＳＢケーブルなどで直接接続されていてもよい。
【００５２】
クライアントＰＣ１００は、それぞれバスで相互に接続されているＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、外部Ｉ／Ｆ１４、通信装置１５、入力装置１６、表示制御部１７及び記憶装置１８を有する。ＣＰＵ１１は、ＯＳ１０、アプリケーション３１、及び、プリンタドライバ３０を記憶装置１８から読み出して、ＲＡＭ１０３を作業メモリにして実行する。
【００５３】
アプリケーション３１は、プリンタ２００に印刷要求するものであればよく、例えば、文書作成ソフト、ブラウザソフト、プレゼン資料作成ソフト等、種々のものがある。印刷対象となる文書データを、作成、編集、表示、管理などして、印刷可能なアプリケーションであればどのようなものでもよい。なお、文書データは、文字や記号、数値だけを含むものではなく、画像、写真など種々の印刷対象物を含む。
【００５４】
ＲＡＭ１３は必要なデータを一時保管する作業メモリ（主記憶メモリ）になり、ＲＯＭ１２にはＢＩＯＳや初期設定されたデータ、ブートプログラム等が記憶されている。
【００５５】
外部Ｉ／Ｆ１４はＵＳＢケーブル等のケーブルや、可搬型の記憶媒体２０を装着するインタフェースである。通信装置１５は、ＬＡＮカードやイーサネット（登録商標）カードであり、ＣＰＵ１１からの指示によりプリンタ２００にフレームデータ（本実施形態では主に印刷データ）を送信する。
【００５６】
入力装置１６は、キーボード、マウスなど、ユーザの様々な操作指示を受け付けるユーザインターフェイスである。タッチパネルや音声入力装置を入力装置とすることもできる。表示制御部１７は、アプリケーション３１が指示する画面情報に基づき所定の解像度や色数等でディスプレイ１９の描画を制御する。ディスプレイ１９は、液晶や有機ＥＬなどのＦＰＤ（Flat  Panel  Display）である。
【００５７】
記憶装置１８は、ＨＤＤ（Hard  Disk  Drive）やフラッシュメモリなどの不揮発メモリを実体とし、ＯＳ１０、プリンタドライバ３０、及び、アプリケーション３１を記憶している。
【００５８】
記憶媒体２０は、例えば、ＳＤカードやＵＳＢメモリなど不揮発性のメモリである。プリンタドライバ３０は、記憶媒体２０に記録された状態又は不図示のサーバからダウンロードされる態様で配布される。
【００５９】
図９は、クライアントＰＣ１００及びプリンタドライバ３０の機能ブロック図の一例である。クライアントＰＣ１００は、Windows系ＯＳ上で動作する、アプリケーション３１、プリンタドライバ３０、LanguageMonitor３２及び通信部４０を有する。このうち、LanguageMonitor３２はWindows系ＯＳにより提供されるため、広義ではWindows系ＯＳの一部である。この他のＧＤＩ、スプーラ、プリンタプロセッサなどは省略したが、Windows系ＯＳと共にクライアントＰＣ１００にインストールされている。
【００６０】
プリンタドライバ３０は、ＵＩドライバ３８と描画ドライバ３９を有している。さらにＵＩドライバ３８はデータ生成部３８１を有する。ＵＩドライバ３８は、ユーザがアプリケーションに対して文書の送信操作を入力することで、送信設定画面をディスプレイ１９に表示する。ユーザは、送信設定画面に対し、宛先のＦＡＸ番号、氏名、会社名、部門名、及び、送付状の添付の有無などを設定することができる。アドレス帳を有する場合、アドレス帳からＦＡＸ番号等を選択することができる。
【００６１】
また、ＵＩドライバ３８は、ユーザが送信開始指示を入力した後も、送信設定画面をディスプレイ１９に表示して、送信設定の変更を受け付けることができる。
【００６２】
データ生成部３８１は、図１のような送付状データを生成する。送付状には予めテンプレートが用意されており、送信元の氏名、会社名、部門名、及び、宛先のＦＡＸ番号、氏名、会社名、部門名の記述位置は決まっている。データ生成部３８１は、送信設定画面で設定された送信設定を送付状データのテンプレートに配置して、描画データに変換する。送信設定やテンプレートを予め用意しておくことで、種々の情報を画像データ化することができる。
【００６３】
また、描画ドライバは、送付状データを表紙として１枚目に追加する必要はなく、２枚目以降に追加することができる。また、１つの送付状データを複数枚、印刷することもでき、文書データに送付状データを合成する（例えば、全ページ又は一部のページに「ＦＡＸ送信文書」と表示したり、全ページ又は一部のページの一部にアイコンを追加したりする）ことができる。
【００６４】
なお、印刷ジョブでは、送付状データの生成は一般に行われていないが、ＵＩドライバ３８と描画ドライバ３９は印刷ジョブでも送信ジョブでも同じものが使用される。したがって、印刷設定や送信設定から生成される画像データを印刷ジョブにおいて印刷することも可能である。
【００６５】
送信設定は、DEVMODE構造体（以下、DEVMODEという）という構造体（データテーブル）に格納される。DEVMODEはWindows系ＯＳ上で動作する各種のプリンタドライバ３０に対して送信条件を共通に設定するためのメンバ変数が定義されたデータ構造である。
【００６６】
描画ドライバ３９は、DEVMODEを参照して、アプリケーション３１によって与えられた印刷対象の文書データから送信設定を反映した印刷データを作成する。なお、印刷データには描画データ（例えばＰＤＬデータ）と制御データ（例えばＰＪＬの印刷コマンド）が含まれる。
【００６７】
LanguageMonitor３２は、データ保持部３２１と通信部３２２を有する。このうち、通信部３２２は、プリンタドライバ３０が通信部４０に印刷データを送信する際に、通信を制御するものであり、従来のLanguageMonitor３２が有している。通信部３２２はLanguageMonitorとクライアントＰＣの通信部４０との間で、データの送受信制御を行う。通信部３２２は通信部４０を介してプリンタ２００からのメッセージを受信することもできる。これに対し、データ保持部３２１は、JobIDをキーに送付状データを対応づけて記憶する。データ保持部３２１は、LanguageMonitor３２の機能を利用してプリンタドライバ３０により実現される。このため、Windows系ＯＳの変更は必要ないか、あったとしてもわずかである。データ保持部３２１については後述する。
【００６８】
クライアントＰＣの通信部４０は、プリンタとの通信を行うブロックで、ＴＣＰ／ＩＰなどのプロトコルに従う処理を行う。
【００６９】
図１０は、LanguageMonitor３２の動作を説明する図の一例である。LanguageMonitor３２はプリントプロセッサ４１から送信された印刷データを受け取り、通信部４０（ポートモニタ４２及びポートドライバ４３）に送信する。プリントプロセッサ４１は、スプーラの機能である。ポートモニタ４２は、通信プロトコルに基づく処理を行い、ポートドライバ４３に印刷データを送信する。ポートドライバ４３は、プリンタ２００とクライアントＰＣ１００との接続インタフェース（USB,NIC等）を制御して、印刷データをプリンタ２００に送信する。
【００７０】
〔従来のWindows系ＯＳの印刷アーキテクチャ〕
図１１は、Windows系ＯＳの印刷アーキテクチャにおける、描画ドライバ３９とＵＩドライバ３８について説明する図の一例である。
【００７１】
Windows系ＯＳのＧＤＩ３４はＤＤＩコールによりプリンタドライバ３０のＵＩドライバ３８と描画ドライバ３９を呼び出す。ＵＩドライバ３８と描画ドライバ３９は、直接相互にやりとりをすることができない。しかし、Windows系ＯＳからのドライバの呼び出しI/FであるＤＤＩの引数にDEVMODEがあることにより、双方がDEVMODEを参照することができる。
・Windows系ＯＳから呼び出されたＵＩドライバ３８は、ユーザの送信設定を受け付けDEVMODEに保存する
・DEVMODEは印刷準備開始時にWindows系ＯＳから描画ドライバ３９に渡される
すなわち、ＵＩドライバ３８は、「送信設定」を決定し、描画ドライバ３９は「送信設定」を印刷準備開始時に受け取り、送信設定に基づき印刷コマンドや描画データを生成する。これがWindows系ＯＳの印刷アーキテクチャの基本的な印刷シーケンスとなる。描画ドライバ３９は、ＵＩドライバ３８に続いて処理するので、一般的なプリンタドライバ３０では、ユーザの印刷開始指示後に送信設定を変更することはできない。
【００７２】
図１２は、ＲＡＷスプールにおける、Windows系ＯＳの印刷アーキテクチャの流れを説明する図の一例である。
（１）ユーザが、ＵＩドライバ３８が提供する印刷ダイアログ（ＧＵＩ）によって送信設定を変更する（すでに登録されている初期値を変更する）。
（２）ユーザがアプリケーションに印刷開始指示の操作を行う。
（３）アプリケーションはＵＩドライバ３８と送信設定が入っているDEVMODEをやりとりして、ユーザの送信設定を受け取る。
（４）アプリケーションはＧＤＩ３４に印刷命令とDEVMODEをＧＤＩコールとして伝える。
（５）ＧＤＩ３４はＧＤＩコールをＤＤＩコールに変換して描画ドライバ３９に伝える。
（６）描画ドライバ３９は、プリンタが理解できる言語に変換したＲＡＷデータをスプーラ３５に送出する。
（７）スプーラ３５は、描画ドライバ３９から受け取ったＲＡＷデータをプリンタ２００に送信する。
【００７３】
図１３は、図１２のWindows系ＯＳの印刷アーキテクチャのシーケンス図の一例である。なお、実際にはＧＤＩ３４とＵＩドライバ３８、又は、ＧＤＩ３４と描画ドライバ３９の間では、不図示の通信が行われているが省略している。ＧＤＩ３４からＵＩドライバ３８へのメッセージはＵＩ系のＤＤＩ関数で、描画ドライバ３９へのメッセージは描画系ＤＤＩ関数でそれぞれ通知される。
【００７４】
この図１３のS1までにＵＩドライバ３８はユーザが設定した送信設定を受け付けており、ユーザが印刷開始指示の操作を行うアプリケーション３１がDEVMODEに格納された送信設定を取得する。
S1: アプリケーション３１はまず、ＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーションはCreateDC()関数で送信設定（DEVMODE）を引数にしてＧＤＩ３４をコールする。
S1.1:ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に送信設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した送信設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）送信設定を参照することができる。
【００７５】
S2:ＧＤＩ３４が印刷準備完了をアプリケーションに通知すると、アプリケーションはＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーションはStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。
S2.1:ＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPRE()をＵＩドライバ３８に送出する。
S2.2:ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。Windows系ＯＳは、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()をＵＩドライバ３８に送出する。
【００８０】
この後、デバイスコンテキストが消去され（アプリケーションがＧＤＩにDeleteDC（）を通知し）、描画ドライバ３９は送信設定を参照できなくなる（描画ドライバ３９にDrvDisablePDEV()のＤＤＩコールが通知される）。
【００８１】
図１４は、ＥＭＦスプールにおける、Windows系ＯＳの印刷アーキテクチャの流れを説明する図の一例である。
（１）ユーザが、ＵＩドライバ３８が提供する印刷ダイアログ（ＧＵＩ）によって送信設定を変更する（すでに登録されている初期値を変更する）。
（２）ユーザがアプリケーションに印刷開始指示の操作を行う。
（３）アプリケーションはＵＩドライバ３８と送信設定が入っているDEVMODEをやりとりして、ユーザの送信設定を受け取る。
（４）アプリケーションはＧＤＩ３４に印刷命令をＧＤＩコールとして通知する。
（５）ＧＤＩ３４はＥＭＦデータをスプールデータとしてスプーラ３５に渡す。
（６）アプリケーションの印刷データが一通りスプールされると、スプーラ３５がプリントプロセッサ４１にデスプールすることを伝え、スプールデータを渡す。
（７）プリントプロセッサ４１は、スプールデータをページごとに編集することで、集約・逆順・製本の機能を実現し、編集した内容をＧＤＩ３４にＧＤＩコールとして通知する。
（８）ＧＤＩ３４はＧＤＩコールをＤＤＩコールに変換して描画ドライバ３９に通知する。
（９）描画ドライバ３９は、プリンタが理解できる言語に変換したＲＡＷデータをスプーラ３５に送出する。
（１０）スプーラ３５は、描画ドライバ３９から受け取ったＲＡＷデータをプリンタに送信する。
【００８２】
図１５は、図１４のWindows系ＯＳの印刷アーキテクチャのシーケンス図の一例である。なお、実際にはＧＤＩ３４とＵＩドライバ３８、又は、ＧＤＩ３４と描画ドライバ３９の間では、不図示の通信が行われているが省略している。また、ＥＭＦスプールでは、アプリケーションプロセスとスプーラプロセスが分かれている。
【００８３】
なお、この図１５の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()をＧＤＩ３４に送出する。
【００９０】
このように、アプリケーションのプロセスが終了すると、印刷が完了していなくてもアプリケーションは印刷を終了したように見える。この後、スプーラプロセスで再度印刷処理がかかり、ここでＥＭＦデータからＲＡＷデータへ変換される。
【００９１】
Windows系ＯＳはアプリケーション３１とＧＤＩ３４の通信を監視して、所定のタイミングになると（例えばStartPage()の後）、スプーラ３５にスプーラプロセスを開始させる。
【００９２】
S7:スプーラ３５は、プリントプロセッサ４１に印刷準備開始を指示する。具体的には、PrintDocumentOnPrintProcessor()を送信する。
S7.1:プリントプロセッサ４１はＧＤＩ３４に印刷準備開始を指示する。具体的にはGetJobAttributes()を送信する。
S7.1.1:ＧＤＩ３４は描画ドライバ３９に送信設定を送出する。具体的には、CreateDC()の引数でアプリーションがＧＤＩ３４に渡した送信設定（DEVMODE）が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）送信設定を参照することができる。
S7.1.2:ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。Windows系ＯＳは、CreateDC()関数により所定のタイミングでJobIDを生成している。ＧＤＩ３４はDrvStartDoc()関数の引数にJobIDを設定するので、描画ドライバ３９はJobIDを参照できるようになる。
S7.2:以降、プリントプロセッサ４１はページ単位の処理を繰り返す。まず、プリントプロセッサ４１はＧＤＩ３４に新しいページの印刷データを受け入れるよう指示する。具体的には、プリントプロセッサ４１はGdiStartPageＥＭＦ()をＧＤＩ３４に送出する。
S7.2.1:ＧＤＩ３４はDrvStartPage()を描画ドライバ３９に送出する。
S7.2.2:ＧＤＩ３４は、描画関数（文書データ）を描画ドライバ３９に送出する。描画ドライバ３９は送信設定に従って文書データを印刷データに変換する。
S7.2.3:ＧＤＩ３４は描画ドライバ３９に１ページ分の書き込みが終了したことを通知する。具体的には、ＧＤＩ３４はDrvSendPage()を描画ドライバ３９に送出する。
【００９３】
以降は、ページ単位の繰り返しになる。
【００９４】
〔本実施形態のWindows系ＯＳの印刷アーキテクチャ〕
次に、本実施形態のWindows系ＯＳの印刷アーキテクチャについて説明する。
まず、本実施形態の印刷アーキテクチャで使用するＡＰＩ等について説明する。
図１６（ａ）は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３２にもWindows系ＯＳによって決められた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系ＯＳは「Bidi Request and Response Schemas」として、プリンタとアプリケーションの間で双方向通信のために使用可能な、問い合わせと応答の組を提供するデータベースのスキーマを提供している。
・versionは、スキーマのバージョンであり例えば"１"である。
・Flagsは、システム（Windows系ＯＳ）により予約されたフラグのセットでありゼロでなければならない。
・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と送付状データの格納＞
従来から、Windows系ＯＳは印刷開始命令を受け付けた順にシステムで一意のID（JobID）を生成している。ＲＡＷスプールとＥＭＦスプールのいずれでも、描画ドライバ３９及びＵＩドライバ３８がJobIDを取得するステップがある。すなわち、
描画ドライバ３９は、DrvStartDoc()の引数で受け取ることができる。
ＵＩドライバ３８は、DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()の引数で受け取ることができる。
【０１０６】
図１９は、Windows系ＯＳが付与するJobIDを模式的に説明する図の一例である。アプリケーションＡ及びアプリケーションＢが任意に印刷開始命令１〜３を発行する。
【０１０７】
Windows系ＯＳは、
アプリケーションＡの印刷開始命令１にJobID1を付与し、
アプリケーションＢの印刷開始命令２にJobID2を付与し、
アプリケーションＡの印刷開始命令３にJobID3を付与している。
【０１０８】
描画ドライバ３９及びＵＩドライバ３８はこれらのJobIDを取得するので、描画ドライバ３９及びＵＩドライバ３８が取得するJobIDも一意性が保証される。
【０１０９】
本実施形態では、このJobIDをキーにしてLanguageMonitor３２に送付状データを記憶させる。
【０１１０】
図２０は、LanguageMonitor３２に記憶されるJobIDと送付状データを模式的に説明する図の一例である。アプリケーションＡ,Ｂは、以下のように印刷開始を指示している。印刷開始が指示された順に、Windows系ＯＳによってJobIDが振られる。
１．アプリケーションAで送付状追加機能を「ON」にして印刷開始命令
２．アプリケーションBで送付状追加機能を「ON」にして印刷開始命令
３．アプリケーションAで送付状追加機能を「ON」にして印刷開始命令
ＵＩドライバ３８は、印刷開始後に送信設定画面を表示し送信設定を受け付ける。ＵＩドライバは送付状追加機能が「ON」なので、送付状データを作成する。そして、その送信刷設定に送付状データを紐付けして、JobIDをキーにしてLanguageMonitor３２に設定する（setする）。図の例だと、LanguageMonitor３２は、JobIDと送付状データの組み合わせをテーブル状に保持し、JobIDと送付状データが対応づけて保持される。
【０１１１】
描画ドライバ３９は、送付状データが必要になった時に、JobIDをキーとしてLanguageMonitorに送付状データを問い合わせる（getする）。
【０１１２】
このように、Windows系ＯＳによって印刷ジョブに一意のキーが振られ、そのキーを利用して情報を保持する仕組みをLanguageMonitor３２が有する。このため、複数のアプリケーションが任意に複数の送信ジョブを開始しても、プリンタドライバ３０は送信ジョブ毎に送付状データを管理できる。このようにWindows系ＯＳの機能を利用することで、LanguageMonitor３２におけるデータ保持部３２１のキーを印刷ジョブで重複しないJobIDとすることができる。
【０１１３】
LanguageMonitor３２への設定及び問い合わせにSendRecvBidiDataFromPort()関数が使用される。プリンタドライバ３０がSendRecvBidiDataFromPort()にてLanguageMonitor３２を呼び出すことで、LanguageMonitor３２を保存場所として使うことが可能となる。すなわちLanguageMonitor３２とSendRecvBidiDataFromPort()関数によりデータ保持部３２１が実現される。
【０１１４】
上記のように、LanguageMonitor３２はメーカが開発しなくとも、標準のLanguageMonitor３２がWindows系ＯＳと共に利用可能である。メーカが開発しない場合はそのLanguageMonitor３２が動作する。メーカは決められたI/Fに合わせ、LanguageMonitor３２を開発すれば、独自の機能を追加することができる。本実施形態では、SendRecvBidiDataFromPort()というI/Fを利用することによりプリンタドライバ３０等はLanguageMonitor３２とのデータのやりとりが可能となる。
【０１１５】
より具体的には、COM InterfaceのインスタンスであるIBidiRequestのSetSchema()にJobIDを設定する。IBidiRequestのSetInputData()に送付状データを設定する。ＵＩドライバ３８がIBidiRequestオブジェクトをセットしてSendRecv()をコールすると、スプーラがSendRecvBidiDataFromPort()を呼び出し、LanguageMonitorにJobIDと送付状データが設定する。SendRecvBidiDataFromPort()の例えば第３引数のpActionにJobIDが設定され、第４引数のpReqDataに送付状データが設定される。
【０１１６】
描画ドライバ３９が送付状データを読み出す際は、IBidiRequestオブジェクトをセットしてSendRecv()をコールすると、IBidiRequestに送付状データが保存される。描画ドライバ３９がIBidiRequestのGetOutputData()をコールすると、送付状データを受け取ることができる。
【０１１７】
ＵＩドライバ３８も描画ドライバ３９も直接はSendRecvBidiDataFromPort()を呼び出していないが、実質的にSendRecvBidiDataFromPort()を呼び出しているとしてよい。
【０１１８】
＜動作手順＞
・ＲＡＷスプール
図２１は、ＲＡＷスプールのWindows系ＯＳの印刷アーキテクチャのシーケンス図の一例である。なお、実際にはＧＤＩ３４とＵＩドライバ３８、又は、ＧＤＩ３４と描画ドライバ３９の間では、不図示の通信が行われているが省略している。ＧＤＩ３４からＵＩドライバ３８へのメッセージはＵＩ系のＤＤＩ関数で、描画ドライバ３９へのメッセージは描画系ＤＤＩ関数でそれぞれ通知される。
【０１１９】
この図２０のS1までにＵＩドライバ３８はユーザが設定した送信設定を受け付けており、ユーザが印刷開始指示を操作するとアプリケーションがDEVMODEに格納された送信設定を取得する。
【０１２０】
S1: アプリケーションはまず、ＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーションはCreateDC()関数で送信設定を引数にしてＧＤＩ３４をコールする。
S1.1:ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に送信設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した送信設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）送信設定を参照することができる。
【０１２１】
S2:ＧＤＩ３４が印刷準備完了をアプリケーションに通知すると、アプリケーションはＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーションはStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。
【０１２２】
S2.1:ＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPRE()をＵＩドライバ３８に送出する。
【０１２３】
S2.2:ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。Windows系ＯＳは、CreateDC()関数により所定のタイミングでJobIDを生成している。ＧＤＩ３４はDrvStartDoc()関数の引数にJobIDを設定するので、描画ドライバ３９はJobIDを参照できるようになる。
【０１２４】
S2.3: 同様にＧＤＩ３４はＵＩドライバ３８に印刷開始を指示する。具体的にはDrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()をＵＩドライバ３８に送出する。ＧＤＩ３４はこの関数の引数にJobIDを設定するので、ＵＩドライバ３８はJobIDを参照できるようになる。
【０１２５】
S2.3.1: ここでデータ生成部３８１は、送付状データを生成するため（生成するかどうか判定するため）送信設定を参照するが、描画ドライバ３９と直接通信できないので、ＧＤＩ３４にExtEscape()を送出する。
【０１２６】
S2.3.1.1:ＧＤＩ３４は描画ドライバ３９にDrvEscape()を通知する。描画ドライバ３９はＧＤＩ３４を介して保持している送信設定をＵＩドライバ３８に送出する。
【０１２７】
S2.3.2:ExtEscape()の処理によりＵＩドライバ３８は、送信設定を取得できたことになる。送信設定に、送付状データの生成が指示されている場合、ＵＩドライバ３８は図１のような送付状データを作成する。なお、送信設定を再表示したり、変更を受け付ける設定が送信設定に設定されている場合、ここで、送信設定が再度、表示される。
【０１２８】
S2.3.3:ユーザが印刷ダイアログを閉じることで、ＵＩドライバ３８は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系ＯＳの印刷アーキテクチャのシーケンス図の一例である。なお、実際にはＧＤＩ３４とＵＩドライバ３８、又は、ＧＤＩ３４と描画ドライバ３９の間では、不図示の通信が行われているが省略している。
【０１３４】
図２２の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.2.2:ExtEscape()の処理によりＵＩドライバ３８は送信設定を取得したので、送信設定に、送付状データの生成が指示されている場合、ＵＩドライバ３８は図１のような送付状データを作成する。なお、送信設定を再表示したり、変更を受け付ける設定が送信設定に設定されている場合、ここで、送信設定が再度、表示される。
【０１４３】
S2.2.3:ユーザが印刷ダイアログを閉じることで、ＵＩドライバ３８はSendRecvBidiDataFromPort()::setで、JobIDをキーとし送付状データをLanguageMonitor３２に送出する。これにより、LanguageMonitor３２はJobIDと送付状データを対応づけて保持することができる。この時、ユーザがダイアログを"OK"又は"キャンセル"どちらで閉じたのかという内容も送出される。
【０１４４】
以降のS3〜S6について従来と同様なので省略する。ここまででアプリケーションプロセスでの印刷(ＥＭＦデータの生成)が終了する。
【０１４５】
この後、スプーラ３５のプロセスで再度印刷処理が始まり、ここでＥＭＦデータからＲＡＷデータへ変換される。Windows系ＯＳはアプリケーションとＧＤＩ３４の通信を監視して、所定のタイミングになると（例えばStartPage()の後）、スプーラ３５にプロセスを開始させる。
【０１４６】
S7:スプーラ３５は、プリントプロセッサ４１に印刷準備開始を指示する。
S7.1:プリントプロセッサ４１はＧＤＩ３４に印刷準備開始を指示する。
S7.1.1:ＧＤＩ３４は描画ドライバ３９に送信設定を送出する。具体的には、CreateDC()の引数でアプリーションがＧＤＩ３４に渡した送信設定が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）送信設定を参照することができる。
S7.1.2:ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。Windows系ＯＳは、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"でユーザが閉じていれば、送信設定に基づき印刷データを生成する。"キャンセル"で閉じていれば、ＦＡＸ装置にデータを送信しないようにする。
【０１５０】
S7.2.2:ＧＤＩ３４は、描画関数（文書データ）を描画ドライバ３９に送出する。描画ドライバ３９は送信設定に従って文書データを印刷データに変換する。
【０１５１】
S7.2.3:ＧＤＩ３４は描画ドライバ３９に１ページ分の書き込みが終了したことを通知する。具体的には、ＧＤＩ３４はDrvSendPage()を描画ドライバ３９に送出する。
以降はページ単位の繰り返しとなる。
【０１５２】
このようにJobIDをキーにしてLanguageMonitorに送付状データを記録することで、ＥＭＦスプールにおいて印刷開始後に、別のジョブが送付状データを作成しても、上書きされるおそれがない。
【０１５３】
なお、図２１，２２では、印刷のシーケンスがスプール形式によって異なるため、差異があるように見える。
しかし、描画ドライバ３９の
・DrvEnablePDEV()
・DrvStartDoc()
・DrvStartPage()
・DrvEscape()
ＵＩドライバ３８の
・DrvDocumentEvent()DOCUMENTEVENT_STARTDOCPOST()
LanguageMonitor３２の
・SendRecvBidiDataFromPort()::set
・SendRecvBidiDataFromPort()::get
の各関数内で行われている処理は、ＲＡＷスプールでもＥＭＦスプールでも全く同じ処理である。したがって、本実施形態の送付状データの管理方法はスプール形式によらず、実現可能である。また、複数のアプリケーションが作動する環境でも、LanguageMonitorを利用することで、他のアプリケーションにより破壊されることなく送付状データを送信することができる。また、描画ドライバ３９が送付状データを作成するわけではないので、Windows系ＯＳとの親和性を損なうこともない。
【０１５４】
＜６４bitＯＳ上で３２bitアプリが動作する場合＞
また、アプリケーションが３２bitアプリで、Windows系ＯＳが６４bitＯＳの場合、ＷＯＷ６４によりＵＩドライバ３８がsplwow64.exeのプロセスで動作する場合がある。しかし、アプリケーションが３２bitアプリでも、ＵＩドライバ３８が６４bitプロセスのLanguageMonitorにJobIDと送付状データを記録するので、６４bitプロセスの描画ドライバ３９がLanguageMonitorにアクセスして送付状データを取得できる。
【０１５５】
具体的には、splwow64.exeがアプリケーションに置き換わり、アプリケーションプロセスがsplwow64プロセスになるだけで、図２１，２２のシーケンス図に変更がない。
【０１５６】
このように、本実施例のデバイスドライバは、Windows系ＯＳとの親和性を損なうことなく、スプール形式(ＲＡＷスプール、ＥＭＦスプール)、及び、ＯＳ(３２bitＯＳ、６４bitＯＳ)の違いに影響されずに、送付状を送信できる。
【実施例２】
【０１５７】
本実施例では、Point＆Print環境においてLanguageMonitor３２を利用した送付状データの管理方法について説明する。
【０１５８】
図２３は、Point＆Print環境を備えた印刷システムの概略構成図の一例を示す。４台のクライアントＰＣがネットワークを介してサーバＰＣと接続されている。サーバＰＣ１１０にはプリンタ２００が接続されているが、プリンタ２００はネットワークに接続されていてもよい。
【０１５９】
サーバＰＣ１１０にはプリンタドライバ３０がインストールされており、サーバＰＣ１１０が各クライアントＰＣにプリンタドライバ３０をコピーして配布する。よって、ユーザの手を煩わせることなく、サーバＰＣ１１０とクライアントＰＣが協働してプリンタドライバ３０をインストールすることができる。なお、以降は、クライアントＰＣ1がサーバＰＣ１１０に接続し、Point&Printによりプリンタドライバをインストールしたものとする。
【０１６０】
Point＆Print環境のサーバサイドレンダリングでは、クライアントＰＣがユーザの送信設定を受け付け、サーバＰＣ１１０が描画処理を行うため、送信設定などを共有することが困難である。
【０１６１】
これに対し、本実施例ではWindows系ＯＳが提供する印刷アーキテクチャの内部のLanguageMonitor３２を利用してクライアントＰＣとサーバＰＣ１１０が送信設定や送付状データを交換する。よって、サーバＰＣ１１０はクライアントＰＣから印刷アーキテクチャ内の処理で送付状データを取得できる。
【０１６２】
図２４は、Point & Print環境におけるLanguageMonitor３２の作用を説明する図の一例である。LanguageMonitor３２はWindows系ＯＳの印刷アーキテクチャの中に組み込まれる一モジュールである。このため、Point&PrintによりクライアントＰＣ側がＵＩドライバ３８の処理を、サーバＰＣ側が描画ドライバ３９の処理を受け持ったとしても、LanguageMonitor３２はサーバＰＣ側で１つだけ機能する。クライアントＰＣ側にもLanguageMonitorはあるが機能しない。
【０１６３】
このため、クライアントＰＣのプリンタドライバ３０とサーバＰＣ１１０のプリンタドライバ３０は1つのLanguageMonitor３２にアクセスする。
【０１６４】
クライアントＰＣのWindows系ＯＳとサーバＰＣのWindows系ＯＳは、クライアントＰＣとサーバＰＣ１１０の通信を確立している（例えば、ＲＰＣ（Remote Procedure Call）を利用する）。そして、ＵＩドライバ３８がクライアントＰＣのLanguageMonitor３２にアクセスする場合、クライアントＰＣのLanguageMonitor３２は動作せず、スプーラ３５がサーバＰＣのLanguageMonitorにJobIDと送付状データを送信する。
【０１６５】
このようにクライアントＰＣとサーバＰＣ１１０が同じWindows系ＯＳをインストールしているので、Windows系ＯＳの印刷アーキテクチャのLanguageMonitor３２を共通に利用できる。このため、メーカ独自で開発したモジュールなどで生じやすいアクセス権限や通信エラーなどが起こりにくい。また、同様の理由で、Windows系ＯＳとの親和性も高い。
【０１６６】
なお、Point＆Printでもスプール形式にはＲＡＷスプールとＥＭＦスプールがあるが、ＲＡＷスプールの場合、サーバサイドレンダリングが存在しない。ＲＡＷスプールはアプリケーションのプロセスなので、レンダリング場所が制限されるためである。
【０１６７】
その他の場合、ＲＡＷスプールのクライアントサイドレンダリング、ＥＭＦスプールのクライアントサイドレンダリング、及び、ＥＭＦスプールのサーバサイドレンダリング、のいずれの場合も、図２４のようにLanguageMonitor３２を利用することができる。
【０１６８】
６４bitＯＳ上で３２bitアプリが動作した場合は、実施例１と同様に、クライアントＰＣ１でsplwow64.exeが動作するので、サーバＰＣの６４bitのLanguageMonitorにJobIDと送付状データが記憶される。
【０１６９】
このように、本実施例の印刷システム４００では、プリンタドライバのインストール形式、スプール形式及びＯＳに種類に関係なく、送付状データを送信することができる。
【符号の説明】
【０１７０】
３１        アプリケーション
３２        LanguageMonitor
３４        ＧＤＩ
３５        スプーラ
３８        ＵＩドライバ
３９        描画ドライバ
１００      クライアントＰＣ
２００      プリンタ
３２１      データ保持部
３２２      通信部
３８１      データ生成部
４００      印刷システム
【先行技術文献】
【特許文献】
【０１７１】
【特許文献１】特開２０１０−０６６８７６号公報
【図１】
0005919925.tif 000002
【図２】
0005919925.tif 000003
【図３】
0005919925.tif 000004
【図４】
0005919925.tif 000005
【図５】
0005919925.tif 000006
【図６】
0005919925.tif 000007
【図７】
0005919925.tif 000008
【図８】
0005919925.tif 000009
【図９】
0005919925.tif 000010
【図１０】
0005919925.tif 000011
【図１１】
0005919925.tif 000012
【図１２】
0005919925.tif 000013
【図１３】
0005919925.tif 000014
【図１４】
0005919925.tif 000015
【図１５】
0005919925.tif 000016
【図１６】
0005919925.tif 000017
【図１７】
0005919925.tif 000018
【図１８】
0005919925.tif 000019
【図１９】
0005919925.tif 000020
【図２０】
0005919925.tif 000021
【図２１】
0005919925.tif 000022
【図２２】
0005919925.tif 000023
【図２３】
0005919925.tif 000024
【図２４】
0005919925.tif 000025