JP4667280B2 - 情報処理装置及びその制御方法、プログラム - Google Patents

Description

本発明は、複数種類のプリンタドライバと、各プリンタドライバが処理可能な複数種類の描画部とが動作する情報処理装置及びその制御方法、プログラムに関するものである。

ホストコンピュータ内のオペレーティングシステム上で動作するアプリケーションから印刷を行う場合は、オペレーティングシステムの持つグラフィックスエンジンと、印刷先プリンタのプリンタドライバを使用して印刷を行うことが一般的である。印刷を行うアプリケーションは、まず、プリンタドライバに問い合わせてプリンタの能力にあった印刷設定情報を作成する。次に、作成した印刷設定情報を元にして描画データを作成しグラフィックスエンジンに渡し、プリンタドライバと連携しながらプリンタが解釈可能な印刷データを作成する。

このときに、一時的に作成されるデータは、スプールファイルと呼ばれ、最終的にはプリンタを制御するコマンド言語データの集まったスプールファイルとなり、スプーラに渡される。スプーラは、プリンタに対して複数のスプールファイルがあっても順番に印刷処理行うことができるように、スプールファイルを「キュー」と呼ばれる待ち行列で管理している。プリンタが印刷可能状態になったらスプーラは、キューからスプールファイルを順に取り出してプリンタに送信し、印刷を行う。

一方、グラフィックスエンジンは、アプリケーションが一意に描画するだけで、ディスプレイの種類やビデオカード、プリンタの種類やプリンタ制御言語などのハードウェアの違いを問わず、同じ出力結果を得られるように描画を行うシステムである。一般的には、オペレーティングシステムの一部として提供される。そして、このグラフィックスエンジンは、ＷＹＳＩＷＹＧ（“ｗｈａｔ−ｙｏｕ−ｓｅｅ−ｉｓ−ｗｈａｔ−ｙｏｕ−ｇｅｔ”）と呼ばれる「ディスプレイで見たものがそのまま印刷できる」という環境を実現するためのエンジンとして知られている。このグラフィックスエンジンは、必ずしもオペレーティングシステム上で１つであるとは限らず、二つ以上のグラフィックスエンジンが共存する構成が存在する。

例えば、Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムの場合、ＧＤＩ（Ｇｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）とＤｉｒｅｃｔＸ Ｇｒａｐｈｉｃｓと呼ばれる２つのグラフィックスエンジンが共存している。ワードプロセッサやスプレッドシートのようなビジネスアプリケーションで扱うデータは、従来から存在するＧＤＩで十分処理することが可能である。一方、ＤｉｒｅｃｔＸ Ｇｒａｐｈｉｃｓは、ゲームやマルチメディアタイトル等のリアルタイムグラフィックス処理のために、ハードウェアデバイスの能力を極限まで引きだすグラフィックスエンジンとして存在している。そして、アプリケーションは、これらの両者のグラフィックスエンジンを適応的に使い分けることができる。しかし、ＤｉｒｅｃｔＸ Ｇｒａｐｈｉｃｓは、ディスプレイ用のグラフィックスエンジンであり、印刷用のグラフィックスエンジンはＧＤＩが長い間使用されていた。

また、例えば、２００５年に米国シアトルにて、ＷｉｎＨＥＣ ２００５というハードウェアエンジニアリングカンファレンスがマイクロソフト社によって開催された。この場にて、Ｍｉｃｒｏｓｏｆｔ社の最新のオペレーティングシステムであるＷｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａでは、ＷＰＦという新たなグラフィックスエンジンが追加されている（非特許文献１）。ＷＰＦは、印刷の処理も新規に追加されたため、従来のＧＤＩを使用した印刷に加え、新しい印刷のシステムが使用できることになる（非特許文献２）。尚、ＷＰＦは、Ｗｉｎｄｏｗｓ（登録商標） Ｐｒｅｓｅｎｔａｔｉｏｎ Ｆｏｕｎｄａｔｉｏｎである。

従来のＷｉｎｄｏｗｓ（登録商標）からの印刷処理システムは、Ｗｉｎ３２ＡＰＩというＡＰＩを使用したアプリケーションから、ＧＤＩを経由してＥＭＦと呼ばれるスプールファイルを使用して、ＧＤＩ用のプリンタドライバで印刷データを作成するシステムである。

ここで、ＡＰＩとは、Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅの略称である。また、Ｗｉｎ３２ＡＰＩというＡＰＩを使用したアプリケーションを、以後、Ｗｉｎ３２アプリと略称する。また、ＥＭＦは、Ｅｎｈａｎｃｅｄ Ｍｅｔａｆｉｌｅの略称である。また、ＧＤＩ用のプリンタドライバを、以後、ＧＤＩプリンタドライバと略称する。

また、上記のように、Ｗｉｎ３２アプリからＧＤＩプリンタドライバを経由して印刷を行う印刷処理システムをＧＤＩプリントパスと呼ぶ。これに対し、ＷＰＦを使った印刷処理システムは、ＸＰＳ（ＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）プリントパスと呼ばれる。ＸＰＳプリントパスは、ＷｉｎＦＸＡＰＩというＡＰＩを使用したアプリケーションから、ＷＰＦを経由してＸＰＳと呼ばれるスプールファイルを使用して、ＷＰＦ用のプリンタドライバで印刷データを作成するシステムである。

ここで、ＷｉｎＦＸＡＰＩというＡＰＩを使用したアプリケーションを、以後、ＷＰＦアプリと略称する。また、ＷＰＦ用のプリンタドライバを、以後、ＸＰＳＤｒｖプリンタドライバと略称する。

従来のＧＤＩプリントパスに対して、ＸＰＳプリントパスを使用すると、より高度なカラー処理が可能になり、オープンな仕様であるＸＰＳスプールファイルやマークアップ言語のＸＭＬ形式の印刷設定により拡張や互換性が容易になるなど、多くの利点を持つ。

ここで、ＸＭＬは、ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅの略称である。

しかしながら、ＧＤＩプリンタドライバとＸＰＳＤｒｖプリンタドライバは異なる属性のプリンタドライバになるため、たとえ同じプリンタに対するプリンタドライバであっても、アプリケーションは、それぞれ異なるプリンタに見える。アプリケーションがＧＤＩプリンタドライバか、ＸＰＳＤｒｖプリンタドライバかをＡＰＩを使用して判定することはできる。しかしながら、このＡＰＩは新規に追加されたＡＰＩなので、従来から存在するＷｉｎ３２アプリから印刷を行う場合は判定を行うことができない。また、ユーザがこれらのドライバのどちらかを選択することはできるが、Ｗｉｎ３２アプリかＷＰＦアプリか、またＧＤＩプリンタドライバかＸＰＳＤｒｖプリンタドライバかを明示的に判定することは難しく、両者の違いまで意識して印刷することは困難である。

そこで、新しいＷＰＦを使用する印刷処理システムでは、Ｗｉｎ３２アプリからＧＤＩの印刷をＸＰＳに変換するシステムと、ＷＰＦアプリからのＸＰＳの印刷をＧＤＩに変換するシステムを用意している。これにより、アプリケーションが意識することなく自動で相互変換を行うようになっている。このシステムにより、アプリケーション開発者（ＩＳＶ：Ｉｎｄｅｐｅｎｄｅｎｔ Ｓｏｆｔｗａｒｅ Ｖｅｎｄｏｒ）はＧＤＩプリンタドライバかＸＰＳＤｒｖプリンタドライバかを意識することなく、印刷することが可能である。また、プリンタドライバ開発者（ＩＨＶ：Ｉｎｄｅｐｅｎｄｅｎｔ Ｈａｒｄｗａｒｅ Ｖｅｎｄｏｒ）も、ひとつのプリンタに対してＧＤＩプリンタドライバとＸＰＳＤｒｖプリンタドライバをそれぞれ用意する必要もなく、互換性と利便性が保たれている。
マイクロソフトコーポレーション、「Advances in Windows（登録商標） Printing:TWPR05001_WinHEC05.ppt」、［オンライン］、平成１６年５月７日、［平成１７年２月２８日検索］、インターネット、＜http://www.microsoft.com/whdc/device/print/default.mspx＞ ＸＰＳ ａｎｄ Ｃｏｌｏｒ Ｐｒｉｎｔｉｎｇ Ｅｎｈａｎｃｅｍｅｎｔｓ ｉｎ Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｖｉｓｔａ（http://www.microsoft.com/whdc/xps/vista_print.mspx）

しかしながら、ＧＤＩのＥＭＦ形式とＷＰＦのＸＰＳ形式では、表現できる範囲に違いがあるため、描画データを完全に相互変換することができない。

ＥＭＦからＸＰＳに変換する際には、ラスタオペレーション（ＲＯＰ）による描画データが欠落する。ＲＯＰとは、ビットマップイメージを転送する場合に、転送元（ソース：Ｓ）のビット、転送先（ディスティネーション：Ｄ）のビット、及びその時点でのブラシパターン（Ｐ）のビットの３つのビットを組み合わせる。そして、それらのビットの組み合わせによって、結果のビットが決定される論理演算の描画である。

