JP2009086722A - 情報処理装置、情報処理方法、プログラム、及び記憶媒体 - Google Patents

Abstract

【課題】 アプリケーションの仕様や開発環境、プリンタドライバがいずれの印刷システムに対応したものであるかを意識することなく、容易に印刷を実行できる情報処理装置、印刷装置、およびそれらの制御方法を提供する。
【解決手段】 プリンタドライバは、共通モジュールとしてＢｒｉｄｇｅモジュールを備え、アプリケーションが拡張ＤＤＩを利用して印刷情報を制御する場合において、アプリケーションのアーキテクチャ仕様やインターフェース、プリンタドライバが対応している印刷システムを判断して利用する拡張ＤＤＩを切り替える。
【選択図】 図６

Description

本発明は、情報処理装置、印刷システム、印刷装置およびそれらの制御方法に関し、特にホストコンピュータ等に存在する印刷データをプリンタ等の出力装置によって印刷される印刷システム、そのシステムにおける情報処理装置、印刷装置、およびそれらの制御方法に関するものである。

一般に、ホストコンピュータなどに搭載されるオペレーティングシステムには、印刷要求を行うホストコンピュータにプリンタが接続された環境での印刷をサポートするための印刷システムが備えられている。ホストコンピュータには、その印刷システムおよび使用するプリンタの機種に対応したプリンタドライバが搭載される。このため、各印刷システムにそれぞれ対応したプリンタドライバを作成して供給しなければならないが、印刷システムは必ずしも一つであるとは限らず、二つ以上の印刷システムが共存するオペレーティングシステムの構成が存在する。

例えば、米国アップル社の「ＭａｃＯＳ（登録商標）」では、ＭａｃＯＳ（登録商標） Ｘ１０．０で導入された印刷システム（以後、印刷システムＡと呼ぶ）が既に搭載されている。しかし、ＭａｃＯＳ Ｘ１０．２では新たに「ＣＵＰＳ（Ｃｏｍｍｏｎ ＵＮＩＸ（登録商標） Ｐｒｉｎｔｉｎｇ Ｓｙｓｔｅｍ）」と呼ばれる印刷システム（以後、ＣＵＰＳ印刷システムと呼ぶ）が導入された。従って、双方の印刷システムが共存する構成が存在する。それら双方のシステム間では、プリンタドライバが取得する印刷設定情報のデータの形式やラスタデータの取得方法が異なるため、印刷システムＡとＣＵＰＳ印刷システムとでそれぞれに準拠したプリンタドライバを別々に開発することが余儀なくされているのが現状である。従って、プリンタドライバを使用するユーザにとっても混乱を生じさせる要因となるため、複数の印刷システムに対応したプリンタドライバを開発することが望まれている。（例えば、特許文献１）
さらに近年ではホストコンピュータに64ビットプロセッサが搭載され、1クロックサイクルあたりのデータ処理量が多く、より多くのメモリにアドレス指定が可能となり数値計算をより高速に実行できることから、より優れたパフォーマンスが実現され、それに対応した64ビットアプリケーションの普及も進んでいる。

そこで、米国アップル社の「ＭａｃＯＳ」のようなオペレーティングシステムには、単一のファイルに32ビットおよび64ビットコードを両方入れられるファットバイナリ形式がサポートされている。従って、一つのアプリケーションで32ビットプラットフォーム搭載のホストコンピュータ、および64ビットプロセッサ搭載のホストコンピュータなど全ユーザをサポートすることができ、ユーザ側のシステムにインストールされたファットバイナリ形式のアプリケーションは、ユーザを介在させることなく、自動的に最適なコードで起動する。

従って、このファットバイナリ形式でプリンタドライバが作成された場合、32ビットアプリケーションから印刷が実行された場合は32ビットバイナリが、一方、64ビットアプリケーションから印刷が実行された場合は64ビットバイナリが選択されて動作することになる。
特開2007-034795号公報

しかしながら、一般のユーザの多くは、システムが何のアーキテクチャに対応しているのか、またシステムにインストールされたアプリケーションが32ビットアプリケーションなのか64ビットアプリケーションなのかを認識していない。さらに、従来のプリンタドライバはファットバイナリ形式ではなく32ビットバイナリしか保持していないため、新規64ビットアプリケーションから印刷が実行された場合には、起動できずにアプリケーションがクラッシュしてしまうという問題がある。

