以下、本実施形態について説明するが、本実施形態は、以下に説明する実施形態に限定されるものではない。なお、以下の説明では、プログラム、および情報処理装置として、プリンタドライバ、および該プリンタドライバを動作させるホスト装置を一例として説明する。
図1は、本実施形態によるプリントシステム100の概略構成を示す図である。図1に示すようにプリントシステム100は、ネットワーク102を介して相互に接続される、ホスト装置110と、画像形成装置180とを含む。ホスト装置110は、パーソナル・コンピュータ、ワークステーションなどの汎用コンピュータなどとして構成される。画像形成装置180は、レーザプリンタや複合機などのプリント機能を備える画像処理装置として構成される。ネットワーク102は、例示的には、TCP/IPプロトコルスタックによる有線や無線のLAN(Local Area Network)などとして構成される。
ホスト装置110は、本実施形態によるプリンタドライバを動作させており、画像形成装置180に対し、ネットワーク102を介して、印刷データとともに印刷要求を送信するホスト・コンピュータである。画像形成装置180は、ネットワーク102を介したホスト装置110からの印刷要求に応答して、受信した印刷データに従い、画像形成処理を実行する周辺機器である。
なお、図1に示すプリントシステム100では、ホスト装置110および画像形成装置180は、ネットワーク102を介して直接接続されているが、これは一例であり、図1に示す実施形態に限定されるものではない。例えば、画像形成装置180に接続するプリントサーバをネットワーク102上に設け、ホスト装置110からプリントサーバを経由して画像形成装置180に印刷要求を行う実施形態としてもよい。また、LANに代えて例えばUSBなどのバスを介してホスト装置110および画像形成装置180を接続する実施形態としてもよい。
図2は、本実施形態におけるホスト装置110上で動作するソフトウェア・コンポーネントを示すブロック図である。図2には、ホスト装置110上のソフトウェア・コンポーネントとして、アプリケーション112と、プリンタドライバ114と、GDI(Graphics Device Interface)120と、プリント・スプーラ122と、プリントプロセッサ124と、ランゲージ・モニタ126と、ポートモニタ132と、ポートドライバ134とが示されている。なお、説明する実施形態は、Windows(登録商標)のプリント・アーキテクチャに基づくものである。
アプリケーション112は、ワードプロセッサやスプレッドシート、プレゼンテーション、ドロー、フォトレタッチ、ブラウザ、文書ビューアなどの印刷機能を備えた各種アプリケーションである。アプリケーション112は、ユーザ操作に応答して、プリンタドライバ114が提供する印刷設定ユーザ・インタフェースを呼び出し、また、印刷設定に基づく印刷命令をプリンタドライバ114に発行する。
プリンタドライバ114は、本実施形態によるプログラムが提供する画像処理ドライバであり、ホスト装置110にインストールされている。プリンタドライバ114は、アプリケーション112からの印刷命令に応答して、印刷データを生成し、画像形成装置180に印刷要求と共に印刷データを送信する。プリンタドライバ114は、より具体的には、印刷設定用GUI(Graphical User Interface)を提供するUI部116と、描画部118とを含み構成される。描画部118は、GDI120を支援しながら印刷データの描画を行い、描画データにプリンタ用のコマンドを付与してプリント・スプーラ122へ渡すグラフィック・ドライバである。
本実施形態によるプリンタドライバ114は、印刷設定に基づいて、アプリケーション112により作成された画像に対し所定の描画オブジェクトを付加する、描画オブジェクト付加印刷機能を実現する。なお、以下に説明する実施形態では、基本ソフトウェア(OS:Operating System)が提供するアウトライン・フォント・システム(例えばTrueTypeフォント)から取得される所定文字列のウォータマークが描画オブジェクトとして付加されるものとする。しかしながら、描画オブジェクトは、これに限定されるものではなく、任意の文字、図形および記号これらの組み合わせを用いることができる。
GDI120は、OSにより提供されるWindows(登録商標)のサブシステムであり、描画オブジェクトの表示や、画像形成装置などの出力装置へのデータ転送を制御する。プリント・スプーラ122も、OSにより提供され、印刷処理にかかるデータを一時的に保存し、処理状況に応じて印刷処理の実行を管理する。プリントプロセッサ124は、プリントジョブのスプールされたデータを、プリンタドライバ114の描画部118を利用して、送信すべきフォーマットへ変換する。プリントプロセッサ124は、上記OSによって標準のものが提供されるが、ベンダで独自に開発されたカスタム・プリント・プロセッサが用いられてもよい。
ランゲージ・モニタ126は、プリント・モニタの一種であり、プリント・スプーラ122から受信したデータを、ポートモニタ132へ送信する。ポートモニタ132もプリント・モニタの一種であり、ランゲージ・モニタ126からデータを受信し、通信プロトコルに基づく処理を行い、ポートドライバ134に印刷データを送信する。ポートドライバ134は、入出力ポートへアクセスし、画像形成装置180とホスト装置110との接続インタフェース(USBやネットワーク・インタフェース・カード)を制御して、画像形成装置180に印刷データを送信する。ランゲージ・モニタ126およびポートモニタ132は、上記OSにより標準のものが提供されているが、ベンダで独自に開発されたものが用いられてもよい。
説明する実施形態において、ランゲージ・モニタ126は、データ保存部128と、通信部130とを含み構成される。通信部130は、通常のランゲージ・モニタとしてのデータ送受信制御を実現する機能部である。これに対して、データ保存部128は、本実施形態において、プリンタドライバ114のUI部116と描画部118との間で、所定のデータを受け渡しするためデータを一時保持する保存手段である。
図3は、本実施形態におけるプリンタドライバ114を構成するコンポーネントを示すブロック図である。図3に示すプリンタドライバ114は、例えばPostScript用の標準ミニ・ドライバをベースとして構成されている。プリンタドライバ114は、ミニ・ドライバ(テキストファイル)148と、バイナリ・データ・ファイル150と、CPSUI(Common Property Sheet User Interface)DLL(Dynamic Link Library)152と、プリンタ・インタフェース(Printer Interface)DLL140と、プリンタ・グラフィックス(Printer Graphics)DLL154とを含み構成される。
ミニ・ドライバ148は、PostScriptの場合は、PostScriptプリンタで利用可能なすべての機能を記述するPPD(PostScript Printer Description)ファイルとして提供される、テキストベースのミニ・ドライバである。バイナリ・データ・ファイル150は、プリンタ・インタフェースDLL140のパーサ(PPDパーサ)142によりミニ・ドライバ(テキストファイル)148に含まれる情報を解析した後に生成される一時ファイルである。CPSUI DLL152は、プリンタやドキュメントのプロパティシートを取り扱うユーザ・インタフェースを提供する。
プリンタ・インタフェースDLL140は、上記パーサ142と、すべてのPostScriptをサポートするプリンタに対する共通ユーザ・インタフェース・コード(Common UI code)144とを提供する。プリンタドライバ114は、適宜、ユーザ・インタフェース・プラグイン146を備えてもよい。ユーザ・インタフェース・プラグイン146は、任意で提供されるものであり、プリンタ・インタフェースDLL140と組み合わせられて、プリンタ固有のユーザ・インタフェースを提供することができる。
プリンタ・グラフィックスDLL154は、PostScriptレンダラであり、テキストの出力およびイメージのレンダリングを処理し、プリント・スプーラ122にテキストおよびイメージ・データを送信する。プリンタドライバ114は、さらに、レンダリング・プラグイン156を備えることができる。レンダリング・プラグイン156は、プリンタ・グラフィックスDLL154に対し追加的に提供されるものであり、プリンタ・グラフィックスDLL154と組み合わせられて、追加レンダリング機能を提供する。なお、説明する実施形態では、レンダリング・プラグイン156は、後述する描画オブジェクト付加印刷機能の処理の一端を担う。
なお、図3において点線の矩形116で囲まれたコンポーネントが、UI部116を構成し、点線の矩形118で囲まれたコンポーネントが、描画部118を構成する。プリンタドライバ114は、典型的には、OSにより提供されるソフトウェア・コンポーネントと、プリンタドライバのインストーラなどにより外部から提供される固有のコンポーネント(148,146,156)とから構成される。
(第1の実施形態)
以下、図4〜図10を参照しながら、第1の実施形態による描画オブジェクト付加印刷機能を実現する印刷処理の流れについて説明する。図4および図5は、それぞれ、RAWスプール形式およびEMFスプール形式での描画オブジェクト付加印刷処理をデータの流れとともに説明する図である。以下、描画オブジェクト付加印刷処理について、まず、図4を参照しながら、RAWスプール形式の場合を参照して説明する。RAWスプール形式においては、アプリケーション112、OSが提供するGDI120およびプリント・スプーラ122、並びにプリンタドライバ114のUI部116および描画部118が処理に関与している。
まず、ユーザは、(1)プリンタドライバ114のUI部116が提供する印刷設定用GUIを介して印刷設定を行い、(2)アプリケーション112に対し印刷指示を行う。この印刷指示に応答して、(3)アプリケーション112は、UI部116との間で、印刷設定を保持するDEVMODE構造体をやり取りし、ユーザが行った印刷設定情報を取得する。(4)アプリケーション112は、さらに、GDI120に対し、印刷命令をGDIコールとして伝達する。(5)GDI120は、プリンタドライバ114の描画部118に対し、GDIコールをDDI関数として伝達する。(6)描画部118は、プリンタ言語に変換されたRAWデータとして、印刷データをプリント・スプーラ122に送信する。
描画部118からプリント・スプーラ122へ送信されたRAWデータは、プリント・スプーラ122から、ランゲージ・モニタ126、ポートモニタ132およびポートドライバ134を介して、画像形成装置180へ送信され、印刷されることになる。
上述した印刷処理の流れにおいて、上記(4)でのアプリケーション112からのジョブ開始に際した所定GDIコールに応答して、GDI120により、印刷ジョブに関するイベントを処理するためのUI部116の所定DDI関数のコールが行われる。具体的には、Windows(登録商標)におけるDrvDocumentEvent関数がコールされる。DrvDocumentEvent関数は、印刷中、描画部118に対するDDI関数の合間合間にコールされて単独の処理を行う、UI部116に対するDDI関数である。このため、前後のDrvDocumentEvent関数の間でデータの共有はできない。しかしながら、UI部116に対するDDI関数であるので、GDIコールを行うことが可能である。また、DrvDocumentEvent関数は、引数にデバイスコンテキストを有しているため、DDI関数の中で、デバイスコンテキストを引数にAPI(Application Programing Interface)をコールすることにより、描画部118に対して命令を伝達することができる。
本実施形態によるプリンタドライバ114のUI部116は、上記所定DDI関数のコールに応答して、所定エスケープコマンド(具体的には、Windows(登録商標)におけるExtEscape関数を用いることができる。)にて、プリンタドライバ114の描画部118から印刷設定情報を取得する(設定取得関数)。ユーザが設定した印刷設定情報は、DEVMODEとしてアプリケーション112からGDI120を介して描画部118に渡される。UI部116は、取得したデバイスコンテキストに対してExtEscape関数をコールすることにより、OSを介して、描画部118から印刷設定情報を取得している。ExtEscape関数のコールに応答してDrvEscape関数が描画部118に通知されるため、描画部118は、自身が保持している印刷設定情報を返す。上述した構成によれば、UI部116がOSのAPIをコールするだけで、描画部118からデータが取得されるので、上記構成は、独自のAPIを提供する必要がない点で有利である。
UI部116は、さらに、取得された印刷設定情報内に所定文字列のウォータマークの付加が指定される場合は、アウトライン・フォント・システムを用いて所定文字列のウォータマークを生成し、GDI120を介して、そのパスの情報を準備する(パス準備関数)。
図6(A)は、第1の実施形態によるUI部116が生成する、ウォータマークのパス情報を含んだPostScriptコマンドのデータ構造を例示する図である。図6(A)に例示するコマンドは、ウォータマークの文字「A」のパスの情報を含んでいる。UI部116は、アウトライン・フォントのパスを生成し、所定関数(具体的には、Windows(登録商標)におけるGetPath関数)を用いてOSからパス情報を取得し、これに基づいて、このパスを塗りつぶすという所定プリンタ言語のコマンド(以下、PostScripのコマンドをPSコマンドと参照する。)を生成する。図6(A)に示すPSコマンドでは、SetPatternからClosePathで特定されたパスを塗りつぶす(fill)コマンドが指定されている。
そして、UI部116は、準備されたウォータマークのパス情報をランゲージ・モニタ126に所定インタフェースを介して設定する(パス設定関数)。説明する実施形態では、パス情報は、図6(A)に示すような、ウォータマークのパス情報が含まれるPSコマンドの形でランゲージ・モニタ126に渡される。
ランゲージ・モニタに対しては、OSにより、所定のインタフェースが定められており、ベンダ独自のランゲージ・モニタでも、OSで定められたインタフェースに適合させて開発される。本実施形態によるランゲージ・モニタ126は、所定のインタフェース(具体的には、Windows(登録商標)におけるSendRecvBidiDataFromPort関数)を介して、呼び出し元のコンポーネントとのデータのやり取りを行うことができるよう構成されている。
図7は、第1の実施形態によるランゲージ・モニタ126が有する、プリントジョブに対応付けてパス情報を保存する機能を説明する図である。本実施形態によるランゲージ・モニタ126は、呼び出し元からキーを伴う設定要求(set)を受け取り、このキーに対応付けてパス情報200などのデータをデータ保存部128に保存することができる。ランゲージ・モニタ126は、呼び出し元からキーを伴う取得要求(get)を受け取り、このキーに対応付けてデータ保存部128に保存されたデータ200を読み出し、呼び出し元に返すことができる。
上記キーとしては、特に限定されるものではないが、好適にはジョブ識別子(ID)を用いることができる。ジョブ識別子は、OS136によって、プリントジョブに対し印刷開始から印刷終了まで一意性のあるIDとしてセットされるためである。ランゲージ・モニタ126は、データ保存部128に、図7に示すような、キーとデータ(パス情報)との組み合わせを保持するテーブル210を格納する。これにより、複数のアプリケーション112A,112Bから前後して(図7の例では、アプリケーション112A、アプリケーション112B、アプリケーション112Aの順で行われている。)印刷指示が行われたとしても、各プリントジョブに、適切にパス情報を対応付けて処理することができる。
再び図4を参照すると、上述した印刷処理の流れにおいて、上記(4)でのアプリケーション112からのページ終了に際した所定GDIコール(より具体的にはEndPage関数)に応答して、GDI120により、描画部118のDDI関数のコールが行われる。本実施形態による描画部118は、上記DDI関数のコールに応答して、所定インタフェースを介してランゲージ・モニタ126からパス情報を取得する(パス取得関数)。
ここで描画部118が取得するパス情報は、UI部116側でプリントジョブについて事前に準備されたウォータマークのパス情報であり、描画部118に渡されるジョブ識別子をキーとして取得される。すなわち、UI部116および描画部118は、アプリケーション112からのジョブ開始の指令に際してOS136により与えられるジョブ識別子をキーとして、ランゲージ・モニタ126との間で、各ジョブについての描画オブジェクトのパスの情報の設定および取得を行っている。
描画部118は、さらに、所定の塗りつぶしパターンを準備する。図6(B)〜(D)は、(B)塗りつぶしパターンのデータ構造、(C)塗りつぶしパターン・イメージおよび(D)塗りつぶしパターンを作成するPSコマンドを示す。塗りつぶしパターンは、図6(B)および(C)に示すように、文字列のパスを塗りつぶす部分(図6(B)で「1」が設定され、図6(C)で黒である部分)と、文字列のパスを塗りつぶさずに印刷データを透過させる部分(図6(B)で「0」が設定され、図6(C)で白である部分)とからなるマスクパターンである。図6(D)に示すPSコマンドは、特に限定されるものではないが、8×8の領域において、黒で塗りつぶす領域と、透過させる領域とが、1行2列の単位で市松模様を形成するように、マスクパターンを規定している。
描画部118は、典型的には、印刷設定情報内に規定されたウォータマークの透過率の指定値に応じた塗りつぶしパターンを準備することができる。図8は、第1の実施形態による描画部118が参照する、ウォータマークの透過率と、マスクパターンとを対応付けるテーブルを模式的に示す図である。透過率の指定値に対応付けて、予め複数の塗りつぶしパターンが準備されており、描画部118は、テーブルの中から、印刷設定情報内の指定値に対応するものを選択して、必要なマスクパターンを準備することができる。
図8に模式的に示すように、透過率が100%の場合は、典型的には、塗りつぶしは行われず、パスのみが出力される。一方、透過率が0%の場合は、パスの囲まれた領域がすべて指定色で塗りつぶされて出力される。また、透過率が0〜100%の間の中間値(図8には50%が示されている。)の場合は、パスの囲まれた領域が指定色で、塗りつぶす部分と透過させる部分とが混在するマスクパターンにより部分的に塗りつぶされて出力される。
図9は、上記(1)でプリンタドライバ114のUI部116により提供される、ウォータマークを編集するための設定用GUI画面を示す図である。ウォータマーク編集画面300は、ウォータマークのプロファイルを選択するプルダウン・メニュー302と、選択されたウォータマークのプレビュー表示を行うプレビュー領域304と、ウォータマークのプロファイルを削除するボタン306と、選択されたウォータマークのプロファイルの編集を行う編集領域310と、ウォータマークを配置決めするための配置決め領域340と、設定内容を反映させるボタン350と、設定内容を破棄するためのボタン352とを含む。
編集領域310は、選択されたウォータマークのプロファイルの名称が入力されるテキストボックス312と、ウォータマークの文字列が入力されるテキストボックス314と、文字列のフォントを選択するためのプルダウン・メニュー316と、文字列のフォントスタイルを選択するためのプルダウン・メニュー318と、文字列の指定色を選択するためのプルダウン・メニュー320と、文字列の文字修飾を選択するためのプルダウン・メニュー322とを含む。編集領域310は、さらに、文字列のサイズを指定するためのスピンボタン324、文字列の角度を指定するためのスピンボタン326、文字列の透過率(図中では濃度と示されている。)を指定するためのスピンボタン328と、プレビュー領域304を更新するためのボタン330と、編集中の内容でウォータマークのプロファイルを追加するためのボタン332とを含む。
配置決め領域340は、水平方向の位置を指定するためのスピンボタン342、垂直方向の位置を指定するためのスピンボタン344と、位置を中央に設定するためのボタン346とを含む。図9に示したウォータマーク編集画面300において、プルダウン・メニュー302でウォータマークが選択されて、ボタン350が押下されると、所定のウォータマークの印刷が印刷設定に指定される。
再び図4を参照すると、描画部118は、上記準備された塗りつぶしパターンで、上記取得されたパスの塗りつぶしを指令するPSコマンドを生成する。このPSコマンドは、描画部118で準備された塗りつぶしパターンを規定する第1のコマンドと、パスをセットし、パスを描画(塗りつぶす)よう指令する第2のコマンドとを含む。描画部118は、所定プリンタ言語(PostScript)に変換されたRAWデータとして、上記PSコマンドをプリント・スプーラ122に送信する。
上記構成により、アプリケーション112で生成された原稿画像(図10(A))の上に、UI部116で準備されたパスが、描画部118で準備された塗りつぶしパターンで塗りつぶされたウォータマーク(図10(B))が描画される。ひいては、図10(C)に示すような透過的なウォータマークの印刷が実現される。なお、説明する実施形態では、上述したパス情報を取得し、PSコマンドを生成して送信する機能は、レンダリング・プラグイン156により提供される。
以下、描画オブジェクト付加印刷処理について、図5を参照しながら、EMFスプール形式の場合について説明する。RAWスプールの場合と類似した処理の流れとなるが、EMFスプール形式においては、アプリケーション112、GDI120、プリント・スプーラ122、UI部116および描画部118に加えて、プリントプロセッサ124が処理に関与する。
まず、RAWスプール形式の場合と同様に、ユーザは、(1)プリンタドライバ114のUI部116が提供する印刷設定用GUIを介して印刷設定を行い、(2)アプリケーション112に対し印刷指示を行う。この印刷指示に応答して、(3)アプリケーション112は、プリンタドライバ114のUI部116との間で、DEVMODE構造体をやり取りすることによって、ユーザが行った印刷設定情報を取得する。
(4)アプリケーション112は、さらに、GDI120に対し、印刷命令をGDIコールとして伝達する。(5)GDI120は、EMFスプール形式においては、プリント・スプーラ122に対し、EMFデータをスプールデータとして渡す。アプリケーション112の印刷データが一通りスプールされると、(6)プリント・スプーラ122は、プリントプロセッサ124に対しデスプールを伝達し、スプールデータを渡す。(7)プリントプロセッサ124は、スプールデータをページごとに編集し、これにより、集約、逆順および製本の機能を実現し、編集した内容をGDI120にGDIコールとして伝達する。(8)GDI120は、プリンタドライバ114の描画部118に対し、GDIコールをDDI関数として伝達する。(9)プリンタドライバの描画部118は、プリンタ言語に変換されたRAWデータとして、印刷データをプリント・スプーラ122に送信する。
描画部118からのRAWデータは、RAWスプール形式の場合と同様に、プリント・スプーラ122により、ランゲージ・モニタ126、ポートモニタ132およびポートドライバ134を介して、画像形成装置180へ送信されることになる。EMFスプール形式では、一旦、EMFデータがスプールされ、プリントプロセッサ124により再印刷がかけられるが、概ね同様な処理となる。
EMFスプール形式の場合も、上述した処理の流れにおいて、GDI120は、上記(4)でのアプリケーション112からのジョブ開始に際した所定GDIコールに応答して、所定DDI関数のコールを行う。本実施形態によるプリンタドライバ114のUI部116は、この所定DDI関数のコールに応答して、設定取得関数、パス準備関数およびパス設定関数を呼び出し、印刷設定情報に応じたウォータマークのパス情報をランゲージ・モニタ126に設定する。
一方、描画部118は、上記(7)でのプリントプロセッサ124からのページ終了に際した所定GDIコール(より具体的にはGdiEndPageEMF関数)に応答して、ランゲージ・モニタ126からパス情報を取得する(パス取得関数)。描画部118は、同時に、所定の塗りつぶしパターンでパスを塗りつぶすPSコマンドを生成し、RAWデータとして、上記PSコマンドをプリント・スプーラ122に送信する。これにより、EMFスプール形式でも、図10(C)に示すような透過的なウォータマークの印刷が実現される。
以下、図11および図12、並びに図13〜図16を参照しながら、第1の実施形態による各スプール形式での描画オブジェクト付加印刷機能を実現する印刷処理における、各機能部間の相互作用および処理の流れについて、より詳細に説明する。なお、各機能部間の相互作用は、図11および図12、並びに図13〜図16に示す通りであるが、以下、本実施形態による画オブジェクト付加印刷機能に関連する主要な箇所について説明する。
図11および図12は、RAWスプール形式での描画オブジェクト付加印刷処理を示すシーケンス図である。図11および図12に示す処理では、ステップS1では、アプリケーション(図中APで表される。)112は、CreateDC関数をコールし、プリンタのデバイスコンテキストを作成する。CreateDC関数の引数で指定されたDEVMODE構造体(印刷設定情報)へのポインタが、ステップS1.3のDrvEnablePDEV関数の引数として描画部(図中GRで表される。)118に伝達される。これにより、プリンタドライバ114の描画部118は、ステップS1.3のDrvEnablePDEV関数からS7.2のDrvDisablePDEV関数までの間にコールされる描画部118のDDI関数において、印刷設定情報が参照可能となる。
ステップS2では、アプリケーション112は、StartDoc関数をコールし、プリントジョブを開始する。プリンタドライバ114の描画部118は、ステップS2.3のDrvStartDoc関数で、OSによって当該プリントジョブに付されたジョブ識別子を受け取ることができる。これにより、以降の描画部118のDDI関数において、ジョブ識別子が参照可能となる。これに対して、プリンタドライバ114のUI部116は、ステップS2.4のDrvDocumentEvent関数(iESC=DOCUMENTEVENT_STARTDOCPOST)でのみ、ジョブ識別子を受け取ることができる。GDI120は、この関数の引数にジョブ識別子を設定するからである。そこで、本実施形態によるUI部116は、このタイミングで、設定取得関数、パス準備関数およびパス設定関数を呼び出す。
より具体的には、ステップS2.4.1で、デバイスコンテキストを引数としてExtEscape関数をコールし、描画部118が保持する印刷設定情報を要求する。取得された印刷設定情報において、ウォータマークの付加が指定されていれば、UI部116は、ステップS2.4.2で、ウォータマークを生成し、ステップS2.4.2.1でGetPath関数を用いて、ウォータマークの文字列のパス情報をOSから受け取る。ステップS2.4.3では、UI部116は、上記ステップS2.4で取得されたジョブ識別子をキーとして、SendRecvBidiDataFromPort関数をコールして、上記ステップS2.4.2.1で準備されたパス情報をランゲージ・モニタ126に設定(set)する。
以降、ステップS3では、アプリケーション112は、StartPage関数をコールし、プリンタドライバ114に対し新しいページのデータを受け入れるよう指示する。ステップS4では、アプリケーション112は、所定の描画関数をコールし、プリンタドライバ114に描画データを渡す。
ステップS5では、アプリケーション112は、EndPage関数をコールし、ページ分の書き込みが終了したことを通知し、新しいページに進むように指示する。ページの書き込みが終了し、ページのデータを送信できるようになったことに応答して、ステップS5.2では、GDI120により描画部118のDrvSendPage関数がコールされる。描画部118は、プリントジョブのデータ・ストリーム中のSHOWPAGEコマンド(1ページ毎の記述の後に呼び出されるコマンドである。)前のタイミングで、ステップS5.2.1で示すように、IPrintOemPS::Commandメソッドをコールする。
IPrintOemPS::Commandメソッドは、プリントジョブのデータ・ストリーム中にPSコマンドを挿入するためのものである。このとき、IPrintOemPS::Commandメソッドの第2引数(インデックス)がPSINJECT_SHOWPAGEである場合、レンダリング・プラグイン(図中Pluginで示されている。)156は、ステップS5.2.1.1で、保持するジョブ識別子をキーとして、SendRecvBidiDataFromPort関数をコールして、ランゲージ・モニタ126からウォータマークのパス情報を含むPSコマンドを取得する(get)。
ステップS5.2.1.2では、描画部118は、こうして取得したパスを所定塗りつぶしパターンで塗りつぶすよう指令するPSコマンドをプリンタに向けて送信する。なおジョブ識別子をキーに関連付けて保存されていた情報は、このタイミングで不要となるので、ランゲージ・モニタ126にジョブ識別子をキーとしてデータ破棄要求を送信し、情報を破棄させてもよい。
ウォータマークを付加する場合、アプリケーション112で生成した原稿画像の背面にウォータマークが印刷されてしまい、図10(D)のような印刷結果が生じてしまう場合がある。この事象は、ウォータマークの描画オブジェクトを印刷した後に、アプリケーション112で生成したオブジェクトが描画されてしまうことに起因して発生する。説明する実施形態では、ポストスクリプトのコマンドのIDが「PSINJECT_SHOWPAGE」のタイミングを、各ページでのウォータマークの描画のタイミングとし、ウォータマークのPSコマンドを出力している。これにより、図10(C)で示すような、当該ページに対するウォータマークの透過的な付加印刷を行うことができる。
以降は、通常の印刷シーケンスと同様であり、アプリケーション112は、ステップS6で、EndDoc関数をコールし、印刷ジョブを終了させ、ステップS7で、DeleteDC関数をコールし、ステップS1で生成されたデバイスコンテキストを削除する。以上が、RAWスプール形式での印刷処理のシーケンスである。
図13〜図16は、EMFスプール形式での描画オブジェクト付加印刷処理を示すシーケンス図である。なお、図中の白色の機能部は、アプリケーションのプロセスで動作するものであり、図中の灰色で示す機能部は、スプーラのプロセスで動作するものである。ステップS1〜S6で示す主にアプリケーション112のプロセス間で行われるメッセージのやり取りが、EMFデータへの変換処理となる。EMFスプール形式では、その後、スプーラ・プロセスにおいて、ステップS8で再度印刷処理がかかり、これ以降で、EMFデータからRAWデータへの変換処理が行われる。ステップS8以降の主にスプーラ・プロセス間のメッセージのやり取りが、RAWデータへの変換処理に対応する。
ステップS1では、アプリケーション112は、CreateDC関数をコールする。ステップS1.3のアプリケーション・プロセスにおけるDrvEnablePDEV関数で、アプリケーション112で決定されたDEVMODE構造体(印刷設定情報)へのポインタが描画部118に伝達される。これにより、プリンタドライバ114の描画部118は、描画部118のDDI関数において、印刷設定情報が参照可能となる。
ステップS2では、アプリケーション112は、StartDoc関数をコールし、プリントジョブを開始する。UI部116は、ステップS2.2のDrvDocumentEvent関数(iESC=DOCUMENTEVENT_STARTDOCPOST)でのみ、ジョブ識別子を受け取ることができる。本実施形態によるUI部116は、ここで、ステップS2.2.1で、デバイスコンテキストを引数としてExtEscape関数をコールし、描画部118が保持している印刷設定情報を要求する。ステップS2.2.1.1では、描画部118にDrvEscape関数が通知されるので、描画部118は、保持している印刷設定を返却する。
取得された印刷設定情報において、ウォータマークの付加が指定されていれば、UI部116は、ステップS2.2.2で、指定のウォータマークを生成する。ステップS2.2.2.1では、UI部116は、GetPath関数を用いて、指定されたウォータマークのパス情報をOSから受け取る。ステップS2.2.3では、UI部116は、ステップS2.2で取得されたジョブ識別子をキーとして、SendRecvBidiDataFromPort関数をコールし、ステップS2.2.2.1で準備されたパス情報をランゲージ・モニタ126に設定する。
アプリケーション・プロセスでの処理が終了した後は、スプーラ・プロセスでの再印刷処理となる。アプリケーション・プロセスにおけるEndDoc関数以降、ステップS7では、プリント・スプーラ122は、OpenPrintProcessor関数をコールし、プリントプロセッサ(図中PPで示されている。)124を準備する。ステップS8では、プリント・スプーラ122は、PrintDocumentOnPrintProcessor関数をコールし、プリントプロセッサ124によるRAWデータへの変換処理を開始させる。
ステップS8.1で、プリントプロセッサ124により、GetJobAttributes関数が呼び出されると、DrvQueryJobAttributes関数がコールされる。ステップS8.2では、プリントプロセッサ124は、GdiGetSpoolFileHandle関数で、スプールファイルのハンドルを取得し、ステップS8.3では、GdiGetDC関数で、プリンタのデバイスコンテキストを取得する。ステップS8.4では、GdiStartDocEMF関数で、EMF形式のプリントジョブのための初期化を行う。ステップS8.4.2のDrvStartDoc関数では、プリンタドライバ114の描画部118は、ジョブ識別子を受け取ることができる。これによって描画部118のDDI関数において、ジョブ識別子が参照可能となる。ステップS8.5では、プリントプロセッサ124は、GdiStartPageEMF関数で、EMF形式のプリントジョブのページの初期化を行い、ステップS8.6では、プリントプロセッサ124は、GdiPlayPageEMF関数をコールする。
ステップS8.7では、プリントプロセッサ124は、GdiEndPageEMF関数をコールし、EMF形式のプリントジョブのページについてのEMFの再生を終了させる。ページの書き込みが終了し、ページをプリンタに送信できるようになったことに応答して、ステップS8.7.5で、GDI120により描画部118のDrvSendPage関数がコールされる。描画部118は、ステップS8.7.5.1で示すCommand()で第2引数がPSINJECT_SHOWPAGEの場合、レンダリング・プラグイン156により、ステップS8.7.5.1.1で、SendRecvBidiDataFromPort関数をコールし、ランゲージ・モニタ126からウォータマークのパス情報を含むPSコマンドを取得する。ステップS8.7.5.1.2では、こうして取得したパスを所定塗りつぶしパターンで塗りつぶすよう指令するコマンドを出力する。これにより、ウォータマークの透過的な付加が実現される。
以降は、通常の印刷シーケンスと同様であり、アプリケーション112は、ステップS9で、DeleteDC関数をコールする。スプーラ・プロセスにおいても、ステップS8.8で、プリントプロセッサ124は、GdiEndDocEMF関数をコールし、ステップS8.9で、GdiDeleteSpoolFileHandle関数をコールし、スプールファイルのハンドルを解放する。プリント・スプーラ122は、ステップS11で、ControlPrintProcessor関数をコールしてプリントジョブを制御しつつ、ステップS12で、ClosePrintProcessor関数をコールし、プリントジョブの印刷を完了させる。以上が、EMFスプール形式での印刷処理のシーケンスである。
図11および図12で示したRAWスプール形式の印刷処理シーケンスと、図13〜図16で示したEMFスプール形式の印刷処理シーケンスとは異なってはいる。しかしながら、プリンタドライバ114のUI部116のDrvDocumentEvent関数(iESC=DOCUMENTEVENT_STARTDOCPOST)、ランゲージ・モニタ126のSendRecvBidiDataFromPort関数(set)、SendRecvBidiDataFromPort関数(get)、プリンタドライバ114の描画部118のDrvEnablePDEV関数、DrvStartDoc関数、DrvSendPage関数、DrvEscape()関数の各関数内で行っている処理は、RAWスプール形式でもEMFスプール形式でも同一である。よって、本実施形態によるプリンタドライバ114は、スプール形式によらず、描画オブジェクト付加印刷処理を実現可能である。
上記構成によれば、プリンタドライバ114のUI部116は、OSからジョブ識別子を受け取る機能(DrvDocumentEvent関数(iESC=DOCUMENTEVENT_STARTDOCPOST))と、OSを介してプリンタドライバ114の描画部118からデータを取得する機能(設定取得関数)と、印刷開始後に、GDIコールによりパス情報を準備し、上記パス情報からウォータマークのPSコマンドを生成する機能(パス準備関数)とを備える。ランゲージ・モニタ126は、キーを指定したデータ設定要求(SendRecvBidiDataFromPort関数(set))に対し、キーとデータの組み合わせを保持する機能と、キーに対応したデータ取得要求(SendRecvBidiDataFromPort関数(get))に対しデータを返却する機能とを備える。プリンタドライバ114の描画部118は、ジョブ識別子を受け取る機能(DrvStartDoc関数)と、ジョブ識別子をキーとしてパス情報をランゲージ・モニタ126から取得し、塗りつぶしパターンのPSコマンドを生成してプリンタに送信する機能(IPrintOemPS::Command methodメソッド)とを備える。
プリンタドライバ114およびランゲージ・モニタ126が上記機能を備えることにより、プリンタドライバ114のUI部116が描画オブジェクトのパス情報を準備してランゲージ・モニタ126に設定する。一方で、描画部118がランゲージ・モニタ126からパス情報を読み出して、RAWデータのストリーム中にウォータマークのPSコマンドを挿入することができる。したがって、独自のプリントプロセッサを必要とせず、スプール形式にかかわらず、アウトライン・フォントの文字列など、描画オブジェクトを透過させて付加することができる。また、独自のAPIを提供する必要もない。
(第2の実施形態)
以上説明した第1の実施形態では、ウォータマークの設定を含む印刷設定は、ユーザによる印刷指示が行われる前にアプリケーション112から呼び出された印刷設定画面を介して設定されるものとして説明した。一方、印刷開始後にポップアップ画面を立ち上げて印刷設定を変更する技術が知られている。以下、ポップアップ画面による印刷設定機能とともに、上述した描画オブジェクト付加印刷機能を実現する第2の実施形態について説明する。なお、第2の実施形態は、上述した第1の実施形態と同様な構成を備えているので、以下、相違点を中心に説明する。
以下、図17〜図19を参照しながら、第2の実施形態による各スプール形式での描画オブジェクト付加印刷機能を実現する印刷処理について説明する。図17は、第2の実施形態における、RAWスプール形式での描画オブジェクト付加印刷処理を示すシーケンス図であり、図11および図12で説明した第1の実施形態におけるシーケンス図との相違点が抜き出されて示されている。
図11および図12に示す処理と同様に、アプリケーション112は、ステップS1で、CreateDC関数をコールし、ステップS2で、StartDoc関数をコールする。第2の実施形態でも、描画部118は、ステップS2.3のDrvStartDoc関数でジョブ識別子を受け取る。ステップS2.4では、UI部116は、DrvDocumentEvent関数(iESC=DOCUMENTEVENT_STARTDOCPOST)でジョブ識別子を受け取り、ステップS2.4.1で、ExtEscape関数をコールし、描画部118が保持している印刷設定情報を取得する。
第2の実施形態では、ステップS2.4.2で、UI部116は、ステップS2.4.1で取得した印刷設定情報を初期値として、ポップアップ設定画面を表示する。ポップアップ画面は、図9に示したGUI画面と同様のものである。UI部116は、ユーザによりポップアップ設定画面で入力された変更後の印刷設定情報を取得する。取得された印刷設定情報において、ウォータマークの付加が指定されていれば、UI部116は、ステップS2.4.3で、ウォータマークを生成する。ステップS2.4.3.1では、UI部116は、GetPath関数を用いて、生成されたウォータマークの文字列のパス情報をOSから受け取る。ステップS2.4.4では、UI部116は、上記ステップS2.4で取得されたジョブ識別子をキーとして、SendRecvBidiDataFromPort関数をコールして、上記ステップS2.4.2で取得された印刷設定情報と、上記ステップS2.4.3.1で準備されたパス情報とを、ランゲージ・モニタ126に設定(set)する。
ステップS3では、アプリケーション112は、StartPage関数をコールする。ステップS3.2では、GDI120により描画部118のDrvStartPage関数がコールされる。描画部118は、最初のページ処理の場合は、ステップS3.2.1で、保持していたジョブ識別子をキーとして、SendRecvBidiDataFromPort関数をコールし、ランゲージ・モニタ126に保存された情報のうちの印刷設定情報を取得する(get)。
以降、第1の実施形態と同様に(ここでは図12を参照して説明する。)、アプリケーション112は、ステップS4で、所定の描画関数をコールし、ステップS5で、EndPage関数をコールする。ステップS5.2では、GDI120により描画部118のDrvSendPage関数がコールされる。ステップS5.2.1で示すIPrintOemPS::Commandメソッドの第2引数がPSINJECT_SHOWPAGEである場合、レンダリング・プラグイン156は、ステップS5.2.1.1で、SendRecvBidiDataFromPort関数をコールして、ランゲージ・モニタ126から、ランゲージ・モニタ126に保存された情報のうちのパス情報を含むPSコマンドを取得する(get)。ステップS5.2.1.2では、取得したパスを所定塗りつぶしパターンで塗りつぶすよう指令するPSコマンドをプリンタに向けて送信する。以降は、通常の印刷シーケンスと同様である。
図18および図19は、第2の実施形態によるEMFスプール形式での描画オブジェクト付加印刷処理を示すシーケンス図であり、図13〜図16で説明した第1の実施形態におけるシーケンス図との相違点が抜き出されて示されている。
RAWスプール形式の場合と同様に、アプリケーション112は、ステップS1で、CreateDC関数をコールし、ステップS2で、StartDoc関数をコールする。第2の実施形態では、UI部116は、ステップS2.2のDrvDocumentEvent関数(iESC=DOCUMENTEVENT_STARTDOCPOST)でジョブ識別子を受け取る。ステップS2.2.1で、ExtEscape関数をコールし、描画部118が保持している印刷設定情報を要求する。ステップS2.2.1.1では、描画部118にDrvEscape関数が通知されるので、描画部118は、保持している印刷設定を返却する。
UI部116は、ExtEscape関数の処理から戻ってくるタイミングで、ステップS2.2.2で、取得した印刷設定情報を初期値として、ポップアップ設定画面を表示、ユーザにより入力された変更後の印刷設定情報を取得する。取得された印刷設定情報内でウォータマークの付加が指定されていれば、UI部116は、ステップS2.2.3で、ウォータマークを生成し、ステップS2.2.3.1でGetPath関数を用いて、生成されたウォータマークの文字列のパス情報を受け取る。ステップS2.2.4では、UI部116は、上記ステップS2.2で取得されたジョブ識別子をキーとして、上記ステップS2.2.2で取得した印刷設定情報と、上記ステップS2.2.3.1で準備されたパス情報とを、SendRecvBidiDataFromPort関数をコールして、ランゲージ・モニタ126に設定する(set)。
アプリケーション・プロセスでの処理が終了した後は、スプーラ・プロセスでの再印刷処理となる。ここでは図14および図15を参照して説明すると、アプリケーション・プロセスにおけるEndDoc関数以降、ステップS7では、プリント・スプーラ122は、OpenPrintProcessor関数をコールする。ステップS8では、プリント・スプーラ122は、PrintDocumentOnPrintProcessor関数をコールする。
プリントプロセッサ124は、ステップS8.1で、GetJobAttributes関数をコールし、ステップS8.2で、GdiGetSpoolFileHandle関数をコールし、ステップS8.3で、GdiGetDC関数をコールする。ステップS8.4では、プリントプロセッサ124は、GdiStartDocEMF関数をコールする。ステップS8.4.2のDrvStartDoc関数では、スプーラ・プロセスにおけるプリンタドライバ114の描画部118は、ジョブ識別子を受け取る。引き続き、プリントプロセッサ124は、ステップS8.5で、GdiStartPageEMF関数をコールし、ステップS8.6で、GdiPlayPageEMF関数をコールする。
ここで、図19を参照すると、ステップS8.7では、プリントプロセッサ124は、GdiEndPageEMF関数をコールし、8.7.2では、GDI120により描画部118のDrvStartPage関数がコールされる。描画部118は、最初のページ処理の場合は、ステップS8.7.2.1で、SendRecvBidiDataFromPort関数をコールして、保持していたジョブ識別子をキーとして、ランゲージ・モニタ126に保存された情報のうちの印刷設定情報を取得する(get)。
ステップS8.7.5では、GDI120により描画部118のDrvSendPage関数がコールされる。描画部118は、ステップS8.7.5.1で示すCommand()で第2引数がPSINJECT_SHOWPAGEの場合で、レンダリング・プラグイン156により、ステップS8.7.5.1.1で、SendRecvBidiDataFromPort関数をコールし、保持していたジョブ識別子をキーとして、ランゲージ・モニタ126からウォータマークのパス情報を含むPSコマンドを取得する(get)。ステップS8.7.5.1.2では、取得したパスを所定塗りつぶしパターンで塗りつぶすよう指令するPSコマンドを出力する。これにより、ウォータマークの透過的な付加が実現される。以降は、通常の印刷シーケンスと同様である。
上記第2の実施形態によれば、ジョブ開始に際して、ステップS2.2のDrvDocumentEvent関数(iESC=DOCUMENTEVENT_STARTDOCPOST)で受け取ったジョブ識別子に関連付けて、パス情報と印刷設定情報との両方がランゲージ・モニタ126に設定される。このため、ポップアップ画面による印刷設定機能を有する場合でも、描画オブジェクト付加印刷機能の両方を適切に実現することが可能となる。
(ハードウェア構成)
以下、図20を参照しながら、上述までの実施形態におけるホスト装置110のハードウェア構成について説明する。ホスト装置110は、典型的には、汎用コンピュータ装置として構成される。図20は、本実施形態による汎用コンピュータ装置のハードウェア構成を示す図である。
汎用コンピュータ装置110は、デスクトップ型のパーソナル・コンピュータ、ワークステーションなどとして構成されている。汎用コンピュータ装置110は、CPU(Central Processing Unit)12と、CPU12とメモリとの接続を担うノースブリッジ14と、サウスブリッジ16とを含む。サウスブリッジ16は、上記ノースブリッジ14と専用バスまたはPCIバスを介して接続され、PCIバスやUSBなどのI/Oとの接続を担う。
ノースブリッジ14には、CPU12の作業領域を提供するRAM(Random Access Memory)18と、映像信号を出力するグラフィックボード20とが接続される。グラフィックボード20には、アナログRGB、HDMI(High-Definition Multimedia Interface;HDMIおよびHigh-Definition Multimedia Interfaceは登録商標または商標である)、DVI(Digital Visual Interface)などの映像出力インタフェースを介してディスプレイ50に接続される。
サウスブリッジ16には、PCI(Peripheral Component Interconnect)22、LANポート24、IEEE1394、USB(Universal Serial Bus)ポート28、補助記憶装置30、オーディオ入出力32、シリアルポート34が接続される。補助記憶装置30は、HDD(Hard Disk Drive)やSSD(Solid State Drive)などであり、コンピュータ装置を制御するためのOS、上記プリンタドライバのプログラムや各種システム情報や各種設定情報を格納する。LANポート24は、汎用コンピュータ装置110を有線および無線でネットワークに接続させるインタフェース機器である。USBポート28には、キーボード52およびマウス54などの入力装置が接続され、操作者からの各種指示の入力を受け付けるためのユーザ・インタフェースを提供する。
本実施形態による汎用コンピュータ装置110は、補助記憶装置30からプログラムを読み出し、RAM18が提供する作業空間に展開することにより、CPU12の制御の下、上述した各機能部および各処理を実現する。なお、汎用コンピュータ装置110のハードウェア構成について説明したが、画像形成装置180についても、画像形成処理、画像読取処理、ファクシミリ送受信処理など特定の用途に応じたハードウェアを備える他、CPUおよびRAM等などのハードウェアを備える点では共通しており、同様な構成とすることができる。
上述した実施形態によれば、独自のプリントプロセッサを必要とせず、スプール形式にかかわらず、描画オブジェクトを付加して描画処理することができるプログラム、情報処理装置、および、上記プログラムと画像処理装置とを含む画像処理システムを提供することができる。
なお、上記機能部は、アセンブラ、C、C++、C#、Java(登録商標)などのレガシープログラミング言語やオブジェクト指向プログラミング言語などで記述されたコンピュータ実行可能なプログラムにより実現でき、ROM、EEPROM、EPROM、フラッシュメモリ、フレキシブルディスク、CD−ROM、CD−RW、DVD−ROM、DVD−RAM、DVD−RW、ブルーレイディスク、SDカード、MOなど装置可読な記録媒体に格納して、あるいは電気通信回線を通じて頒布することができる。また、上記説明では、ホスト装置110と画像形成装置180とを含み構成されるプリントシステムについて説明したが、上記プリンタドライバおよび画像形成装置を含むシステムとして提供されてもよい。
これまで本発明の実施形態について説明してきたが、本発明の実施形態は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。