(57)【要約】【課題】  現行のプリントチケットを使った印刷システムでは、ユーザーインターフェースにおいて、ユーザーが操作した結果が印刷設定として反映されるかどうかユーザーにはわからない。【解決手段】  プリントチケット、及びプリントチケットのスコープを入力し、入力されたスコープとユーザーインターフェース機能のスコープとに基づきユーザーインターフェースを有効にして表示するか、あるいは無効にして表示し、ユーザーインターフェースで設定された設定に基づき前記入力手段により入力されたプリントチケットを編集してアプリケーションに返却することを特徴とする。【選択図】  図１９
2008217433.tif 000002
【特許請求の範囲】
【請求項１】
プリントチケット、及びプリントチケットのスコープを入力する入力手段と、
前記入力手段により入力されたスコープとユーザーインターフェース機能のスコープとに基づきユーザーインターフェースを有効にして表示するか、あるいは無効にして表示する表示手段と、
前記ユーザーインターフェースで設定された設定に基づき前記入力手段により入力されたプリントチケットを編集してアプリケーションに返却する返却手段とを有することを特徴とする情報処理装置。
【請求項２】
前記スコープは、ジョブ、ドキュメント、ページを含むことを特徴とする請求項１記載の情報処理装置。
【請求項３】
前記入力手段は、アプリケーションから直接入力するインターフェースを介して印刷設定、及び印刷設定のスコープを入力することを特徴とする請求項１記載の情報処理装置。
【請求項４】
前記ユーザーインターフェースは、プリンタドライバのユーザーインターフェースを含むことを特徴とする請求項１記載の情報処理装置。
【請求項５】
プリントチケット、及びプリントチケットのスコープを入力する入力ステップと、
前記入力ステップにより入力されたスコープとユーザーインターフェース機能のスコープとに基づきユーザーインターフェースを有効にして表示するか、あるいは無効にして表示する表示ステップと、
前記ユーザーインターフェースで設定された設定に基づき前記入力ステップにより入力されたプリントチケットを編集してアプリケーションに返却する返却ステップとを有することを特徴とする情報処理方法。
【請求項６】
前記スコープは、ジョブ、ドキュメント、ページを含むことを特徴とする請求項５記載の情報処理方法。
【請求項７】
前記入力ステップは、アプリケーションから直接入力するインターフェースを介して印刷設定、及び印刷設定のスコープを入力することを特徴とする請求項５記載の情報処理方法。
【請求項８】
前記ユーザーインターフェースは、プリンタドライバのユーザーインターフェースを含むことを特徴とする請求項５記載の情報処理方法。
【請求項９】
プリントチケット、及びプリントチケットのスコープを入力する入力ステップと、
前記入力ステップにより入力されたスコープとユーザーインターフェース機能のスコープとに基づきユーザーインターフェースを有効にして表示するか、あるいは無効にして表示する表示ステップと、
前記ユーザーインターフェースで設定された設定に基づき前記入力ステップにより入力されたプリントチケットを編集してアプリケーションに返却する返却ステップとをコンピュータに実行させるためのプログラム。
【請求項１０】
前記スコープは、ジョブ、ドキュメント、ページを含むことを特徴とする請求項９記載のプログラム。
【請求項１１】
前記入力ステップは、アプリケーションから直接入力するインターフェースを介して印刷設定、及び印刷設定のスコープを入力することを特徴とする請求項９記載のプログラム。
【請求項１２】
前記ユーザーインターフェースは、プリンタドライバのユーザーインターフェースを含むことを特徴とする請求項９記載のプログラム。
【請求項１３】
請求項９乃至１２いずれかに記載のプログラムを記憶したコンピュータが読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、プログラム、及び記憶媒体に関するものである、特に印刷設定に関するものである。
【背景技術】
【０００２】
Ｍｉｃｒｏｓｏｆｔ社のオペレーティングシステム（ＯＳ）であるＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）Ｖｉｓｔａにおいて印刷システムが大きく変更された。従来のＧＤＩ（Ｇｒａｐｈｉｃ  Ｄｅｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ）ベースの印刷システムと互換性を維持しつつ、ＸＰＳ（ＸＭＬ  Ｐａｐｅｒ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ）ベースの新しい印刷システムが導入された（ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｊａｐａｎ／ｗｈｄｃ／ｄｅｖｉｃｅ／ｐｒｉｎｔ／ｄｅｆａｕｌｔ．ｍｓｐｘ）。
【０００３】
ＸＰＳとは、電子文書フォーマットの一つである。その中身は、文書構造、描画情報、印刷設定などの情報を保持するＸＭＬとビットマップやフォントなどのバイナリリソースといった様々なパーツから構成される。ＸＰＳを構成する特に重要なパーツを図１にて示す。ＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅ１０１をジョブ、ＦｉｘｅｄＤｏｃｕｍｅｎｔ１０２をドキュメント、ＦｉｘｅｄＰａｇｅ１０３をページと理解するとよい。ＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅパーツ２０１は必ず１つだけ存在し、複数のＦｉｘｅｄＤｏｃｕｍｅｎｔパーツ２０２を保持する。さらに各々のＦｉｘｅｄＤｏｃｕｍｅｎｔパーツ２０２は複数のＦｉｘｅｄＰａｇｅパーツ２０３を保持する。さらに、これら任意のＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅパーツ２０１、ＦｉｘｅｄＤｏｃｕｍｅｎｔパーツ２０２、ＦｉｘｅｄＰａｇｅパーツ２０３には各々印刷設定を関連付けることができる（図２）。この印刷設定のことをプリントチケットと呼ぶ。ここで、ＦｉｘｅｄＤｏｃｕｍｅｎｔＳｅｑｕｅｎｃｅパーツ２０１に関連付けた印刷設定をジョブレベルのプリントチケット２０４、ＦｉｘｅｄＤｏｃｕｍｅｎｔパーツ２０２に関連付けた印刷設定をドキュメントレベルのプリントチケット２０５、ＦｉｘｅｄＰａｇｅパーツ２０３に関連付けた印刷設定をページレベルのプリントチケット２０６、と呼ぶ。ジョブレベルのプリントチケットはジョブの印刷設定を行う。ドキュメントレベルのプリントチケットはドキュメントの印刷設定を行う。ページレベルのプリントチケットはページの印刷設定を行う。
【０００４】
プリントチケットの中身の記述においてもジョブレベル、ドキュメントレベル、ページレベルの指定が可能となるため、さらに複雑な構造となる。
【０００５】
図３にプリントチケットのレベルと記述可能な要素を示している。ジョブレベルのプリントチケットはジョブレベルとドキュメントレベルとページレベル、即ち全レベルの記述が許される。ドキュメントレベルのプリントチケットはドキュメントレベルとページレベルの記述が許される。ジョブレベルの記述は許されない。ページレベルのプリントチケットはページレベルのみ記述が許される。ジョブレベルとドキュメントレベルの記述は許されない。
【０００６】
ここで理解を深めるために具体例を示す。例えば、３ページ保持するドキュメントでかつ３ページ目のみ給紙方法を変えるようなプリントチケットを保持するＸＰＳを生成するとする。このＸＰＳの構成を図４と図５の場合で考えてみる。なお、図４の構成において、ジョブレベルのプリントチケットは図６、ページレベルのプリントチケットは図７を指す。図５の構成において、ジョブレベルのプリントチケットは図８、ページレベルのプリントチケットは図９を指す。図３の拘束条件から、図４のＸＰＳは構成上正しく、図５のＸＰＳは構成上誤りであることがわかる。なぜならば、図５のＸＰＳは、ページレベルのプリントチケットにジョブレベルの記述をしてしまっている。
【０００７】
このように、プリントチケットに記述する内容はプリントチケットに関連付けるＸＰＳのパーツに依存して拘束される。図９のプリントチケットは、それ自身正しい記述にもかかわらずＦｉｘｅｄＰａｇｅに関連付けたことによって構成上不正になってしまう。つまり、アプリケーションがどのレベルのプリントチケットを指定するかが重要となる。以後、指定されるプリントチケットのレベルをスコープと呼ぶ。
【０００８】
ここまで、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）  Ｖｉｓｔａで導入された新しい印刷システムにおけるＸＰＳとプリントチケットの関係を述べた。次は、従来の印刷設定形式とプリンタドライバのインターフェースについて説明する。
【０００９】
従来のＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）の印刷システムにおいて、Ｗｉｎ３２アプリケーションが使用するＤＥＶＭＯＤＥと呼ばれるメモリブロックが印刷設定データとして重要な役割を担ってきた。図１０はそのＤＥＶＭＯＤＥの全体像を簡略化して描いたものである。ＤＥＶＭＯＤＥ構造体の特徴は、仕様が公開されているパブリック部１００１と仕様が公開されないプリンタドライバのみアクセス可能なプライベート部１００２の２つの領域から構成されることにある。一般に、ＤＥＶＭＯＤＥ構造体のパブリック部は、用紙、用紙の向き、解像度などのごく基本部分を記述するのみで、大部分を占める残りの全てをプライベート部に記述する。
【００１０】
図１１は、図１０のＤＥＶＭＯＤＥパブリック部１００１を具体的に示したものである。このようにＤＥＶＭＯＤＥ構造体はＭｉｃｒｏｓｏｆｔ社によってＣ言語のヘッダファイルとして厳密に規定されている。ＤＥＶＭＯＤＥパブリック部１００１には、スコープの概念が無いことわかる。一方、プリンタドライバを開発する各社が独自に定義するプライベート部１００２は、この構造体の直後に続き、その拡張サイズはｄｍＤｒｉｖｅｒＥｘｔｒａで指定される。
Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）  Ｖｉｓｔａ  から導入されたプリントチケットは、このようなレガシーな印刷設定フォーマットに替わる新しいフォーマットである。
【００１１】
以上をまとめると、従来形式であるＤＥＶＭＯＤＥは、
構造体で記述される。大部分を占めるプライベート部の仕様は非オープン。
バイナリなので可読性なし。
プリンタドライバのみアクセス可能。
各印刷設定にスコープの概念が無い。
という次第であるのに対し、新形式であるプリントチケットは、
ＸＭＬで記述される。仕様はオープン。
テキストなので可読性あり。
プリンタドライバ以外にアプリケーションなども自由にアクセス可能。
各印刷設定にスコープを指定する。
という特徴をもつ。
【００１２】
このようにプリントチケットはＤＥＶＭＯＤＥに比べ大きく機能拡張されている。特にスコープの指定が可能という大きな特徴を持つ。アプリケーションからプリントチケットを利用できるようになることは大きな前進であるが、これはアプリケーション層に限った話で、ドライバ層では大きく事情が異なる。
【００１３】
図１２は、印刷設定の処理において、アプリケーション層からＯＳ層、そしてドライバ層に至る各階層でＤＥＶＭＯＤＥやプリントチケットがどのようにやり取りされるかを示した図である。
【００１４】
まず、左上にあるＷｉｎ３２アプリケーション１２０６がプリンタドライバ１２０１とＤＥＶＭＯＤＥをやり取りするのが分かる。
【００１５】
一方、右上にあるプリントチケット対応アプリケーション１２０４がプリンタドライバ１２０１とプリントチケットをやり取りする処理は、やや複雑になる。プリンタドライバ本体１２０１の入出力はあくまでもＤＥＶＭＯＤＥに限られる。プリンタドライバはプリントチケットに対応するためにプリントチケットとＤＥＶＭＯＤＥを相互変換するプリントチケット・プロバイダと呼ばれるサブモジュール１２０２を提供する。このサブモジュール１２０２が機能することによって、ドライバ本体１２０１はＤＥＶＭＯＤＥしか扱えないに係らずアプリケーションはプリントチケットを扱えるようになる。ここで、注意すべきは、アプリケーションがスコープを指定しているにも係らずプリンタドライバにスコープが伝わらないことである。アプリケーションがスコープを指定することによってプリントチケットの記述内容に拘束が生じることを前述したが、そのような調整はＯＳレベルで解決される。プリンタドライバがスコープを解決することはない。
【特許文献１】特開２００６−２８５８７０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
一見、プリンタドライバがスコープを解決することがないのは、プリンタドライバの実装負担が減り良いことだと思われる。しかしながら、プリンタドライバからユーザーインターフェースを表示させユーザーによる操作を伴う場合は、プリンタドライバがスコープを認識できないことによる問題が生じる。例えば、プリンタドライバがジョブレベルの供紙方法のみサポートするとする。アプリケーションがスコープの指定をページレベルにして供紙方法を変更しようとしても、プリンタドライバはスコープを認識できないためユーザーインターフェース上では供紙の切り替えが操作できてしまう。しかし、実際にはＯＳ層でプリントチケットのスコープが解決されるときに、供紙方法の設定は消えてしまう。本来は、無理なスコープが指定されたら、それがユーザーインターフェースにも反映されるべきである。上記例だと、ユーザーインターフェースにおいて、供紙方法設定部がグレイ表示されて設定不可になるのが望ましい。
以上、現行のプリントチケットを使った印刷システムでは、プリンタドライバのユーザーインターフェースにおいて、ユーザーが操作した結果が印刷設定として反映されるかどうかユーザーにはわからない、といったユーザビリティ上大きな欠陥がある。
【課題を解決するための手段】
【００１７】
上述した課題を解決するために、本発明は、
プリントチケット、及びプリントチケットのスコープを入力する入力手段と、
前記入力手段により入力されたスコープとユーザーインターフェース機能のスコープとに基づきユーザーインターフェースを有効にして表示するか、あるいは無効にして表示する表示手段と、
前記ユーザーインターフェースで設定された設定に基づき前記入力手段により入力されたプリントチケットを編集してアプリケーションに返却する返却手段とを有することを特徴とする。
【発明の効果】
【００１８】
本発明によって、アプリケーションがプリンタドライバにプリントチケットの編集を依頼する際に、アプリケーションが指定したスコープに従いユーザーインターフェース上操作可能な部分と操作不可能な部分が明示される。ユーザーは何が設定できて何が設定できないのかを視覚的に認識できるため、ユーザーの利便性を向上させることができる。
【発明を実施するための最良の形態】
【００１９】
（実施例１）
本発明に係る情報処理装置の一実施形態としてのコンピュータについて説明する。図１３は、本実施形態のコンピュータを含むプリンタ制御システムの構成を説明するブロック図である。なお、特に断らない限り、本発明の機能が実行されるのであれば、単体の機器であっても、複数の機器からなるシステムであっても、ＬＡＮ，ＷＡＮ等のネットワークを介して接続が為され処理が行われるシステムであっても本発明を適用できることは言うまでもない。
【００２０】
図において、３００はホストコンピュータである。ホストコンピュータはＲＯＭ３のプログラム用ＲＯＭあるいは外部メモリ１１に記憶された文書処理プログラム等に基づいて図形、イメージ、文字、表（表計算等を含む）等が混在した文書処理を実行するＣＰＵ１を備え、システムバス４に接続される各デバイスをＣＰＵ１が総括的に制御する。
【００２１】
また、このＲＯＭ３のプログラム用ＲＯＭあるいは外部メモリ１１には、ＣＰＵ１の制御プログラムであるオペレーティングシステムプログラム（以下ＯＳ）等を記憶する。また、ＲＯＭ３のフォント用ＲＯＭあるいは外部メモリ１１には上記文書処理の際に使用するフォントデータ等を記憶し、ＲＯＭ３のデータ用ＲＯＭあるいは外部メモリ１１には上記文書処理等を行う際に使用する各種データを記憶する。
【００２２】
２はＲＡＭで、ＣＰＵ１の主メモリ、ワークエリア等として機能する。５はキーボードＩ／Ｆで、キーボード９や不図示のポインティングデバイスからのキー入力を制御する。６はディプレイＩ／Ｆで、ディスプレイ１０の表示を制御する。７は外部メモリＩ／Ｆで、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶するハードディスク（ＨＤ）、フロッピー（登録商標）ディスク（ＦＤ）等の外部メモリ１１とのアクセスを制御する。なお、外部メモリはプリンタドライバ等の各種処理プログラムを記憶するコンピュータが読み取り可能な記憶媒体として機能する。
【００２３】
８はプリンタＩ／Ｆで、所定の双方向性インターフェース２１を介してプリンタ１５０に接続されて、プリンタ１５０との通信制御処理を実行する。なお、ＣＰＵ１は、例えばＲＡＭ２上に設定された表示情報ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ディプレイ１０上でのＷＹＳＩＷＹＧを可能としている。
【００２４】
また、ＣＰＵ１は、ＣＲＴ１０上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウインドウを開き、種々のデータ処理を実行する。ユーザは印刷を実行する際、印刷の設定に関するウインドウを開き、プリンタの設定や、印刷モードの選択を含むプリンタドライバに対する印刷処理方法の設定を行える。
【００２５】
プリンタ１５０において、１２はプリンタＣＰＵで、ＲＯＭ１３のプログラム用ＲＯＭに記憶された制御プログラム等あるいは外部メモリ１４に記憶された制御プログラム等に基づいてシステムバス１５に接続される印刷部（プリンタエンジン）１７に出力情報としての画像信号を出力する。
【００２６】
また、このＲＯＭ１３のプログラムＲＯＭには、ＣＰＵ１２の制御プログラム等を記憶する。ＲＯＭ１３のフォント用ＲＯＭには上記出力情報を生成する際に使用するフォントデータ等を記憶し、ＲＯＭ１３のデータ用ＲＯＭにはハードディスク等の外部メモリ１４がないプリンタの場合には、ホストコンピュータ上で利用される情報等を記憶している。
【００２７】
ＣＰＵ１２は入力部１８を介してホストコンピュータとの通信処理が可能となっており、プリンタ内の情報等をホストコンピュータ３０００に通知可能に構成されている。１９はＣＰＵ１２の主メモリ、ワークエリア等として機能するＲＡＭで、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。なお、ＲＡＭ１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。前述したハードディスク（ＨＤ）、ＩＣカード等の外部メモリ１４は、メモリコントローラ（ＭＣ）２０によりアクセスを制御される。
【００２８】
外部メモリ１４は、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、１８は前述した操作パネルで操作のためのスイッチおよびＬＥＤ表示器等が配されている。また、前述した外部メモリは１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。さらに、図示しないＮＶＲＡＭを有し、操作パネル２０からのプリンタモード設定情報を記憶するようにしてもよい。
【００２９】
図１４は、ホストコンピュータにおける典型的な印刷データ生成方法を説明する図である。
アプリケーション２０１、グラフィックエンジン２０２、プリンタドライバ２０３、およびシステムスプーラ２０４は、外部メモリ１１に保存されたファイルとして存在し、ＯＳやそのモジュールを利用するモジュールによってＲＡＭ２にロードされ実行されるプログラムモジュールである。また、アプリケーション２０１およびプリンタドライバ２０３は、外部メモリ１１のＦＤや不図示のＣＤ−ＲＯＭ、あるいは不図示のネットワークを経由して外部ディスク１１のＨＤに追加することが可能となっている。
【００３０】
外部メモリ１１に保存されているアプリケーション２０１はＲＡＭ２にロードされて実行されるが、このアプリケーション２０１からプリンタ１５００に対して印刷を行う際には、同様にＲＡＭ２にロードされ実行可能となっているグラフィックエンジン２０２を利用して出力（描画）を行う。グラフィックエンジン２０２は、印刷装置ごとに用意されたプリンタドライバ２０３を、外部メモリ１１からＲＡＭ２にロードし、アプリケーション２１０の出力をプリンタドライバ２０３を用いてプリンタの制御コマンドに変換する。変換されたプリンタ制御コマンドはＯＳによってＲＡＭ２にロードされたシステムスプーラ２０４を経てインターフェース２１経由でプリンタ１５００へ出力される仕組みとなっている。
【００３１】
図１５は、アプリケーション１５０４と、各プリンタ用のプリンタドライバ１５０１，１５０２との関係をあらわした模式図である。
【００３２】
アプリケーション１５０４はオペレーティングシステム１５０３が提供する各種関数（ＡＰＩ）をコールして処理を行う。
【００３３】
オペレーティングシステム１５０３は印刷に関わる処理を選択されているプリンタのプリンタドライバ１５０１，１５０２が提供する関数（ＤＤＩ）をコールして処理を行う。
このようにしてアプリケーションから選択されたプリンタへの印刷が可能となっている。
【００３４】
このときプリンタドライバ１５０１，１５０２とオペレーティングシステム１５０３、及び、アプリケーション１５０４間でプリンタの印刷設定データがやり取りされる。これを表したのが図１６である。図１６のＷｉｎ３２アプリケーション１２０６やプリントチケット対応アプリケーション１２０４から印刷設定する場合については図１２にて説明済みなので、ここでは説明を省略する。プリンタドライバ１２０１にプリントチケットの入出力を直接管理する機能を設ける（１６０１）。そしてＯＳの関与しない独自のインターフェースを設ける（図１７）。この新インターフェースに対応したアプリケーション１６０２は、プリントチケットＡＰＩ１２０３を呼び出すことなく、前述したプリンタドライバが公開する独自のインターフェースを呼び出すことで、プリントチケットおよびそのスコープをプリンタドライバへ直接入力する。
【００３５】
図１７および図１８は、プリンタドライバが公開する独自のインターフェースの一部である。
図１７はＣ言語の関数として定義している。ＯＳが定義するプリンタドライバインターフェース関数ＤｒｖＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｙＳｈｅｅｔｓとは名前が異なるだけで関数仕様はほぼ同等なので、ここでは説明を省略する。なお、ＤｒｖＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｙＳｈｅｅｔｓ関数の詳細については、ｈｔｔｐ：／／ｍｓｄｎ２．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｌｉｂｒａｒｙ／ｍｓ８０１１３１．ａｓｐｘにて確認できる。
【００３６】
図１８は、図１７の関数で使用される構造体の一部である。これもＯＳが定義するＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体を模した仕様になっている。なお、ＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体の詳細については、ｈｔｔｐ：／／ｍｓｄｎ２．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｌｉｂｒａｒｙ／ａａ５０６３０６．ａｓｐｘにて確認できる。以下、ＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体とＣＮ＿ＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体の違いのみを説明する。ＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体には、入出力するＤＥＶＭＯＤＥ構造体をメンバとして保持し、さらに出力用ＤＥＶＭＯＤＥのサイズもメンバとして保持しているが、これらはＣＮ＿ＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体には一切存在しない。その代わりに、入出力するプリントチケットをメンバ（ＩＳｔｒｅａｍ  ＊ｐＰｒｉｎｔＴｉｃｋｅｔ）として保持し、さらにスコープ情報もメンバ（ＥＰｒｉｎｔＴｉｃｋｅｔＳｃｏｐｅ  ｓｃｏｐｅ）として保持する。
【００３７】
図１９は、図１７のＣＮ＿ＤｒｖＤｏｃｕｍｅｎｔＰｒｏｐｅｒｔｙＳｈｅｅｔｓ関数の呼び出しにおいて、プリンタドライバに対しユーザーインターフェースの表示が指示された場合の処理フローの一部を示す。なお、処理フローに係るプリンタドライバのプログラムは外部メモリのＨＤ１１に記憶されており、ＲＡＭ２に読み出されＣＰＵ１によって実行される。なお、ユーザーインターフェースの表示の指示は、図１８のＣＮ＿ＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体のｆＭｏｄｅメンバにＤＭ＿ＩＮ＿ＰＲＯＭＰＴが設定された場合に相当する。
【００３８】
ステップ１９０１でＣＮ＿ＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体のｓｃｏｐｅメンバとしてアプリケーションから渡されるプリントチケットのスコープをメモリへ読み込む。ステップ１９０２でＣＮ＿ＤＯＣＵＭＥＮＴＰＲＯＰＥＲＴＹＨＥＡＤＥＲ構造体のｐＰｒｉｎｔＴｉｃｋｅｔメンバとして渡されるプリントチケットをメモリへ読み込む。ステップ１９０３でデバイスの能力を記述したプリンタドライバのデータファイルを読み込む。このデータファイルにはプリンタドライバの全機能の各々のスコープが記されている。
【００３９】
例えば、給紙方法にはジョブ、出力ビン（排紙方法）にはジョブ、パンチにはジョブがスコープとして記されている。また、解像度にはページ、メディアタイプにはページがスコープとして記されている。なお、給紙方法をページ単位で切り替えられるプリンタであれば、給紙方法にはページがスコープとして記される。
【００４０】
なお、このデータファイルの形式は、独自フォーマットであってもかまわないし、Ｍｉｃｒｏｓｏｆｔ社が規定するＰｒｉｎｔＣａｐａｂｉｌｉｔｉｅｓ（ｈｔｔｐ：／／ｍｓｄｎ２．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｌｉｂｒａｒｙ／ｍｓ７１６４３１．ａｓｐｘ）形式であってもかまわない。ステップを１９０４から表示するユーザーインターフェースの初期化が始まる。ステップ１９０４でユーザーインターフェース機能の列挙を実施する。このユーザーインターフェース機能の列挙はループ処理になっていて、列挙すべき機能が尽きるとステップ１９０５からループを抜ける。ステップ１９０６でスコープに関する本実施形態にとって重要な判断を行う。ステップ１９０３で得たデータと列挙された列挙されたユーザーインターフェース機能とを比較し、列挙されたユーザーインターフェース機能のスコープを得る。このスコープとステップ１９０１で得たスコープを比較する。なお、比較の際に、ジョブ＞ドキュメント＞ページ、という表現する。つまり、ジョブレベルのスコープはドキュメントレベルのスコープより大きいと表現する。ドキュメントレベルのスコープはページレベルのスコープより大きいと表現する。列挙されたユーザーインターフェース機能のスコープがステップ１９０１で得たスコープ以下の場合、ステップ１９０７へ進み、ユーザーインターフェースを入力可能にする。すなわちユーザーインターフェースの表示を有効にしてユーザに入力可能とする。逆の場合は、ステップ１９０８へ進みユーザーインターフェースをグレイ表示して設定不可にする。すなわちユーザーインターフェースの表示を無効にしてユーザに入力不可能とする。ユーザーインターフェース上で入力可能の場合のみ、ステップ１９０９に進み、ステップ１９０２で得たプリントチケットの設定をユーザーインターフェースに反映する。
【００４１】
ここで、具体例を示す。列挙されたユーザーインターフェース機能が供紙方法で、そのスコープはジョブレベル、ステップ１９０１で得たスコープもジョブレベルの場合、ステップ１９０７へ進み、ユーザーインターフェースは図２０のように表示される。一方、列挙されたユーザーインターフェース機能が供紙方法で、そのスコープはジョブレベル、ステップ１９０１で得たスコープがページレベルの場合、ステップ１９０８へ進み、ユーザーインターフェースは図２１のように表示される。
【００４２】
また、列挙されたユーザーインターフェース機能が解像度で、そのスコープはページレベル、ステップ１９０１で得たスコープがページレベルの場合、ステップ１９０７へ進み、ユーザーインターフェースは解像度が設定可能なように表示される。また、列挙されたユーザーインターフェース機能が解像度で、そのスコープはページレベル、ステップ１９０１で得たスコープがジョブレベルの場合、ステップ１９０７へ進み、ユーザーインターフェースは解像度が設定可能なように表示される。
【００４３】
以上のステップを経て、プリンタドライバのユーザーインターフェースは初期化処理を完了し、ユーザーに入力可能な状態になる。なお、ユーザーがプリンタドライバのユーザーインターフェース上で何かしら操作した結果、プリンタドライバはステップ１９０２で読み込んだプリントチケットを編集し、アプリケーションへプリントチケットが返却される。なお、本実施形態においては、新インターフェース対応アプリ１６０２が直接プリンタドライバのプリントチケット入出力部１６０１を呼びだすことによって実現している。ここでは説明を省略するが、ＯＳ層で図１７と図１８相当のインターフェースが用意されていて、アプリケーションはＯＳ層を呼び出し、プリンタドライバは、そのインターフェースを実装する、といった構成であってもかまわない。
【図面の簡単な説明】
【００４４】
【図１】ＸＰＳを構成する主要なパーツを使った概観図である。
【図２】ＸＰＳの構成する主要なパーツとプリントチケットの関係図である。
【図３】プリントチケットのスコープを説明する図である。
【図４】ＸＰＳの構成事例１を示す図である。
【図５】ＸＰＳの構成事例２を示す図である。
【図６】プリントチケットの記述例１を示す図である。
【図７】プリントチケットの記述例２を示す図である。
【図８】プリントチケットの記述例３を示す図である。
【図９】プリントチケットの記述例４を示す図である。
【図１０】ＤＥＶＭＯＤＥ構造体を簡略化したブロック図である。
【図１１】ＤＥＶＭＯＤＥ構造体のパブリック部の詳細図である。
【図１２】アプリ層からＯＳ層、ドライバ層に至るＤＥＶＭＯＤＥとプリントチケットの取り扱いを示す関係図である。
【図１３】本発明の一実施形態としてのコンピュータを含むシステムの構成を説明するブロック図である。
【図１４】本発明の一実施形態としてのコンピュータにおける典型的な印刷データ生成方法を説明するブロック図である。
【図１５】本発明の一実施形態としてのコンピュータにおける、アプリケーションと各プリンタ用のプリンタドライバとの関係をあらわした図である。
【図１６】本発明の一実施形態としてのコンピュータにおける、アプリ層からＯＳ層、ドライバ層に至るＤＥＶＭＯＤＥとプリントチケットの取り扱いを示す関係図である。
【図１７】本発明の一実施形態としてのプリンタドライバにおける、プリンタドライバ独自のインターフェース（Ｃ言語の関数）を示す図である。
【図１８】本発明の一実施形態としてのプリンタドライバにおける、プリンタドライバ独自のインターフェース（Ｃ言語の構造体）を示す図である。
【図１９】本発明の一実施形態としてのプリンタドライバにおける、ユーザーインターフェースの初期化処理のフローチャートを示す図である。
【図２０】本発明の一実施形態としてのプリンタドライバにおける、ユーザーインターフェースの給紙機能設定部が有効になる場合の事例を示す図である。
【図２１】本発明の一実施形態としてのプリンタドライバにおける、ユーザーインターフェースの給紙機能設定部が無効になる場合の事例を示す図である。
【図１】
2008217433.tif 000003
【図２】
2008217433.tif 000004
【図３】
2008217433.tif 000005
【図４】
2008217433.tif 000006
【図５】
2008217433.tif 000007
【図６】
2008217433.tif 000008
【図７】
2008217433.tif 000009
【図８】
2008217433.tif 000010
【図９】
2008217433.tif 000011
【図１０】
2008217433.tif 000012
【図１１】
2008217433.tif 000013
【図１２】
2008217433.tif 000014
【図１３】
2008217433.tif 000015
【図１４】
2008217433.tif 000016
【図１５】
2008217433.tif 000017
【図１６】
2008217433.tif 000018
【図１７】
2008217433.tif 000019
【図１８】
2008217433.tif 000020
【図１９】
2008217433.tif 000021
【図２０】
2008217433.tif 000022
【図２１】
2008217433.tif 000023