また、二つ以上の印刷システムが共存するオペレーティングシステムの構成において、ユーザはホストコンピュータに接続されているプリンタに対応したプリンタドライバを選択するが、いずれの印刷システムに対応しているプリンタドライバであるかどうかを意識することはない。そのために、一つのプリンタドライバをデフォルトのプリンタドライバとしていったん選択してしまうと、アプリケーションの種類に関わらず選択したプリンタドライバが使用される。

このように、印刷処理経路において、最適なプリンタドライバをユーザ自身が選択することは困難である。

さらに、Ｍａｃ ＯＳ Ｘの開発環境には、現在、旧Ｍａｃ ＯＳと互換性のある「Ｃａｒｂｏｎ」と、Ｍａｃ ＯＳ Ｘネイティブの新しい環境として「Ｃｏｃｏａ」が用意されている。双方の開発環境の主な相違点は開発言語であり、「Ｃａｒｂｏｎ」はＣ＋＋およびＣ言語、「Ｃｏｃｏａ」はＯｂｊｅｃｔｉｖｅ−Ｃ言語がメインとなっている。そのため、「Ｃａｒｂｏｎ」で構築されたアプリケーションと、「Ｃｏｃｏａ」で構築されたアプリケーションが存在する。「Ｃｏｃｏａ」に関して言えば、Ｃ言語などのＣａｒｂｏｎ用のコードを含むことも可能であるが、一つのアプリケーションを開発する際に、類似の異なる言語を使うのは開発効率が良くない。

本発明は、上記の問題に鑑みてなされたものであって、アプリケーションの仕様や開発環境、プリンタドライバがいずれの印刷システムに対応したものであるかを意識することなく、容易に印刷を実行できる情報処理装置、印刷装置、およびそれらの制御方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を備える。

接続された印刷装置に対して印刷用データを提供する情報処理装置において、アプリケーションからは直接読み書きできない印刷情報を制御可能な拡張モジュールを有するプリンタドライバであって、アプリケーションからの描画出力に応じて処理可能なプリンタドライバが、第一の印刷システムからの第一態様の印刷設定情報と第一態様の印刷データの入力を受け付け、プリンタで印刷可能なプリントデータを生成する第一態様のプリンタドライバであるか、第二の印刷システムからの第二態様の印刷設定情報と第二態様の印刷データの入力を受け付け、プリンタで印刷可能なプリンタデータを生成する第二態様のプリンタドライバであるかを判別する印刷システム判別手段と、第一種類のアプリケーションからの描画出力命令と、第二種類のアプリケーションからの描画出力命令を受け付ける描画出力命令受け付け手段と、前記受け付けた描画出力命令に応じて、出力先として呼び出されたプリンタドライバが出力元のアプリケーションのアーキテクチャ仕様と一致するかを判別するアーキテクチャ判別手段とを有する。

また、前記拡張モジュールは、プリンタドライバとアプリケーションとの間でプリンタドライバ固有の設定情報をやり取りするために、オペレーティングシステムが提供する印刷オブジェクトを受け取る手段を備えた拡張インターフェースを有する。

また、前記印刷システム判別手段は、前記アプリケーションから受信した前記印刷オブジェクトに対してプリンタ名称を検索し、検索した前記プリンタ名称からプリンタ固有の情報を格納した設定情報ファイルを取得し、前記印刷システム固有の識別情報に基づいて前記第一の印刷システムであるか、前記第二の印刷システムであるかを判別する。

本発明によれば、アプリケーションの仕様や開発環境、プリンタドライバがいずれの印刷システムに対応したものであるかを意識することなく、容易に印刷を実行することが可能となる。

次に、本発明の詳細を実施例の記述に従って説明する。

以下、本発明の第一実施形態について説明する。図１は、本発明の実施形態を示す情報処理装置を説明するブロック図であり、ホストコンピュータ101とEtherNet（登録商標）やUSBなどの通信バス112を介してプリンタＡ113、プリンタＢ117とが通信可能な印刷システムの例である。図１では、プリンタは２つのみ図示したが、通信バス112を介して任意の数のプリンタが接続可能である。

ホストコンピュータ101において、102は、ＲＡＭ104及び外部記憶装置105に格納されたプログラムに従って各部を制御するＣＰＵである。プリンタＡ113及びプリンタＢ117に対応したプリンタドライバを実行し、アプリケーションプログラムに基づいて作成された出力情報をプリンタに対応する出力コマンドに変換し、プリンタＡ113またはプリンタＢ117に所定のプロトコルで出力する。

