JP2006239946A - 印刷制御装置及びその制御方法とデバイスドライバ - Google Patents

Abstract

【課題】 ＧＤＩドライバを一度開発すれば、以後どのようなデバイスであっても修正することなくそのまま使用できる。
【解決手段】 ＧＤＩドライバにより、ＮＧＰＰグラフィックエンジン仕様のスプールフォーマット５０５を生成し、そのスプールフォーマットを用いてＮＧＰＰグラフィックエンジン仕様のアプリケーションを起動し、そのＮＧＰＰグラフィックエンジン仕様のアプリケーションにより、そのスプールフォーマット５０５に基づいて印刷を実行させる。
【選択図】 図５

Description

本発明は、互いに異なる２つのグラフィックエンジンを用いて印刷処理を実行する印刷制御装置及びその制御方法とデバイスドライバに関するものである。

複数のＯＳに対応したプリンタドライバをより効率的に開発するために、第１のＯＳからの描画コマンドと第２のＯＳからの描画コマンドとをＯＳ非依存形式の共通のスプールデータに変換し、ＯＳ非依存形式の共通のスプールデータをＯＳ共通のレンダラに渡し、印刷コマンドを生成することが特許文献１に開示されている。

また、２００４年米国シアトルにおいて、ハードウェアエンジニアリングカンファレンスWinHEC 2004がマイクロソフト社によって開催された。この場にて、マイクロソフト社の次世代のプリンティングシステム（NextGen Print Path：以後ＮＧＰＰと記す）の概要が紹介された。

このＮＧＰＰは、ＧＤＩ（Graphic Device Interface）に代わる新しいグラフィックエンジンAvalonに、ネイティブに対応したマイクロソフトの次世代のプリンティングシステムである。このＮＧＰＰにおいては、印刷ジョブのスプールフォーマットもＧＤＩベースのEnhanced Metafile（以後、ＥＭＦと記す）に代わり、新しいファイル形式（NextGen Spool File：以後ＮＧＳＦと記す）に置き換わる。

図３は、ＮＧＰＰを初めとするプリントパスの概要を説明する図である。

図において、新プリントパスがＮＧＰＰで、旧プリントパスはＧＤＩプリントパスである。ＮＧＰＰドライバが存在しない場合、NextGen転換プリントパスが使われる。これらの関係より次のことが明らかになる。
・Avalonアプリケーション３０３は、ＮＧＰＰドライバ３０４を使用する（右上から右下へ）。
・Ｗｉｎ３２アプリケーション３０１は、ＧＤＩドライバ３０２を使用する（左上から左下）。
・Avalonアプリケーション３０３は、ＮＧＰＰドライバ３０４が存在しない場合、NextGen転換プリントパスによりＧＤＩドライバ３０２を使用する（右上から左下）。

つまり、いかなる場合であってもＧＤＩドライバ３０２は常に必要で、ＮＧＰＰドライバ３０４はオプション扱いという位置付けになる。
特開平１１−１１０１５１号公報

今後、プリンタドライバを開発する各社の開発戦略において、ＮＧＰＰに投資してＧＤＩプリントパスに投資しないという選択をする企業が増えてくると思われる。しかしながら上述したプリンティングシステムの構成上、ＧＤＩドライバを必ず開発しなければならなくなるため、ＧＤＩプリントパスへの投資は避けられず、開発コスト上、大きな負担になることが容易に予想される。

本発明は、上記従来技術の欠点を解決することにある。

また本願発明の特徴は、汎用のＧＤＩを用いて次世代のプリントパスに対応する汎用のスプールファイルを作成し、次世代のアプリケーションにその汎用のスプールファイルを渡すことにより、次世代のアプリケーションに対応したデバイスドライバを提供できることにある。

上記特徴は、独立クレームに記載の特徴の組み合わせにより達成され、従属項は発明の単なる有利な具体例を規定するものである。

