JP5919930B2 - プログラム、情報処理装置、記憶媒体 - Google Patents

Description

本発明は、情報処理装置に、印刷の設定条件を表示し設定を受け付け、文書データを印刷データに変換させるプログラムに関する。

プリンタドライバを用いた印刷、及び、PC-FAXドライバを用いたＦＡＸ送信は次のような手順で行われる。
（１）ユーザがアプリケーションの印刷メニューから印刷設定画面を表示し、印刷条件や送信設定などを設定する（送信条件と印刷条件で設定内容が異なるが、区別せずに印刷設定という）。
（２）ユーザがアプリケーション上で印刷開始指示を行う
プリンタドライバは、（１）で決定された印刷設定をDEVMODE構造体というデータベースを介して（２）で受け取ることにより、その印刷設定に基づいて、アプリケーションから受け取る文書データをプリンタが解釈可能な印刷データに変換する。印刷データをプリンタやＦＡＸ装置に送信することで、プリンタは印刷を実行し、ＦＡＸ装置はＦＡＸ送信する。

ＯＳ（Operating System）であるWindows（登録商標。以下、省略する）の印刷アーキテクチャでは、プリンタドライバ又はPC-FAXドライバ（以下、単にプリンタドライバという）がアプリケーションから印刷設定を受け取る場合、まず、アプリケーションが、印刷設定をWindowsのＡＰＩを使ってWindowsのＧＤＩ（Graphics Device Interface）に対して通知する。ＧＤＩはWindows系ＯＳの一部である。

プリンタドライバに対してはＧＤＩから、印刷設定の命令がＤＤＩ（Device Driver Interface）で通知される。ＤＤＩはＩ／Ｆのみ定義されているので、ＤＤＩ内の実装方法（ＤＤＩで呼ばれた場合のプリンタドライの処理）は各メーカ(各プリンタドライバ・PC-FAXドライバ)で設計できる。

しかし、メーカが、プリンタドライバに独自にＩ／Ｆを定義したとしてもWindows系ＯＳはそのＩ／Ｆを知ることができないため、そのＩ／Ｆがコールされることはない。

１．DEVMODE構造体について
印刷設定を格納するDEVMODE構造体は、Public領域とPrivate領域に分かれている。図１は、DEVMODE構造体を説明する図の一例を、図２はDEVMODE構造体の参照について説明する図の一例を示す。Public領域は、ＯＳ定義の領域なので、アプリケーションから変更することができる。Public領域には、「印刷方向」「用紙サイズ」などといった、どのようなプリンタドライバでも設定することが必要な項目が存在する。

Private領域はメーカ独自の領域であり、メーカやプリンタドライバ毎にどのような情報を格納するかを定義することができる。アプリケーションやWindows系ＯＳは、Private領域にどのような情報が格納されているかを知ることができないので、Private領域を変更するにはプリンタドライバのＵＩドライバがPrivate領域の設定を表示して、変更を受け付けるしか方法がない。Private領域には、「印刷方式」「認証」などといったメーカやプリンタ機種ごとの特徴をもった設定項目が存在する。

ユーザは、ＵＩドライバが作成した用紙サイズや部数、両面印刷などの印刷条件を設定し印刷を指示する。ユーザが印刷設定指示の操作を行うと、アプリケーションがＧＤＩコールしてDEVMODE構造体をＧＤＩに送出する。図示するアプリケーションは、例えば文書作成プログラムなどのアプリケーション（例えば、ＭＳ−Ｗｏｒｄ：登録商標）である。 ＧＤＩは、アプリケーションからDEVMODE構造体を取得すると、ＤＤＩコールによりプリンタドライバの描画ドライバを呼び出して、DEVMODE構造体を送出する。

描画ドライバは、ＧＤＩから取得したDEVMODE構造体を参照して、アプリケーションによって印刷指示された文書データから、印刷設定を反映した印刷データを作成し、その作成した印刷データをスプーラに送出する。なお、印刷データには描画データ（例えばＰＤＬのデータ）と制御データ（例えばＰＪＬの印刷コマンド）が含まれる。

すなわち、ＵＩドライバと描画ドライバは、いずれもDEVMODE構造体を参照することができ、ＵＩドライバはPrivate領域を表示したり、設定変更を受け付けることができる。

２．自動化ニーズについて
このように、Private領域を変更するには、プリンタドライバが設定画面を表示し、ユーザ操作を受け付けるしか方法がないため、ユーザの操作が必須となってしまう。

しかし、ユーザによる操作なしに、全自動で処理を完了させたい処理も存在する。例えば、このような処理として、帳票印刷やＤＭ（ダイレクトメール）をＦＡＸ送信する処理がある。このような処理において、印刷設定は変わらないのに、１つの帳票毎に又は１つの送信文書の度に、ユーザが設定画面を操作してPrivate領域を変更しなければならないとすると、操作性が低下してしまう。

このため、ユーザの操作を伴わず、処理に適したアプリケーションにプリンタドライバのPrivate領域に格納される印刷設定を変更させたいという要求がある。

この要求に対し、メーカによっては、アプリケーションがプリンタドライバと直接、通信することができるように、プリンタドライバの拡張Ｉ／Ｆを提供している（例えば、特許文献１参照。）。ユーザからの要求によっては処理に適したアプリケーションも開発する。

図３は、拡張Ｉ／Ｆ、アプリケーション、及び、DEVMODE構造体について説明する図の一例である。図３のアプリケーションは、ユーザ側の処理に適したアプリケーション又は少なくとも拡張Ｉ／Ｆを呼び出せるアプリケーションである。アプリケーションは、拡張Ｉ／Ｆを呼び出して、Private領域の印刷設定を変更できる。このため、ユーザがアプリケーションで印刷開始指示を操作した後、ユーザによる操作なしに処理を完了させることができる。

３．DEVMODE構造体に格納される印刷設定について
ところで、プリンタドライバの中には、ユーザによる印刷開始指示後、プリンタに印刷データを送信する前に、設定画面を再度、表示し、印刷設定の変更を受け付けることが可能なものも存在する。

図４は、設定画面の再表示の一例として、機密印刷機能の画面例を示す図である。印刷開始指示後、機密印刷機能により、ユーザＩＤとパスワードの入力が要求される。ユーザは、ユーザＩＤとパスワードを入力しないと、ＯＫボタン５０１を押下できない。ユーザがユーザＩＤとパスワードを入力してＯＫボタン５０１を押下すると、ユーザＩＤとパスワードがプリンタに送信される。プリンタ本体側にはユーザＩＤとパスワードの組が予め登録されており、この組み合わせが一致しないとプリンタは印刷しない。この機密印刷機能では、よりセキュリティを高めるために、印刷ごとにパスワードを毎回入力させるようにすることも可能である。なお、ユーザがキャンセルボタン５０２を押下すると、印刷が中止される。

図５は、PC-FAXドライバの宛先確認機能の画面例を示す図である。印刷開始指示後、PC-FAXドライバは図示する宛先確認機能の画面を表示して、ユーザにＦＡＸ送信の宛先（ＦＡＸ番号）の入力を要求する。ＦＡＸ送信においては、宛先が送信毎ごとに異なることが多いため、PC-FAXドライバは、誤送信を防ぐためにこのような画面を表示する。

ユーザがＦＡＸ番号を入力し、送信ボタン５０３を押下すると、画像データがＦＡＸ装置に送信され、ＦＡＸ装置がＦＡＸを送信する。なお、ユーザがキャンセルボタン５０４を押下すると、ＦＡＸ送信が中止される。

図４，５の設定は、ユーザにパスワードを毎回、入力させることでセキュリティを強化したり、ＦＡＸの宛先指定を毎回、確認させることで誤送信を抑制したりするなど、印刷単位ごとに入力や確認を強制させたい場合に使われている。

印刷開始指示後に印刷設定の変更が可能であることは、アプリケーションがＵＩドライバによって印刷設定(DEVMODE構造体)を決定し、その印刷設定で印刷指示をするという手順を踏まなくてもよくなることを意味する。すなわち、DEVMODE構造体を介さずとも、印刷開始指示後に変更した印刷設定のみを描画ドライバが取得し印刷に利用できればいいということになる。

したがって、印刷設定が格納される場所は、DEVMODE構造体だけとは限らなくなる。実際に、PC-FAXドライバでは、ＦＡＸの送信宛先情報などが、DEVMODE構造体以外の構造体やファイルに格納されている。また、全ての設定をDEVMODE構造体以外の構造体等に格納するプリンタドライバも存在する。

図６は、DEVMODE構造体の外に格納され得る印刷設定の一例を示す図である。例えばＦＡＸ送信時の宛先情報と印刷時の個人情報が、DEVMODE構造体の外に格納され得る印刷設定である。

また、DEVMODE構造体に印刷設定を格納しなくてもよい情報だから格納しないという以外にも、格納可能な情報でもあえてDEVMODE構造体に印刷設定を格納していない場合もある。

上記のように、DEVMODE構造体は、ＵＩドライバによって印刷設定が格納されたり、グラフィックスドライバによって印刷設定が参照されたりする。格納時・参照時、DEVMODE構造体を渡す起点になっているのはアプリケーションである。実際にはアプリケーションがメモリを確保し、Windows系ＯＳを介してＵＩドライバに渡し、その中身をＵＩドライバが埋める。また、アプリケーションがWindows系ＯＳを介して印刷を行うと、グラフィックスドライバがDEVMODE構造体の中身を参照するようになっている。

しかし、このことは、アプリケーションがDEVMODE構造体を破棄しない場合、もともとのユーザが設定した印刷設定が残ってしまい、DEVMODE構造体のファイルが別のユーザに渡される可能性があることを意味する。多くのアプリケーションは、印刷終了後、DEVMODE構造体を破棄するが、まれに破棄しないアプリケーションが存在する。

よって、DEVMODE構造体に、認証情報やパスワードといった個人情報を入れてしまうと、ファイルにその情報が残り、別のユーザに渡ってしまいセキュリティを低下させてしまう。そのため、個人情報はDEVMODE構造体に格納していないプリンタドライバが存在する。