これは、２つの絵を重ね合わせて背景を透明にする等の用途で用いられ、主にプレゼンテーションや画像処理を行うＷｉｎ３２アプリケーションで使用される。ＧＤＩではＲＯＰによる描画を行うが、ＷＰＦでは透過度を指定できるＯｐａｃｉｔｙＭａｓｋという機能はあるものの論理演算で描画する手法を持っていない。従って、ＥＭＦからＸＰＳに変換する際には、ＲＯＰ描画が欠落する可能性があり、ユーザがＷｉｎ３２アプリケーションを用いて作成した出力結果を得られなくなる恐れがある。

また、逆にＸＰＳからＥＭＦに変換する際には、ＧＤＩでサポートされていない高度なグラフィックス処理が欠落する恐れがある。例えば、ストロークパス（ライン）の線端を別々の表示（例えば、片方が半円で片方が三角等）で描画できるＸＰＳに対して、ＧＤＩでは両方とも同じ線端でなければならないため、全体をビットマップとして変換せざるを得ない。

ビットマップに変換されてしまうと、ＧＤＩプリンタドライバは、この描画がストロークパスであると認識できなくなるので、プリンタ制御言語の印刷データに変換する際に最適なデータに変換することができなくなる可能性がある。他にも、ＧＤＩプリンタドライバで拡大縮小等を伴うレイアウトの変更を行ったときに、ビットマップで拡大すると線のエッジがギザギザになり粗くなってしまう（ジャギー）といった問題が発生することも考えられる。つまり、コマンドで処理することにより画質の低下を防ぐことはできるが、ビットマップデータを処理する場合に、拡大縮小により出力結果の品質低下を招く恐れがある。

このため、ＧＤＩからＸＰＳもしくはＸＰＳからＧＤＩに変換するシステムを通らないで印刷することが望ましいといえるが、オペレーティングシステムは自動でこれらの変換を行ってしまう。ここで、ユーザがこれらの変換を回避するためにはアプリケーションとプリンタドライバがそれぞれどちらの属性なのかを判断しなければならない。また、そもそもこの変換の問題を認識しているユーザも少ない。そのため、容易に上述したような出力結果の品質低下を防ぐこと、または、印刷機能の低下を防ぐことができなくなる恐れがある。

また、ＧＤＩからＸＰＳもしくはＸＰＳからＧＤＩに変換する際のコンバータはオペレーティングシステムとして組み込まれた形で提供されるため、外部から変換ロジックを変更することはできない。従って、描画が欠落する部分はプリンタやプリンタドライバを変更したとしても、更にはアプリケーションを変更したとしても、ＧＤＩからＸＰＳもしくはＸＰＳからＧＤＩに変換を行う限りは上述したような問題が発生することも考えられる。

印刷設定の場合、ＧＤＩプリントパスではＤＥＶＭＯＤＥ構造体と呼ばれるデータ構造で印刷設定データを持っていたが、ＸＰＳプリントパスではＰｒｉｎｔＴｉｃｋｅｔと呼ばれるＸＭＬ形式のデータ構造になる。こちらもＧＤＩからＸＰＳもしくはＸＰＳからＧＤＩに変換する際にＤＥＶＭＯＤＥからＰｒｉｎｔＴｉｃｋｅｔへ、ＰｒｉｎｔＴｉｃｋｅｔからＤＥＶＭＯＤＥに変換する処理が必要となる。描画データ同様に、ＤＥＶＭＯＤＥで表現できる範囲とＰｒｉｎｔＴｉｃｋｅｔで表現できる範囲も異なるが、この処理はオペレーティングシステムが自動で行うのではなく、プリンタドライバ自身が拡張されたアーキテクチャを用いて行うようになっている。従って、プリンタドライバを作成するＩＨＶが適切に変換処理を作成すれば、描画のようにデータが抜け落ちてしまうという問題はない。

本発明は上記の課題を解決するためになされたものである。その目的は、印刷データを生成する形式が異なる描画機能が混在する環境で、使用する描画機能によって画像劣化等の不具合が生じる可能性があると判定された場合、印刷前に警告することができる情報処理装置及びその制御方法、プログラムを提供することにある。

上記の目的を達成するための本発明による情報処理装置は以下の構成を備える。即ち、
第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理が可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理が可能な第２描画データを生成する第２描画部とが動作する情報処理装置であって、
前記第１アプリケーションからの印刷指示に応じて作成された前記第１描画データから変換された第２描画データの描画状態が不自然である場合、警告情報として前記第２描画データに基づくプレビュー画面を表示すると共に、前記描画状態が不自然であると判定された前記第２描画データ中の領域については他の領域と識別可能に表示する出力手段と
を備える。

本発明によれば、印刷データを生成する形式が異なる描画機能が混在する環境で、使用する描画機能によって不具合が生じる可能性があると判定された場合、印刷前に警告することができる情報処理装置及びその制御方法、プログラムを提供できる。

以下、本発明の実施の形態について図面を用いて詳細に説明する。

図１は本発明の実施形態の印刷処理システムのブロック構成図である。

尚、特に断らない限り、本発明の機能が実行されるのであれば、単体の機能であっても、複数の機器からなるシステムであっても本発明を適用できることは言うまでもない。更には、ＬＡＮ、ＷＡＮ等のネットワークを介して接続がなされ処理が行われるシステムであっても、本発明を適用できることは言うまでもない。

図１では、一般的なコンピュータを用いて実現される印刷処理システムのブロック構成図を示している。ＣＰＵ１０１は、ＲＯＭ１０２、ＲＡＭ１０３あるいは外部記憶装置１０５に格納されたプログラムに従ってシステム全体の制御を行う。ＲＡＭ１０３は、ＣＰＵ１０１が各種処理を行う際のワークエリアとしても使用される。外部記憶装置１０５は、アプリケーション１０５１、印刷関連プログラム１０５２、プリンタドライバ１０５３、オペレーティングシステム（ＯＳ）１０５４等の各種プログラムを記憶する。

キーボード１０８やポインティングデバイス１０９（例えば、マウス等）の入力デバイスは、入力Ｉ／Ｆ１０４を通じて、ユーザがシステムに対して各種指示を与えるためのデバイスである。出力Ｉ／Ｆ１０６は、データを外部装置に出力するためのインタフェースであり、モニタ１１０やプリンタ１１１等の出力デバイスに対してデータを出力する。ここで、プリンタ１１１は、ローカルプリンタのみならず、ネットワークを通して接続されていてもよい。また、１０７は、上記各種構成要素を相互に接続するシステムバスであり、各構成要素それぞれの間でデータのやりとりを行う。

次に、図１の印刷処理システムの主要な機能構成について、図２を用いて説明する。

図２は本発明の実施形態の印刷処理システムの機能構成を示す図である。

図２では、一般的なコンピュータを用いて実現される印刷処理システムの機能構成を示している。ユーザは、キーボード１０８やポインティングデバイス１０９等の入力デバイスを使用して、出力デバイスであるモニタ１１０に表示されたアプリケーション２０１を使用して作成した文書２０１１の印刷処理を実行する。

ユーザによって印刷処理が実行されると、アプリケーション２０１は、ユーザの印刷操作を解釈する。これにより、文書２０１１の印刷設定２０１２と文書内容の描画データ２０１３を元に、印刷を実行するプリンタ２０７に対応したプリンタドライバ２０６を選択した後、オペレーティングシステム２００に印刷処理の実行を通知する。

オペレーティングシステム２００は、グラフィックスエンジン２０２を通じて、スプールファイル２０３への描画や、指定されたプリンタドライバ２０６への描画を行う。プリンタドライバ２０６は、レンダリングモジュール２０６２によって、機種依存データファイル２０６３を参照して、出力先のプリンタ２０７が解釈できるデータ言語、即ち、プリンタ制御言語に変換する。

プリントマネージャ２０４は、各アプリケーションからの印刷処理のスケジュール管理を行う。プリントマネージャ２０４は、プリンタ２０７が印刷できる状態になったときに、Ｉ／Ｏモジュール２０５を介してプリンタ２０７に印刷ジョブデータ（プリンタ制御言語）を送信する。これにより、印刷が実行される。

文書２０１１の印刷設定２０１２は、プリンタドライバ２０６のコンフィギュレーションモジュール２０６１によって印刷設定の初期値が作成される。そして、コンフィギュレーションモジュール２０６１は、その作成した印刷設定の初期値をアプリケーション２０１もしくはプリンタドライバ２０６のユーザインタフェースに対するユーザ操作に基づいて、ユーザが望む最終印刷結果になるように変更する。

印刷設定２０１２には、２種類の形態があり、１つはＤＥＶＭＯＤＥと呼ばれるバイナリデータ形式のデータ構造体であり、もう１つはプリントチケットと呼ばれるタグを用いたマークアップ言語のテキストデータである。尚、本実施形態では、マークアップ言語をＸＭＬとして説明するが、これに限られる必要はない。この形態は、プリンタドライバ２０６やオペレーティングシステム２００の仕様によって異なる。

次に、オペレーティングシステムが２つのグラフィックスエンジンを搭載している場合の印刷処理システムの機能構成について、図３Ａを用いて説明する。

図３Ａは本発明の実施形態の２つのグラフィックスエンジンを搭載するオペレーティングシステムの印刷処理システムの機能構成を示す図である。

２つのグラフィックエンジンが共存するこのシステムでは、対象とするデータが、その印刷処理経路に応じて、お互いのフォーマットにそれぞれ自動変換されるのが大きな特徴である。そのため、印刷処理経路（プリントパス）は、４つになる。