本発明の一態様に係るデバイスドライバは以下のような構成を備える。即ち、
互いに異なる第１及び第２グラフィックエンジンが混在したコンピュータＯＳ上で実行可能なデバイスドライバであって、
前記第２グラフィックエンジン仕様のスプールフォーマットを生成する前記第１グラフィックエンジン仕様の第１デバイスドライバと、
前記第１デバイスドライバにより前記スプールフォーマットを用いて前記第２グラフィックエンジン仕様のアプリケーションを起動させる手段と、
前記第２グラフィックエンジン仕様の前記アプリケーションにより前記スプールフォーマットに基づいて印刷を実行させる前記第２グラフィックエンジン仕様の第２デバイスドライバとを有することを特徴とする。

本発明の一態様に係る印刷制御装置は以下のような構成を備える。即ち、
ＯＳ上で互いに異なる第１及び第２グラフィックエンジンを実行可能な印刷制御装置であって、
前記第２グラフィックエンジン仕様のスプールフォーマットを生成する前記第１グラフィックエンジン仕様の第１デバイスドライバと、
前記第１デバイスドライバにより前記スプールフォーマットを用いて前記第２グラフィックエンジン仕様のアプリケーションを起動させる手段と、
前記第２グラフィックエンジン仕様の前記アプリケーションにより前記スプールフォーマットに基づいて印刷データを印刷装置に出力する前記第２グラフィックエンジン仕様の第２デバイスドライバとを有することを特徴とする。

本発明の一態様に係る印刷制御装置の制御方法は以下のような工程を備える。即ち、
ＯＳ上で互いに異なる第１及び第２グラフィックエンジンを実行可能な印刷制御装置における制御方法であって、
前記第１グラフィックエンジン仕様の第１デバイスドライバにより、前記第２グラフィックエンジン仕様のスプールフォーマットを生成する工程と、
前記第１デバイスドライバにより前記スプールフォーマットを用いて前記第２グラフィックエンジン仕様のアプリケーションを起動させる工程と、
前記第２グラフィックエンジン仕様の第２デバイスドライバにより、前記第２グラフィックエンジン仕様の前記アプリケーションにより前記スプールフォーマットに基づいて印刷データを印刷装置に出力する工程とを有することを特徴とする。

尚、この発明の概要は、必要な特徴を全て列挙しているものでなく、よって、これら特徴群のサブコンビネーションも発明になり得る。

本発明によれば、ＧＤＩドライバを一度開発すれば、以後どのようなデバイスであっても修正することなくそのまま使用できる。

以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。尚、この実施の形態に係る情報処理装置としてコンピュータ機器（ＰＣ）の場合で説明する。

図１は、本発明の実施の形態に係るコンピュータ（ＰＣ）を含むプリンタ制御システムの構成を説明するブロック図である。尚、特に断らない限り、本実施の形態の機能が実行されるのであれば、単体の機器であっても、複数の機器からなるシステムであっても、或はＬＡＮ，ＷＡＮ等のネットワークを介して複数の装置が接続されて処理が行われるシステムであっても本発明を適用できることは言うまでもない。

図において、ホストコンピュータ３０００は、ＲＯＭ３のプログラム用ＲＯＭ或は外部メモリ１１に記憶された文書処理プログラム等に基づいて図形、イメージ、文字、表（表計算等を含む）等が混在した文書処理を実行するＣＰＵ１を備え、システムバス４に接続される各デバイスをＣＰＵ１が総括的に制御する。また、このＲＯＭ３のプログラム用ＲＯＭ或は外部メモリ１１には、ＣＰＵ１の制御プログラムであるオペレーティングシステムプログラム（以下ＯＳ）等が記憶されており、ＲＯＭ３のフォント用ＲＯＭ或は外部メモリ１１には、上記文書処理の際に使用するフォントデータ等が記憶されており、ＲＯＭ３のデータ用ＲＯＭ或は外部メモリ１１には、上記文書処理等を行う際に使用する各種データが記憶されている。ＲＡＭ２は、ＣＰＵ１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）５は、キーボード９や不図示のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）６は、ＣＲＴディスプレイ（ＣＲＴ）１０の表示を制御する。ディスクコントローラ（ＤＫＣ）７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタ制御コマンド生成プログラム（以下プリンタドライバ）等を記憶するハードディスク（ＨＤ）、フロッピー（登録商標）ディスク（ＦＤ）等の外部メモリ１１とのアクセスを制御する。プリンタコントローラ（ＰＲＴＣ）８は、所定の双方向性インターフェース２１を介してプリンタ１５００に接続されて、プリンタ１５００との通信制御処理を実行する。尚、ＣＰＵ１は、例えばＲＡＭ２上に設定された表示用ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ＣＲＴ１０上でのＷＹＳＩＷＹＧを可能としている。またＣＰＵ１は、ＣＲＴ１０上の不図示のマウスカーソル等で指示されたコマンドに基づいて登録された種々のウインドウを開き、種々のデータ処理を実行する。これによりユーザは印刷を実行する際、印刷の設定に関するウインドウを開き、プリンタの設定や、印刷モードの選択を含むプリンタドライバに対する印刷処理方法の設定を行える。