４．Windows系ＯＳの印刷アーキテクチャについて
ところで、Windows系ＯＳの印刷アーキテクチャとして、プリンタドライバの印刷では、ＲＡＷスプール形式とＥＭＦスプール形式といった２つのスプール形式が存在する。ＲＡＷスプール形式では、アプリケーションのプロセスで、アプリケーションからプリンタドライバが取得した文書データをプリンタが解釈可能なＲＡＷデータに変換する印刷処理を行う。ユーザから見ると印刷処理が完了するまでアプリケーションの操作ができない。

ＥＭＦスプール形式では、アプリケーションのプロセスで、アプリケーションからWindows系ＯＳが取得した文書データをプリンタに依存しないＥＭＦデータ形式に変換しスプールする。そして、スプーラプロセスでスプールされたＥＭＦデータをプリンタドライバが、プリンタが解釈可能なＲＡＷデータに変換する印刷処理を行う。ユーザから見ると、アプリケーションのプロセスでＥＭＦデータへの変換が終了した時点で、アプリケーションを操作できるようになる。

いずれの仕組みでも、ＤＤＩの実装方法として、印刷開始後に印刷設定画面を表示して印刷設定を表示できるようにすることは可能である。

５．Point & Printについて
次に、プリンタドライバ又はPC-FAXドライバのインストール方式と、印刷開始後の印刷設定の関係について説明する。Windows系ＯＳのプリンタドライバではPoint & Printというインストール形式が存在する。

図７は、Point & Printの概略を説明する図の一例である。ネットワークにプリンタ、サーバＰＣ及びクライアントＰＣが接続されている。サーバＰＣ及びクライアントＰＣにWindows系ＯＳ(サーバはサーバ用)がインストールされている。

クライアントＰＣは、このサーバＰＣをプリントサーバとして、プリンタに対して印刷要求することができる。このようなシステムでは、クライアントＰＣにはサーバＰＣと同じプリンタドライバがインストールされている必要がある。ネットワーク上の個々のクライアントＰＣに、管理者などがプリンタドライバをインストールするには多くの時間と労力を必要とする。

Point & Printではこの不都合を解決する手段として、サーバＰＣからクライアントＰＣにプリンタドライバをダウンロードしてインストールすることを可能にしている。これは、Windows系ＯＳ標準の機能である。なお、Point & Printによる印刷手順においても、印刷時にはＲＡＷスプール形式とＥＭＦスプール形式が存在する。

Point & Printによりインストールされたプリンタドライバは（ＥＭＦスプールの場合）、描画処理（レンダリングともいい、上記の描画ドライバによる処理）をクライアントＰＣが行うかサーバＰＣが行うかをユーザが変更することができる。クライアントＰＣ側で描画処理を行うことを「クライアントサイドレンダリング」という。サーバＰＣ側で描画処理を行う「サーバサイドレンダリング」という。

６．６４bitＯＳについて
従来の３２bitＯＳを搭載したクライアントＰＣが多くのユーザに使用されている状態で、６４bitＯＳも普及し始めている。６４bitＯＳでは原則的に６４bitアプリケーションしか動作しないが、すでに流通したり販売された３２bitアプリを動作させるため、Windows系ＯＳではＷＯＷ６４（Windows ON Windows６４）という仕組みが提供されている。

しかし、アプリケーションと異なりプリンタドライバは、６４bitＯＳ上では６４bitで作成されていなければならない。よって、クライアントＰＣには６４bitのプリンタドライバがインストールされている。

３２bitアプリがＷＯＷ６４で動作する場合、印刷は次のように行われる。
・ＷＯＷ６４としてsplwow64.exeが動作する。
・３２bitのアプリケーションからの描画命令はsplow64.exeを経由して６４bitのプリンタドライバに通知される。

なお、プリンタの共有（Point ＆ Print）のため、Windows系ＯＳでは「代替ドライバ」をインストールすることができる。代替ドライバは、サーバ上にインストールされているプリンタドライバをクライアントＰＣにインストールする仕組みである。クライアントＰＣに、プリンタに対応したプリンタドライバがインストールされていない場合、適切なプリンタドライバがインストールされる。この場合、６４bitＯＳに３２bitのプリンタドライバを登録することができる。

しかし、従来の技術では以下のような問題があった。
Ａ．拡張Ｉ／Ｆを用いた場合でも、印刷設定を格納できない場合がある。
図３に示したように、プリンタドライバが独自に拡張した拡張Ｉ／Ｆを利用して、アプリケーションが印刷設定を変更する場合、
・アプリケーションがプリンタドライバの拡張Ｉ／Ｆに対してDEVMODE構造体を入力し、
・印刷設定の変更を行った後のDEVMODE構造体を出力として受け取り、
・これを印刷開始時に描画ドライバに渡すDEVMODE構造体とする、
という処理が必要であった。

つまり、拡張Ｉ／Ｆを用いた場合に、DEVMODE構造体以外に印刷設定を格納すると、拡張Ｉ／ＦからDEVMODE構造体以外の印刷設定を取得できないので、DEVMODE構造体に全ての印刷設定を格納する必要がある。

このため、プリンタドライバが個人情報に関わる場合や、印刷開始指示後に印刷設定を決定・変更する場合に好ましい実装といえないおそれがある。このようなプリンタドライバでは、DEVMODE構造体に全ての設定項目を格納することができない。よって、ＵＩドライバに拡張Ｉ／Ｆを追加したとしても印刷設定を格納することができない場合がある。

Ｂ．DEVMODE構造体以外で印刷設定を一時的に保持する方法
そこで、ファイルやレジストリや共有メモリ空間などに印刷設定を出力する方法を採用しているプリンタドライバも存在する。

図８は、プリンタドライバの拡張Ｉ／ＦでDEVMODE構造体以外に印刷設定を格納する方法を説明する図の一例である。図８では、設定格納領域という領域に印刷設定の全て又は一部が格納される。

この方法ではDEVMODE構造体に設定を格納しないものを格納できるという点ではＡ．の問題点を解消するが、DEVMODE構造体を用いないことで別の問題が発生する。
以下の３つのケースである。
１．ＥＭＦスプールでの印刷シーケンスのケース
２．Point&Printインストールしたプリンタドライバでの印刷シーケンスのケース
３．６４bitＯＳを使用した場合
１．について、
DEVMODE構造体を使用する方法は、印刷時のＤＤＩコールシーケンスを利用しており、ＲＡＷスプールの時は実現可能である。しかし、スプール形式が異なると、Windows系ＯＳから呼ばれるＤＤＩコールシーケンスが変化する。ＥＭＦスプールでは、アプリケーションからの文書データをＥＭＦデータに変換する処理と、ＥＭＦデータをプリンタが解釈可能な描画データに変換する処理とがある。このため、Windows系ＯＳ内部の動作として、２回の印刷処理シーケンスが動作する。

この２回の印刷処理シーケンスのうち、ＥＭＦデータに変換する処理と、ＥＭＦデータをプリンタが解釈可能なＲＡＷデータに変換する処理では、プロセスが異なってしまう。Windows系ＯＳなどのシステム上では、プロセスの権限（例えば、システム権限とそれ以外）によって、リソースへのアクセス可能／不可能が決まるため、ファイルやレジストリの場所によっては、最終的にプリンタが印刷データを解する際に、拡張Ｉ／Ｆで設定した印刷設定を設定格納領域から取得できない可能性がある。また、最近のWindows系ＯＳではセキュリティの観点から、権限が異なるだけで全くアクセスできない場合もある。

２．について
拡張Ｉ／Ｆを用いる方法は、ローカル環境で、ユーザが使用するＰＣにプリンタドライバをインストールする方法では実現可能である。

しかし、上述したPoint & Printというインストール形式でインストールされたプリンタドライバではＩ／Ｆドライバと描画ドライバが動作する場所が異なる場合がある（サーバサイドレンダリングの場合）。

クライアントサイドレンダリングでは、ＵＩドライバ、描画ドライバともにクライアントＰＣ側で動作するが、サーバサイドレンダリングでは、ＵＩドライバはクライアントＰＣ側で動作し、描画ドライバはサーバＰＣ側で動作をする。このサーバサイドレンダリングでは、そもそも動作するＰＣが物理的に別であるため、プリンタドライバの拡張Ｉ／Ｆによって設定格納領域（ファイルやレジストリ）に一時格納した印刷設定を描画ドライバが取得できない。

３．について
ＷＯＷ６４は、Windows系ＯＳが提供する仕組みであり、splwow64.exeは印刷を行う時のみ動作する。３２bitアプリが６４bitの拡張Ｉ／Ｆにアクセスすることは、Windows系ＯＳがサポートする仕組みではないため、splwow64.exeが動作しない。よって、３２bitアプリは、６４bitの拡張Ｉ／Ｆを有するプリンタドライバを利用することができない。

図９は、以上説明した、外部Ｉ／Ｆを利用した場合の印刷設定の受け渡しの実現可否状況を説明する図の一例である。図示するように、インストール環境がローカルでスプール形式がＥＭＦスプールの場合、インストール環境がPoint＆Printでスプール形式がＥＭＦスプールでレンダリング場所がサーバの場合、及び、６４bitＯＳ上で３２bitアプリが動作する場合、印刷設定の受け渡しが困難である。

本発明は、上記課題に鑑み、どのようなシステム環境においても、プリンタドライバが拡張Ｉ／Ｆを提供し、アプリケーションが拡張Ｉ／Ｆを利用して印刷設定を決定する印刷処理を行うことが可能なプログラムを提供することを目的とする。