Ｗｉｎ３２アプリケーション３０１がＧＤＩプリンタドライバ３０９を介して印刷する場合は、次のような処理を行う。まず、Ｗｉｎ３２アプリケーション３０１は、描画データあるＧＤＩ関数をＧＤＩグラフィックスエンジン３０３に対して渡す。ＧＤＩプリンタドライバは、描画データをＥＭＦスプールファイル３０７の形式として受信し、プリンタ制御言語に変換する。このような印刷処理経路をＧＤＩプリントパスと呼ぶ。

一方、ＷＰＦアプリケーション３０２がＸＰＳＤｒｖプリンタドライバ３１０を介して印刷する場合は、次のような処理を行う。まず、ＷＰＦアプリケーション３０２は、ＷＰＦ ＡＰＩ形式データをＷＰＦグラフィックエンジン３０４に対して渡す。ＸＰＳＤｒｖプリンタドライバ３１０は、描画データをＸＰＳスプールファイル３０８の形式として受信し、プリンタ制御言語に変換する。このような印刷処理経路をＸＰＳプリントパスと呼ぶ。尚、ＧＤＩプリントパス及びＸＰＳプリントパスをストレートパスと総称する。

それぞれＧＤＩプリントパスとＸＰＳプリントパスは、図２の通常の印刷処理システムで実行される処理経路である。

これに対し、Ｗｉｎ３２アプリケーション３０１がＸＰＳＤｒｖプリンタドライバ３１０を介して印刷する場合は、ＧＤＩグラフィックスエンジン３０３を経由した後、ＧＤＩｔｏＸＰＳコンバータ３０６で描画データがＥＭＦからＸＰＳに変換される。そして、その変換によって生成されたＸＰＳスプールファイル３０８は、ＸＰＳＤｒｖプリンタドライバ３１０に渡される。この処理経路は、ＧＤＩｔｏＸＰＳプリントパスと呼ばれる。

一方、ＷＰＦアプリケーション３０２がＧＤＩプリンタドライバ３０９を介して印刷する場合は、ＷＰＦグラフィックスエンジン３０４を経由した後、ＸＰＳｔｏＧＤＩコンバータ３０５で描画データがＸＰＳからＥＭＦに変換される。そして、その変換によって生成されたＥＭＦスプールファイル３０７は、ＧＤＩプリンタドライバ３０９に渡される。この処理経路は、ＸＰＳｔｏＧＤＩプリントパスと呼ばれる。尚、ＧＤＩｔｏＸＰＳプリントパス及びＸＰＳｔｏＧＤＩプリントパスをクロスパスと総称する。

このように、ＧＤＩグラフィックスエンジン３０３とＷＰＦグラフィックスエンジン３０４の両方を搭載するシステムにおいては、印刷フォーマットを相互変換するためのコンバータを搭載している。そして、このようなシステム上でのオペレーティングシステムは、これらのコンバータの処理状況に基づいて、自動的に処理対象のデータの処理経路を判定して、必要とする変換を適宜行う。尚、ＧＤＩプリンタドライバ３０９もＸＰＳＤｒｖプリンタドライバ３１０も印刷設定をレジストリに保存する。この場合は、両者のプリンタドライバは、Ｄｅｖｍｏｄｅ形式にて印刷設定を保存する。

次に、ＸＰＳＤｒｖプリンタドライバ３１０の詳細構成について、図３Ｂを用いて説明する。

図３Ｂは本発明の実施形態のＸＰＳＤｒｖプリンタドライバの詳細構成を示す図である。

ＸＰＳＤｒｖプリンタドライバ３１０は、プリントチケットプロバイダ３１０ａ、ＵＩドライバモジュール（ＸＰＳ）３１０ｂを保持している。ＵＩドライバモジュール（ＸＰＳ）３１０ｂは、ＤＥＶＭＯＤＥベースであり、アプリケーションから呼び出されることによって印刷設定情報を設定するためのＵＩを表示する。また、プリントチケットプロバイダ３１０ａは、プリントチケットからＤＥＶＭＯＤＥ、または、ＤＥＶＭＯＤＥからプリントチケットへの変換処理を行う。

図３Ｂでは、Ｗｉｎ３２アプリケーション３０１が、印刷設定を行うためにＤＥＶＭＯＤＥを要求する場合、ＸＰＳＤｒｖプリンタドライバ３１０は、ＤＥＶＭＯＤＥベースのため変換処理の必要が生じない。よって、Ｗｉｎ３２アプリケーション３０１が、ＸＰＳドライバを用いて印刷処理を行う場合、プリントチケットプロバイダ３１０ａは、変換処理を行う必要がない。

一方、ＷＰＦアプリケーション３０２は、印刷設定を行うためプリントチケットを要求する。ＸＰＳＤｒｖプリンタドライバ３１０は、プリントチケットを保持していないため、プリントチケットプロバイダ３１０ａは、プリントチケットからＤＥＶＭＯＤＥへの変換処理を実行する。

ＸＰＳＤｒｖプリンタドライバ３１０は、プリントチケットプロバイダ３１０ａの変換処理を認識することができる。そのため、プリントチケットプロバイダ３１０ａによってプリントチケットからＤＥＶＭＯＤＥへの変換処理が行われた場合、ＸＰＳＤｒｖプリンタドライバ３１０は、印刷設定の要求元がＷｉｎＦＸアプリケーション３０２であると判定できる。一方、印刷対象のデータを受け付けた時に、プリントチケットプロバイダ３１０ａによる変換処理が行われていない場合、ＸＰＳＤｒｖプリンタドライバ３１０は、印刷設定の要求元をＷｉｎ３２アプリケーション３０１と判定できる。

尚、ＧＤＩプリンタドライバ３０９の構造は、ＸＰＳＤｒｖプリンタドライバ３１０と同様であるが、ＵＩドライバモジュール（ＸＰＳ）３１０ｂに相当するものとして、ＵＩドライバモジュール（ＧＤＩ）が構成される。

そして、ＧＤＩプリンタドライバ３０９は、ＸＰＳＤｒｖプリンタドライバ３１０と同様に、プリントチケットプロバイダ３１０ａの変換処理を認識できる。そのため、印刷対象のデータの処理経路及び、印刷設定の要求元のアプリケーションを判定することができる。
尚、ＧＤＩプリンタドライバ３０９も、印刷対象のデータを受け付けた時に、プリントチケットプロバイダ３１０ａによってプリントチケットからＤＥＶＭＯＤＥへの変換処理が行われた場合、印刷設定の要求元がＷｉｎＦＸアプリケーション３０２であると判定できる。一方、プリントチケットプロバイダ３１０ａによる変換処理が行われていない場合、ＸＰＳＤｒｖプリンタドライバ３１０は、印刷設定の要求元をＷｉｎ３２アプリケーション３０１と判定できる。

次に、ＤＥＶＭＯＤＥ構造体のデータ構造について、図４を用いて説明する。

図４は本発明の実施形態のＤＥＶＭＯＤＥ構造体のデータ構造の一例を示す図である。

ＧＤＩプリンタドライバ３０９が印刷設定として使用するのがＤＥＶＭＯＤＥ構造体である。ＤＥＶＭＯＤＥ構造体は大きく分けて２つの設定領域からなる。１つは、オペレーティングシステムで定義されている共通の基本情報を設定する領域であり、これは、パブリック領域と呼ばれる。もうひとつはプリンタドライバが自由に拡張できる領域であり、これはプライベート領域と呼ばれる。

パブリック領域はその中に含まれる情報が何を示すのかについては、オペレーティングシステムのフォーマットとして一般に広く公開されており、どのアプリケーションからも設定を変更することができる。これは、例えば、アプリケーションの「ページ設定」ユーザインタフェースから指定することができる。一方、プライベート領域は、プリンタドライバが自由にデータを拡張できるため、プリンタドライバしか設定することができない。

そこで、プリンタドライバ（コンフィギュレーションモジュールによる）はユーザインタフェース（ＵＩ）を提供して、ユーザに拡張領域の印刷設定を変更することを可能とさせている。

ＤＥＶＭＯＤＥ構造体のパブリック領域には、例えば、デバイス名や全体の構造体のメモリサイズ等のプリンタの基本情報、用紙のサイズや幅・高さ等の用紙の基本情報が格納されている。また、カラー・モノクロや解像度等の印刷品質の基本情報、給紙するカセットや排紙時にどういう順番で排紙を行うか等の給紙・排紙の基本情報が格納されている。

一方、プライベート領域には、パブリック領域の基本情報では持ちきれない項目、例えば、プリンタ固有の機能やミドルウェアが持つ機能、あるいは基本情報で持っている内容のさらに詳細なデータ等のプリンタ特有の情報が格納されている。

次に、プリントチケットのデータ構造について、図５を用いて説明する。

図５は本発明の実施形態のプリントチケットのデータ構造の一例を示す図である。

ＸＰＳＤｒｖプリンタドライバ３１０が印刷設定として使用するのがプリントチケットである。ＤＥＶＭＯＤＥ構造体と同様にプリントチケットにもパブリック領域とプライベート領域がある。しかし、ＸＭＬの形式で記述されたプリントチケットにはＤＥＶＭＯＤＥのように境界線によって領域が分かれているわけではない。この両者は、名前空間と呼ばれる、タグの内部構造における区画に分けられる仕組みによって区別されている。