次にプリンタ１５００の構成を説明する。プリンタＣＰＵ１２は、ＲＯＭ１３のプログラム用ＲＯＭに記憶された制御プログラム等或は外部メモリ１４に記憶された制御プログラム等に基づいてシステムバス１５に接続される印刷部（プリンタエンジン）１７に出力情報としての画像信号を出力する。また、このＲＯＭ１３のプログラム用ＲＯＭには、ＣＰＵ１２の制御プログラム等が記憶されている。ＲＯＭ１３のフォント用ＲＯＭは、上記出力情報を生成する際に使用するフォントデータ等を記憶し、ＲＯＭ１３のデータ用ＲＯＭは、ハードディスク等の外部メモリ１４がないプリンタの場合には、ホストコンピュータ３０００で利用される情報等を記憶している。

ＣＰＵ１２は入力部１８を介してホストコンピュータ３０００との通信処理が可能となっており、プリンタ１５００の情報等をホストコンピュータ３０００に通知可能に構成されている。ＣＰＵ１２の主メモリ、ワークエリア等として機能するＲＡＭ１９は、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。尚、このＲＡＭ１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。前述したハードディスク（ＨＤ）、ＩＣカード等の外部メモリ１４は、メモリコントローラ（ＭＣ）２０によりアクセスを制御される。外部メモリ１４はオプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、入力部１８は、前述した操作パネルで操作のためのスイッチおよびＬＥＤ表示器等が配されている。また、前述した外部メモリ１４は１個に限らず、少なくとも１個以上備え、内蔵フォントに加えてオプションフォントカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。更に、図示しないＮＶＲＡＭを有し、操作パネル１５０１を使用して設定されたプリンタのモード設定情報を記憶するようにしてもよい。

図２は、本実施の形態に係るホストコンピュータ３０００における典型的な印刷データの生成方法を説明する図である。

アプリケーション２０１、グラフィックエンジン２０２、プリンタドライバ２０３及びシステムスプーラ２０４は、ハードディスクなどの外部メモリ１１に保存されたファイルとして存在し、ＯＳやそのモジュールを利用するモジュールによってＲＡＭ２にロードされ実行されるプログラムモジュールである。また、アプリケーション２０１及びプリンタドライバ２０３は、外部メモリ１１のＦＤや不図示のＣＤ−ＲＯＭ、或は不図示のネットワークを経由して外部ディスク１１のＨＤに追加することが可能となっている。また外部メモリ１１に保存されているアプリケーション２０１は、ＲＡＭ２にロードされて実行されるが、このアプリケーション２０１からプリンタ１５００に対して印刷を行う際には、同様にＲＡＭ２にロードされて実行可能となっているグラフィックエンジン２０２を利用して出力（描画）を行う。このグラフィックエンジン２０２は、プリンタごとに用意されたプリンタドライバ２０３を、外部メモリ１１からＲＡＭ２にロードし、アプリケーション２１０の出力をプリンタドライバ２０３を用いてプリンタ１５００の制御コマンドに変換する。こうして変換されたプリンタ制御コマンドは、ＯＳによってＲＡＭ２にロードされたシステムスプーラ２０４を経て、インターフェース２１を経由してプリンタ１５００へ出力され、プリンタ１５００による印刷処理が実行される。

図４は、本実施の形態に係るホストコンピュータ３０００におけるアプリケーション２０１と、各プリンタ用のプリンタドライバ２０３ａ，２０３ｂとの関係を説明する模式図である。