本発明は、情報処理装置の動作の基本となる所定のプログラムを介して印刷の第１の設定条件の設定値を受け付ける設定受付プログラムと、アプリケーションから前記所定のプログラムを介して文書データを取得し、前記設定受付プログラムにより受け付けられた第１の設定条件に基づいて印刷データに変換する画像処理プログラムと、を有し、前記設定受付プログラムは、情報処理装置に、前記所定のプログラムを介することなく、前記アプリケーションから第２の設定条件を受け付けるステップと、インタフェースにより受け付けられた第２の設定条件を、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力するステップと、を実行させ、前記画像処理プログラムは、情報処理装置に、 前記アプリケーションからの文書データを印刷データに変換する際に、前記印刷データ処理プログラムから第２の設定条件を受け付けるステップと、前記設定受付プログラムにより受け付けた第１の設定条件と、前記印刷データ処理プログラムから受け付けた第２の設定条件の少なくとも一方に基づき、文書データを印刷データに変換するステップと、を実行させる、ことを特徴とする。

どのようなシステム環境においても、プリンタドライバが拡張Ｉ／Ｆを提供し、アプリケーションが拡張Ｉ／Ｆを利用して印刷設定を決定する印刷処理を行うことが可能なプログラムを提供することができる。

DEVMODE構造体を説明する図の一例である。 DEVMODE構造体の参照について説明する図の一例である。 拡張Ｉ／Ｆ、設定アプリケーション、及び、ＤＥＶＭＯＤＥについて説明する図の一例である。 プリンタドライバの機密印刷機能の画面例を示す図である。 PC-FAXドライバの宛先確認機能の画面例を示す図である。 DEVMODE構造体の外に格納され得る印刷設定の一例を示す図である。 Point & Printの概略を説明する図の一例である。 プリンタドライバの拡張Ｉ／ＦでDEVMODE構造体以外に印刷設定を格納する方法を説明する図の一例である。 外部Ｉ／Ｆを利用した場合の印刷設定の受け渡しの実現可否状況を説明する図の一例である。 本実施形態のプリンタドライバの概略的な特徴を説明する図の一例である。 印刷システムの概略構成図の一例、及び、クライアントＰＣのハードウェア構成図の一例である。 クライアントＰＣ及びプリンタドライバの機能ブロック図の一例である。 クライアントＰＣ及びプリンタドライバの機能ブロック図の別の一例である。 プリンタドライバの拡張Ｉ／Ｆ、アプリケーション及びＯＳの関係について説明する図の一例である。 Windows系ＯＳの印刷アーキテクチャにおける、描画ドライバとＵＩドライバについて説明する図の一例である。 LanguageMonitor３２の動作を説明する図の一例である。 拡張Ｉ／Ｆへの印刷設定の設定例を説明する図の一例である。 拡張Ｉ／Ｆへの印刷設定の設定例を説明する図の別の一例である。 SendRecvBidiDataFromPort()の書式を説明する図の一例である。 アプリケーションが拡張Ｉ／Ｆを介してＵＩドライバに印刷（ＦＡＸ送信）設定する際のシーケンス図の一例である。 拡張Ｉ／Ｆへの印刷設定の設定例を説明する図の一例である。 一括送信の送信手順を説明する図の一例である。 一括送信の送信手順を説明する図の一例である。 一括送信の送信手順を説明する図の一例である。 複数の論理プリンタに対する印刷設定を説明する図の一例である。 Point ＆ Print環境を備えた印刷システムの概略構成図の一例である。 Point ＆ Print環境におけるLanguageMonitor３２の作用を説明する図の一例である。 ６４bitＯＳ上で３２bitのアプリケーションが動作する場合のLanguageMonitorの作用を説明する図の一例である。

以下、本発明を実施するための形態について図面を参照しながら説明する。
図１０は、本実施形態のプリンタドライバの概略的な特徴を説明する図の一例である。
（１）プリンタドライバのＵＩドライバは、Windows系ＯＳ（Operating System）で定義されたＤＤＩ（Device Driver Interface）以外に、独自の拡張Ｉ／Ｆ（拡張Ｉ／Ｆを提供するブロックを拡張Ｉ／Ｆ部３８２としている）をアプリケーション３１に提供する。ＵＩドライバ３８は、独自の拡張Ｉ／Ｆ部３８２で印刷設定の変更を受け付けることができる。
（２）ＵＩドライバ３８は、拡張Ｉ／Ｆ部３８２で受け取った印刷設定をLanguageMonitor３２に保持させる。アプリケーション３１がＵＩドライバを介して設定した印刷設定があればDEVMODE構造体に記憶される。以下では、印刷設定の格納先を区別せずにどちらも印刷設定という。なお、LanguageMonitor３２は、プリンタドライバの論理プリンタごとに印刷設定を保持することができる。なお、LanguageMonitorはＡＰＩの一種なので、以降、ＵＩドライバ等が直接、LanguageMonitorに印刷設定するという説明は、ＡＰＩを介して設定することを意味する。
（３）アプリケーション３１が印刷実行指示をWindows系ＯＳに出力すると、プリンタドライバの描画ドライバ３９はLanguageMonitor３２から印刷設定を読み出す。LanguageMonitor３２は、印刷設定を描画ドライバ３９に送出する。DEVMODE構造体に印刷設定が登録されていれば、その印刷設定も読み出す。
（４）描画ドライバ３９は、取得した印刷設定を反映し、プリンタに対する命令(PJL)やプリンタが印字できる印刷データ（PDL）を生成する。

アプリケーション３１が、拡張Ｉ／Ｆ部３８２を介して印刷設定を設定するので、DEVMODE構造体に秘匿性の高い情報を格納する必要がない。

LanguageMonitor３２を利用することで、印刷アーキテクチャがＲＡＷスプールかＥＭＦスプールかに関係なく、描画ドライバ３９が印刷設定を取得できる。すなわち、LanguageMonitor３２はWindows系ＯＳの一部の機能なので、プロセスが異なる等の理由でアクセスできなくなるということがない。

また、後述するようにLanguageMonitor３２は、Windows系ＯＳがサポートする機能なので、サーバサイドでレンダリングする場合でも、描画ドライバ３９はLanguageMonitor３２にアクセスすることができる。したがって、クライアントＰＣ（Personal Computer）にPoint ＆ Printでプリンタドライバがインストールされた場合でも、描画ドライバ３９が印刷設定を取得できる。

〔構成例〕
図１１（ａ）は印刷システム４００の概略構成図の一例を、図１１（ｂ）はクライアントＰＣ１００のハードウェア構成図の一例をそれぞれ示す。クライアントＰＣ１００とプリンタ２００がネットワーク３００を介して接続されている。プリンタ２００は１台のみあればよい。

クライアントＰＣ１００がユーザの操作を受け付け、文書作成ソフトなどのアプリケーション３１が、ＧＤＩ、ＤＤＩ及びプリンタドライバ等を利用して印刷を要求する。プリンタドライバ３０は、後述する手順で印刷データを作成してプリンタ２００に送信する。プリンタ２００は画像形成機能を有していれば、コピー機、複写機、ＦＡＸ装置などその呼称は問われない。また、プリンタ２００は電子写真方式の画像形成機能又はインクジェット方式の画像形成機能のどちらの機能を有していてもよい。また、クライアントＰＣ１００とプリンタ２００はＵＳＢケーブルなどで直接接続されていてもよい。

クライアントＰＣ１００は、それぞれバスで相互に接続されているＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、外部Ｉ／Ｆ１４、通信装置１５、入力装置１６、表示制御部１７及び記憶装置１８を有する。ＣＰＵ１１は、ＯＳ１０、アプリケーション３１、及び、プリンタドライバ３０を記憶装置１８から読み出して、ＲＡＭ１０３を作業メモリにして実行する。

アプリケーション３１は、プリンタ２００に印刷要求するものであればよく、例えば、文書作成ソフト、ブラウザソフト、プレゼン資料作成ソフト等、種々のものがある。印刷対象となる文書データを、作成、編集、表示、管理などして、印刷可能なアプリケーションであればどのようなものでもよい。なお、文書データは、文字や記号、数値だけを含むものではなく、画像、写真など種々の印刷対象物を含む。

ＲＡＭ１３は必要なデータを一時保管する作業メモリ（主記憶メモリ）になり、ＲＯＭ１２にはＢＩＯＳや初期設定されたデータ、スタートプログラム等が記憶されている。

外部Ｉ／Ｆ１４はＵＳＢケーブル等のケーブルや、可搬型の記憶媒体２０を装着するインタフェースである。通信装置１５は、ＬＡＮカードやイーサネット（登録商標）カードであり、ＣＰＵ１１からの指示によりプリンタ２００にパケットデータ（本実施形態では主に印刷データ）を送信する。

入力装置１６は、キーボード、マウスなど、ユーザの様々な操作指示を受け付けるユーザインターフェイスである。タッチパネルや音声入力装置を入力装置とすることもできる。表示制御部１７は、アプリケーション３１が指示する画面情報に基づき所定の解像度や色数等でディスプレイ１９の描画を制御する。ディスプレイ１９は、液晶や有機ＥＬなどのＦＰＤ（Flat Panel Display）である。

記憶装置１８は、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発メモリを実体とし、ＯＳ１０、プリンタドライバ３０、及び、アプリケーション３１を記憶している。

ＯＳ１０はWindows系ＯＳである。Windows系ＯＳのクライアント系には、WindowsNT、Windows98、Windows2000、WindowsMe、WindowsXP、WindowsVista、Windows７、Windows(r)8及びこれ以降のバージョンのＯＳが含まれる。サーバ系には、Windows 2000 Server、2003 Server、2008 Server及びこれ以降のバージョンのＯＳが含まれる。本実施例では、Windows系ＯＳを好適例とするが、Windows系ＯＳと同等の機能を有するＯＳであれば、ＯＳ１０を制限しない。

記憶媒体２０は、例えば、ＳＤカードやＵＳＢメモリなど不揮発性のメモリである。プリンタドライバ３０は、記憶媒体２０に記録された状態又は不図示のサーバ（Point ＆ Printの場合はサーバＰＣから）ダウンロードされる態様で配布される。

図１２は、クライアントＰＣ１００及びプリンタドライバ３０の機能ブロック図の一例である。クライアントＰＣ１００は、Windows系ＯＳ上で動作する、アプリケーション３１、プリンタドライバ３０、LanguageMonitor３２、及び、通信部４０を有する。このうち、LanguageMonitor３２はWindows系ＯＳにより提供されたため、広義ではWindows系ＯＳの一部である。この他のＧＤＩ、スプーラ、プリンタプロセッサなどは省略したが、Windows系ＯＳと共にクライアントＰＣ１００にインストールされている。