名前空間は接頭辞としてそれぞれのタグで指定され、接頭辞を持たないタグは名前空間に属さないものとして扱われる。接頭辞はコロン（：）記号の前につけ、ｐｓｆ：Ｆｅａｔｕｒｅのように記述される。この図５にあるプリントチケットには、５個の名前空間が存在し、それぞれが異なった役割を担っている。

ｐｓｆ名前空間は、プリントチケットのフレームワークを定義しているプリントスキーマフレームワークである。プリントチケットとして成り立つ構造を提供するために、ＦｅａｔｕｒｅやＯｐｔｉｏｎ、Ｖａｌｕｅ等の基本的なタグを定義している。Ｆｅａｔｕｒｅはデバイス属性、ジョブフォーマット設定、他の関連する特徴等の機能を定義している。Ｏｐｔｉｏｎは機能に付属するものを定義している。Ｖａｌｕｅは要素の値、ＰａｒａｍｅｔｅｒＩｎｉｔは要素の値の定義と同時に初期値を設定することを定義している。

ｐｓｋ名前空間は、パブリック領域におけるプリントチケットのキーワードを定義している。具体的なキーワードとしては、用紙のサイズを指定するＰａｇｅＭｅｄｉａＳｉｚｅや、印刷部数を指定するＰａｇｅＣｏｐｙＣｏｕｎｔ等がある。

ｐｓｆ名前空間とｐｓｋ名前空間はオペレーティングシステムによってプリントスキーマという形で一般に公開される形で定義されており、アプリケーションは定義に基づき自由にデータを配置することができる。

ｘｓｉ名前空間とｘｓ名前空間は、ＸＭＬスキーマの規格として一般的に定義されているものである。ｘｓｉ名前空間は、ＸＭＬスキーマの組込属性・インスタンスを定義している。ｘｓ名前空間は、ＸＭＬスキーマの既定属性となる。ｎｓ００００名前空間は、プリンタドライバが独自に拡張した名前空間となり、プリンタドライバが独自で持つ機能を記述する。

尚、図４に示すＤＥＶＭＯＤＥ構造体、図５に示すプリントチケットは、例えば、印刷設定情報として、ＲＡＭ１０３上に記憶される。

次に、ＧＤＩグラフィックスエンジンの機能であるラスタオペレーション（ＲＯＰ）について、図６及び図７を用いて説明する。

図６及び図７は本発明の実施形態のＧＤＩグラフィックスエンジンによるラスタオペレーションを説明するための図である。

ＲＯＰとは、ビットマップイメージを転送する場合に、転送元（ソース：Ｓ）のビット、転送先（ディスティネーション：Ｄ）のビット、及びその時点でのブラシパターン（Ｐ）の３つのビットを組み合わせる。そして、それらのビットの組み合わせによって、結果のビットが決定されるような論理演算の描画である。

ここでは、ソースにボールの絵を、ディスティネーションに灰色の背景を用意し、ＢｉｔＢｌｔというＡＰＩでＲＯＰを使用してビットマップ画像を転送した場合の結果を示している。

図６は、ＳＲＣＣＯＰＹというＲＯＰで、ソースのボールのデータ（６０１）でディスティネーションの背景データ（６０２）を上書きしている。このように描画すると、ボールの背景までが残る画像ができあがる（６０３）。

例えば、これを図７のように、ボールのマスク画像（７０１）を用意しておき、まずはＳＲＣＡＮＤというＲＯＰで、ソースとディスティネーションのデータの論理ＡＮＤを行う。すると、マスク部分がくりぬかれた背景画像ができあがる（７０３）。次に、このデータにＳＲＣＰＡＩＮＴというＲＯＰで、ソースのボール画像（７１１）とディスティネーションの背景画像の論理ＯＲを行うと、くりぬかれた部分のみソースがコピーされるので、綺麗にボールの絵だけが残った画像（７１３）ができあがる。

このようにして、論理演算の組み合わせで描画する手法がＲＯＰであり、代表的な使い方がこのマスク処理となる。他にも論理演算の組み合わせは多数あり、ソースとディスティネーションだけだとビットの組み合わせが２の２乗で４通りある。また、この４通りのビットの結果の組み合わせがＲＯＰなので、この場合は、２の４乗で１６通り存在（これをＲＯＰ２と呼ぶ）する。

更に、ブラシパターンが加わると２の３乗の８通りのビットの組み合わせなので、結果の組み合わせは２の８乗で２５６通り（これをＲＯＰ３と呼ぶ）のＲＯＰが存在する。更に、ＲＯＰ３が２つ掛け合わさったＲＯＰ４も存在する。これにより、図６及び図７のようなコピーや透過だけでなく、くり抜きや反転・ミラーの表現を実現することができる。

ここで、図３Ａで説明したＧＤＩｔｏＸＰＳコンバータ３０６について着目する。ＧＤＩｔｏＸＰＳコンバータ３０６は、ＧＤＩの描画データからＸＰＳに変換するが、ＧＤＩの論理演算描画であるＲＯＰは、ＸＰＳの描画フォーマットには存在しない。従って、ＧＤＩｔｏＸＰＳコンバータ３０６は、ＲＯＰを完全にＸＰＳに変換できないケースが存在する。ＸＰＳにはＯｐａｃｉｔｙＭａｓｋという透過を行う描画形式はあるが、これはあくまで画像を透明化させ下に隠れる画像と重ねるという手法にすぎず、ＧＤＩで言うところのアルファブレンドに相当するため、ＲＯＰとは異なる。

マスクをくり抜いたりする用途などで使用される論理演算のＲＯＰの描画を完全に再現するには、描画データの前後関係（ｚオーダ）をすべて把握してピクセル毎に計算を行わなければならない。これは非常に困難な作業であるため、通常、ＧＤＩｔｏＸＰＳコンバータ３０６は、ＲＯＰを削除する動作を行う。ＲＯＰを削除する動作とは、ソースもしくはディスティネーションのどちらかだけの画像にしてしまうことを指す。この場合、図６及び図７のようなボール画像のマスクの場合は、常に、図６のような結果しか得られなくなり、変換後の画像が元画像から欠落してしまう。

また、ＸＰＳｔｏＧＤＩコンバータ３０５の場合は、ＸＰＳにしかない描画手法による描画データは、ＧＤＩにうまく変換することができない。例えば、図８は、ＸＰＳのＲａｄｉａｌＧｒａｄｉｅｎｔＢｒｕｓｈという機能による描画で、同心円状に広がるグラデーション（連続した階調表現）をかけることができる。

一方、ＧＤＩのＧｒａｄｉｅｎｔＦｉｌｌという機能による描画でもグラデーションを実現できるが、直線方向にしか表現できない線形グラデーションなので、同心円状に広がったグラデーションの画像を描画することができない。

他にも、ＸＰＳのＳｔｒｏｋｅ（線）という機能では、線端の形を片方ずつ変えることができる。例えば、図９のように片方の線端を半円に、もう片方の線端を三角形にといった具合である。ＧＤＩのＰｅｎでは線端の形を変えることはできるものの、両端を同時に変更することしかできなかったので、これもＸＰＳのほうが描画の表現力が高い部分になる。

しかしながら、このようなデータを作成しても、ＸＰＳｔｏＧＤＩコンバータ３０５において、直接ＧＤＩの描画に変換することができないのでビットマップに変換せざるをえない。その結果、グラデーションや線等の描画オブジェクトは、ビットマップオブジェクトに変化してしまう。

そのため、ＧＤＩプリンタドライバ３０９がプリンタ制御言語に変換するときには、本来の描画オブジェクトに対して最適なコマンドに変換することができずに、すべてイメージデータとして扱わなければならなくなってしまう。また、ＧＤＩプリンタドライバ３０９が拡大縮小を伴うようなレイアウト変更を行う場合は、ビットマップを拡大縮小するために、画像のエッジが荒くぎざぎざになってしまう、いわゆる、ジャギーの現象が起こる。

このように、アプリケーションが印刷するときに選択するプリンタドライバによっては、コンバータによるスプールファイルの変換が行われ、描画がうまく変換されず、ユーザの意図する出力結果を得られなくなる恐れがある。尚、スプールファイルの変換は、ＥＭＦ形式からＸＰＳ形式への変換、または、ＸＰＳ形式からＥＭＦ形式への変換である。

そこで、本発明では、この描画がうまく変換されないような状態において、その旨をユーザに警告として通知して、その状態を印刷前にユーザに認知させるとともに、最終的な印刷を実行するか否かの機会を提供する構成について説明する。

以下、本発明の印刷処理システムの特徴的な構成を説明するにあたり、まず、その動作シーケンスについて、図１０を用いて説明する。

図１０は本発明の実施形態の印刷処理システムの動作シーケンスを示す図である。

図１０では、Ｗｉｎ３２アプリケーション３０１からＸＰＳＤｒｖドライバ３１０を介して印刷を行う場合、つまり、ＧＤＩｔｏＸＰＳコンバータ３０６経由の動作シーケンスを示している。