アプリケーション２０１は、オペレーティングシステム２１０が提供する各種関数（ＡＰＩ）をコールして処理を行い、オペレーティングシステム２１０は印刷に関わる処理を、選択されているプリンタのプリンタドライバが提供する関数（ＤＤＩ）をコールして処理を行う。こうしてアプリケーション２０１から選択されたプリンタドライバ２０３ａ，２０３ｂに対応するプリンタにおける印刷処理が可能となっている。

図５は、本実施の形態に係るアプリケーション層からＯＳ層、ドライバ層、デバイス層までの印刷データの流れを示した図である。

Ｗｉｎ３２アプリケーション５０１が、ＧＤＩ５０２のＡＰＩを呼び出して印刷処理を実行すると、中間スプールファイルとしてＥＭＦ５０３が生成される。そして、このＥＭＦ５０３からドライバ関数（ＤＤＩ）の呼び出しに置き換わりＧＤＩドライバ５０４が呼び出される。このＧＤＩドライバ５０４はＰＤＬを出力しない。その代わり、ＮＧＰＰのスプールファイルであるＮＧＳＦ５０５を生成する。更に、このＧＤＩドライバ５０４の中から独自のAvalonアプリケーション５０６を起動し、そのAvalonアプリケーション５０６に、その生成したＮＧＳＦ５０５を渡す。このＮＧＳＦ５０５の生成処理の詳細は、図６のフローチャートを参照して後述する。

ＧＤＩドライバ５０４から起動されたAvalonアプリケーション５０６は、ＯＳ層のAvalon５０７のＡＰＩを呼び出してＮＧＳＦの印刷を実行する。ここでは詳細を述べないが、この段階で、ＮＧＳＦ５０５内の描画データのレイアウトを編集することも可能である。ここではAvalon５０７のＡＰＩにより中間スプールファイルとしてＮＧＳＦ５０８が生成される。尚、ここで必ずしもＮＧＳＦ５０５とＮＧＳＦ５０８とは一致するとは限らない。ＮＧＰＰドライバ５０９は、この生成されたＮＧＳＦ５０８を読み込み、ＰＤＬ５１０へ変換してプリンタ１５００に出力する。このＰＤＬ変換の詳細は、図１０のフローチャートを参照して後述する。尚、ここでＰＤＬ５１０を出力せず、ＧＤＩドライバ５０４のように、再度Avalonアプリケーション５０６を起動し、その編集したＮＧＳＦ５０８を、再度印刷し直してもよい。

以上の説明より、ＧＤＩドライバ５０４は、プリンタ１５００及びＰＤＬ５１０と依存関係がないことがわかる。このようなＧＤＩドライバ５０４の汎用性の高さが本実施の形態における特徴である。

図６は、本実施の形態に係るＧＤＩドライバ５０４がＮＧＳＦ５０５を生成する処理を説明するフローチャートである。尚、このフローチャートでは、ＧＤＩ特有の描画データ（例えばＲＯＰ）をAvalonの描画データに変換するのは困難であるため、そのＧＤＩ特有の描画データをアルファチャンネルに置き換えたスプールファイルを作成している。

通常の印刷ではドキュメントは複数のページから構成され、ページは複数の描画ＤＤＩ（Device Driver Interface）から構成される。つまり、このフローチャートで示される処理は、描画ＤＤＩが一回呼び出されたときの処理のみ記述しているので、この処理はページ内において複数回繰り返され、更に、そのページも複数回繰り返される。その結果、印刷物としてのドキュメントが生成されることになる。以上を踏まえ、このフローチャートの詳細を説明する。

まずステップＳ１でＤＤＩが呼び出される。このＤＤＩは関数で、引数として描画に必要な様々なパラメータが渡されてくる。次にステップＳ２で、その入力されたＤＤＩのパラメータと、後述するステップＳ４で保存しておいたＤＤＩパラメータとを組み合わせて、アルファブレンド処理に置き換え可能かどうか判定する。置き換え可能な場合はステップＳ３に進み、それ以外の場合はステップＳ６へ進む。尚、このアルファブレンド置き換え条件の詳細については、図７及び図８を参照して後述する。