103はＲＯＭで、ＣＰＵ102が実行するＢＩＯＳプログラムやフォントデータを格納するＲＯＭである。104は、ＲＡＭで、必要に応じてＣＰＵ102がデータの書き込みや読み出しを行ったりするために使用され、プリンタドライバ起動時には、プリンタドライバのプログラムコードがこのＲＡＭ104にロードされる。

105は外部記憶装置で、ＣＰＵ102が読み出すプログラムコードが格納されており、本実施形態の機能の一部を実現するデバイスで、例えば、ＦＤ、ＣＤ−ＲＷ、ＨＤＤなどである。

106が入力デバイス制御部で、キーボードやマウス等の入力デバイス108を制御する。107は表示装置制御部で、ＣＲＴ等の表示装置109を制御する。110は内部バスで、各構成要素間のデータ通信を行うデータバス、システムバスで構成される。111は通信Ｉ／Ｆで、通信バス112を介してプリンタＡ113及びプリンタＢ117との通信を司り、双方向通信可能である。

なお、シリアルインタフェースとしてはＵＳＢ、ＩＥＥＥ１３９４など、パラレルインタフェースとしてはセントロニクス、ＳＣＳＩなど複数の種類が想定されるが、双方向の通信を実現するものであればどのようなインタフェースでも構わない。

プリンタＡ113において、115はプリントコントローラで、通信Ｉ／Ｆ114より得られたプリンタコマンドをもとにプリンタエンジン116を制御し印刷を行う。116はプリンタエンジンで、プリンタヘッドの操作や記録媒体の搬送を行う機構である。

本実施例では、ホストコンピュータ101上で実行されるオペレーティングシステムは、二つ以上の印刷システムが共存するオペレーティングシステムの構成を有し、ファットバイナリ形式をサポートしているものとする。このような仕様のオペレーティングシステムとして、米国アップル社のＭａｃ ＯＳ Ｘを想定している。

図２は、オペレーティングシステム（Ｍａｃ ＯＳ Ｘ）における印刷処理を説明するブロック図である。印刷処理が実行されると、アプリケーション201は、ユーザによって作成された文書データ（画像データ）に基づく描画データを、オペレーティングシステム202へ渡すとともにオペレーティングシステム202に対し印刷処理の依頼を行う。オペレーティングシステム202はアプリケーションから渡された描画データを印刷スプールファイル203にセーブする。アプリケーションから描画データをすべて受け取り印刷スプールファイル203に保存した後、オペレーティングシステム202は出力先のプリンタに対応したプリンタドライバ204をロードする。オペレーティングシステム202は印刷スプールファイル203から描画データをロードして、バンド処理を行い、１バンド分のラスタライズデータを作成する。オペレーティングシステム202は生成したラスタライズデータをプリンタドライバ204に渡し処理依頼する。プリンタドライバ204は渡されたラスタライズデータをプリンタコマンドへ変換して、オペレーティングシステム202の通信機能を利用してプリンタ205へ出力する。プリンタ205ではこのようにして生成された印刷コマンドに基づいて印刷を行う。

図３は、本実施の形態において、印刷システムＡを備えるオペレーティングシステムに適用した印刷システムと、ＣＵＰＳ印刷システムを備えるオペレーティングシステムに適用した印刷システムが共存する環境における全体の概略構成を示すブロック図である。

以下、図面を参照して印刷システムＡ303について説明する。印刷システムＡ303は、情報処理装置としてのホストコンピュータ301と、それにEtherNetやUSBなどの通信バスを介して接続されるプリンタＡ319とから構成される。ホストコンピュータ301は、印刷システムＡ303、印刷システムＡ用プリンタドライバ311を備え、アプリケーション302から受け取った印刷データを印刷システムＡ303及び印刷システムＡ用プリンタドライバ311を通じてプリンタＡ319が処理可能（印刷可能）なプリントデータに変換して出力する。

アプリケーション302は、印刷システムＡ303に対して印刷要求を行うものであり、印刷開始時にＰＤＦ形式の印刷データと用紙サイズ、用紙種類、インク種類などが設定された印刷設定情報とを印刷システムＡ303に受け渡す。印刷システムＡ303は、プリンタＡ319に印刷を実行させるための印刷処理全般を管理する処理を行う。この印刷システムＡ303は、アプリケーション302からの印刷設定情報をジョブチケットとして受け取り、印刷システムＡ用プリンタドライバ311のプリントデータ生成部313からのデータ取得要求に基いて、オペレーティングシステム内にライブラリとして備えられている所定のＡＰＩ（Application Program Interface）を読み込むことで、上記ＰＤＦ形式の印刷データをラスタデータに変換する。このラスタデータとジョブチケットとを印刷システムＡ用プリンタドライバ311に受け渡す。