プリンタドライバ３０は、ＵＩドライバ３８と描画ドライバ３９を有している。さらにＵＩドライバ３８は表示部３８１及び拡張Ｉ／Ｆ部３８２を有する。ＵＩドライバ３８の表示部３８１は、ユーザがアプリケーションに対して文書の印刷操作を入力することで、印刷設定画面（印刷ダイアログと呼ばれることがある）をディスプレイ１９に表示する。ユーザは、印刷設定画面に対し、部数や両面などといった設定、「集約」「製本」「変倍」等の設定を行うことができる。また、表示部３８１は、ユーザが印刷開始指示を入力した後も、印刷設定画面をディスプレイ１９に表示して、印刷設定の変更を受け付けることができる。印刷設定は、DEVMODE構造体（以下、DEVMODEという）という構造体（データテーブル）に格納される。DEVMODEはWindows系ＯＳ上で動作する各種のプリンタドライバ３０に対して印刷条件を共通に設定するためのメンバ変数が定義されたデータ構造である。

また、ＵＩドライバ３８は、Windows系ＯＳを介さずアプリケーションからの印刷設定を受け付ける拡張Ｉ／Ｆ部３８２を有している。一般に、アプリケーション３１がＵＩドライバ３８にアクセスするには、ＧＤＩコールするなどして、Windows系ＯＳを介してアクセスする必要がある。拡張Ｉ／Ｆ部３８２は、ＵＩドライバ３８がアプリケーション３１から直接（ＯＳを介さずに）、印刷設定や印刷時の動作設定（後述する一括送信設定など）を受け取るための、プリンタドライバに独自のインタフェースである。

描画ドライバ３９は、DEVMODE（に印刷設定が含まれる場合）及び印刷設定（後述する動作設定がある場合は動作設定も）を参照して、アプリケーション３１によって印刷対象の文書データから印刷設定を反映した印刷データを作成する。

LanguageMonitor３２は、データ保持部３２１と通信部３２２を有する。このうち、通信部３２２は、プリンタドライバ３０が通信部４０に印刷データを送信する際に、通信を制御するものであり、従来のLanguageMonitor３２が有している。通信部３２２はLanguageMonitor３２とクライアントＰＣ１００の通信部４０との間で、データの送受信制御を行う。通信部３２２は通信部４０を介してプリンタ２００からのメッセージを受信することもできる。これに対し、データ保持部３２１は、印刷設定を記憶する。データ保持部３２１は、LanguageMonitor３２の機能を利用してプリンタドライバ３０により実現される。このため、Windows系ＯＳの変更は必要ないか、あったとしてもわずかである。データ保持部３２１については後述する。

クライアントＰＣ１００の通信部４０は、プリンタ２００との通信を行うブロックで、ＴＣＰ／ＩＰなどのプロトコルに従う処理を行う。

なお、図１２では、ＵＩドライバ３８が拡張Ｉ／Ｆ部３８２を有しているが、拡張Ｉ／Ｆ部３８２は、プリンタドライバに含まれていればよい。このため、図１３に示すように、ＵＩドライバ３８から独立した構成でもよい。

図１４は、プリンタドライバの拡張Ｉ／Ｆ部３８２、アプリケーション３１及びWindows系ＯＳの関係について説明する図の一例である。ＵＩドライバ３８が、本実施形態の特徴部の１つである拡張Ｉ／Ｆ部３８２を有さない場合、アプリケーション３１とプリンタドライバ（ＵＩドライバ３８と描画ドライバ３９）は、必ずWindows系ＯＳを介してデータを受け渡す。

本実施形態では、プリンタドライバ３０が拡張Ｉ／Ｆ部３８２を有することで、アプリケーション３１とプリンタドライバ３０が直接、データを受け渡すことができる。このため、アプリケーションが直接、プリンタドライバに印刷設定を設定することが可能となる。

図１５は、Windows系ＯＳの印刷アーキテクチャにおける、描画ドライバ３９とＵＩドライバ３８について説明する図の一例である。Windows系ＯＳのＧＤＩ３４はＤＤＩコールによりプリンタドライバ３０のＵＩドライバ３８と描画ドライバ３９を呼び出す。ＵＩドライバ３８と描画ドライバ３９は、直接相互にやりとりをすることができない。しかし、Windows系ＯＳからのプリンタドライバの呼び出しＩ／ＦであるＤＤＩの引数にDEVMODEがあることにより、双方がDEVMODEを参照することができる。
・Windows系ＯＳから呼び出されたＵＩドライバ３８は、ユーザの印刷設定を受け付けDEVMODEに保存する
・DEVMODEは印刷準備開始時にWindows系ＯＳから描画ドライバ３９に渡される
すなわち、ＵＩドライバ３８は、「印刷設定」を決定し、描画ドライバ３９は「印刷設定」を印刷準備開始時に受け取り、印刷設定に基づき印刷コマンドや描画データを生成する。これがWindows系ＯＳの印刷アーキテクチャの基本的な印刷シーケンスとなる。

よって、Windows系ＯＳの印刷アーキテクチャに従っただけのプリンタドライバでは、DEVMODEに格納しない印刷設定を、描画ドライバ３９が参照することができない。本実施形態のプリンタドライバ３０は、DEVMODEの印刷設定を参照することも、LanguageMonitorに設定された印刷設定を参照することもできる。

図１６は、LanguageMonitor３２の動作を説明する図の一例である。LanguageMonitor３２はプリントプロセッサ４１から送信された印刷データを受け取り、通信部４０（ポートモニタ４２及びポートドライバ４３）に送信する。プリントプロセッサ４１は、スプーラの機能である。ポートモニタ４２は、通信プロトコルに基づく処理を行い、ポートドライバ４３に印刷データを送信する。ポートドライバ４３は、プリンタ２００とクライアントＰＣ１００との接続インタフェース（USB,NIC等）を制御して、印刷データをプリンタ２００に送信する。

Windows系ＯＳでは、プリンタドライバ３０は、Windows系ＯＳが提供するLanguageMonitor３２を使用しても、メーカ（プリンタメーカ、FAXメーカ等）が提供するLanguageMonitor３２を使用してもよいとされている。本実施形態においても、LanguageMonitor３２は汎用品とメーカ製のどちらも使用することができる。

〔適用例〕
図１７は、拡張Ｉ／Ｆ部３８２への印刷設定の設定例を説明する図の一例である。アプリケーション３１は、拡張Ｉ／Ｆ部３８２を呼び出してＵＩドライバ３８に印刷設定（正確には送信設定であるが、区別せずに印刷設定という）を設定するために、拡張Ｉ／Ｆ呼出部３１１を有している。メーカは拡張Ｉ／Ｆ部３８２の仕様（ＡＰＩ）を公開しているので、メーカ以外のサードパーティが拡張Ｉ／Ｆ呼出部３１１を作成することができる。また、メーカが拡張Ｉ／Ｆ呼出部３１１又は拡張Ｉ／Ｆ呼出部３１１を有するアプリケーション３１を作成して、ユーザに提供することもできる。

アプリケーション３１は、拡張Ｉ／Ｆ呼出部３１１によりWindows系ＯＳを介さずにプリンタドライバ３０の拡張Ｉ／Ｆ部３８２を呼び出し、印刷設定を設定する。背景にて説明したように、DEVMODEに設定されないデータとしては秘匿性の高い情報が想定される。図では、セキュリティの観点からDEVMODEに格納すべきではないデータとして、ユーザ名（個人情報）とパスワードを図示している。

ＵＩドライバ３８は、拡張Ｉ／Ｆ部３８２を介して受け取った、印刷設定をLanguageMonitor３２に保存する。この時、後述するSendRecvBidiDataFromPort()というWindows系ＯＳのＡＰＩを使用する。

印刷実行は、アプリケーションからWindows系ＯＳを介して、描画ドライバ３９に通知される。すでに印刷設定がLanguageMonitor３２に登録されているので、ＵＩドライバ３８が設定画面を表示する必要はない。

印刷実行により、DEVMODEに格納された印刷設定は、DEVMODEのまま描画ドライバ３９に渡される。さらに、描画ドライバ３９は、拡張Ｉ／Ｆ部３８２によって設定された印刷設定をLanguageMonitor３２から取得する。そして、プリンタが解釈可能な印刷データを生成する。

ここでは、セキュリティに関する印刷設定以外はDEVMODEに格納し、Windows系ＯＳを介してDEVMODEとして描画ドライバ３９に渡されるとしたが、すべての印刷設定を拡張Ｉ／Ｆ部３８２経由で、LanguageMonitor３２に記憶してもよい。図１７はDEVMODEが図示されていないように、DEVMODEを全く利用していない例である。

図１８は、拡張Ｉ／Ｆ部３８２への印刷設定の設定例を説明する図の別の一例である。図１８では、文書データを作成するアプリケーションとは別に設定アプリケーション３１Ａが図示されている。設定アプリケーション３１Ａは、図１７のアプリケーションと同様に、拡張Ｉ／Ｆ部３８２を呼び出してＵＩドライバ３８に印刷設定を設定するために、拡張Ｉ／Ｆ呼出部３１１を有している。

設定アプリケーション３１Ａは、プリンタドライバ（PC-FAXドライバ）に印刷設定（送信設定）として、ＦＡＸ送信の宛先と送信者情報を設定する。ＵＩドライバ３８はこれらの印刷設定をLanguageMonitor３２に登録する。すなわち、設定アプリケーション３１Ａは、プリンタドライバに印刷設定を行う専用のアプリであり、アプリケーションＡ、Ｂが文書データを作成するアプリケーション３１である。設定アプリケーション３１Ａは、アプリケーションＡ、Ｂが文書データを作成する前に、印刷設定しておくことができる。