ステップＳ３では、ステップＳ２で得た一連のＤＤＩパターンの形成が完了したかどうか判定する。一連のＤＤＩパターンの形成がまだ完了していない場合はステップＳ４へ進み、ステップＳ１で得たＤＤＩを保存する。形成が完了していればステップＳ５へ進み、ステップＳ２で得た一連のＤＤＩパターンをアルファブレンド処理に置き換えてＮＧＳＦ５０５を出力する。

一方ステップＳ６では、ステップＳ４で保存しておいたＤＤＩ群をＮＧＳＦ５０５に拡張・変換しながら出力する。この拡張変換の詳細については後述する。次にステップＳ７で、ステップＳ１で得たＤＤＩがＲＯＰを使用しているかどうか判定する。使用していない場合はステップＳ８へ進み、使用している場合はステップＳ９へ進む。ステップＳ８では、ステップＳ１で得たＤＤＩをＮＧＳＦ５０５に変換して出力する。またステップＳ９では、ステップＳ１で得たＤＤＩをＮＧＳＦ５０５に拡張・変換して出力する。

図７及び図８は、ＤＤＩをアルファブレンド処理に置き換える処理の一例を説明する図で、図７はＤＤＩ、図８はアルファブレンド処理を示している。

図７は、ＲＯＰを用いてビットマップの背景を透かしながらビットマップを描画する典型的な例を示している。具体的には、DrvBitBltというビットマップ系ＤＤＩ関数が、ステップ１とステップ２で２回連続描画される。ステップ１では、２値の白黒画像を下地に対し論理積の論理描画（ＲＯＰではSRCANDと表現される）を行う。

ステップ２では、背景が黒いビットマップを、ステップ１で生成された下地に対し論理和の論理描画（ＲＯＰではSRCPAINTと表現される）を行う。

以上の描画によって、下地に対しビットマップの特定の色を透かしながらビットマップを描画できるようになる。

図８は、アルファブレンドを用いてビットマップの背景を透かしながらビットマップを描画する典型的な例を示す。ここでは２値の白黒画像を基に、アルファブレンドの指定を振り分けて描画する。この例では白黒画像の黒が不透明を示し、白は透明を示す。

以上より、図７のＲＯＰを用いた複数回の描画方法と、図８のアルファブレンドを用いた１回の描画方法により同一の描画結果が得られることがわかる。

図９は、ＤＤＩを拡張変換して拡張ＮＧＳＦを生成する処理例を説明する図である。

ＮＧＳＦにはＲＯＰを記述する方法は無い。しかしながら、ＮＧＳＦの描画部はＸＭＬで記述できるので、９０１で示すように独自のネームスペースを定義することによって、アルファブレンドにより置き換えることができないＲＯＰの記述を拡張してＮＧＳＦに追記できる。９０１では、ＲＯＰ３コード「ＳＲＣＡＮＤ」を記述している。これにより、いかなるＲＯＰでもＮＧＳＦで定義することができる。

図１０は、ＮＧＰＰドライバ５０９がＰＤＬ５１０を生成する処理フローの概略を示すフローチャートである。

まずステップＳ１１で、ＮＧＳＦ５０８が入力される。次にステップＳ１２で、描画方式を判定する。出力データをベクターグラフィックとして描画処理をする場合はステップＳ１３に進み、それ以外、即ちラスタイメージとして描画処理する場合はステップＳ１６に進む。ステップＳ１３では、ＮＧＳＦが拡張されているかどうか調べる。ここで前述の図６のステップＳ６やステップＳ９を経てきたならばＮＧＳＦは拡張されていることになる。ＮＧＳＦが拡張されていればステップＳ１４に進み、それ以外の場合はステップＳ１５に進む。ステップＳ１４では、ＰＤＬ５１０がＲＯＰを処理可能かどうか判定する。処理可能な場合はステップＳ１５に進み、それ以外の場合はステップＳ１６に進む。ステップＳ１５では、ベクタグラフィックデータを有するＰＤＬ５１０を出力する。一方、ステップＳ６では、ラスタイメージデータを有したＰＤＬ５１０を出力する。

以上説明したように本実施の形態によれば、ＧＤＩドライバを一度開発すれば、以後どのようなデバイスであっても修正することなくそのまま使用できる。