印刷システムＡ用プリンタドライバ311は、印刷システムＡ303より取得したジョブチケットに基いて、ラスタデータをプリンタＡ319で処理可能なプリントデータに変換するデータ展開処理を行う。このデータ展開処理では、色変換などの画像形成用のデータを生成し、そのデータに所定の印刷コマンドを付加することでプリントデータを生成する。印刷システムＡ用プリンタドライバ311は、生成したプリントデータをプリンタＡ319へ出力する。これにより、プリンタＡ319では、プリントデータに基づいて印刷媒体への印刷が行われる。以上までの構成が印刷システムＡの基本構成となる。

印刷システムＡ303は、ファイル生成部304とファイル登録部305とを備えている。ファイル登録部305には、そのプリンタＡ319のプリンタ名やアイコンに関する情報の他、プリンタＡ319のオプションや機能に関するプリンタ機能固有の情報を記述したＰＰＤ（PostScript（登録商標）Printer Description）ファイル306が登録される。

ファイル生成部304は、プリンタＡ319の初回起動時に、プリンタＡ319に対応する印刷システムＡ用プリンタドライバ311にプリンタ情報を問い合わせ、印刷システムＡ用プリンタドライバ311からプリンタ情報を取得すると、取得したプリンタ情報に基づきＰＰＤファイル306を生成し、ファイル登録部305に登録する。印刷システムＡ303は、このようにファイル生成部304により生成したＰＰＤファイル306をファイル登録部305に登録することで、オペレーティングシステムへのプリンタＡ319の登録処理を行う。アプリケーション302から印刷要求を受付けた際には、ファイル登録部305に登録されているＰＰＤファイル306を参照することで、対応するプリンタ情報をアプリケーション302に回答する。これにより、アプリケーション302では、プリンタ情報に基づきジョブチケットが生成される。

印刷システムＡ用プリンタドライバ311は、プリンタ情報返答部312とプリントデータ生成部313と相互通信部314とを備えている。プリンタ情報返答部312は、プリンタ登録処理の際に必要となるプリンタ情報を印刷システムＡ303からの問い合わせに対して返答する処理部である。プリントデータ生成部313は、印刷開始時に、印刷システムＡ用プリンタドライバ311によって初期化され、ジョブ開始指示に基づいて印刷システムＡ303から取得したラスタデータをプリンタＡ319での処理に適した画像形成用のデータに展開し、印刷コマンドを付加してプリントデータを生成する。そして印刷システムＡ303からのジョブ終了指示に基づいて処理を終了する。また、プリントデータ生成部313は、プリンタＡ319から一定時間間隔で取得したプリンタＡ319に関するステータス情報を解析しエラー処理なども行う。相互通信部314は、プリンタＡ319との間で双方向のデータ通信を行うための通信モジュールであって、プリントデータ生成部313から受信したプリントデータをプリンタＡ319へ送信したり、プリンタＡ319から受信したステータス情報をプリントデータ生成部313へ送信したりする。

次に、図面を参照してＣＵＰＳ印刷システム307について説明する。ＣＵＰＳ印刷システム307は、情報処理装置としてのホストコンピュータ301と、それにEtherNetやUSBなどの通信バスを介して接続されるプリンタＢ320とから構成される。ホストコンピュータ301は、ＣＵＰＳ印刷システム307、ＣＵＰＳ用プリンタドライバ315を備え、アプリケーション302から受け取った印刷データをＣＵＰＳ印刷システム307及びＣＵＰＳ用プリンタドライバ315を通じてプリンタＢ320が処理可能（印刷可能）なプリントデータに変換して出力する。

アプリケーション302は、ＣＵＰＳ印刷システム307に対して印刷要求を行うものであり、印刷開始時にＰＤＦ形式の印刷データと用紙サイズ、用紙種類、インク種類などが設定された印刷設定情報とをＣＵＰＳ印刷システム307に受け渡す。ＣＵＰＳ印刷システム307は、プリンタＢ320に印刷を実行させるための印刷処理全般を管理する処理を行う。このＣＵＰＳ印刷システム307は、印刷要求があった場合に、ＰＰＤファイル310を元に、アプリケーション302からの印刷設定情報をカップスオプション（Cups Option）として受け取り、カップスオプションとＰＤＦ形式の印刷データとをＣＵＰＳ用プリンタドライバ315に受け渡す。