まず、ユーザは、Ｗｉｎ３２アプリケーション３０１に対して印刷設定を行う（１００１）。ここで、Ｗｉｎ３２アプリケーション３０１は、ＸＰＳＤｒｖプリンタドライバ３１０のコンフィギュレーションモジュールを呼び出し、ＸＰＳＤｒｖプリンタドライバ３１０のドライバユーザインタフェース（ＵＩ）を開く（１００２）。ここで、印刷設定を行うために、ＸＰＳＤｒｖプリンタドライバ３１０は、Ｗｉｎ３２アプリケーション３０１からＤＥＶＭＯＤＥ構造体が渡されることになる。

但し、ＸＰＳＤｒｖプリンタドライバ３１０が本来正しく印刷できるのはＸＰＳフォーマットの印刷設定、つまり、ＰｒｉｎｔＴｉｃｋｅｔ（プリントチケット）を受け取った時である。そのため、ＤＥＶＭＯＤＥ構造体が渡された時点で、ＸＰＳＤｒｖプリンタドライバ３１０は、Ｗｉｎ３２アプリケーション３０１からの印刷であると判別できる。

このような場合、ＸＰＳＤｒｖプリンタドライバ３１０は、まず、図１１の警告メッセージを表示する（１００３）。その後、図１１のＯＫボタンが押されると、ユーザは、ＸＰＳＤｒｖプリンタドライバ３１０のドライバユーザインタフェースを使って印刷設定を行う（１００４）。

ここで、本実施形態におけるＸＰＳＤｒｖプリンタドライバ３１０のユーザインタフェースには、警告設定画面１２００（図１２）において、描画変換時の警告設定を行うことができる（１００５）。つまり、ＸＰＳＤｒｖプリンタドライバ３１０は、ＤＥＶＭＯＤＥ構造体が渡されることにより、クロスパスであると判定して、第１警告を行う。さらに後述する図１４及び図１７にて後述する処理により描画不正が起きると判定した場合に、ＸＰＳＤｒｖプリンタドライバ３１０は、第２警告を行う。

また、後述するが図１０はＸＰＳＤｒｖプリンタドライバ３１０を主体として説明している。よって、ＧＤＩプリンタドライバ３０９が主体となる場合には処理が変更される。例えば、ＧＤＩプリンタドライバ３０９は、プリントチケットを渡されることにより、クロスパスであると判定して第１警告を行う。また、ＧＤＩプリンタドライバ３０９は、図１４及び図１８にて後述する処理により描画不正が起きると判定した場合に、第２警告を行う。

ここで、警告設定画面１２００について、図１２を用いて説明する。

図１２は本発明の実施形態の警告設定画面の一例を示す図である。

この警告設定画面は、警告方法を設定するための各種コントロール（ラジオボタン、チェックボックス等）で構成されている。

警告の種類は、大きく分類すると「警告タイミング」（項目１２０１）と「警告内容」（項目１２０２）という２つの内容がある。

警告タイミングは、描画変換時にどのようなときに警告するかを決めるものである。ここでは、「警告しない」（項目１２０１ａ）、「描画変換した際に描画が不自然なときのみ警告する」（項目１２０１ｂ）、及び「描画変換するときは常に警告する」（項目１２０１Ｃ）の３種類のいずれか１つを選択することできる。

警告内容は、描画変換時に行う動作であり、描画変換時に「プレビューを強制的に表示させユーザに確認させる」か否かを指定するためのフィールド１２０２ａがある。また、「印刷後のデータに強引にスタンプをつける」か否かを指定するためのフィールド１２０２ｂがある。

また、「印刷後のデータに強引に地紋（用紙に印刷されている薄い模様のことで、コピーを行うと潜像している文字が浮き出てくるもの、主にコピー防止のために用いる）をつける」か否かを指定するためのフィールド１２０２ｃがある。また、「印刷時に警告メッセージを表示する」、「印刷後のデータの最初のページの前に、警告文字が載った紙を印刷する」、「常にエラーにして印刷しない」を実行するか否かを指定するためのフィールド１２０２ｄがある。

また、「プリンタに描画変換した旨を伝える」、「アプリケーションに描画変換した旨を伝える」等の通知に関する設定を指定するためのフィールド１２０２ｅがある。

また、複数部数印刷する際の設定を指定するためのフィールド１２０２ｆがある。ここでは、上記の各種の警告設定による警告方法で、複数部数印刷する場合においては、１部目のみ警告を行い、後は印刷することなくプリンタの記憶領域に保持しておくという機能である。

図１２では、「描画変換するときは常に警告する」と「プレビューする」が選択されている状態を示している。

そして、この状態でＯＫ１２０３ボタンを操作すると、図１２中の設定状態（警告設定情報）が印刷設定情報の一部として、例えば、ＲＡＭ１０３上に記憶されるとともに、警告設定画面１２００の表示が消去される。一方、キャンセルボタン１２０４を操作すると、図１２中の設定状態がキャンセルされて、この警告設定画面１２００の表示が消去される。

更に、適用ボタン１２０５ボタンを操作した場合には、図１２中の設定状態が警告設定情報として、一旦ＲＡＭ１０３上に記憶されるが、警告設定画面１２００の表示は維持される。そのため、必要に応じて、引き続き警告設定操作を続行することが可能となる。

図１０の説明に戻る。

ＸＰＳＤｒｖプリンタドライバ３１０のコンフィギュレーションモジュール（ＵＩ）は、印刷設定も警告設定も、どちらもＤＥＶＭＯＤＥ構造体に保存する。そして、ユーザインタフェースを閉じる（１００６）。

次に、ユーザは、作成したＤＥＶＭＯＤＥ構造体を元に印刷を指示する（１００７）。ここでのアプリケーションは、Ｗｉｎ３２アプリケーション３０１であるので、ＧＤＩグラフィックスエンジン３０３を用いて描画を行う（１００８）。ここで、印刷対象の画像は、例えば、図１３に示す画像であるとする。描画命令を受けたオペレーティングシステムは、ＸＰＳＤｒｖプリンタドライバ３１０に対しての描画であることがわかるため、ＧＤＩｔｏＸＰＳコンバータ３０６の処理を開始する。

まず、ＸＰＳＤｒｖプリンタドライバ３１０は、印刷設定であるＤＥＶＭＯＤＥ構造体をＰｒｉｎｔＴｉｃｋｅｔに変換する。ＸＰＳＤｒｖプリンタドライバ３１０は、ＸＰＳＤｒｖプリンタドライバ３１０内のコンフィギュレーションモジュール（ＵＩ）を呼び出し、ＤＥＶＭＯＤＥ構造体を渡す（１００９）。

コンフィギュレーションモジュールは、ここでＰｒｉｎｔＴｉｃｋｅｔに変換を行うが、同時にＰｒｉｎｔＴｉｃｋｅｔの中に「ＤＥＶＭＯＤＥ構造体からの変換」であることを示す変換フラグを追加する（１０１０）。ここでは、「ｎｓ０００：ＪｏｂＣｏｎｖｅｒｔ」のＦｅａｔｕｒｅを「ｎｓ０００：Ｏｎ」というＯｐｔｉｏｎでＰｒｉｎｔＴｉｃｋｅｔに追加する。そして、ＸＰＳＤｒｖプリンタドライバ３１０は、生成したＰｒｉｎｔＴｉｃｋｅｔをＧＤＩｔｏＸＰＳコンバータ３０６に返す（１０１１）。

ＧＤＩｔｏＸＰＳコンバータ３０６は、ＧＤＩの描画命令をＸＰＳに変換する（１０１２）。ここで、描画データにＲＯＰが含まれている場合は、ＲＯＰ処理が失われる。例えば、処理対象である図１３の画像中の背景画像として描かれている世界地図は、マスクのＲＯＰで描画されているため、この背景画像の部分がうまくマスクした透過画像にならず、そのまま重ね合わせた描画が行われることになる。

次に、ＧＤＩｔｏＸＰＳコンバータ３０６は、変換処理によって得られるＸＰＳをＸＰＳＤｒｖプリンタドライバ３１０に渡す（１０１３）。Ｗｉｎ３２アプリケーション３０１は、このタイミングで印刷処理から開放され（１０１４）、次の処理を行うことができるようになる。

一方、ＸＰＳＤｒｖプリンタドライバ３１０は、受け取ったＸＰＳに対し、レンダリング部（レンダリングモジュール）による処理を実行するとともに、警告設定情報に従って、各種警告処理を実行する。

例えば、ＰｒｉｎｔＴｉｃｋｅｔ中の変換フラグがＯＮで、警告設定情報に警告内容をプレビューすることが指定されている場合、ＸＰＳＤｒｖプリンタドライバ３１０は、レンダリングによって得られる画像をプレユーとして出力する（１０１５）。

また、ＰｒｉｎｔＴｉｃｋｅｔ中の変換フラグがＯＮで、警告設定情報に警告メッセージを出力することが指定されている場合、ＸＰＳＤｒｖプリンタドライバ３１０は、警告メッセージ（ダイアログ）を出力する（１０１６）。

その後、ＸＰＳＤｒｖプリンタドライバ３１０は、ＸＰＳをＰＤＬに変換し（１０１７）、変換したＰＤＬをプリンタに送信する（１０１８）。これにより、印刷終了通知がオペレーティングシステムへ送信され、処理が終了する（１０１９）。このように、ＸＰＳＤｒｖプリンタドライバ３１０は、プリントチケットに、ＤｅｖＭｏｄｅから変換したことを示すフラグが設定されていた場合、印刷依頼元をＷｉｎ３２アプリケーション３０１と判定できる。この場合、ＸＰＳＤｒｖプリンタドライバ３１０は、描画不正や印刷機能の低下とうが考えられるため、図１２の設定に従って警告すべきか否かを決定する。