アプリケーションＡ，Ｂが印刷実行すると、描画ドライバ３９は、LanguageMonitor３２から印刷設定を取得し、プリンタが解釈可能なデータに変換しプリンタに送信する。

図１８のように、設定アプリケーション３１ＡがアプリケーションＡ，Ｂと別体なのは印刷設定するためだからでなく、プリンタドライバに印刷設定する場合も、設定アプリケーション３１ＡがアプリケーションＡ，Ｂと別体になる場合がある。なお、プリンタドライバに印刷設定する場合に、設定アプリケーション３１ＡとアプリケーションＡ，Ｂが一体となる場合（図１７と同様）となる場合もある。

設定アプリケーション３１ＡがアプリケーションＡ，Ｂと別体になる例としては、設定アプリケーション３１Ａが帳票印刷アプリケーションの場合が挙げられる。

〔 SendRecvBidiDataFromPort() 〕
図１９（ａ）は、SendRecvBidiDataFromPort()の書式を説明する図の一例である。SendRecvBidiDataFromPort()関数は、LanguageMonitor３２に実装されるＡＰＩである。プリンタドライバ３０と同じようにLanguageMonitor３２にもWindows系ＯＳによって決められたＩ／Ｆが存在する。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３２への設定及び問い合わせにSendRecvBidiDataFromPort()関数が使用される。プリンタドライバ３０がSendRecvBidiDataFromPort()にてLanguageMonitor３２を呼び出すことで、LanguageMonitor３２を保存場所として使うことが可能となる。すなわちLanguageMonitor３２とSendRecvBidiDataFromPort()関数によりデータ保持部３２１が実現される。

上記のように、LanguageMonitor３２はメーカが開発しなくとも、標準のLanguageMonitor３２がWindows系ＯＳと共に利用可能である。メーカが開発しない場合はそのLanguageMonitor３２が動作する。メーカは決められたＩ／Ｆに合わせ、LanguageMonitor３２を開発すれば、独自の機能を追加することができる。本実施形態では、SendRecvBidiDataFromPort()というＩ／Ｆを利用することによりプリンタドライバ３０等はLanguageMonitor３２とのデータのやりとりが可能となる。

より具体的には、COM InterfaceのインスタンスであるIBidiRequestのSetSchema()にJobIDを設定する。IBidiRequestのSetInputData()に印刷設定を設定する。ＵＩドライバ３８がIBidiRequestオブジェクトをセットしてSendRecv()をコールすると、スプーラがSendRecvBidiDataFromPort()を呼び出し、例えば第３引数や第４引数に印刷設定を設定することで、LanguageMonitor３２に印刷設定を設定する。

描画ドライバ３９が印刷設定を読み出す際は、IBidiRequestオブジェクトをセットしてSendRecv()をコールすると、IBidiRequestに印刷設定が保存される。描画ドライバ３９がIBidiRequestのGetOutputData()をコールすると、印刷設定を受け取ることができる。

〔拡張Ｉ／Ｆ部３８２を介する印刷（ＦＡＸ送信）設定の動作手順〕
図２０は、アプリケーションが拡張Ｉ／Ｆ部３８２を介してＵＩドライバ３８に印刷（ＦＡＸ送信）設定する際のシーケンス図の一例である。設定時の手順なので設定アプリケーション３１Ａがアプリケーション３１と別体でも、そうでなくてもよい。

S1：アプリケーション３１は、プリンタドライバの拡張Ｉ／Ｆ部３８２に印刷設定を設定する。アプリケーション３１は、ＵＩドライバ３８と同様に印刷設定の設定画面を表示することができ、ユーザから印刷設定を受け付けることができる。

S2：アプリケーション３１は、指定した印刷設定の確定指示をプリンタドライバの拡張Ｉ／Ｆ部３８２に通知する。
Ｓ2.1：プリンタドライバ３０の拡張Ｉ／Ｆ部３８２は、LanguageMonitor３２に、アプリケーション３１から指定された印刷設定を保持させる。具体的には、SendRecvBidiDataFromPort()という関数の引数に印刷設定を格納する。なお、シーケンス図では拡張Ｉ／Ｆ部３８２がLanguageMonitor３２にアクセスしているが、これは簡略化のためでありＵＩドライバ３８がLanguageMonitor３２にアクセスすると表現することもできる。

S3：以降、アプリケーション３１は、従来と同様の印刷処理を行う。アプリケーション３１はまず、ＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーション３１はCreateDC()関数で印刷設定を引数にしてＧＤＩ３４をコールする。なお、アプリケーション３１は、例えば送信処理が終了すると、ＧＤＩ３４に印刷準備開始を指示する。
S3.1：ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に印刷設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定（DEVMODE）が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）印刷設定を参照することができる。

S4：ＧＤＩ３４が印刷準備完了をアプリケーション３１に通知すると、アプリケーション３１はＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーション３１はStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。
S4.1：ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。
S4.1.1：プリンタドライバの描画ドライバ３９は、DrvStartDoc()で呼ばれると、LanguageMonitor３２に、アプリケーション３１が設定した印刷設定があるか否かを問い合わせる。具体的には、SendRecvBidiDataFromPort()の引数に問い合わせを意味する値を設定し、LanguageMonitor３２に送出する。LanguageMonitor３２は、アプリケーション３１が設定した印刷設定がある場合、SendRecvBidiDataFromPort()にそれを設定して描画ドライバ３９に送出する。

プリンタドライバの描画ドライバ３９は、DEVMODEで受け取った印刷設定があればその印刷設定と、LanguageMonitor３２から取得した印刷設定から印刷データを生成しプリンタにデータを送信する
S5：ＧＤＩ３４が印刷開始完了をアプリケーション３１に通知すると、アプリケーション３１はページ単位の処理を繰り返す。まず、アプリケーション３１はＧＤＩ３４に新しいページの印刷データを受け入れるよう指示する。具体的には、アプリケーション３１はStartPage()をＧＤＩ３４に送出する。
S5.1：ＧＤＩ３４はDrvStartPage()を描画ドライバ３９に送出する。

この後、ＧＤＩ３４は、アプリケーション３１から取得した描画関数（文書データ）を描画ドライバ３９に送出する。描画ドライバ３９は印刷設定に従って文書データを印刷データに変換する。描画ドライバ３９は印刷データをプリンタに送信する。

S6：ＧＤＩ３４が１ページ分の描画処理の完了をアプリケーション３１に通知すると、アプリケーション３１は１ページ分の書き込みが終了したことをＧＤＩ３４に通知する。具体的には、アプリケーション３１はEndPage()をＧＤＩ３４に送出する。

S7：アプリケーション３１は、全てのページの描画処理が終了すると、印刷ジョブの終了をＧＤＩ３４に通知する。具体的には、アプリケーション３１はEndDoc()をＧＤＩ３４に送出する。

S8：アプリケーション３１はＧＤＩにDeleteDC（）を通知し、デバイスコンテキストを消去する。

この段階で、アプリケーション３１が再度、印刷開始を指示した場合、LanguageMonitor３２の印刷設定が変わっていないので、描画ドライバ３９は同じ印刷設定で印刷データを生成する。

S9：アプリケーション３１は、印刷終了後、プリンタドライバの拡張Ｉ／Ｆ部３８２に対して、印刷設定の解除を通知する。

S10：プリンタドライバの拡張Ｉ／Ｆ部３８２は、SendRecvBidiDataFromPort()の引数に解除を意味する値を設定し、拡張Ｉ／Ｆ部３８２（ＵＩドライバ３８）はLanguageMonitor３２に印刷設定を破棄させる。

図２０のステップＳ2.1では、1回の通信で、印刷設定を設定しているが、複数回の通信で設定してもよい。ステップＳ4.1.1で読み出す時も同様である。また、S1でS2.1の処理を行ってもよい。

図示するように、プリンタドライバ３０の描画ドライバ３９は、DrvStartDoc()で呼び出された時に、LanguageMonitor３２から拡張Ｉ／Ｆ部３８２の設定情報を取得する。

背景で説明したとおり、ＲＡＷスプールとＥＭＦスプールでは、動作シーケンスとWindows系ＯＳのプロセスが異なるが、LanguageMonitor３２へのアクセスはプリンタドライバが動作するプロセスが異なっていても共通である。

よって、描画ドライバ３９は、DrvStartDoc()のタイミングで、LanguageMonitor３２から設定を取得するように設計しておけばよい。すなわち、スプール形式を意識した処理をプリンタドライバに設計していなくてよく、同じＤＤＩのタイミングで同じ処理をすることだけで、スプール形式の差異に影響しないでLanguageMonitor３２を利用できる。

なお、図では、描画ドライバ３９がLanguageMonitor３２から印刷設定を取得するのはDrvStartDoc()で呼び出された時としているが、プリンタに送信する印刷データを生成する前ならば、どのタイミングでも構わない。

〔動作設定が設定された場合の印刷設定後の送信手順〕
ユーザは、設定アプリケーション３１Ａを操作して印刷設定する際、動作設定を行うことができる。動作設定は印刷設定の一項目であるが、本実施形態ではプリンタの動作を指定する設定である。

図２１は、拡張Ｉ／Ｆ部３８２への印刷設定の設定例を説明する図の一例である。図２１では、図１８と比べ設定アプリケーション３１Ａが印刷設定と動作設定をＵＩドライバ３８に設定している点で異なっている。その他、ＵＩドライバ３８が拡張Ｉ／Ｆ部３８２を有する点などは図１７と同様である。

設定アプリケーション３１Ａは以下の動作設定を行っているものとする。
動作設定：一括送信設定
複数の文書をプリンタがＦＡＸ送信する際、アプリケーションの印刷実行指示ごとに通信を行うと、その都度、接続料金が発生してしまう。宛先が同じなら、接続・切断を繰り返すのでなく、１回の接続で全ての文書を送信した方が、接続料金を節約できる。一括送信設定は、そのための動作設定であり、複数のアプリケーションからの文書（Job）をまとめて送信するという動作を描画ドライバ３９に指示する設定である。