ＣＵＰＳ用プリンタドライバ315は、ＣＵＰＳ印刷システム307より取得したカップスオプションをジョブチケットに変換するとともに、ＰＤＦ形式の印刷データをラスタデータに変換する。その後、ＣＵＰＳ用プリンタドライバ315は、さらに変換したジョブチケットに基づいてラスタデータを、プリンタＢ320で処理可能なプリントデータに変換して、プリンタＢ320に出力する。これにより、プリンタＢ320では、受信したプリントデータに基づいて印刷媒体への印刷が行われる。以上までの構成がＣＵＰＳ印刷システムの基本構成となる。

ＣＵＰＳ印刷システム307は、ファイル取得部308と、ファイル登録部309とを備えている。ファイル登録部309には、印刷システムＡ303と同様、プリンタＢ320のプリンタ名やアイコンに関する情報の他、そのプリンタＢ320のオプションや機能に関するプリンタ機種固有の情報を記述したＰＰＤファイル310が登録される。

ここで、ＣＵＰＳ印刷システム307においては、ＰＰＤファイル310はＣＵＰＳ用プリンタドライバ315のインストールの際にファイル登録部308に登録される。このため、ＣＵＰＳ印刷システム307においては、プリンタＢ320の初回接続時には、ファイル取得部308により、ＰＰＤファイル310の検索処理のみ行われる。そして、その後、アプリケーション302から印刷要求を受け付けた際には、ＰＰＤファイル310を参照することで必要なプリンタ情報を読み取り、それをアプリケーション302に回答する。これにより、アプリケーション302では、ＰＰＤファイル310のプリンタ情報に基づいてカップスオプションが生成される。

ＣＵＰＳ用プリンタドライバ315は、データ形式変換部316と、プリントデータ生成317と、相互通信部318とを備えている。このうち、プリントデータ生成部317および相互通信部318は、前述した印刷システムＡ用プリンタドライバ311に備えられるものと同じものである。データ形式変換部316は、プリントデータ生成部317に対する印刷開始に伴う初期化処理や、その後のジョブの開始処理および終了処理などを行う。また、データ形式変換部316は、そのジョブ実行時において、アプリケーション302から受信した印刷設定情報をカップスオプション形式からジョブチケット形式に変換する処理を行うとともに、ＰＤＦ形式の印刷データを中間データのラスタデータに変換する処理を行う。プリントデータ生成部317は、こうしてデータ形式変換部316から取得したラスタデータとジョブチケットとに基づいてプリントデータを生成し、このプリントデータを相互通信部318を介してプリンタＢ320へ送信する。

図４は、ファットバイナリ形式とそうでない非ファットバイナリ形式、すなわち異なるアーキテクチャのアプリケーションとプリンタドライバの関係を表すブロック図である。本実施例では、64ビットプロセッサが搭載されたホストコンピュータ上で動作しているものとする。32ビットアプリケーション401は、32ビットバイナリコードのみを含んでいる非ファットバイナリ形式のアプリケーションであるとみなすことができる。一方、64ビットアプリケーション402は、ファットバイナリ形式の32ビットバイナリコードと64ビットバイナリコードの両方を含んでおり、インストールされたホストコンピュータに搭載されているプロセッサの仕様に基づいて最適なコードが決定付けられる。本実施例では、64ビットプロセッサが搭載されたホストコンピュータ上で動作しているものと想定しているため、64ビットアプリケーションであるとみなすことができる。

実施形態では、Ｍａｃ ＯＳ Ｘシステムで定義されているプリンタドライバ命令（ＤｅｖｉｃｅＤｒｉｖｅｒＩｎｔｅｒｆａｃｅ、略して以後ＤＤＩと呼ぶ）とは別に、独自のプリンタドライバ命令（以後、拡張ＤＤＩと呼ぶ）を新たに定義し、アプリケーションはプリンタドライバに用意された拡張ＤＤＩを直接利用することで、印刷情報の制御を行い、アプリケーションの設定画面上にプリンタドライバ固有の設定項目をメニューとして用意する手段を用いる。