次に、ＸＰＳＤｒｖプリンタドライバ３１０のレンダリング部（レンダリングモジュール）による処理（図１０の１０１５〜１０１７）の詳細に関して、図１４を用いて説明する。

図１４は本発明の実施形態のＸＰＳＤｒｖプリンタドライバのレンダリング部による処理の詳細を示すフローチャートである。

ＸＰＳが渡されたＸＰＳＤｒｖプリンタドライバ３１０は、まず、印刷設定であるＰｒｉｎｔＴｉｃｋｅｔ内にある「ｎｓ０００：ＪｏｂＣｏｎｖｅｒｔ」の変換フラグがＯＮであるか否かを判定する（ステップＳ１１０２）。これにより、ＧＤＩｔｏＸＰＳ変換が行われたか否かがわかる。
ＸＰＳＤｒｖプリンタドライバ３１０は、ＰｒｉｎｔＴｉｃｋｅｔ内の変換フラグがＯＮでない場合（ステップＳ１１０２でＮＯ）、ＷＰＦアプリケーション３０２からの印刷と判定し、通常の印刷処理を実行する（ステップＳ１１０９）。つまり、ＸＰＳＤｒｖプリンタドライバ３１０が、印刷依頼元がＷＰＦアプリケーション３０２であると判定した場合、描画不正や印刷機能の低下が発生する恐れがないと判定できるため、特に警告処理を行うことなく印刷処理を実行する。

一方、変換フラグがＯＮである場合（ステップＳ１１０２でＹＥＳ）、ＸＰＳＤｒｖプリンタドライバ３１０は、ＰｒｉｎｔＴｉｃｋｅｔの中にある「警告タイミング」が記述されたＦｅａｔｕｒｅを参照し、警告の有無及びその条件を判定する（ステップＳ１１０３）。

警告を行わない場合（ステップＳ１１０３でＮＯ）、ＷＰＦアプリケーション３０２からの印刷と判定し、通常の印刷処理を実行する（ステップＳ１１０９）。一方、警告を行う場合（ステップＳ１１０３でＹＥＳ）、ＸＰＳＤｒｖプリンタドライバ３１０は、警告の条件として、常に警告を行うか否かを判定する（ステップＳ１１０４）。警告の条件が常に警告を行う場合（ステップＳ１１０４でＹＥＳ）、ステップＳ１１０６に進む。

一方、警告の条件が常に警告を行わない場合（ステップＳ１１０４でＮＯ）、警告の条件が「描画変換した際に描画が不自然なときのみ警告する」ことになる。そこで、これを実行するために、ＸＰＳＤｒｖプリンタドライバ３１０は、レンダリング部での画像の描画が不自然な状態であるか否かを判定する（ステップＳ１１０５）。

つまり、ＸＰＳＤｒｖプリンタドライバ３１０は、Ｗｉｎ３２アプリケーション３０１からの印刷指示に応じて、ＧＤＩ関数をＷＰＦ ＡＰＩ形式データへデータ変換する。そして、ＸＰＳＤｒｖプリンタドライバ３１０へ出力する場合に、ＷＰＦ ＡＰＩ形式データの描画状態を判定する。ＸＰＳＤｒｖプリンタドライバ３１０が、描画が不自然な状態でないと判定した場合（ステップＳ１１０５でＮＯ）、ＷＰＦアプリケーション３０２からの印刷と判定し、通常の印刷処理を実行する（ステップＳ１１０９）。一方、描画が不自然な状態である場合（ステップＳ１１０５でＹＥＳ）、ステップＳ１１０６に進む。

ステップＳ１１０５での判定は、ＧＤＩからＸＰＳに変換するにあたっての描画が不自然であるか否かを判定することになる。具体的には、ＲＯＰが削除された形跡があるかどうかで判定する。すべてのＲＯＰが削除されたかどうかの判定はできないが、大半のＲＯＰはマスク処理に使用されているため、例えば、「周りがビットマップであり、黒もしくは白の単色で描かれているものが中にあるもの」を検出したら、描画が不自然であると判定する。

ここで、黒もしくは白と限定しているのは、ＲＯＰ処理による論理演算においてマスクを行うには黒もしくは白の単色である必要があるためである。但し、この判定方法においてもＲＯＰが削除されたかどうかの厳密な判定はできないので、あくまで警告を出すという目的での判定ロジックとなる。

図１７を用いて、ステップＳ１１０５の処理の詳細な処理を説明する。

ＸＰＳＤｒｖプリンタドライバ３１０は、描画部を介して受信したＸＰＳのビットマップデータを解析する（ステップＳ１７０１）。

ＸＰＳＤｒｖプリンタドライバ３１０は、受信したＸＰＳに特定の色と任意の色の２色の組み合わせで表現されているビットマップデータが含まれているか否かを判定する（ステップＳ１７０２）。

詳細には、ＸＰＳＤｒｖプリンタドライバ３１０は、黒と任意の色の２色の組み合わせ、または、白と任意の色の２色の組み合わせから構成されるビットマップデータが受信したＸＰＳに含まれているか否かを判定する。

特定の色と任意の色の２色の組み合わせで表現されているビットマップデータが含まれていると判定された場合（ステップＳ１７０２でＹＥＳ）、ＸＰＳＤｒｖプリンタドライバ３１０は、受信したＸＰＳは不自然な状態であると判定する（ステップＳ１７０３）。そして、ステップＳ１１０６へと処理を進める。

一方、特定の色と任意の色の２色の組み合わせで表現されているビットマップデータが含まれていないと判定された場合（ステップＳ１７０２でＮＯ）、ＸＰＳＤｒｖプリンタドライバ３１０は、受信したＸＰＳは自然な状態であると判定する（ステップＳ１７０４）。そして、警告表示処理は、実行されずに印刷用にプリンタが解釈可能な印刷データを生成する。

このようにＸＰＳＤｒｖプリンタドライバ３１０は、ＷＰＦ ＡＰＩ形式データに特定の色と任意の色の２色に基づいて表現されているビットマップデータが含まれていると判定した場合に、描画状態が不正であると判定する。このような処理を印刷前に実行して、ユーザに提示するため、ユーザは印刷処理を実行する前に描画不正が発生することを認識することができる。

ステップＳ１１０４あるいはステップＳ１１０５の処理を経た後は、警告内容として、警告時にプレビューを表示するか否かを判定するために、ＸＰＳＤｒｖプリンタドライバ３１０は、警告時のプレビューがＯＮであるか否かを判定する。つまり、図１２の警告設定画面１２００中のフィールド１２０２ａで「プレビューする」（プレビューがＯＮ）が指定されているか否かを判定する。

警告時のプレビューがＯＮでない場合（ステップＳ１１０６でＮＯ）、図１２の警告設定画面１２００中の警告内容フィールド１２０２に設定されている設定項目に従って、ＸＰＳＤｒｖプリンタドライバ３１０は、各種処理を実行する（ステップＳ１１１２）。この各種処理には、例えば、警告メッセージの表示、警告用紙の挿入、スタンプ処理、地紋処理、通知処理等がある。そして、その警告内容及びその処理結果に基づいて、印刷処理を実行する（ステップＳ１１１０）、あるいは印刷処理を中止する（ステップＳ１１１１）。

一方、警告時のプレビューがＯＮである場合（ステップＳ１１０６でＹＥＳ）、ＸＰＳＤｒｖプリンタドライバ３１０は、描画した画像のプレビュー画面（図１５）を出力する（ステップＳ１１０７）。つまり、Ｓ１１０５にて判定したＷＰＦ ＡＰＩ形式データの描画状態に従って、警告情報を出力する。

次に、ＸＰＳＤｒｖプリンタドライバ３１０は、プレビュー画面中の印刷ボタンが押下されたか否かを判定する。印刷ボタンが押下された場合（ステップＳ１１０８でＹＥＳ）、印刷処理を実行する。一方、中止ボタンが押下された場合（ステップＳ１１０８でＮＯ）、ＸＰＳＤｒｖプリンタドライバ３１０は、印刷処理を中止する（ステップＳ１１１１）。

次に、図１４の処理における具体例について説明する。

本実施形態では、図１２において、「描画変換するときは常に警告する」（フィールド１２０１ｃ）を選択している。そのため、ＸＰＳＤｒｖプリンタドライバ３１０は、描画が不自然な状態であるか否かの判定は行わずに、ステップＳ１１０４からステップＳ１１０６以降の処理に進み、警告を行うことになる。

また、図１２において、「プレビューする」を選択しているので、ＸＰＳＤｒｖプリンタドライバ３１０は、受信したＸＰＳスプールファイルに基づくプレビュー画像（図１５）を出力する（ステップＳ１１０７）。

ここで、このプレビュー画像を出力するプレビュー画面について、図１５を用いて説明する。

図１５は本発明の実施形態のプレビュー画面の一例を示す図である。

このプレビュー画面１５００を生成するにあたっては、印刷対象の画像の「描画が不自然な状態であるか否か」を判定する。そして、不自然な領域がある場合には、その対象領域を他の領域と識別可能にするために、例えば、所定色（例えば、赤）の矩形枠１５０１〜１５０４等で表示する。