図２１では、設定アプリケーション３１Ａが、ＦＡＸ送信の印刷設定を受け付けたりＵＩドライバ３８に印刷設定を設定する。そして、設定アプリケーション３１Ａは、プリンタドライバ３０の拡張Ｉ／Ｆ部３８２を介して、ＦＡＸ送信の印刷設定として宛先情報、送信者名などを設定し、さらに、動作設定として一括送信設定を行う。

ＵＩドライバ３８に一括送信設定が設定された後は、アプリケーションＡ，Ｂが印刷を実行するだけで、描画ドライバ３９が、LanguageMonitor３２から印刷設定と動作設定を読み出し、プリンタが解釈可能な印刷データを生成する。そして、描画ドライバ３９は、動作設定の一括送信設定に基づきプリンタに印刷データをまとめて送信する。これにより、同一の宛先には、１回の接続でＦＡＸ送信することができる。

アプリケーションＡ又はＢが複数の文書を送信する場合も、アプリケーションＡとＢがそれぞれ文書を送信する場合も、一括で送信することができる。

なお、図２１においても、設定アプリケーション３１Ａがアプリケーション１、２と一体でもよい。また、動作設定としては、例えば、同じ文書を複数の宛先に送信する同報送信も可能である。

図２２〜２４は一括送信の送信手順を説明する図の一例である。ここでは設定アプリケーション３１Ａとアプリケーション１，２を区別していない。

S1：アプリケーション３１は、プリンタドライバの拡張Ｉ／Ｆ部３８２に動作設定を設定する。アプリケーション３１は、ＵＩドライバ３８と同様に動作設定の設定画面を表示することができ、ユーザから動作設定を受け付けることができる。

S2：次に、アプリケーション３１は、プリンタドライバの拡張Ｉ／Ｆ部３８２に印刷設定を設定する。

S3：アプリケーション３１は、指定した印刷設定と動作設定の確定指示をプリンタドライバの拡張Ｉ／Ｆ部３８２に通知する。

Ｓ3.1：プリンタドライバの拡張Ｉ／Ｆ部３８２は、LanguageMonitor３２に、アプリケーション３１から指定された印刷設定と動作設定を保持させる。具体的には、SendRecvBidiDataFromPort()という関数の引数に印刷設定と動作設定を格納する。動作設定は解除されるまで維持されるので、動作設定はＬｏｃｋされた状態となる。

S4：以降、アプリケーション３１は、従来と同様の印刷処理を行う。アプリケーション３１はまず、ＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーション３１はCreateDC()関数で印刷設定を引数にしてＧＤＩ３４をコールする。
S4.1：ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に印刷設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定（DEVMODE）が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。この後、描画ドライバ３９は、ジョブが終了するまで（デバイスコンテキストが消去されるまで）印刷設定を参照することができる。

S5：ＧＤＩ３４が印刷準備完了をアプリケーション３１に通知すると、アプリケーション３１はＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーション３１はStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。
S5.1：ＧＤＩ３４は描画ドライバ３９に印刷開始を指示する。具体的にはDrvStartDoc()関数を描画ドライバ３９に送出する。
S5.1.1：プリンタドライバの描画ドライバ３９は、DrvStartDoc()で呼ばれると、LanguageMonitor３２に、アプリケーション３１が設定した印刷設定と動作設定があるか否かを問い合わせる。具体的には、SendRecvBidiDataFromPort()の引数に問い合わせを意味する値を設定し、LanguageMonitor３２に送出する。LanguageMonitor３２は、アプリケーション３１が設定した印刷設定と動作設定がある場合、SendRecvBidiDataFromPort()にそれを設定して描画ドライバ３９に送出する。

プリンタドライバの描画ドライバ３９は、DEVMODEで受け取った印刷設定があればその印刷設定と、LanguageMonitor３２から取得した印刷設定から印刷データを生成する。

S6：ＧＤＩ３４が印刷開始完了をアプリケーション３１に通知すると、アプリケーション３１はページ単位の処理を繰り返すが、図では１ページのみを印刷するとしている。まず、アプリケーション３１はＧＤＩ３４に新しいページの印刷データを受け入れるよう指示する。具体的には、アプリケーション３１はStartPage()をＧＤＩ３４に送出する。
S6.1：ＧＤＩ３４はDrvStartPage()を描画ドライバ３９に送出する。

S7：ＧＤＩ３４は、アプリケーション３１から取得した描画関数（文書データ）を描画ドライバ３９に送出する。描画ドライバ３９は印刷設定に従って文書データを印刷データに変換する。一括送信設定の設定がなければ、描画ドライバ３９はLanguageMonitor３２から取得した印刷設定から印刷データを生成しプリンタに印刷データを送信するが、描画ドライバ３９は一括送信設定の設定を検出して、プリンタに印刷データを送信せずに保持しておく。

S8：ＧＤＩ３４が１ページ分の描画処理の完了をアプリケーション３１に通知すると、アプリケーション３１は１ページ分の書き込みが終了したことをＧＤＩ３４に通知する。具体的には、アプリケーション３１はEndPage()をＧＤＩ３４に送出する。
S8.1：ＧＤＩ３４は、DrvSendPage()を描画ドライバ３９に送信する。

S9：アプリケーション３１は、全てのページの描画処理が終了すると、印刷ジョブの終了をＧＤＩ３４に通知する。具体的には、アプリケーション３１はEndDoc()をＧＤＩ３４に送出する。
S9.1：ＧＤＩ３４は、DrvEndDoc()を描画ドライバ３９に送信する。

S10：アプリケーション３１はＧＤＩにDeleteDC（）を通知し、デバイスコンテキストを消去する。
S10.1：ＧＤＩ３４は、DrvDisiblePDEV()を描画ドライバ３９に送信する。描画ドライバ３９はDEVMODEを消去する。

この段階で１つのJobが終了した（１つの文書の送信処理が終了した）。一括送信では、プリンタに印刷データを送信することなく、アプリケーション３１が次のJobを実行する。

S11〜S17の処理は、S4〜S10と同様となる。このように各アプリケーション３１はS4〜S10を何回でも繰り返すことができる。本実施形態では２回のJob（２つの文書データ）を一括で送信するものとする。

S18：アプリケーション３１は、プリンタドライバの拡張Ｉ／Ｆ部３８２に対して、一括送信の解除を指示する。例えば、アプリケーション３１には、送信対象の複数の文書データがユーザにより登録されており、全ての送信処理が終了すると、アプリケーション３１は一括送信の解除を指示する。このように、文書作成のアプリケーション３１と印刷設定・動作設定を行う設定アプリケーション３１Ａが一体である方が好ましい場合がある。

文書作成のアプリケーション３１と印刷設定・動作設定を行う設定アプリケーション３１Ａが異なっている場合、ユーザの操作によりアプリケーション３１が一括送信の解除を指示してもよいし、一括送信の設定から所定時間が経過した時、設定した時刻が到来した時、などのように自動的に一括送信の解除を指示してもよい。

S18.1：以降、拡張Ｉ／Ｆ部３８２は、従来と同様の印刷処理を行う。アプリケーション３１が拡張Ｉ／Ｆ部３８２の代わりに従来と同様の印刷処理を行ってもよい。

まず、拡張Ｉ／Ｆ部３８２はＧＤＩ３４に印刷準備開始を指示する。具体的には、アプリケーション３１はCreateDC()関数で印刷設定を引数にしてＧＤＩ３４をコールする。

S18.1.1：ＧＤＩ３４はＡＰＩに対応するＤＤＩをコールすることで、描画ドライバ３９に印刷設定を送出する。CreateDC()の引数でアプリーションがＧＤＩ３４に渡した印刷設定（DEVMODE）が、DrvEnablePDEV()の引数に格納され描画ドライバ３９に通知される。しかし、文書データが送信されないので、描画ドライバ３９がDEVMODEを参照して印刷データを作成することはない。

S18.2：ＧＤＩ３４が印刷準備完了を拡張Ｉ／Ｆ部３８２に通知すると、拡張Ｉ／Ｆ部３８２はＧＤＩ３４に印刷開始を指示する。具体的には、アプリケーション３１はStartDoc()関数でDocINFOなどを引数にしてＧＤＩ３４をコールする。

S18.3：拡張Ｉ／Ｆ部３８２は、ＧＤＩ３４にExtEscape()を送信する。ExtEscape()関数は、ＧＤＩ経由ではアクセスできないモジュール（ここでは描画ドライバ３９）にアクセスするためのＡＰＩである。アプリケーション等がＧＤＩ３４を関与させずにドライバにデータを送信する場合、ドライバからＧＤＩ３４を関与させずにデータを取得する場合に利用されることがある。ExtEscape()に、蓄積している印刷データのプリンタへの送信要求が含まれる。

S18.3.1：ＧＤＩ３４は、ExtEscape()をＤＤＩであるDrvStartPage()に変換して描画ドライバ３９に送信する。

S18.3.2：また、ＧＤＩ３４は、DrvEscape()::PASSTHROUGH()を描画ドライバ３９に送信する。描画ドライバはこの命令により、蓄積している印刷データをプリンタに送信する。

S18.4：拡張Ｉ／Ｆ部３８２は、ＧＤＩ３４から印刷データの送信の通知を受けると、印刷ジョブの終了をＧＤＩ３４に通知する。具体的には、アプリケーション３１はEndDoc()をＧＤＩ３４に送出する。

S18.4.1：ＧＤＩ３４は、DrvEndDoc()を描画ドライバ３９に送信する。

S18.5：拡張Ｉ／Ｆ部３８２は、ＧＤＩ３４にDeleteDC（）を通知し、デバイスコンテキストを消去する。

S18.5.1：ＧＤＩ３４は、DrvDisiblePDEV()を描画ドライバ３９に送信する。描画ドライバ３９はDEVMODEを消去する。

S19：アプリケーション３１は、拡張Ｉ／Ｆ部３８２が処理の終了を通知されると、プリンタドライバの拡張Ｉ／Ｆ部３８２に対して、印刷設定の解除を通知する。