プリンタドライバはアプリケーションの仕様に基づいて最適なコードが決定付けられる。32ビットアプリケーション401が非ファットバイナリ形式のプリンタドライバ403に対して印刷を実行しようとした場合、プリンタドライバ403は32ビットバイナリコード404を含む拡張ＤＤＩを備えているため、正常に印刷処理を実行することができる。また同様に、32ビットアプリケーション401がファットバイナリ形式のプリンタドライバ405に対して印刷を実行しようとした場合、プリンタドライバ405は32ビットバイナリ406を含む拡張ＤＤＩを備えているため、正常に印刷処理を実行することが可能である。

一方、64ビットアプリケーション402が非ファットバイナリ形式のプリンタドライバ403に対して印刷を実行しようとした場合、プリンタドライバ403は32ビットバイナリコード404を含む拡張ＤＤＩを備えていないため、印刷処理を実行することはできない。この場合、64ビットアプリケーション402がプリンタドライバ403に印刷処理を実行した時点で、64ビットアプリケーション402が強制終了してしまう。また、64ビットアプリケーション402がファットバイナリ形式のプリンタドライバ405に対して印刷を実行しようとした場合には、プリンタドライバ405は64ビットバイナリコード407を含む拡張ＤＤＩを備えているため、正常に印刷処理を実行することが可能である。

以上、図３で述べたように印刷システムＡ303とＣＵＰＳ印刷システム307とが共存する環境において、それぞれ取得する印刷設定情報のデータの形式やラスタデータの取得方法が異なるため、プリンタドライバはそれぞれ別々に作成する必要がある。また、図４で述べたように非ファットバイナリ形式のアプリケーションとプリンタドライバの関係には正常に印刷処理を実行できない系が存在する。

図５は、本発明の実施形態におけるプリンタドライバの構成を表すブロック図である。図３や図４で述べたように、Ｍａｃ ＯＳ Ｘにおいて、印刷システムＡ用プリンタドライバとＣＵＰＳ用プリンタドライバ、またはファットバイナリ形式プリンタドライバと非ファットバイナリプリンタドライバなど印刷システムや対応アーキテクチャの異なるプリンタドライバが同システム内に混在する場合が存在する。さらに、アプリケーション側においても「Ｃｏｃｏａ」で構築されたアプリケーション（501、または502）と「Ｃａｒｂｏｎ」で構築されたアプリケーション（503、または504）などが混在している。そのため、プリンタドライバは共通モジュールとしてＢｒｉｄｇｅモジュール505を備え、アプリケーションに対して最適なインターフェースを提供するために、Ｃｏｃｏａ用インターフェースとＣａｒｂｏｎ用インターフェースの両方を有し、アプリケーションが意識することなく所望のプリンタに対応したプリンタドライバの用意した拡張ＤＤＩ（506、または507）を利用することを可能とする。

一般的にＭａｃ ＯＳ Ｘシステムにおいて、プリンタドライバの設定情報を格納するための印刷オブジェクトが用意されている。この印刷オブジェクトには、現在選択されているプリンタ名称や、用紙サイズ、オリエンテーションなど印刷設定の一般的な項目が保持されており、アプリケーションは自身のプログラム内部で直接現在の設定を参照し、同時にアプリケーションから直接更新することが可能である。さらに、印刷オブジェクトにはプリンタドライバの仕様に固有の情報についても保持されているが、これについては、プリンタドライバごとにその内部構造が異なるためアプリケーションは直接現在の設定を参照したり、更新したりすることができない。従って、アプリケーションはプリンタドライバの用意した拡張ＤＤＩを利用してプリンタドライバ固有の印刷情報のやりとりを行っている。つまり、Ｂｒｉｄｇｅモジュール505は、アプリケーションが拡張ＤＤＩを利用して印刷情報をコントロールする場合において、拡張ＤＤＩ命令のアプリケーション側からの入力情報を印刷オブジェクトの形で受け付ける。