詳細には、特定の色と任意の色の２色の組み合わせで表現されているビットマップデータを不自然な領域として、そのビットマップデータを所定の色の矩形枠で囲んで表示する。具体的には、黒と任意の色の２色の組み合わせ、または、白と任意の色の２色の組み合わせで表現されているビットマップデータを指す。

これにより、ユーザは、印刷を最終的に実行する前に、描画（印刷）が不自然となる可能性のある領域を容易に識別することが可能となる。この矩形枠の表示は、警告表示ボタン１５１１を押下する毎に、その表示／非表示をサイクリックに行うことが可能となる。

また、この表示内容で印刷を許容する場合には、印刷ボタン１５１０を押下することで、印刷処理を実行することができる。一方、印刷を中止する場合には、中止ボタン１５１２を押下することで、印刷処理を中止することができる。

さて、プレビュー画面１５００では、図１３の背景にある世界地図のマスクの画像が、ＲＯＰが削除されたことにより単色ビットマップの黒ぬき画像となっているので、この画像領域が所定色の矩形枠１５０１等として警告表示されている。

尚、警告設定画面１２００（図１２）において、「描画するときは常に警告する」（フィールド１２０２ａ）を指定している場合には、印刷処理前に、常にプレビュー画面１５００が表示されることになる。一方、「描画変換した際に描画が不自然なときのみ警告する」（フィールド１２０１ｂ）を指定している場合には、印刷ジョブ全体においてひとつでも不自然と判定される部分が存在した場合に、プレビュー画面１５００を表示する。尚、図１７に記載した処理は、「描画変換した際に描画が不自然なときのみ警告する」が選択されたときに実行される。

また、どちらの場合でも不自然と判定された領域がある最初のページをプレビューとして最初に表示する。この時点でユーザが望んだ印刷でなければ、プレビュー画面１５００上で中止ボタン１５１２を押下することにより印刷を中止することができる。

また、「プレビューしない」に指定されているものの、「警告メッセージを表示する」が指定されている場合は、プレビュー画面１５００は表示しないが、警告メッセージ１６００（図１６）が表示されることになる。そして、この警告メッセージ１６００において、中止ボタン１６０２を押下することにより印刷を中止することができる。一方、印刷を続行する場合には、ＯＫボタン１６０１を押下する。

また、「警告スタンプをつける」（フィールド１２０２ｂ）や「警告地紋つける」（フィールド１２０２ｃ）を選択している場合は、ユーザによって選択されたスタンプや地紋等の選択画像を強制的に印刷後の文書に付加する。これにより、実際に印刷された後に、描画が不自然な領域が存在することをユーザに警告することが可能となる。また、この選択画像の付加については、最初のページだけに付加するか、すべてのページに付加するかを指定することもできる。

また、「最初のページに警告用紙を印刷する」（フィールド１２０２ｄ）を選択している場合は、印刷文書の前に１ページの警告文が載った用紙を印刷する。換言すれば、警告文を印刷するための印刷データを、印刷対象の印刷データの先頭に追加する。

また、「常にエラーにして印刷しない」（フィールド１２０２ｄ）を選択している場合は、描画変換を行った際に実際に印刷を行うことなく常にエラーとする。つまり、印刷処理を禁止する。

「プリンタに通知する」（フィールド１２０２ｅ）を選択している場合は、プリンタドライバは、印刷先のプリンタへ描画変換した旨を通知する（警告イベント）。プリンタは、その警告イベントを検出したら、描画変換されている印刷ジョブであることを認識できる。そのため、条件に応じて、その受信する印刷ジョブを直ちに印刷しないでキューに一旦溜めておき、指示があるまで印刷を保留しておくこともできる。

また、「アプリケーションに通知する」（フィールド１２０２ｅ）を選択している場合は、プリンタドライバは、アプリケーションへ描画変換した旨を通知する。アプリケーションは、プリンタドライバから警告イベントを受信した場合は、使用するプリンタドライバを変更することで、描画変換が発生しないように印刷を実行することが可能になる。

尚、図１２の警告設定画面１２００で構成されている警告条件及び警告方法は、任意に組み合わせて設定することが可能で、描画変換時の劣化に対して、ユーザが自由に警告の種類を選択することができる。また、これらの警告はあくまで描画変換時にのみ起こす警告であるため、Ｗｉｎ３２アプリケーションがＧＤＩプリンタドライバに印刷するとき、またＷＰＦアプリケーションがＸＰＳＤｒｖプリンタドライバに印刷するときには影響しない。

ＸＰＳからＧＤＩの変換の場合は、これまでと逆のロジックで動作する。即ち、ＰｒｉｎｔＴｉｃｋｅｔからＤＥＶＭＯＤＥに変換する際に、ＤＥＶＭＯＤＥのプライベート領域にＰｒｉｎｔＴｉｃｋｅｔから変換したことを示す変換フラグをＯＮにしておく。また、ＤＥＶＭＯＤＥに警告設定情報を保持しておく。ＸＰＳｔｏＧＤＩコンバータにより描画を変換した結果、完全に変換できず不自然な状態になるのは、上述のように、ＸＰＳでは表現できるがＧＤＩでは表現できない内容である。尚、この場合の主体は、ＧＤＩプリンタドライバ３０９となる。

即ち、ＷＰＦは、ＷＰＦアプリケーション３０２からの印刷指示に応じて、ＷＰＦ ＡＰＩ形式のデータを出力する。ＸＰＳｔｏＧＤＩコンバータ３０５は、ＧＤＩ関数に変換して、ＧＤＩプリンタドライバ３０９へ出力する。この場合に、ＧＤＩプリンタドライバ３０９は、ＧＤＩ関数の描画状態を判定する。尚、詳細な判定方法は、図１８にて後述する。ＧＤＩプリンタドライバ３０９は、判定したＧＤＩ関数の描画状態に従って、警告情報を出力する。

上述したように、ＷｉｎＦＸアプリケーションが生成した描画データは、すべてビットマップ画像としてＧＤＩプリンタドライバ３０９には渡されてくる。そのため、ＧＤＩプリンタドライバ３０９は、「単色あるいは色数がそれほど多くないビットマップが渡された場合」を不自然な状態と判定する。

これ以外に、「ビットマップ内部に黒によるエッジが見られる場合」、「ビットマップ内部の単色エッジが、隣接するグラフィックス図形と連続する場合」を不自然な状態と判定することも可能である。また、多くの場合、線オブジェクトはグラフィックコマンドとしてプリンタドライバに通知される。しかしながら、ＸＰＳからＧＤＩに変換する場合には、全てビットマップ画像として通知されるため、ビットマップデータ内に線オブジェクトが含まれることもある。この場合も、ＧＤＩプリンタドライバ３０９は、不自然な状態であると判定する。

続いて、ＧＤＩプリンタドライバ３０９が、描画が不自然な状態であると判定する場合の処理について、図１８を用いて説明する。

ＧＤＩプリンタドライバ３０９は、ビットマップデータを受信する（ステップＳＳ１８０１）。受信されたビットマップデータ内に特定のオブジェクトが含まれているか否かを判定する（ステップＳ１８０２）。尚、特定のオブジェクトの代表例としては、線オブジェクトが挙げられる。即ち、ＧＤＩプリンタドライバ３０９は、ビットマップデータ内に線オブジェクトを検出した場合に、描画が不自然な状態であると判定する（ステップＳ１８０３）。

また、ＧＤＩプリンタドライバ３０９が、ビットマップデータ内に特定のオブジェクトが含まれていないと判定した場合、描画が自然な状態であると判定する（ステップＳ１８０４）。そして、通常どおり印刷処理を実行する。

ＧＤＩプリンタドライバ３０９は、ＧＤＩ関数に含まれるビットマップデータに特定のオブジェクトが含まれていると判定した場合に、ＧＤＩ関数の描画状態が不正であると判定し、ユーザに警告することができる。このような処理を印刷前に実行して、ユーザに提示するため、ユーザは印刷処理を実行する前に描画不正が発生することを認識することができる。

そして、これらを描画が不自然な状態と判定するのは、通常、このような簡易な描画を、ビットマップを使用して描画することは少なく、ストローク（線）や四角や円等の命令を使用するのが自然であるという理論に基づくものである。

そして、ＧＤＩからＸＰＳに変換するときと同じように警告を行うことで、ＧＤＩドライバでも描画変換時にプレビューで警告表示を行ったり、警告の印刷を行ったりすることが可能となる。

このようにして、ユーザに描画変換が行われたことを認知させ、画像劣化がない印刷を導くことができる。

以上説明したように、本実施形態によれば、ユーザはアプリケーションが印刷時に使用するグラフィックスエンジンに最適なプリンタドライバを確認することができ、画像情報が欠落した印刷を防ぐことが可能になる。また、印刷を行った場合に画像が欠けていたとしても、描画変換が理由で画像情報が欠落していることがわかるため、ユーザが早く問題を認識させることが可能となる
以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスクがある。また、更に、記録媒体としては、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、その接続先のホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。また、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。