S19.1：プリンタドライバの拡張Ｉ／Ｆ部３８２は、SendRecvBidiDataFromPort()の引数に解除を意味する値を設定し、LanguageMonitor３２に設定を破棄させる。これにより、拡張Ｉ／Ｆ部３８２は、LanguageMonitor３２の印刷設定と動作設定を消去する。動作設定もＬｏｃｋが解除される。

このように、DEVMODEに設定項目がない、プリンタドライバの動作の指定をLanguageMonitor３２に登録することも可能になる。

ステップS18では、一括送信の解除通知として、プリンタドライバの拡張Ｉ／Ｆ部３８２からＧＤＩ３４を介してプリンタドライバの描画部に対して命令を送信している（通常の印刷ジョブ）。しかし、拡張Ｉ／Ｆ部３８２から、直接、描画ドライバ３９に一括送信の解除通知を送信することも可能である。

〔複数の論理プリンタの識別〕
一台のクライアントＰＣ１００に複数の論理プリンタが登録されることがある。論理プリンタとは、Windows系ＯＳのプリンタフォルダに、プリンタのアイコンとして表示されている論理的なプリンタである。Windows系ＯＳは、１つのプリンタドライバに対して、複数の論理プリンタを作成することができる。論理プリンタは、アプリケーション３１からみた仮想的な出力先ともいえ、プリンタドライバが描画した印刷データは、ユーザが指定した論理プリンタに出力され、Windows系ＯＳが論理プリンタから物理プリンタに提供する。

論理プリンタには、１つずつ名前を付与することができ、ユーザなどが任意に付けたり、プリンタドライバのパッケージ名などから自動的に付与される。各論理プリンタには、機能、共有の有無、スプール形式、オプション構成などが設定可能になっている。すなわち、１つの物理的なプリンタの初期設定を変えることができる。

したがって、複数の論理プリンタが登録されている場合、論理プリンタ毎に、印刷設定や動作設定を設定することができればユーザの利便性が向上する。
・一度、拡張Ｉ／Ｆ部３８２を介した印刷設定で、複数のアプリケーション３１で同じ設定を使う構成
・一度、拡張Ｉ／Ｆ部３８２を介した動作設定で、複数のアプリケーション３１が同じ動作となる構成
これらの印刷設定や動作設定を論理プリンタごとに保持できればよいことになる。そこで、拡張Ｉ／Ｆ部３８２は、論理プリンタ名（以下、論理プリンタＩＤという）をキーに、印刷設定や動作設定をLanguageMonitor３２に登録する。
図２５は、複数の論理プリンタに対する印刷設定を説明する図の一例である。１台のクライアントＰＣ１００に複数の論理アイコンが登録されている場合、LanguageMonitor３２に、論理プリンタＩＤをキーとして、印刷設定が登録される。

図２５のアプリケーション３１は、設定アプリケーション３１Ａとアプリケーション３１とが一体の例を示す。以下のように、アプリケーション３１がプリンタドライバの拡張Ｉ／Ｆ部３８２を使用したものとする。
１．アプリケーション３１が論理プリンタＩＤ＝Ａに対して印刷設定ＡＢを設定
２．アプリケーション３１が論理プリンタＩＤ＝Ｂに対して印刷設定ＭＮを設定
論理プリンタＩＤは、ユーザが出力先として指定している論理プリンタのＩＤなので、アプリケーション３１、ＵＩドライバ３８、及び、描画ドライバ３９ともに、参照すべき論理プリンタＩＤを検知している。よって、ＵＩドライバ３８は、出力先の論理プリンタの論理プリンタＩＤをキーにLanguageMonitor３２に印刷設定を設定でき、描画ドライバ３９は論理プリンタＩＤをキーにLanguageMonitor３２に問い合わせることにより印刷設定を取得できる。

このように、論理プリンタごとに印刷設定や動作設定を指定し、印刷・FAX送信することができる。なお、一括送信の場合も論理プリンタごとに印刷設定・動作設定を行うことができる。

〔Point ＆ Print インストールにおけるLanguageMonitor〕
Point ＆ PrintインストールにおけるLanguageMonitor３２を利用した印刷設定及び動作設定の管理方法について説明する。

図２６は、Point＆Print環境を備えた印刷システム４００の概略構成図の一例を示す。４台のクライアントＰＣ１００がネットワークを介してサーバＰＣと接続されている。サーバＰＣ１１０にはプリンタ２００が接続されているが、プリンタ２００はネットワークに接続されていてもよい。

サーバＰＣ１１０にはプリンタドライバ３０がインストールされており、サーバＰＣ１１０が各クライアントＰＣ１００にプリンタドライバ３０をコピーして配布する。よって、ユーザの手を煩わせることなく、サーバＰＣ１１０とクライアントＰＣ１００が協働してプリンタドライバ３０をインストールすることができる。なお、以降は、クライアントＰＣ１がサーバＰＣ１１０に接続し、Point&Printによりプリンタドライバをインストールしたものとする。

Point＆Print環境のサーバサイドレンダリングでは、クライアントＰＣ１がユーザの印刷設定を受け付け、サーバＰＣ１１０が描画処理を行うため、印刷設定などを共有することが困難である。

しかし、これまで説明したLanguageMonitor３２は、Windows系ＯＳ内の機能なので、Point ＆ PrintインストールされたクライアントＰＣ１のWindows系ＯＳは、サーバＰＣ１１０に印刷設定を送信することができる。よって、サーバＰＣ１１０はクライアントＰＣ１から印刷アーキテクチャ内の処理で印刷設定と動作設定を取得できる。

図２７は、Point & Print環境におけるLanguageMonitor３２の作用を説明する図の一例である。LanguageMonitor３２はWindows系ＯＳの印刷アーキテクチャの中に組み込まれる一モジュールである。このため、Point & PrintによりクライアントＰＣ側がＵＩドライバ３８の処理を、サーバＰＣ側が描画ドライバ３９の処理を受け持ったとしても、LanguageMonitor３２はサーバＰＣ側で１つだけ機能する。クライアントＰＣ側にもLanguageMonitorはあるが機能しない。

クライアントＰＣ１のプリンタドライバ３０とサーバＰＣ１１０のプリンタドライバ３０は1つのLanguageMonitor３２にアクセスする。

クライアントＰＣ１のWindows系ＯＳとサーバＰＣのWindows系ＯＳは、クライアントＰＣ１とサーバＰＣ１１０の通信を確立している（例えば、ＲＰＣ（Remote Procedure Call）を利用する）。そして、ＵＩドライバ３８がクライアントＰＣ１のLanguageMonitor３２にアクセスする場合、クライアントＰＣ１のLanguageMonitor３２は動作せず、スプーラ３５がサーバＰＣのLanguageMonitor３２に印刷設定を送信する。

このようにクライアントＰＣ１とサーバＰＣ１１０が同じWindows系ＯＳをインストールしているので、Windows系ＯＳの印刷アーキテクチャのLanguageMonitor３２を共通に利用できる。このため、メーカ独自で開発したモジュールなどで生じやすいアクセス権限や通信エラーなどが起こりにくい。また、同様の理由で、Windows系ＯＳとの親和性も高い。

なお、Point＆Printでもスプール形式にはＲＡＷスプールとＥＭＦスプールがあるが、ＲＡＷスプールの場合、サーバサイドレンダリングが存在しない。ＲＡＷスプールはアプリケーション３１のプロセスなので、レンダリング場所が制限されるためである。

その他の場合、ＲＡＷスプールのクライアントサイドレンダリング、ＥＭＦスプールのクライアントサイドレンダリング、及び、ＥＭＦスプールのサーバサイドレンダリング、のいずれの場合も、図２７のようにLanguageMonitor３２を利用することができる。

〔６４bitＯＳ上で３２bitのアプリケーションが動作する場合〕
図２８は、６４bitＯＳ上で３２bitのアプリケーションが動作する場合のLanguageMonitorの作用を説明する図の一例である。

ＦＡＸ送信の印刷設定を行う設定アプリケーション３１Ａが３２bitアプリ、Windows系ＯＳが６４bitＯＳであるとする。アプリケーション３１が印刷実行すると、ＷＯＷ６４の仕組みによりsplwow64.exeが動作するので、アプリケーション３１は３２bitアプリ又は６４bitアプリのどちらでもよい。プリンタドライバはWindows系ＯＳと同じく６４bitで作成されている必要があり、描画ドライバ３９は６４bitドライバである。

ＵＩドライバ３８も当然ながら６４bitドライバが用意されておりクライアントＰＣ１にインストールされている。しかしながら、３２bitアプリである設定アプリケーション３１Ａが拡張Ｉ／Ｆ部３８２にアクセスしてもsplwow64.exeは動作せず、設定アプリケーション３１Ａが拡張Ｉ／Ｆ部３８２にアクセスすることができない。

このような場合、Windows系ＯＳは代替インストールという仕組みを使用して、クライアントＰＣ１に３２bitのプリンタドライバ（代替される６４bitのプリンタドライバと互換性のあるものとして予め登録されている）をシステムに登録する。システムに登録するとは、例えば、６４bitのプリンタドライバの代わりに、３２bitのプリンタドライバを登録することをいう。

３２bitのＵＩドライバ３８は、拡張Ｉ／Ｆ部３８２を使用する設定アプリケーション３１Ａが３２bitであるため、３２bitの拡張Ｉ／Ｆ部３８２をロードする。これにより、ＵＩドライバ３８は３２bitアプリから印刷設定等を受け付けることができる。

拡張Ｉ／Ｆ部３８２は、SendRecvBidiDataFromPort():というＡＰＩを介してLanguageMonitor３２と通信するので、設定アプリケーション３１ＡとWindows系ＯＳの組み合わせ（３２／６４bitアプリ、３２／６４bitＯＳ）を考慮することなく、拡張Ｉ／Ｆ部３８２が６４bitのLanguageMonitor３２に印刷設定等を格納することができる。すなわち、ＡＰＩを介すので相手が３２bitか６４bitかは問題にならない。