図６は、本発明の実施形態における図５に示すＢｒｉｄｇｅモジュール505が、適切に対象プリンタに対応したプリンタドライバの用意した拡張ＤＤＩを決定する場合の、印刷システムＡ用プリンタドライバとＣＵＰＳ用プリンタドライバの決定処理の流れを表すフローチャートである。ステップ601で、Ｂｒｉｄｇｅモジュールは、Ｃｏｃｏａ用インターフェース、Ｃａｒｂｏｎ用インターフェース、いずれかのインターフェースを用いてアプリケーション側から印刷オブジェクトを受け取る。次にステップ602に進み、印刷オブジェクトの中の設定情報を参照して、所望の対象プリンタの名称を検索する。ステップ602で検索した結果、得られた対象プリンタの名称をもとに、Ｍａｃ ＯＳ Ｘシステムが提供するＡＰＩを利用して、各プリンタの機種固有の情報を記述した設定情報ファイルを取得することができる（ステップ603）。本実施の形態においては、設定情報ファイルは「ＰＰＤファイル」に相当する。続いてステップ604で、取得した設定情報ファイルに記述されている情報を参照して、対応している印刷システムが印刷システムＡであるのか、ＣＵＰＳ印刷システムであるのかを判別し（ステップ605）、対応した拡張ＤＤＩを決定する（ステップ606）。

このように、印刷システムＡ用拡張ＤＤＩとＣＵＰＳ用拡張ＤＤＩのいずれかを判別している。

図７は、本発明の実施形態における図５に示すＢｒｉｄｇｅモジュール505について、アプリケーションが拡張ＤＤＩを利用して印刷情報をコントロールする場合に、図６に示す印刷システム決定処理にて決定した拡張ＤＤＩと、アプリケーションとの組み合わせで正常に動作するかどうかの決定するアーキテクチャ判別処理の流れを表すフローチャートである。ここで、本発明の実施形態におけるＢｒｉｄｇｅモジュールは、アプリケーションの仕様（32ビットまたは、64ビット）に従って正常に動作する必要があるため、ファットバイナリ形式である。図６に示す印刷システム決定処理にて決定した拡張ＤＤＩに対して、Ｂｒｉｄｇｅモジュールはアプリケーションから拡張ＤＤＩ命令を受け取り対象となる拡張ＤＤＩに受け渡す。このとき、対象となる拡張ＤＤＩがアプリケーションの起動アーキテクチャ（32ビットまたは、64ビット）に対応しているか否かの判別を行う（ステップ701）。具体的には、対象となる拡張ＤＤＩに拡張ＤＤＩ命令を直接実行するのではなく、各種拡張ＤＤＩ命令を実現するために拡張ＤＤＩが用意している関数のポインタの取得を行う。Ｂｒｉｄｇｅモジュールは、ポインタの取得が成功した場合に、アプリケーションの起動アーキテクチャと同じバイナリコードを拡張ＤＤＩが含んでいると判断できる（ステップ702／Ｙｅｓ）。その後、拡張ＤＤＩへのアクセスを開始して拡張ＤＤＩ命令を実行し（ステップ703）、印刷設定情報のコントロールを行う（ステップ704）。Ｂｒｉｄｇｅモジュールが、ポインタの取得に失敗した場合には、アプリケーションの起動アーキテクチャと同じバイナリコードを拡張ＤＤＩが含んでいないため（ステップ702／Ｎｏ）、ステップ705に進みアプリケーションにプリンタドライバが非サポートである旨を通知する。

このように、対象とする拡張ＤＤＩが正常に動作するためのバイナリコードを含んでいるのか否かを判断している。

以上の処理により、アプリケーションがプリンタドライバの用意している拡張ＤＤＩを利用して直接印刷情報を制御する場合に、アプリケーション側は、自身の開発環境に適したインターフェースを利用して、起動アーキテクチャを意識することなく、適切な印刷システムに準ずるプリンタドライバに対して印刷処理を実行することが可能となる。

本発明の情報処理装置のハードウェア構成を説明するためのブロック図である。 本発明の情報処理装置で動作するソフトウェア構成を説明するためのブロック図である。 本発明の情報処理装置で動作する印刷システムＡとＣＵＰＳ印刷システムが共存する環境におけるオペレーティングシステムの全体の概略構成を説明するためのブロック図である。 Ｍａｃ ＯＳ Ｘ（登録商標）における、ファットバイナリ形式と非ファットバイナリ形式のプリンタドライバとアプリケーションとの共存の仕組みを説明するためのブロック図である。 本発明の第一実施形態における、プリンタドライバの構成を説明するためのブロック図である。 本発明の第一実施形態における、印刷システム判別を行う動作の流れを説明するためのフローチャートである。 本発明の第一実施形態における、アーキテクチャ判別を行う動作の流れを説明するためのフローチャートである。

Claims (10)