また開発行為においてＮＧＰＰのみ注力可能なので開発コストは激減する。

しかも、本来Avalonで表現不可能なＧＤＩ特有のラスタオペレーション（Raster Operation：以後ＲＯＰと記す）を使った描画であっても正常に印刷可能となる。以上より、プリンタドライバ開発の生産性を大きく向上させることができる。

なお本発明は、前述した実施の形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが、その供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。その他のプログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。

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

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

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

本発明の実施の形態に係るコンピュータ（ＰＣ）を含むプリンタ制御システムの構成を説明するブロック図である。 本実施の形態に係るホストコンピュータにおける典型的な印刷データ生成方法を説明する図である。 ＮＧＰＰを初めとするプリントパスの概要を説明する図である。 本実施の形態に係るホストコンピュータにおけるアプリケーションと、各プリンタ用のプリンタドライバとの関係を説明する模式図である。 本実施の形態に係るアプリケーション層からＯＳ層、ドライバ層、デバイス層までの印刷データの流れを示した図である。 本実施の形態に係るＧＤＩドライバがＮＧＳＦを生成する処理を説明するフローチャートである。 ＤＤＩをアルファブレンド処理に置き換える処理の一例を説明する図で、ＤＤＩ処理を示している。 ＤＤＩをアルファブレンド処理に置き換える処理の一例を説明する図で、アルファブレンド処理を示している。 本発明の一実施形態としての拡張ＮＧＳＦの例。 ＮＧＰＰドライバがＰＤＬを生成する処理フローの概略を示すフローチャートである。

Claims (14)

1. 互いに異なる第１及び第２グラフィックエンジンが混在したコンピュータＯＳ上で実行可能なデバイスドライバであって、
   前記第２グラフィックエンジン仕様のスプールフォーマットを生成する前記第１グラフィックエンジン仕様の第１デバイスドライバと、
   前記第１デバイスドライバにより前記スプールフォーマットを用いて前記第２グラフィックエンジン仕様のアプリケーションを起動させる手段と、
   前記第２グラフィックエンジン仕様の前記アプリケーションにより前記スプールフォーマットに基づいて印刷を実行させる前記第２グラフィックエンジン仕様の第２デバイスドライバと、
   を有することを特徴とするデバイスドライバ。
2. 前記第１デバイスドライバは更に、前記第２グラフィックエンジンではサポートされない前記第１グラフィックスエンジン特有の描画データを前記第２グラフィックエンジン仕様のグラフィックエンジンに適合した形式に変換する手段を有することを特徴とする請求項１に記載のデバイスドライバ。
3. 前記第１デバイスドライバは、前記第２グラフィックエンジンではサポートされない前記第１グラフィックスエンジン特有の描画データを拡張された前記第２グラフィックエンジン仕様のスプールフォーマットに記述する手段を有し、
   前記第２デバイスドライバは、前記拡張された前記第２グラフィックエンジン仕様の前記スプールフォーマットをＰＤＬに変換する手段を有することを特徴とする請求項１又は２に記載のデバイスドライバ。
4. 前記第１グラフィックエンジンは旧タイプのグラフィックエンジンで、前記第２グラフィックエンジンは新タイプのグラフィックエンジンであることを特徴とする請求項１に記載のデバイスドライバ。
5. ＯＳ上で互いに異なる第１及び第２グラフィックエンジンを実行可能な印刷制御装置であって、
   前記第２グラフィックエンジン仕様のスプールフォーマットを生成する前記第１グラフィックエンジン仕様の第１デバイスドライバと、
   前記第１デバイスドライバにより前記スプールフォーマットを用いて前記第２グラフィックエンジン仕様のアプリケーションを起動させる手段と、
   前記第２グラフィックエンジン仕様の前記アプリケーションにより前記スプールフォーマットに基づいて印刷データを印刷装置に出力する前記第２グラフィックエンジン仕様の第２デバイスドライバと、
   を有することを特徴とする印刷制御装置。