また、印刷の実行時は、６４bitの描画ドライバ３９がSendRecvBidiDataFromPort():というＡＰＩを介して使用してLanguageMonitor３２と通信するので、アプリケーション３１とWindows系ＯＳの組み合わせ（３２／６４bitアプリ、３２／６４bitＯＳ）を考慮することなく、印刷設定等を読み出すことができる。

よって、本実施形態のプリンタドライバ３０は、６４bitＯＳ上で３２bitのアプリケーションが動作する場合でも、設定アプリケーション３１Ａが拡張Ｉ／Ｆ部３８２を介して印刷設定し、それを描画ドライバ３９が読み出すことができる。

以上説明したように、本実施形態のプリンタドライバは、アプリケーション３１が拡張Ｉ／Ｆを利用して印刷設定を決定する場合、
・ＲＡＷスプール・ＥＭＦスプールのどちらのスプール形式でも、プリンタドライバの拡張Ｉ／Ｆによって指示した印刷設定で印刷をする
・Point & Printインストールされたプリンタドライバで、スプール形式によらず、プリンタドライバの拡張Ｉ／Ｆによって指示した印刷設定で印刷をする
・６４bitＯＳ上で３２bitアプリが動作した場合でも、プリンタドライバの拡張Ｉ／Ｆによって指示した印刷設定で印刷をする
ことが可能となっている。また、プリンタドライバ３０が印刷設定をDEVMODE構造体に格納することもできるし、全てをLanguageMonitor３２に設定することもできる。

３１ アプリケーション
３２ LanguageMonitor
３４ ＧＤＩ
３５ スプーラ
３８ ＵＩドライバ
３９ 描画ドライバ
１００ クライアントＰＣ
２００ プリンタ
３２１ データ保持部
３２２ 通信部
３８１ 表示部
３８２ 拡張Ｉ／Ｆ部
４００ 印刷システム

特開２００５−１４８９２８号公報

Claims (17)

1. 情報処理装置の動作の基本となる所定のプログラムを介して印刷の第１の設定条件の設定値を受け付ける設定受付プログラムと、
   アプリケーションから前記所定のプログラムを介して文書データを取得し、前記設定受付プログラムにより受け付けられた第１の設定条件に基づいて印刷データに変換する画像処理プログラムと、を有し、
   前記設定受付プログラムは、情報処理装置に、
   前記所定のプログラムを介することなく、前記アプリケーションから第２の設定条件を受け付けるステップと、
   インタフェースにより受け付けられた第２の設定条件を、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力するステップと、を実行させ、
   前記画像処理プログラムは、情報処理装置に、
   前記アプリケーションからの文書データを印刷データに変換する際に、前記印刷データ処理プログラムから第２の設定条件を受け付けるステップと、
   前記設定受付プログラムにより受け付けた第１の設定条件と、前記印刷データ処理プログラムから受け付けた第２の設定条件の少なくとも一方に基づき、文書データを印刷データに変換するステップと、を実行させることを特徴とするプログラム。
2. 前記設定受付プログラムが前記アプリケーションから第２の設定条件を受け付けるステップでは、
   第２の設定条件に加え、画像形成装置又は画像送信装置の動作を設定する動作設定条件をアプリケーションから受け付け、第２の設定条件及び前記動作設定条件を印刷データ処理プログラムに記憶し、
   前記画像処理プログラムが前記印刷データ処理プログラムから第２の設定条件を受け付けるステップでは、
   前記印刷データ処理プログラムから第２の設定条件及び前記動作設定条件を読み出し、
   前記画像処理プログラムが文書データを印刷データに変換するステップでは、
   前記動作設定条件に所定の動作が設定されている場合、印刷データを保持しておき、
   前記画像処理プログラムが前記所定のプログラムから送信命令を取得した場合に、印刷データを画像形成装置又は画像送信装置側に送信させることを特徴とする請求項１記載のプログラム。
3. 前記動作設定条件にＦＡＸ送信の際に複数の文書データを一度の回線接続で送信するという動作が設定されている場合、
   前記画像処理プログラムが文書データを印刷データに変換するステップでは、複数の文書データの印刷データを保持しておき、
   前記画像処理プログラムが前記所定のプログラムから送信命令を取得した場合に、複数の印刷データを全て画像形成装置又は画像送信装置側に送信する、
   ことを特徴とする請求項２記載のプログラム。
4. 情報処理装置に、前記所定のプログラムを介することなく、第２の設定条件又は前記動作設定条件の破棄命令をアプリケーションから受け付ける破棄ステップを実行させ、
   前記設定受付プログラムは、情報処理装置に、第２の設定条件又は前記動作設定条件を前記印刷データ処理プログラムから破棄させるステップを実行させる、
   ことを特徴とする請求項２又は３記載のプログラム。
5. 前記設定受付プログラムが前記アプリケーションから第２の設定条件を受け付けるステップでは、
   前記所定のプログラムから第１の設定条件の設定を受け付けるデバイスドライバインタフェース以外の、独自の拡張インタフェースを介して、アプリケーションから第２の設定条件を受け付け、
   前記破棄ステップでは、
   前記所定のプログラムから第１の設定条件の設定を受け付けるデバイスドライバインタフェース以外の、独自の拡張インタフェースを介して、アプリケーションから前記破棄命令を受け付ける、ことを特徴とする請求項４記載のプログラム。
6. 前記設定受付プログラムが前記アプリケーションから第２の設定条件を受け付けるステップにおいて、第２の設定条件を受け取るアプリケーションと、
   前記画像処理プログラムがインタフェースにより受け付けられた第２の設定条件を、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力するステップにおいて、前記所定のプログラムに前記画像処理プログラムに対し印刷要求を出力させるアプリケーションとは、別体のアプリケーションである、
   ことを特徴とする請求項１記載のプログラム。
7. 前記設定受付プログラムが前記アプリケーションから第２の設定条件を受け付けるステップでは、
   第２の設定条件に識別情報を対応づけて、前記印刷データ処理プログラムに記憶し、
   前記印刷データ処理プログラムから第２の設定条件を受け付けるステップでは、
   前記印刷データ処理プログラムから前記識別情報に対応づけられた第２の設定条件を読み出す、ことを特徴とする請求項１記載のプログラム。
8. 当該プログラムには、画像形成装置又は画像送信装置に対応したプリンタドライバに対する設定を識別するための論理プリンタ情報が設定されており、
   前記識別情報は前記論理プリンタ情報である、
   ことを特徴とする請求項７記載のプログラム。
9. 情報処理装置の動作の基本となる所定のプログラムを介して印刷の第１の設定条件の設定値を受け付ける設定受付手段と、
   アプリケーションから前記所定のプログラムを介して文書データを取得し、前記設定受付手段により受け付けられた第１の設定条件に基づいて印刷データに変換する画像処理手段と、を有し、
   前記設定受付手段は、前記所定のプログラムを介することなく、第２の設定条件をアプリケーションから受け付けるインタフェース、を有し、
   前記インタフェースにより受け付けられた第２の設定条件を、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力し、
   前記画像処理手段は、前記アプリケーションからの文書データを印刷データに変換する際に、前記印刷データ処理プログラムから第２の設定条件を受け付け、前記設定受付手段により受け付けた第１の設定条件と、前記印刷データ処理プログラムから受け付けた第２の設定条件の少なくとも一方に基づき、文書データを印刷データに変換する、
   ことを特徴とする情報処理装置。
10. 前記インタフェースは、第２の設定条件に加え、画像形成装置又は画像送信装置の動作を設定する動作設定条件をアプリケーションから受け付け、第２の設定条件及び前記動作設定条件を前記印刷データ処理プログラムに出力し、
    前記画像処理手段は、前記印刷データ処理プログラムから第２の設定条件及び前記動作設定条件を読み出し、
    前記動作設定条件に所定の動作が設定されている場合、印刷データを保持しておき、
    前記所定のプログラムから送信命令を取得した場合に、印刷データを画像形成装置又は画像送信装置側に送信する、ことを特徴とする請求項９記載の情報処理装置。
11. 前記動作設定条件にＦＡＸ送信の際に複数の文書データを一度の回線接続で送信するという動作が設定されている場合、
    前記画像処理手段は、複数の文書データの印刷データを保持しておき、
    前記所定のプログラムから送信命令を取得した場合に、複数の印刷データを全て画像形成装置又は画像送信装置側に送信する、ことを特徴とする請求項１０記載の情報処理装置。
12. 前記設定受付手段は、前記所定のプログラムを介することなく、第２の設定条件又は前記動作設定条件の破棄命令をアプリケーションから受け付けた場合、
    前記設定受付手段は、第２の設定条件又は前記動作設定条件を前記印刷データ処理プログラムから破棄する、ことを特徴とする請求項１０又は１１記載の情報処理装置。
13. 前記インタフェースは、
    前記所定のプログラムから第１の設定条件の設定を受け付けるデバイスドライバインタフェース以外の、独自の拡張インタフェースを介して、アプリケーションから第２の設定条件を受け付け、
    前記所定のプログラムから第１の設定条件の設定を受け付けるデバイスドライバインタフェース以外の、独自の拡張インタフェースを介して、アプリケーションから前記破棄命令を受け付ける、ことを特徴とする請求項１２記載の情報処理装置。
14. 前記インタフェースが、第２の設定条件を受け取るアプリケーションと、
    前記画像処理手段が、前記所定のプログラムを経由して印刷要求を取得するアプリケーションとは、別体のアプリケーションである、
    ことを特徴とする請求項９記載の情報処理装置。
15. 前記インタフェースは、第２の設定条件に識別情報を対応づけて、前記印刷データ処理プログラムに記憶し、
    前記画像処理手段は、
    前記印刷データ処理プログラムから前記識別情報に対応づけられた第２の設定条件を読み出す、ことを特徴とする請求項９記載の情報処理装置。
16. 前記識別情報は、プリンタドライバに対する設定を識別するために生成されている重複しない論理プリンタ情報である、ことを特徴とする請求項１５記載の情報処理装置。
17. 請求項１〜８いずれか１項に記載のプログラムを記憶したコンピュータ読み取り可能な記憶媒体。

Images