本発明の実施形態の印刷処理システムのブロック構成図である。 本発明の実施形態の印刷処理システムの機能構成を示す図である。 本発明の実施形態の２つのグラフィックスエンジンを搭載するオペレーティングシステムの印刷処理システムの機能構成を示す図である。 本発明の実施形態のＸＰＳＤｒｖプリンタドライバの詳細構成を示す図である。 本発明の実施形態のＤＥＶＭＯＤＥ構造体のデータ構造の一例を示す図である。 本発明の実施形態のプリントチケットのデータ構造の一例を示す図である。 本発明の実施形態のＧＤＩグラフィックスエンジンによるラスタオペレーションを説明するための図である。 本発明の実施形態のＧＤＩグラフィックスエンジンによるラスタオペレーションを説明するための図である。 本発明の実施形態のＸＰＳ特有の描画方法による描画例を説明するための図である。 本発明の実施形態のＸＰＳ特有の描画方法による描画例を説明するための図である。 本発明の実施形態の印刷処理システムの動作シーケンスを示す図である。 本発明の実施形態の警告メッセージの一例を示す図である。 本発明の実施形態の警告設定画面の一例を示す図である。 本発明の実施形態の印刷対象画像の一例を示す図である。 本発明の実施形態のＸＰＳＤｒｖプリンタドライバのレンダリング部による処理の詳細を示すフローチャートである。 本発明の実施形態のプレビュー画面の一例を示す図である。 本発明の実施形態の警告メッセージの一例を示す図である。 本発明の実施形態の描画不正の解析フローチャートを示す図である。 本発明の実施形態の描画不正の解析フローチャートを示す図である。

符号の説明

１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ 入力インタフェース
１０５ 外部記憶装置
１０５１ アプリケーション
１０５２ 印刷関連プログラム
１０５３ プリンタドライバ
１０５４ オペレーティングシステム
１０６ 出力インタフェース
１０７ システムバス
１０８ キーボード
１０９ ポインティングデバイス
１１０ モニタ
１１１ プリンタ

Claims (23)

1. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置であって、
   前記第１アプリケーションからの印刷指示に応じて作成された前記第１描画データから変換された第２描画データの描画状態が不自然である場合、警告情報として前記第２描画データに基づくプレビュー画面を表示すると共に、前記描画状態が不自然であると判定された前記第２描画データ中の領域については他の領域と識別可能に表示する出力手段と
   を備えることを特徴とする情報処理装置。
2. 前記データ変換が行われた際の警告方法を設定する設定手段を更に備え、
   前記出力手段は、前記設定手段によって設定された警告方法と前記第２描画データの描画状態とに従って警告情報を出力する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記プレビュー画面は、前記印刷データの印刷処理の実行を指示する第１指示部と、前記印刷処理の中止を指示する第２指示部とを備える
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記設定手段は、前記警告方法として、前記第２描画データに基づく印刷データのプレビュー画面の出力の可否を設定する
   ことを特徴とする請求項２または３のいずれか１項に記載の情報処理装置。
5. 前記設定手段は、前記警告方法として、指定されたスタンプ画像を前記第２描画データに基づく印刷データへの付加の可否、または、指定された地紋画像を前記第２描画データに基づく印刷データへの付加の可否を設定する
   ことを特徴とする請求項２乃至４のいずれか１項に記載の情報処理装置。
6. 前記設定手段は、前記警告方法として、警告メッセージの出力の可否、または、印刷の禁止の可否を設定する
   ことを特徴とする請求項２乃至５のいずれか１項に記載の情報処理装置。
7. 前記設定手段は、前記警告方法として、指定された印刷データの、前記第２描画データに基づく印刷データの先頭への追加の可否を設定する
   ことを特徴とする請求項２乃至６のいずれか１項に記載の情報処理装置。
8. 前記設定手段は、前記警告方法として、前記データ変換が行われた旨の、出力先のプリンタへの通知の可否、または、前記データ変換が行われた旨の、前記第１アプリケーションへの通知の可否を設定する
   ことを特徴とする請求項２乃至７のいずれか１項に記載の情報処理装置。
9. 前記設定手段は、前記警告方法として、複数部数が指定された印刷ジョブで、１部目の印刷に対してのみ指定された警告方法を適用し、それ以降の部の印刷ジョブについては、出力先のプリンタで保持することの可否を設定する
   ことを特徴とする請求項２乃至８のいずれか１項に記載の情報処理装置。
10. 前記第２描画データに特定の色と任意の色の２色に基づいて表現されているビットマップデータが含まれていると判定した場合、または、前記第２描画データに含まれるビットマップデータに特定のオブジェクトが含まれていると判定した場合、前記第２描画データの描画状態が不自然であると判定する判定手段を更に有し、
    前記出力手段は、前記不自然であると判定された第２描画データを前記設定手段によって設定された警告方法に従って表示する
    ことを特徴とする請求項２乃至９のいずれか１項に記載の情報処理装置。
11. 前記出力手段は、前記第１アプリケーションからの印刷指示に応じて、前記第１描画データを前記第２描画データへデータ変換して、前記第２プリンタドライバへ出力する場合に、第１警告を出力する第１警告手段と、
    前記判定手段により前記第２描画データの描画状態が不自然であると判定された場合、前記設定手段により設定された警告方法に従って第２警告を出力する第２警告手段と
    を備えることを特徴とする請求項１０に記載の情報処理装置。
12. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置の制御方法であって、
    前記第１アプリケーションからの印刷指示に応じて作成された前記第１描画データから変換された第２描画データの描画状態が不自然である場合、警告情報として前記第２描画データに基づくプレビュー画面を表示すると共に、前記描画状態が不自然であると判定された前記第２描画データ中の領域については他の領域と識別可能に表示する出力工程と
    を備えることを特徴とする情報処理装置の制御方法。
13. 第１アプリケーションからの印刷指示に応じて、第１プリンタドライバが処理可能な第１描画データを生成する第１描画部と、第２アプリケーションからの印刷指示に応じて、第２プリンタドライバが処理可能な第２描画データを生成する第２描画部とが動作する情報処理装置の制御をコンピュータに実行させるためのプログラムであって、
    前記第１アプリケーションからの印刷指示に応じて作成された前記第１描画データから変換された第２描画データの描画状態が不自然である場合、警告情報として前記第２描画データに基づくプレビュー画面を表示すると共に、前記描画状態が不自然であると判定された前記第２描画データ中の領域については他の領域と識別可能に表示する出力工程をコンピュータに実行させる
    ことを特徴とするプログラム。
14. 前記データ変換が行われた際の警告方法を設定する設定工程を更に備え、
    前記出力工程は、前記設定工程によって設定された警告方法と前記第２描画データの描画状態とに従って警告情報を出力する
    ことを特徴とする請求項１３に記載のプログラム。
15. 前記プレビュー画面は、前記印刷データの印刷処理の実行を指示する第１指示部と、前記印刷処理の中止を指示する第２指示部とを備える
    ことを特徴とする請求項１３または１４に記載のプログラム。
16. 前記設定工程は、前記警告方法として、前記第２描画データに基づく印刷データのプレビュー画面の出力の可否を設定する
    ことを特徴とする請求項１４または１５のいずれか１項に記載のプログラム。
17. 前記設定工程は、前記警告方法として、指定されたスタンプ画像を前記第２描画データに基づく印刷データへの付加の可否、または、指定された地紋画像を前記第２描画データに基づく印刷データへの付加の可否を設定する
    ことを特徴とする請求項１４乃至１６のいずれか１項に記載のプログラム。
18. 前記設定工程は、前記警告方法として、警告メッセージの出力の可否、または、印刷の禁止の可否を設定する
    ことを特徴とする請求項１４乃至１７のいずれか１項に記載のプログラム。
19. 前記設定工程は、前記警告方法として、指定された印刷データの前記第２描画データに基づく印刷データの先頭への追加の可否を設定する
    ことを特徴とする請求項１４乃至１８のいずれか１項に記載のプログラム。
20. 前記設定工程は、前記警告方法として、前記データ変換が行われた旨の出力先のプリンタへの通知の可否、または、前記データ変換が行われた旨の前記第１アプリケーションへの通知の可否を設定する
    ことを特徴とする請求項１４乃至１９のいずれか１項に記載のプログラム。
21. 前記設定工程は、前記警告方法として、複数部数が指定された印刷ジョブで、１部目の印刷に対してのみ指定された警告方法を適用し、それ以降の部の印刷ジョブについては、出力先のプリンタで保持することの可否を設定する
    ことを特徴とする請求項１４乃至２０のいずれか１項に記載のプログラム。
22. 前記第２描画データに特定の色と任意の色の２色に基づいて表現されているビットマップデータが含まれていると判定した場合、または、前記第２描画データに含まれるビットマップデータに特定のオブジェクトが含まれていると判定した場合、前記第２描画データの描画状態が不自然であると判定する判定工程を更に有し、
    前記出力工程は、前記不自然であると判定された第２描画データを前記設定工程によって設定された警告方法に従って表示する
    ことを特徴とする請求項１４乃至２１のいずれか１項に記載のプログラム。
23. 前記出力工程は、前記第１アプリケーションからの印刷指示に応じて、前記第１描画データを前記第２描画データへデータ変換して、前記第２プリンタドライバへ出力する場合に、第１警告を出力する第１警告工程と、
    前記判定工程により前記第２描画データの描画状態が不自然であると判定された場合、前記設定工程により設定された警告方法に従って第２警告を出力する第２警告工程と
    を備えることを特徴とする請求項２２に記載のプログラム。