6. 前記第１デバイスドライバは更に、前記第２グラフィックエンジンではサポートされない前記第１グラフィックスエンジン特有の描画データを前記第２グラフィックエンジン仕様のグラフィックエンジンに適合した形式に変換する手段を有することを特徴とする請求項５に記載の印刷制御装置。
7. 前記第１デバイスドライバは、前記第２グラフィックエンジンではサポートされない前記第１グラフィックスエンジン特有の描画データを拡張された前記第２グラフィックエンジン仕様のスプールフォーマットに記述する手段を有し、
   前記第２デバイスドライバは、前記拡張された前記第２グラフィックエンジン仕様の前記スプールフォーマットをＰＤＬに変換する手段を有することを特徴とする請求項５又は６に記載の印刷制御装置。
8. 前記第１グラフィックエンジンは旧タイプのグラフィックエンジンで、前記第２グラフィックエンジンは新タイプのグラフィックエンジンであることを特徴とする請求項５に記載の印刷制御装置。
9. ＯＳ上で互いに異なる第１及び第２グラフィックエンジンを実行可能な印刷制御装置における制御方法であって、
   前記第１グラフィックエンジン仕様の第１デバイスドライバにより、前記第２グラフィックエンジン仕様のスプールフォーマットを生成する工程と、
   前記第１デバイスドライバにより前記スプールフォーマットを用いて前記第２グラフィックエンジン仕様のアプリケーションを起動させる工程と、
   前記第２グラフィックエンジン仕様の第２デバイスドライバにより、前記第２グラフィックエンジン仕様の前記アプリケーションにより前記スプールフォーマットに基づいて印刷データを印刷装置に出力する工程と、
   を有することを特徴とする印刷制御装置における制御方法。
10. 前記第１デバイスドライバは更に、前記第２グラフィックエンジンではサポートされない前記第１グラフィックスエンジン特有の描画データを前記第２グラフィックエンジン仕様のグラフィックエンジンに適合した形式に変換する工程を有することを特徴とする請求項９に記載の印刷制御装置における制御方法。
11. 前記第１デバイスドライバは、前記第２グラフィックエンジンではサポートされない前記第１グラフィックスエンジン特有の描画データを拡張された前記第２グラフィックエンジン仕様のスプールフォーマットに記述する工程を有し、
    前記第２デバイスドライバは、前記拡張された前記第２グラフィックエンジン仕様の前記スプールフォーマットをＰＤＬに変換する工程を有することを特徴とする請求項９又は１０に記載の印刷制御装置における制御方法。
12. 前記第１グラフィックエンジンは旧タイプのグラフィックエンジンで、前記第２グラフィックエンジンは新タイプのグラフィックエンジンであることを特徴とする請求項８に記載の印刷制御装置における制御方法。
13. 第１グラフィックエンジン及びＲＯＰを処理不可能な第２グラフィックエンジンが混在したコンピュータＯＳ上で実行可能なデバイスドライバであって、
    ＲＯＰをアルファブレンド処理に置き換えることにより前記第２グラフィックエンジン仕様のスプールフォーマットを生成する前記第１グラフィックエンジン仕様の第１デバイスドライバと、
    前記第１デバイスドライバにより前記スプールフォーマットを用いて前記第２グラフィックエンジン仕様のアプリケーションを起動させる手段と、
    前記第２グラフィックエンジン仕様の前記アプリケーションにより前記スプールフォーマットに基づいて印刷を実行させる前記第２グラフィックエンジン仕様の第２デバイスドライバと、
    を有することを特徴とするデバイスドライバ。
14. ＲＯＰを処理可能な第１グラフィックエンジン及びＲＯＰを処理不可能な第２グラフィックエンジンを実行可能な印刷制御装置における制御方法であって、
    前記第１グラフィックエンジン仕様の第１デバイスドライバにより、ＲＯＰをアルファブレンド処理に置き換えることにより前記第２グラフィックエンジン仕様のスプールフォーマットを生成する工程と、
    前記第１デバイスドライバにより前記スプールフォーマットを用いて前記第２グラフィックエンジン仕様のアプリケーションを起動させる工程と、
    前記第２グラフィックエンジン仕様の第２デバイスドライバにより、前記第２グラフィックエンジン仕様の前記アプリケーションにより前記スプールフォーマットに基づいて印刷データを印刷装置に出力する工程と、
    を有することを特徴とする印刷制御装置における制御方法。

Images