1. 接続された印刷装置に対して印刷用データを提供する情報処理装置において、アプリケーションからは直接読み書きできない印刷情報を制御可能な拡張モジュールを有するプリンタドライバであって、アプリケーションからの描画出力に応じて処理可能なプリンタドライバが、第一の印刷システムからの第一態様の印刷設定情報と第一態様の印刷データの入力を受け付け、プリンタで印刷可能なプリントデータを生成する第一態様のプリンタドライバであるか、第二の印刷システムからの第二態様の印刷設定情報と第二態様の印刷データの入力を受け付け、プリンタで印刷可能なプリンタデータを生成する第二態様のプリンタドライバであるかを判別する印刷システム判別手段と、第一種類のアプリケーションからの描画出力命令と、第二種類のアプリケーションからの描画出力命令を受け付ける描画出力命令受け付け手段と、前記受け付けた描画出力命令に応じて、前記拡張モジュールが出力元のアプリケーションのアーキテクチャ仕様と一致するかを判別するアーキテクチャ判別手段と、
   を有することを特徴とする情報処理装置。
2. 前記拡張モジュールは、プリンタドライバとアプリケーションとの間でプリンタドライバ固有の設定情報をやり取りするために、オペレーティングシステムが提供する印刷オブジェクトを受け取る手段を備えた拡張インターフェースを有することを特徴とする請求項１に記載の情報処理装置。
3. 前記印刷システム判別手段は、前記アプリケーションから受信した前記印刷オブジェクトに対してプリンタ名称を検索し、検索した前記プリンタ名称からプリンタ固有の情報を格納した設定情報ファイルを取得し、前記印刷システム固有の識別情報に基づいて前記第一の印刷システムであるか、前記第二の印刷システムであるかを判別することを特徴とする請求項１または請求項２に記載の情報処理装置。
4. 前記アーキテクチャ判別手段は、前記拡張モジュールが前記出力元のアプリケーションのアーキテクチャ仕様と一致しないと判断された場合に、前記拡張モジュールが前記出力元のアプリケーションにエラーを通知するエラー通知手段を有することを特徴とする請求項１〜請求項３のいずれかに記載の情報処理装置。
5. 接続された印刷装置に対して印刷用データを提供する情報処理装置の情報処理方法において、アプリケーションからは直接読み書きできない印刷情報を制御可能な拡張モジュールを有するプリンタドライバであって、アプリケーションからの描画出力に応じて処理可能なプリンタドライバが、第一の印刷システムからの第一態様の印刷設定情報と第一態様の印刷データの入力を受け付け、プリンタで印刷可能なプリントデータを生成する第一態様のプリンタドライバであるか、第二の印刷システムからの第二態様の印刷設定情報と第二態様の印刷データの入力を受け付け、プリンタで印刷可能なプリンタデータを生成する第二態様のプリンタドライバであるかを判別する印刷システム判別工程と、第一種類のアプリケーションからの描画出力命令と、第二種類のアプリケーションからの描画出力命令を受け付ける描画出力命令受け付け工程と、前記受け付けた描画出力命令に応じて、前記拡張モジュールが出力元のアプリケーションのアーキテクチャ仕様と一致するかを判別するアーキテクチャ判別工程と、を含むことを特徴とする情報処理方法。
6. 前記拡張モジュールは、プリンタドライバとアプリケーションとの間でプリンタドライバ固有の設定情報をやり取りするために、オペレーティングシステムが提供する印刷オブジェクトを受け取る工程を備えた拡張インターフェースを有することを特徴とする請求項５に記載の情報処理方法。
7. 前記印刷システム判別工程は、前記アプリケーションから受信した前記印刷オブジェクトに対してプリンタ名称を検索し、検索した前記プリンタ名称からプリンタ固有の情報を格納した設定情報ファイルを取得し、前記印刷システム固有の識別情報に基づいて前記第一の印刷システムであるか、前記第二の印刷システムであるかを判別する工程を備えたことを特徴とする請求項５または請求項６に記載の情報処理方法。
8. 前記アーキテクチャ判別工程は、前記拡張モジュールが前記出力元のアプリケーションのアーキテクチャ仕様と一致しないと判断された場合に、前記拡張モジュールが前記出力元のアプリケーションにエラーを通知するエラー通知工程を有することを特徴とする請求項５〜請求項７のいずれかに記載の情報処理方法。
9. 請求項５〜請求項８のいずれかに記載の情報処理方法を実行するコンピュータで読取り可能なプログラム。
10. 請求項９に記載のプログラムを記憶したコンピュータで読取り可能な記憶媒体。

Images