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

プログラム、情報処理装置、記憶媒体 Download PDF

Info

Publication number
JP2013196372A
JP2013196372A JP2012062742A JP2012062742A JP2013196372A JP 2013196372 A JP2013196372 A JP 2013196372A JP 2012062742 A JP2012062742 A JP 2012062742A JP 2012062742 A JP2012062742 A JP 2012062742A JP 2013196372 A JP2013196372 A JP 2013196372A
Authority
JP
Japan
Prior art keywords
program
data
driver
predetermined
print
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2012062742A
Other languages
English (en)
Other versions
JP5919925B2 (ja
Inventor
Daisuke Tamashima
大輔 玉島
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2012062742A priority Critical patent/JP5919925B2/ja
Priority to US13/826,443 priority patent/US8922823B2/en
Priority to CN201310087523.XA priority patent/CN103324450B/zh
Publication of JP2013196372A publication Critical patent/JP2013196372A/ja
Application granted granted Critical
Publication of JP5919925B2 publication Critical patent/JP5919925B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/21—Intermediate information storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/00127—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture
    • H04N1/00204—Connection or combination of a still picture apparatus with another apparatus, e.g. for storage, processing or transmission of still picture signals or of information associated with a still picture with a digital computer or a digital computer system, e.g. an internet server
    • H04N1/00206—Transmitting or receiving computer data via an image communication device, e.g. a facsimile transceiver
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00—Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/0008—Connection or combination of a still picture apparatus with another apparatus
    • H04N2201/0065—Converting image data to a format usable by the connected apparatus or vice versa
    • H04N2201/0067—Converting to still picture data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N2201/00—Indexing scheme relating to scanning, transmission or reproduction of documents or the like, and to details thereof
    • H04N2201/0077—Types of the still picture apparatus
    • H04N2201/0094—Multifunctional device, i.e. a device capable of all of reading, reproducing, copying, facsimile transception, file transception

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Accessory Devices And Overall Control Thereof (AREA)
  • Facsimiles In General (AREA)

Abstract

【課題】ＯＳとの親和性を損なわず、スプール形式、インストール方式、及び、ＯＳの違いに影響されずに、送付状を送信できるプログラムを提供する。
【解決手段】情報処理装置１００に、所定のプログラムが生成した出力処理の識別情報を取得する(S2.3)と、設定条件に画像データの生成指示が設定されている場合、画像データを生成するステップ（S2.4）と、取得された識別情報と生成された画像データとを対応付けて、印刷データに対する処理が可能な印刷データ処理プログラムに出力するステップと(S2.3.2)と、所定のプログラムから識別情報を取得するステップ（S2.2）と、所定のプログラムを介して、印刷データ処理プログラムから、取得された識別情報に対応付けられた画像データを受け付けるステップ（S3.1.1）と、画像データと取得された文書データとを、設定条件に基づいて印刷データに変換するステップ(S4.1)を実行させる。
【選択図】図７

Description

本発明は、情報処理装置に、印刷の設定条件を表示し、設定条件の設定を受け付けるステップと、文書データを印刷データに変換するステップと実行させるプログラムに関する。
ＰＣ（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
３４ ＧＤＩ
３５ スプーラ
３８ ＵＩドライバ
３９ 描画ドライバ
１００ クライアントＰＣ
２００ プリンタ
３２１ データ保持部
３２２ 通信部
３８１ データ生成部
４００ 印刷システム
特開２０１０−０６６８７６号公報

Claims (17)

  1. 画像データの出力の設定条件を表示し、前記設定条件を受け付ける設定受付プログラムと、
    アプリケーションから文書データを取得し、前記設定受付プログラムにより受け付けられた設定条件に基づいて印刷データに変換する画像処理プログラムと、を有し、
    前記設定受付プログラムは、所定のプログラムに基づいて動作する情報処理装置に、
    前記所定のプログラムが生成した出力処理の識別情報を取得するステップと、
    前記設定条件に所定の画像データの生成指示が設定されている場合、前記所定の画像データを生成するステップと、
    前記取得された識別情報と前記生成された所定の画像データとを対応付けて、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力するステップと、
    を実行させ、
    前記画像処理プログラムは、情報処理装置に、
    前記アプリケーションから文書データを取得する際に、所定のプログラムから前記識別情報を取得するステップと、
    前記所定のプログラムを介して、前記印刷データ処理プログラムから、前記取得された識別情報に対応付けられた所定の画像データを受け付けるステップと、
    前記受け付けた所定の画像データと前記取得された文書データとを、前記設定条件に基づいて印刷データに変換するステップと
    を実行させる、ことを特徴とするプログラム。
  2. 前記設定受け付けプログラムは、情報処理装置に、
    前記設定条件を受け付けた後、前記画像データが生成される前に、前記設定条件を前記画像処理プログラムに送信するステップと、
    所定のプログラムに対し、前記画像処理プログラムから前記設定条件を送信させるよう要求するステップと、を実行させ、
    前記画像処理プログラムは、情報処理装置に、
    所定のプログラムに対し前記設定条件を送信するステップを実行させ、
    前記所定の画像データを生成するステップでは、前記設定受け付けプログラムが所定のプログラムから前記設定条件を取得する、
    ことを特徴とする請求項１記載のプログラム。
  3. 前記所定の画像データを生成するステップでは、印刷開始の指示の後、前記画像処理プログラムが文書データを前記印刷データに変換する前に前記描画データを生成する、
    ことを特徴とする請求項１又は２記載のプログラム。
  4. 前記識別情報は、所定のプログラムが予め定められた印刷処理手順の中で生成する、印刷処理又は送信処理に一意のジョブＩＤである、
    ことを特徴とする請求項１〜３いずれか１項記載のプログラム。
  5. 前記設定受け付けプログラムは、情報処理装置に、
    所定のプログラムの所定のＡＰＩ関数をコールするステップを実行させることで、前記印刷データ処理プログラムに前記識別情報をキーにして前記設定条件を記憶する、
    ことを特徴とする請求項１〜４いずれか１項記載のプログラム。
  6. 前記画像処理プログラムは、情報処理装置に、
    所定のプログラムの所定のＡＰＩ関数をコールするステップを実行させることで、前記識別情報をキーにして前記印刷データ処理プログラムから前記設定条件を読み出す、
    ことを特徴とする請求項１〜５いずれか１項記載のプログラム。
  7. 前記所定の画像データを生成するステップでは、ファクシミリの送信先情報及び送信元情報が含まれる前記設定条件から、送付状の画像データを生成する、
    ことを特徴とする請求項１〜６いずれか１項記載のプログラム。
  8. 前記画像処理プログラムは、情報処理装置に、
    前記画像データを、文書データから変換された前記印刷データの表紙に追加するステップ、又は、１ページ以上の前記印刷データの一部に配置することで前記印刷データに追加するステップを実行させる、
    ことを特徴とする請求項１〜６いずれか１項記載のプログラム。
  9. 画像データの出力の設定条件を表示し、前記設定条件を受け付ける設定受付手段と、
    アプリケーションから文書データを取得し、前記設定受付プログラムにより受け付けられた設定条件に基づいて印刷データに変換する画像処理手段と、を有し、所定のプログラムに基づいて動作する情報処理装置であって、
    前記設定受付手段は、前記設定条件に所定の画像データの生成指示が設定されている場合、前記所定の画像データを生成する画像データ生成手段を有し、
    前記所定のプログラムが生成した出力処理の識別情報と前記生成された所定の画像データとを対応付けて、前記印刷データに対する処理が可能な印刷データ処理プログラムに出力し、
    前記画像処理手段は、前記アプリケーションから文書データを取得する際に、所定のプログラムから前記識別情報を取得し、前記所定のプログラムを介して、前記印刷データ処理プログラムから、前記取得された識別情報に対応付けられた所定の画像データを受け付け、前記受け付けた所定の画像データと前記取得された文書データとを、前記設定条件に基づいて印刷データに変換する、
    ことを特徴とする情報処理装置。
  10. 前記設定受付手段は前記設定条件を受け付けた後、前記画像データが生成される前に、前記設定条件を前記画像処理手段に送信し、
    前記画像データ生成手段は、所定のプログラムに、前記画像処理手段から前記設定条件を送信させるよう要求し、
    前記画像処理手段は、所定のプログラムに対し、前記設定条件を送信し、
    前記画像データ生成手段は、所定のプログラムから前記設定条件を取得する、
    ことを特徴とする請求項９記載の情報処理装置。
  11. 前記画像データ生成手段は、印刷開始の指示の後、前記画像処理手段が文書データを前記印刷データに変換する前に、前記描画データを生成する、
    ことを特徴とする請求項９又は１０記載の情報処理装置。
  12. 前記識別情報は、所定のプログラムが予め定められた印刷処理手順の中で生成する、印刷処理に一意のジョブIDである、
    ことを特徴とする請求項９〜１１いずれか１項記載の情報処理装置。
  13. 前記設定受付手段は、所定のプログラムの所定のＡＰＩ関数をコールすることで、前記印刷データ処理プログラムに前記識別情報をキーにして前記設定条件を記憶する、
    ことを特徴とする請求項９〜１２いずれか１項記載の情報処理装置。
  14. 前記画像処理手段は、所定のプログラムの所定のＡＰＩ関数をコールすることで、前記識別情報をキーにして前記印刷データ処理プログラムから前記設定条件を読み出す、
    ことを特徴とする請求項９〜１３いずれか１項記載の情報処理装置。
  15. 前記画像データ生成手段は、ファクシミリの送信先情報及び送信元情報が含まれる前記設定条件から、送付状の画像データを生成する、
    ことを特徴とする請求項９〜１４いずれか１項記載の情報処理装置。
  16. 前記画像処理手段は、前記画像データを、文書データから変換された前記印刷データの表紙に追加する、又は、１ページ以上の前記印刷データの一部に配置することで前記印刷データに追加する、
    ことを特徴とする請求項９〜１４いずれか１項記載の情報処理装置。
  17. 請求項１〜９いずれか１項記載のプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
JP2012062742A 2012-03-19 2012-03-19 プログラム、情報処理装置、記憶媒体 Active JP5919925B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2012062742A JP5919925B2 (ja) 2012-03-19 2012-03-19 プログラム、情報処理装置、記憶媒体
US13/826,443 US8922823B2 (en) 2012-03-19 2013-03-14 Information processing apparatus and storage medium with the function of adding a cover letter to a print job
CN201310087523.XA CN103324450B (zh) 2012-03-19 2013-03-19 信息处理设备和信息处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012062742A JP5919925B2 (ja) 2012-03-19 2012-03-19 プログラム、情報処理装置、記憶媒体

Publications (2)

Publication Number Publication Date
JP2013196372A true JP2013196372A (ja) 2013-09-30
JP5919925B2 JP5919925B2 (ja) 2016-05-18

Family

ID=49157345

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012062742A Active JP5919925B2 (ja) 2012-03-19 2012-03-19 プログラム、情報処理装置、記憶媒体

Country Status (3)

Country Link
US (1) US8922823B2 (ja)
JP (1) JP5919925B2 (ja)
CN (1) CN103324450B (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6331910B2 (ja) 2013-09-17 2018-05-30 株式会社リコー 情報処理装置、情報処理システム、及びプログラム
US9870179B2 (en) 2016-03-14 2018-01-16 Ricoh Company, Ltd. Information processing apparatus, information processing method, and image processing system
US10194038B2 (en) * 2016-09-15 2019-01-29 Ricoh Company, Ltd. Information processing apparatus, information processing method, and information processing system
CN114327305B (zh) * 2021-12-23 2024-07-30 中国农业银行股份有限公司 一种异常打印信息检测方法、装置、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0976596A (ja) * 1995-09-13 1997-03-25 Nec Corp ｌｐｒ用フィルタにおける中間ファイルの使用方法
JPH11298717A (ja) * 1998-04-13 1999-10-29 Oki Data Corp 印刷システム
JP2010066876A (ja) * 2008-09-09 2010-03-25 Ricoh Co Ltd 印刷制御装置、プログラム、記録媒体及び印刷制御方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784177A (en) * 1995-05-30 1998-07-21 Canon Kabushiki Kaisha Printer/facsimile driver
JP4592490B2 (ja) * 2005-05-16 2010-12-01 株式会社リコー 撮像装置
KR20080009559A (ko) * 2006-07-24 2008-01-29 삼성전자주식회사 화상형성제어장치 및 그 장치의 제어방법
JP4881171B2 (ja) * 2007-01-23 2012-02-22 株式会社リコー ホスト出力処理システム、ホスト出力処理方法、ホスト出力処理プログラム及び記録媒体
JP4827756B2 (ja) * 2007-02-02 2011-11-30 キヤノン株式会社 データ通信システム、データ通信方法及びプログラム
JP5424807B2 (ja) * 2009-10-15 2014-02-26 キヤノン株式会社 画像処理装置、及び画像処理装置の制御方法
JP5691455B2 (ja) 2010-12-03 2015-04-01 株式会社リコー 印刷プログラム、情報処理装置および記録媒体
JP5891794B2 (ja) 2011-02-09 2016-03-23 株式会社リコー 情報処理装置及びプログラム
JP5803290B2 (ja) 2011-06-01 2015-11-04 株式会社リコー データ処理装置およびプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0976596A (ja) * 1995-09-13 1997-03-25 Nec Corp ｌｐｒ用フィルタにおける中間ファイルの使用方法
JPH11298717A (ja) * 1998-04-13 1999-10-29 Oki Data Corp 印刷システム
JP2010066876A (ja) * 2008-09-09 2010-03-25 Ricoh Co Ltd 印刷制御装置、プログラム、記録媒体及び印刷制御方法

Also Published As

Publication number Publication date
US20130242348A1 (en) 2013-09-19
CN103324450A (zh) 2013-09-25
CN103324450B (zh) 2016-03-09
JP5919925B2 (ja) 2016-05-18
US8922823B2 (en) 2014-12-30

Similar Documents

Publication Publication Date Title
JP5857611B2 (ja) 情報処理装置、システム、プログラム
JP5919930B2 (ja) プログラム、情報処理装置、記憶媒体
JP5677047B2 (ja) 印刷システム、情報処理装置、印刷方法、及び、プログラム
US9442678B2 (en) Information processing apparatus, information processing system and non-transitory computer-readable information recording medium
JP2020004158A (ja) 情報処理装置、情報処理装置の制御方法、及びプログラム
JP5047067B2 (ja) 情報処理装置、データ出力システム、データ生成プログラム及びその記録媒体
JP2023107788A (ja) 情報処理装置、制御方法及びプログラム
JP2015114820A (ja) 印刷サービス提供装置及び印刷システム
JP5170141B2 (ja) プリンタ及び端末装置
JP2012245695A (ja) 画像出力装置、プログラムおよびシステム
JP5919925B2 (ja) プログラム、情報処理装置、記憶媒体
JP6840986B2 (ja) 印刷管理装置及びプログラム
JP2014041599A (ja) プログラム、情報処理装置、システム
JP2005327053A (ja) ログ情報管理装置、ログ情報生成装置、ログ情報管理プログラム及び記録媒体
US9081530B2 (en) Control system for forming and outputting image, control apparatus for forming and outputting image, and recording medium storing a control program for forming and outputting image
JP5961937B2 (ja) 情報処理システム
JP2013196259A (ja) データ処理装置、データ処理システムおよびプログラム
JP4973821B1 (ja) 印刷制御装置およびプログラム
WO2024203449A1 (ja) 情報処理システム
JP5429351B2 (ja) プリンタ及び端末装置
JP2024100224A (ja) クラウドプリントシステムとその制御方法、情報処理装置ならびにプログラム
JP2007237473A (ja) 印刷装置
JP2006146490A (ja) 印刷制御装置及び印刷制御プログラム
JP2010218081A (ja) 印刷システム
US20160182744A1 (en) Printing system and printing instruction apparatus

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150218

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151216

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151222

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160216

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160315

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160328

R151 Written notification of patent or utility model registration

Ref document number: 5919925

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151