(57)【特許請求の範囲】
【請求項１】
デジタルドキュメントを作成し、複数のプリントオブジェクトを含むドキュメントデータを提供するアプリケーションが動作する手段と、
前記プリントオブジェクトを受信し、これらプリントオブジェクトに対応して作成される内部オブジェクトのセットを形成するためのカラービットマップドライバーが動作する手段とを有し、
前記カラービットマップドライバーが動作する手段は、前記内部オブジェクトのビットマップ出力画像を生成し、前記ビットマップ出力画像は、埋め込まれたレンダリングヒントを含むデジタルドキュメント処理システムであって、
前記カラービットマップドライバーが動作する手段から前記ビットマップ出力画像を受信し、前記ビットマップ出力画像から前記埋め込まれたレンダリングヒントを抽出し、前記ビットマップ出力画像データを出力デバイスで利用可能な出力デバイスエンジンレディデータ内にレンダリングする際に、前記抽出したレンダリングヒントを適用するよう、ファームウェアプロセスを実行するようになっている出力デバイスを備え、
前記カラービットマップドライバーが動作する手段は、前記ビットマップ出力画像のサイズが、レンダリングヒントデータによって増加しないよう、ビットマップ出力画像のデータの中の最下位ビットである最小位カラービット平面のうちの少なくとも１つを再使用することにより、前記ビットマップ出力画像に前記レンダリングヒントを埋め込む、デジタルドキュメント処理システム。
【請求項２】
前記出力デバイスは、ＭＦＰデバイス、ソフトコピーデバイスおよびハードコピーデバイスのうちの１つを含む、請求項１に記載のデジタルドキュメント処理システム。
【請求項３】
前記アプリケーションが動作する手段は、ネットワークに結合され、前記アプリケーションがインストールされたホストコンピュータであって、
前記出力デバイスは、前記ビットマップ画像データを受信するように、前記ネットワークに結合されており、
前記カラービットマップドライバーが動作する手段は、実行可能なソフトウェアプロセスとして前記カラービットマップドライバーが実装されている前記ホストコンピュータである、請求項１に記載のデジタルドキュメント処理システム。
【請求項４】
レンダリングヒントをビットマップ画像に符号化するための方法であって、
カラービットマップドライバーが動作する手段が、複数のプリントオブジェクトを定めるデジタルドキュメントの記述を受信するステップと、
前記カラービットマップドライバーが動作する手段が、前記プリントオブジェクトを複数の内部オブジェクトに変換するステップと、
前記カラービットマップドライバーが動作する手段が、各前記内部オブジェクトに対し、前記デジタルドキュメントを出力デバイスでレンダリングする際に使用するための対応するレンダリングヒントを得るステップと、
前記カラービットマップドライバーが動作する手段が、少なくとも１つの内部オブジェクトに対応するレンダリングヒントのタグを付けるステップと、
前記カラービットマップドライバーが動作する手段が、前記受信したデジタルドキュメントのビットマップ出力画像を形成するステップとを備え、
前記ビットマップ出力画像は、内部オブジェクトに付けられたレンダリングヒントのタグに対応したレンダリングヒントを埋め込まれ、
前記カラービットマップドライバーが動作する手段が、所定のサイズを超えてビットマップ画像を拡張することなく、前記ビットマップ出力画像内に前記レンダリングヒントを埋め込むステップを含む、レンダリングヒントをビットマップ画像に符号化するための方法。
【請求項５】
前記カラービットマップドライバーが動作する手段が、前記ビットマップ出力画像のカラー平面の数を選択するステップと、
前記カラービットマップドライバーが動作する手段が、各カラー平面内のビット平面の数を選択するステップと、
前記カラービットマップドライバーが動作する手段が、前記出力デバイスに送られるプリントデータ内に、前記選択のインデックスを含ませることにより、前記カラー平面およびビット平面の数の選択を出力デバイスに送るステップとを備える、請求項４に記載の方法。
【請求項６】
前記カラービットマップドライバーが動作する手段が、ビットマップに存在する、低い値の情報を含むことになるはずの領域を再使用することにより、前記ビットマップ出力画像内に前記レンダリングヒントを埋め込むステップを含む、請求項４に記載の方法。
【請求項７】
前記ビットマップ出力画像は、標準化された基準カラースペースを有する、デバイスから独立したフォーマットとなっている、請求項４に記載の方法。
【請求項８】
前記ビットマップ出力画像は、ｓＲＧＢフォーマットとなっている、請求項７に記載の方法。
【請求項９】
前記ビットマップ出力画像は、ＴＩＦＦ、ＪＰＥＧ、ＰＮＧ、ＧＩＦ、ＢＭＰ、ＥＸＩＦおよびＷＭＰのうちの１つとコンパーチブルなフォーマットを有する、請求項４に記載の方法。
【請求項１０】
前記ビットマップ出力画像は、３つのカラー平面を含み、各カラー平面が上位ビット平面と下位ビット平面とを有し、
前記上位ビット平面は、画像データを含み、
前記下位ビット平面は、レンダリングヒントデータを含む、請求項４に記載の方法。
【請求項１１】
前記プリントオブジェクトを複数の内部オブジェクトに変換する前記ステップの結果、オブジェクト解像度が変更される、請求項４に記載の方法。
【請求項１２】
前記レンダリングヒントは、エッジ検出、ＵＣＲのパーセント、ハーフトーンアルゴリズム、画像エンハンスメント、カラーリダクションのパーセント、グレースケール置換レベルおよび候補スポットカラー置換のうちの少なくとも１つを示す、請求項５に記載の方法。
【請求項１３】
ドキュメント出力デバイスのプロセッサ内で実行するための、マシンで読み取り可能なメディア内に記憶された、実行可能なコードを含むファームウェアプログラムであって、
入力ビットマップ画像データを受信するためのコードと、
前記入力ビットマップ画像データをラスター出力データにレンダリングするためのコードと、
前記入力ビットマップ画像データの少なくとも１つの下位ビット平面からレンダリングヒントデータを抽出するためのコードとを備え、
前記抽出されたレンダリングヒントデータを前記レンダリングコードへの入力として使用し、前記入力ビットマップ画像データを前記ラスター出力データ内にレンダリングするファームウェアプログラム。
【請求項１４】
前記コードは、多機能周辺ＭＦＰデバイスのプロセッサ内で操作されるようになっている、請求項１３に記載のファームウェアプログラム。
【請求項１５】
前記入力ビットマップ画像は、３つのカラー平面を含み、各カラー平面が上位ビット平面と下位ビット平面とを有し、
前記上位ビット平面は、画像データを含み、
前記下位ビット平面は、レンダリングヒントデータを含む、請求項１３に記載のファームウェアプログラム。
【請求項１６】
前記コードは、プリンタのプロセッサ内で操作するようになっている、請求項１５に記載のファームウェアプログラム。
【請求項１７】
アンダーカラーリダクションの量およびタイプ、その他インクの低減／置換方法およびハーフトーン化アルゴリズムのうちの１つ以上を決定するために、前記プリンタのファームウェアにより、前記レンダリングヒントを使用する、請求項１５に記載のファームウェアプログラム。
【請求項１８】
カラーガムート変換を選択するよう、前記プリンタファームウェアにより前記レンダリングヒントを使用する、請求項１５に記載のファームウェアプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタルドキュメントを処理するための方法および装置に関し、より詳細には、カラープリントプロセスまたはシステムにおいて、レンダリングヒントの使用を改良することに関する。
【背景技術】
【０００２】
異なるタイプのグラフィックに対して、カラーレンダリング技術を調節することは、ドキュメントおよび画像形成ソフトウェアアプリケーションおよびプリンタドライバーで利用できる共通する特徴である。例えばユーザーが、ビジネス用グラフィックをデフォルト設定するよりも、より力強くレンダリングしたり、またはビットマップをより現実的なものにすることを好む場合がある。更に、プリンタもハーフトーンを使用している場合に、スキャンされたハーフトーン画像をプリント時に逆スクリーン化しなければならないこともあり得る。更に、一部のユーザーは、コンピュータで生成されたビットマップをデフォルト設定よりも、より力強くレンダリングし、他方、デジタル写真をより現実的にレンダリングしたいことがある。
【０００３】
グラフィックのクラスに基づき、任意のファイル内でレンダリングオプションを選択できるようにする従来の機構がある。ＨＰ社に譲渡された米国特許第５，７０４，０２１号は、オブジェクトタイプに基づき、ユーザーがカラーレンダリングオプションを選択できるようにするプロセスについて述べている。このプロセスの主要な限界は、クラスのすべてのメンバーに対して同じレンダリングプロセスを実施しなければならないことである。例えば、ユーザーが写真に対して特殊なレンダリングオプションを選択した場合、ファイル内のすべての写真に対して同じレンダリングパラメータが適用される。更に、オブジェクトタイプには３つのタイプしかない。すなわちこのＨＰ社の特許で提供されるクラス（オブジェクトタイプ）は、グラフィック、写真およびテキストの３つである。
【０００４】
プリンタによって処理されるハードコピードキュメントのカラーレンダリングをカスタム化し、補正するための他の改良技術も知られている。例えば、本願出願人に譲渡された米国公開特許出願第２００６／００１７９５５号（２００６年１月２６日）は、任意のタイプの画像処理アプリケーションにおいて、グラフィックインスタンスに対し、カスタムレンダリングオプションを使用できるようにしている。
【０００５】
例えば、特許文献１には、画像データの画素毎に画素の属性領域を設定し、属性情報に基づいて出力画像処理を実施するようにした技術が開示されている。また、特許文献２には、画像データ及び画像データに含まれる画像要素の属性を示すタグデータをそれぞれ符号化圧縮して記憶し、時分割で読み出してそれぞれを伸張して画素単位で対応付けて出力する技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−３４１４４６号公報
【特許文献２】特開平１１−１８７２６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
図１ａは、レンダリングヒントを使用する公知の方法の略図である。図１ａでは、アプリケーションプログラムまたはプロセス１０２は、一般に１つ以上のシーケンシャルページを含む入力デジタルドキュメント１００を受信し、または作成する。作動時に、例えばプリントのためのドキュメントの作成時に、アプリケーションはグラフィックプリミティーブのような一組の要素１０４としてドキュメントデータを出力する。ＰＤＬドライバー１０６のようなプリンタドライバーがプリミティーブオブジェクトを受信し、ドキュメントオブジェクトの各々を異なるレンダリングクラス（例えば写真対ビジネスグラフィック、テキストなど）に分類する。この方法は、各オブジェクトタイプ、例えばハーフトーン化およびカラーマッチングを最適にするために、異なるレンダリング方法およびパラメータを使用している。しかしながら、かかる方法はプリンタドライバー（図示せず）によりドキュメントオブジェクトを完全にラスター化するか、またはページデスクリプション言語（ＰＤＬ）フォーマットのプリントデータと共に、他のタイプのレンダリングヒントをパスしなければならず、次に、ＰＤＬフォーマットデータを再びビットマップにレンダリングしなければならず、次にこのビットマップをラスター化しなければならないので、この結果、処理資源と時間がむだになる。
【０００８】
図１ｂは、上記ＰＤＬアプローチの一変形例を示す。図１ｂの方法によれば、オブジェクトタイプの分類およびオブジェクト固有のレンダリング方法の割り当ての決定をプリントファームウェアインタープリターに任せる。あるモードでは、ページデスクリプション言語（ＰＤＬ）でプリンタにプリントデータ１１２を送る。このプリンタは、ドキュメントのオブジェクトコンポジションをまだ保存しており、このシナリオでは、ファームウェアインタープリター１１４は、次にプリントデータを解釈し、レンダリングする際に、レンダリング方法をオンザフライ方式で分類し、割り当てることができる。米国特許第６，２５６，１０４号および米国特許第６，２７５，３０４号を参照されたい。これら結果１１８は、ラスター画像プロセッサＲＩＰ１２０へ入力される。しかしながら、かかる方法は（１）オブジェクトをプリントするためのドキュメントオブジェクトのドライバーのプリントデータコンポジションは、必ずしも１対１に一致しないことがあること、および（２）プリントデータをＰＤＬフォーマットにしなければならず、その場合、再びプリンタはラスター画像１３０を生成するために、ラスター化機能のすべてを実行しなければならないという点で、深刻な問題を生じさせる。
【０００９】
次に図１ｃを参照する。上記方法の別の変形例では、ホスト上でまずビットマップ画像（例えばカラービットマップカバー）となるようにプリントデータを部分的にラスター化する。次に、ファームウェアにビットマップデータが送られ、ラスター化を完了する（ファームウェアなる用語は、一般にプリンタまたはＭＦＰデバイス内に記憶され、実行されるソフトウェアを意味する）。ビットマップページイメージ１４０を受信したファームウェア１３６は、画像のセグメント化１４４を実行し、基本的にはオブジェクト１４８のアイデンティフィケーション（識別）をリバースエンジニアリングできる。次に、レンダリングヒント１５０によりオブジェクトにはオブジェクトのタイプごとにタグがつけられ、次にこのタグのついたオブジェクトは、レンダリングおよびラスター化ファームウェア１５２によって使用され、ラスター画像１５４内の出力画質を最適にする。この方法には、ファームウェア１３６はビットマップ画像内のオブジェクトのアイデンティフィケーションをリカバーするために、高価なプロセスを実行しなければならないこと、およびセグメント化の結果、一般に元のドキュメントオブジェクトの完全に正確なリカバーを行うことができず、忠実性が損なわれるという問題がある。
【００１０】
次に図１ｄを参照する。別の従来技術の方法では、ホスト側（例えばドライバー）が、ドキュメントオブジェクトをカラーＲＧＢビットマップに部分的にラスター化する。更にホスト側は、４番目のエキストラ平面（例えばＲＧＢＸ）を形成し、ここで４番目の平面は、ドキュメントオブジェクトから誘導されたレンダリングヒントを送るのに使用される。このように、ファームウェアはドキュメントオブジェクトをビットマップデータにラスター化しなくてもよいようにすることにより、かつ、レンダリングヒントをリバースエンジニアリング（例えばセグメント化）しなくてもよいようにすることにより、より高速の性能およびレンダリングヒントが得られるという利点を有する。この方法の不利な点は、ビットマップの一部として４番目のエキストラ平面を送らなければならないので、ビットマップのサイズが約２５％増加することである。より詳細については米国公開特許出願第２００２／００７６１０３号を参照されたい。しかしながら、グラフィック画像レンダリングヒントを使用する際の従来技術の限界を克服するという改良を行うニーズが、依然として残っている。
【課題を解決するための手段】
【００１１】
１つの様相において、本発明は、レンダリングヒントをビットマップ画像にコード化するための方法を含む。例えば複数のプリントオブジェクトを定める、デジタルドキュメントのデスクリプションをカラービットマップドライバーが受信し、このビットマップドライバーは、プリントオブジェクトを複数の内部オブジェクトに変換する。ビットマップドライバーは更に、出力デバイス上のドキュメントをレンダリングする際に使用するための、各内部オブジェクトに対する対応するレンダリングヒントを誘導する。次に、この方法は、内部オブジェクトのうちの少なくとも１つに、対応するレンダリングヒントのタグを付け、最後に、受信したデジタルドキュメントの出力ビットマップ画像を形成することを要求する。
【００１２】
ビットマップ画像は、内部オブジェクトと、１つのヒントのタグが付けられた各内部オブジェクトに対する対応するヒントの双方を含み、ビットマップ画像は、埋め込まれたレンダリングヒントを有していない対応するビットマップよりも、まだ事実上大きくなっていない。レンダリングヒントの例として、エッジ検出、グレースケール置換レベル、候補スポットカラー置換などを挙げることができるが、これらだけに限定されない。アンダーカラーリダクションの量およびタイプ、他のインクの低減／置換方法およびハーフトーン化アルゴリズムを決定するために、プリンタファームウェアによってレンダリングヒントを使用できる。これら決定は、オブジェクトごとに行うことができ、この方法では、新規なビットマップドライバーによって組み立てられる内部オブジェクトはアプリケーションまたはＰＤＬレベルのプリントオブジェクトに対し、１：１の相関性に限定されない。アプリケーションソフトウェア、プリンタドライバーおよび同等物において、本発明の種々のフィーチュアを使用できる。更に、少なくとも１つのタイプのハードコピー出力を生成できるカラーＭＦＰデバイスを含むが、これだけに限定されない種々の作動環境で本発明を使用できる。代表的な実装例における出力デバイスのファームウェアは、ビットマップ画像からレンダリングヒントをリカバーし、これらレンダリングヒントを適用し、出力の画質を改善できる。
【００１３】
請求の範囲に対応する技術手段を以下に示す。
第１の技術手段は、デジタルドキュメントを作成し、複数のプリントオブジェクトを含むドキュメントデータを提供するアプリケーションが動作する手段と、前記プリントオブジェクトを受信し、これらプリントオブジェクトに対応して作成される内部オブジェクトのセットを形成するためのカラービットマップドライバーが動作する手段とを有し、前記カラービットマップドライバーが動作する手段は、前記内部オブジェクトのビットマップ出力画像を生成し、前記ビットマップ出力画像は、埋め込まれたレンダリングヒントを含むデジタルドキュメント処理システムであって、前記カラービットマップドライバーが動作する手段から前記ビットマップ出力画像を受信し、前記ビットマップ出力画像から前記埋め込まれたレンダリングヒントを抽出し、前記ビットマップ出力画像データを出力デバイスで利用可能な出力デバイスエンジンレディデータ内にレンダリングする際に、前記抽出したレンダリングヒントを適用するよう、ファームウェアプロセスを実行するようになっている出力デバイスを備え、前記カラービットマップドライバーが動作する手段は、前記ビットマップ出力画像のサイズが、レンダリングヒントデータによって増加しないよう、ビットマップ出力画像のデータの中の最下位ビットである最小位カラービット平面のうちの少なくとも１つを再使用することにより、前記ビットマップ出力画像に前記レンダリングヒントを埋め込むことを特徴としたものである。
【００１４】
第２の技術手段は、第１の技術手段において、前記出力デバイスが、ＭＦＰデバイス、ソフトコピーデバイスおよびハードコピーデバイスのうちの１つを含むことを特徴としたものである。
【００１５】
第３の技術手段は、第１の技術手段において、前記アプリケーションが動作する手段が、ネットワークに結合され、前記アプリケーションがインストールされたホストコンピュータであって、前記出力デバイスが、前記ビットマップ画像データを受信するように、前記ネットワークに結合されており、前記カラービットマップドライバーが動作する手段が、実行可能なソフトウェアプロセスとして前記カラービットマップドライバーが実装されている前記ホストコンピュータであることを特徴としたものである。
【００１７】
第４の技術手段は、レンダリングヒントをビットマップ画像に符号化するための方法であって、カラービットマップドライバーが動作する手段が、複数のプリントオブジェクトを定めるデジタルドキュメントの記述を受信するステップと、前記カラービットマップドライバーが動作する手段が、前記プリントオブジェクトを複数の内部オブジェクトに変換するステップと、前記カラービットマップドライバーが動作する手段が、各前記内部オブジェクトに対し、前記デジタルドキュメントを出力デバイスでレンダリングする際に使用するための対応するレンダリングヒントを得るステップと、前記カラービットマップドライバーが動作する手段が、少なくとも１つの内部オブジェクトに対応するレンダリングヒントのタグを付けるステップと、前記カラービットマップドライバーが動作する手段が、前記受信したデジタルドキュメントのビットマップ出力画像を形成するステップとを備え、前記ビットマップ出力画像は、内部オブジェクトに付けられたレンダリングヒントのタグに対応したレンダリングヒントを埋め込まれ、前記カラービットマップドライバーが動作する手段が、所定のサイズを超えてビットマップ画像を拡張することなく、前記ビットマップ出力画像内に前記レンダリングヒントを埋め込むステップを含むことを特徴としたものである。
【００１９】
第５の技術手段は、第４の技術手段において、前記カラービットマップドライバーが動作する手段が、前記出力ビットマップ画像のカラー平面の数を選択するステップと、前記カラービットマップドライバーが動作する手段が、各カラー平面内のビット平面の数を選択するステップと、前記カラービットマップドライバーが動作する手段が、前記出力デバイスに送られるプリントデータ内に、前記選択のインデックスを含ませることにより、前記カラー平面およびビット平面の数の選択を出力デバイスに送るステップとを備えることを特徴としたものである。
【００２０】
第６の技術手段は、第４の技術手段において、前記カラービットマップドライバーが動作する手段が、ビットマップに存在する、低い値の情報を含むことになるはずの領域を再使用することにより、前記出力ビットマップ画像内に前記レンダリングヒントを埋め込むステップを含むことを特徴としたものである。
【００２１】
第７の技術手段は、第４の技術手段において、前記ビットマップ出力画像が、標準化された基準カラースペースを有する、デバイスから独立したフォーマットとなっていることを特徴としたものである。
【００２２】
第８の技術手段は、第７の技術手段において、前記ビットマップ出力画像が、ｓＲＧＢフォーマットとなっていることを特徴としたものである。
【００２３】
第９の技術手段は、第４の技術手段において、前記ビットマップ出力画像が、ＴＩＦＦ、ＪＰＥＧ、ＰＮＧ、ＧＩＦ、ＢＭＰ、ＥＸＩＦおよびＷＭＰのうちの１つとコンパーチブルなフォーマットを有することを特徴としたものである。
【００２４】
第１０の技術手段は、第４の技術手段において、前記ビットマップ出力画像が、３つのカラー平面を含み、各カラー平面が上位ビット平面と下位ビット平面とを有し、前記上位ビット平面は、画像データを含み、前記下位ビット平面は、レンダリングヒントデータを含むことを特徴としたものである。
【００２５】
第１１の技術手段は、第４の技術手段において、前記プリントオブジェクトを複数の内部オブジェクトに変換する前記ステップの結果、オブジェクト解像度が変更されることを特徴としたものである。
【００２６】
第１２の技術手段は、第５の技術手段において、前記レンダリングヒントが、エッジ検出、ＵＣＲのパーセント、ハーフトーンアルゴリズム、画像エンハンスメント、カラーリダクションのパーセント、グレースケール置換レベルおよび候補スポットカラー置換のうちの少なくとも１つを示すことを特徴としたものである。
【００２７】
第１３の技術手段は、ドキュメント出力デバイスのプロセッサ内で実行するための、マシンで読み取り可能なメディア内に記憶された、実行可能なコードを含むファームウェアプログラムであって、入力ビットマップ画像データを受信するためのコードと、前記入力ビットマップ画像データをラスター出力データにレンダリングするためのコードと、前記入力ビットマップ画像データの少なくとも１つの下位ビット平面からレンダリングヒントデータを抽出するためのコードとを備え、前記抽出されたレンダリングヒントデータを前記レンダリングコードへの入力として使用し、前記入力ビットマップ画像データを前記ラスター出力データ内にレンダリングすることを特徴としたものである。
【００２８】
第１４の技術手段は、第１３の技術手段において、前記コードが、多機能周辺ＭＦＰデバイスのプロセッサ内で操作されるようになっていることを特徴としたものである。
【００２９】
第１５の技術手段は、第１３の技術手段において、前記入力ビットマップ画像が、３つのカラー平面を含み、各カラー平面が上位ビット平面と下位ビット平面とを有し、前記上位ビット平面は、画像データを含み、前記下位ビット平面は、レンダリングヒントデータを含むことを特徴としたものである。
【００３０】
第１６の技術手段は、第１５の技術手段において、前記コードが、プリンタのプロセッサ内で操作するようになっていることを特徴としたものである。
【００３１】
第１７の技術手段は、第１５の技術手段において、アンダーカラーリダクションの量およびタイプ、その他インクの低減／置換方法およびハーフトーン化アルゴリズムのうちの１つ以上を決定するために、前記プリンタのファームウェアにより、前記レンダリングヒントを使用することを特徴としたものである。
【００３２】
第１８の技術手段は、第１５の技術手段において、カラーガムート変換を選択するよう、前記プリンタファームウェアにより前記レンダリングヒントを使用することを特徴としたものである。
【００３３】
以下、添付図面を参照して進める好ましい実施形態の次の詳細な説明から、本発明の上記以外の特徴および利点が明らかとなろう。
【図面の簡単な説明】
【００３４】
【図１ａ】オブジェクトタイプ固有のレンダリング方法を決定し、使用することに関連する従来のシステムおよび方法を示す略図である。
【図１ｂ】オブジェクトタイプ固有のレンダリング方法を決定し、使用することに関連する従来のシステムおよび方法を示す略図である。
【図１ｃ】オブジェクトタイプ固有のレンダリング方法を決定し、使用することに関連する従来のシステムおよび方法を示す略図である。
【図１ｄ】オブジェクトタイプ固有のレンダリング方法を決定し、使用することに関連する従来のシステムおよび方法を示す略図である。
【図２】本発明を使用できる作動環境の一例を示す略図である。
【図３】本発明の現時点で好ましい実施形態を示す、簡略化されたプロセスフローチャートである。
【図４】本発明の別の実施形態を示す、簡略化されたプロセスフローチャートである。
【図５】ダイレクト画像送信アプリケーションのコンテキスト内の、本発明の別の実施形態を示す、簡略化されたプロセスフローチャートである。
【図６】ファームウェアレンダラープロセスにおけるレンダリングヒントのリカバーおよび処理を示す、簡略化されたプロセスファームウェアである。
【発明を実施するための形態】
【００３５】
次に図２を参照する。ここには、作動環境の一例を示す略図が示されている。代表的な作動環境は、ハードコピー出力を生成できる少なくとも１つのカラープリンタ、またはカラーＭＦＰ（多機能周辺）デバイス（図示せず）を含む。このコンテキストにおけるハードコピー出力は、（紙または他のメディア上の）プリント、ファックスおよびソフトコピー入力のウォークアップハードコピー、例えばウォークアップＵＳＢプリントを含むが、これらだけに限定されるものではない。カラーＭＦＰは、他の画像形成作動もサポートでき、この他の画像形成に対しても、本発明の特徴を実施できる。かかる他の作動はフォーマット変換、スキャン／ＯＣＲまたは他のタイプのセグメント化作動を含むが、これらだけに限定されるものではない。
【００３６】
図２を再び参照する。一部のシステムでは、プリントサブシステムは、ドキュメントのネイティブなフォーマット化されたドキュメントオブジェクトの各々を等価的なプリントオブジェクトに変換することにより、ドキュメント２００を処理できるアプリケーション２０２を含む。例として、ＧＤＩおよびＸＰＳを挙げることができる。ＧＤＩとは、グラフィカルデバイスインターフェース（Ｇｒａｐｈｉｃａｌ  ＤｅｖｉｃｅＩｎｔｅｒｆａｃｅ）の略語であり、グラフィックオブジェクトと表示し、これらを出力デバイス、例えばモニタおよびプリンタへ送信するためのウィンドウズ（登録商標）の１つの規格である。ＸＰＳとは、ＸＭＬペーパー仕様を意味する。すなわちマイクロソフト社によって開発されたページ記述言語および固定ドキュメントフォーマットのための仕様である。このＸＰＳは、新しいプリントパスおよびデバイスの独立性および解像度の独立性を申し立てによりサポートする、カラー管理されたベクトルに基づくドキュメントフォーマットに基づく、ＸＭＬをベースとする仕様である。
【００３７】
共通するドキュメントオブジェクトの例として、テキストストリング、特定サイズ／フォントのテキストストリング、ベクトル、所定の幅／フィルのベクトル、ビットマップ、所定のグレースケールまたはカラーのビットマップを挙げることができる。しかしながら、本発明はデジタルコンテント圧縮／コード化／暗号化、フォーマット化およびレンダリング方法における技術進歩に従うように適合でき、これら技術進歩は、新しいか、または異なるドキュメントオブジェクトを必要とし得る。
【００３８】
一実施形態では、本明細書で説明するように作動するよう、構築または変形されたソフトウェアに実装されたカラービットマップドライバー２０８に（要素１〜Ｎ）と表示されたプリントオブジェクトデータ２０４が入力される。カラービットマップドライバー２０８は、これらプリントオブジェクトを後述するように部分的にラスター化された画像、例えばＲＧＢビットマップ２１０に変換する。このビットマップ画像２１０はデバイスから独立していることが好ましい。カラービットマップドライバー２０８は、元のドキュメントオブジェクト（すなわちビットマップに変換する前のドキュメントオブジェクト）に関連するレンダリングヒントをコード化するようになっている。更に、ビットマップのフォーマットのサイズを拡大したり、またはこれを変更することなくレンダリングヒントをデータに追加してもよい。以下、このように行う説明上の方法について説明するが、これら方法はすべてを網羅したものではない。
【００３９】
次に図３を参照する。ここに示された略プロセスフローチャートは、本発明の好ましい一実施形態を示す。このプロセスにおいて、上記のようにグラフィックプリミティブまたはオブジェクト３０４の組を発生するアプリケーション３０２により、入力デジタルドキュメントファイル３００が作成または処理される。このオブジェクトデータは、上記のようにビットマップドライバー３０６に入力され、ビットマップドライバー３０６は次のようにビットマップ画像３１０を生成する。プリンタレディデータにレンダリングするためにドライバーへ送られるドキュメントオブジェクトを検査することにより、一般にレンダリングヒントが決定される。ドキュメントオブジェクトの一部の例をこれまで示した。
【００４０】
異なる実施形態では、カラービットマップドライバーが次のようなプリントオブジェクトのうちの１つ以上を認識し、および／または組み立てることができる。
１．テキスト
ａ．テキストキャラクター
ｂ．単語
ｃ．テキストライン
ｄ．テキストセンテンス
ｅ．テキストパラグラフ
ｆ．エンクロージングテキスト領域
２．ベクトル
ａ．ラインセグメント（線分）
ｂ．テキストライン
ｃ．幾何学的形状
ｄ．幾何学的形状の構成
ｅ．エンクロージングベクトル領域
３．ビットマップ
ａ．白黒ビットマップ
ｂ．グレースケールビットマップ
ｃ．カラービットマップ
ｄ．カラー複雑度
ｅ．カラー密度
【００４１】
レンダリングヒントの例として、限定することなく、エッジ検出、ＵＣＲのパーセント、ハーフトーンアルゴリズム、イメージエンハンスメント、カラーリダクションのパーセント、グレースケール置き換えレベル、候補スポットカラー置き換え、損失対無損失圧縮などを挙げることができる。これらおよびその他のレンダリングプロセスおよびパラメータのサイズについては公知となっている。選択に影響するか、またはその他の方法でレンダリングを制御するために、出力デバイスのファームウェアにより、埋め込まれたレンダリングヒントのうちのいずれか、またはすべてを使用することができる。これらの決定はオブジェクトごとに行うことができる。
【００４２】
新規なビットマップドライバーによって組み立てられた内部オブジェクトは、アプリケーションまたはＰＤＬレベルのプリントオブジェクトへの１：１の相関性に限定されない。むしろこの変換を、１：１、多数：１、１：多数、または多数：多数とすることができる。例えば単語処理アプリケーションは、各々がテキストシーケンス内の単一キャラクターから成るプリントオブジェクトにテキストシーケンスをパースすることができる。カラービットマップドライバーは、次にオブジェクトリソリューションを保存するか、または例えば個々のキャラクターのシーケンスを単語に組み立てるかのいずれかを行うことができる。従って、レンダリングヒントは、オリジナルのドキュメントオブジェクトに関連するが、特定の実現例に応じて一部のオブジェクトまたはすべてのオブジェクトに関し、より高い解像度またはより低い解像度を表すことができる。次に、ビットマップドライバーは、出力デバイスまたはファイル上のドキュメントをレンダリングする際に使用するために、各内部オブジェクトのための対応するレンダリングヒントを誘導する。次にこの方法は、対応するレンダリングヒントにより、内部オブジェクトのうちの少なくとも１つにタグを付け、最後に出力ビットマップ画像を形成することを要求する。
【００４３】
図３の表示では、ビットマップ画像は３つのカラー平面、例えば８ビットのカラー平面（Ｒ（赤）、Ｇ（緑）およびＢ（青））を含み、各平面は、上位のビット平面３１２と下位のビット平面３１４とを含む。この例は、説明のために示されているが、発明を限定するものではない。本発明は、任意の特定のフォーマット、カラー平面の数、またはビット深さだけに限定されるものではない。各ビット平面は、特定のピクセル位置における主要カラーの強度のレベルを示しており、より高いレベル（より重要）のビット平面は、強度が高まるレベルを示し、各１つのレベルは、周知の二進符号化方法のように２倍ごとに増加する。従って、例えば８ビットフォーマット（２８）すなわち２５６のレベルを表示できる。
【００４４】
下方のビットレベルは所定のピクセルに対する最小量のカラー（インク）の強度に寄与するので、最小位の３ビット（下位のビット平面）を比較的価値の低い情報として無視できる。本発明によれば、これらビット位置は無視しないが、その代わりに、データ内にレンダリングヒントを埋め込むのに再使用する。一般に、ビットマップから最小位の１つまたは２つのビット平面をドロップまたは無視しても、ハードコピーにレンダリングするときには、結果に影響を与えない。すなわち上位（より重要な）ビット平面がカラーの決定を支配している。画像のうちの最小位、すなわち低い値のビットを再使用することにより、ファイルのサイズを拡大することなく、またはビットマップのフォーマットを変えることなく、レンダリングヒントを追加する。出力ビットマップは、ＴＩＦＦ、ＪＰＥＧ、ＰＮＧ、ＧＩＦ、ＢＭＰおよびＷＭＦのうちの１つとコンパーチブルなフォーマットを有することが好ましい。しかしながら、技術が進歩するので、将来のファイルフォーマットに本発明の要旨を適合させることができる。
また、画像ビットマップの最下位ビットにヒントを埋め込むので、データ量を増大させることなく、また既存のデータ形式との互換性を維持したままヒントの埋め込みが可能となる。
【００４５】
出力（例えばプリンタ）側において、ファームウェアはこれらビット平面上のピクセル値を、カラー強度としてではなくコード化されたレンダリングヒントとして解釈する。これについては、図６を参照して更に後述する。例えばインターネットのダウンロードを使用すれば、このフィーチャーを実装するためにプリンタのファームウェアをアップグレードすることは困難ではない。他方、好ましい実施形態において、標準的なビットマップフォーマット化が保存され、重要なデータは失われないので、出力ビットマップファイルはレンダリングヒントを認識しない離散的ファームウェアを含むファームウェアおよび標準的な出力デバイスと完全にコンパーチブルなままである。
【００４６】
カラービットマップドライバー３０６は、任意の数のカラー平面および１つのカラー平面内のビット平面を選択できる。カラービットマップドライバー３０６は、コード化されたカラー／ビット平面の選択を（例えば所定のフォーマットまたはプロトコルを使って）暗黙裏、または（例えばプリントデータを有する情報を送ることにより）明示的に、ファームウェアへ送ることができる。後者の例として、ＰＪＬ（プリンタジョブ言語）またはＸＰＳ（プリントチケットコマンド）を使用することを挙げることができるが、これだけに限定されるものではない。
【００４７】
一部の実施形態では、カラービットマップおよびカラーＭＦＰがヒントをコード化するのに使用されるカラー／ビット平面の数のフレキシブルな使用をサポートしている場合、ドライバーはコード化すべき情報（例えばレンダリングヒント）の全体に対する最小または最適な組を選択できる。例えば、コード化されるレンダリングヒントが、１つのピクセルがエッジの一部（例えばライン）であるかどうかに関するものである場合、このヒントを単一のビットとしてコード化できる。このケースでは、ドライバーは単一カラー平面内の単一ビットライン（すなわち最小位のビットライン）しか使用しないことを選択できる。ドライバーは画像のレンダリングに与える影響を最小にするようカラーＭＦＰのカラーガムート変換の知識に基づき、使用するためのカラー平面を選択することもできる。特定カラー／ビット平面の選択は、管理者があらかじめ決定し、コンフィギュアしてもよいし、またはユーザーが選択してもよい。
【００４８】
多数のレンダリングヒントをコード化すべきとき、ドライバーは各レンダリングヒントごとに単一のビット平面を選択できる。換言すれば、ビットフラグを選択できるか、またはすべての実際的な組み合わせの一覧を使用できる。例えば２つのエッジ検出レンダリングヒントが存在できる。すなわちピクセルがテキストキャラクターエッジの一部であることを表示するレンダリングヒントと、ベクトルオブジェクトのラインエッジの一部であることを示す他のレンダリングヒントが存在し得る。この場合、１つのピクセルがテキストキャラクターの一部、かつラインベクトルエッジの一部となることはできないので、４つのステート（２つのフルビット）は、不要である。その代わりに３つのステートだけもよい。すなわちオフステートとテキストステートとベクトルステートだけでよい。
【００４９】
次に図４を参照する。この図は、本発明の別の実施形態を示す簡略化されたプロセスフローチャートである。ここでは、ドライバー４０８内でグラフィックプリミティブ４０４（要素１から要素Ｎと表示）を処理し、プリミティブグループを保存し、Ｎ個の内部オブジェクトの一組を形成する。上記のように、別の実施形態では入力グラフィックプリミティブよりも解像度が高くなったり低くなったりし得る。各内部オブジェクト４０１には対応するレンダリングヒントが割り当てられる。次に、このデータは８−ｎビットのビットマップレンダラープロセスを実行するドライバーレンダラー４２０に入力される。ここで、ｎはレンダリングヒントに対して使用されるビット平面の数を示す。ドライバーレンダラー４２０は、データを８−ｎビットのカラー平面４３０にレンダリングし、対応するドライバーをベースとするヒントのために下方のｎビット４４０を使用する。
【００５０】
一例では、各ピクセルに関連する８つのステート（レンダリングアクション、パラメータ、属性など）を伝えるのに３つのビットが利用できることを条件に３つのカラー平面の各々からの最低ビットラインを再使用する。最小の２つのビット平面（３倍のカラー）を使用する場合、６４（２６）までのステートを伝えるのに、本方法を使用できる。
【００５１】
次に図５を参照する。この図は、ダイレクト画像送信アプリケーションにおける本発明の別の実施形態を示すプロセスの簡略されたプロセスのフローチャートである。ここでドキュメント（入力）は既にビットマップ画像５０２、例えばハードコピースキャナーから得られたスキャンされた画像データとなっている。一般に直接送信アプリケーション（ＤＳＡ）を使ってカラーＭＦＰへ直接画像データを送信する。ＤＳＡは、従来のドライバーの多数の機能（例えば通信ジョブ制御命令）を実行するが、このドキュメントデータ（すなわち画像データ）をプリンタレディデータに変換することはない。しかしながら、このアプリケーションでは、改良されたＤＳＡ５００が画像セグメント化５０４によりドキュメントオブジェクトを決定しようと試みる。画像セグメント化の種々の方法が公知となっている。例えばゼロックス社に譲渡された米国公開特許出願第２００２／００７６１０３号「画像セグメント化技術を使用して画像をセグメント化するための方法および装置」を参照されたい。図５において、ＤＳＡ５００は、これら方法の組み合わせを使用することが好ましい。例えばこのＤＳＡ５００は、テキスト、ベクトルおよびビットマップの領域を識別し、次にこれら領域内のドキュメントオブジェクトのより微細な解像度を決定するように、二次セグメント化技術を使用することができる。
【００５２】
セグメント化プロセス５０４が、一旦ビットマップ画像５０２内のドキュメントオブジェクトを決定すれば、ＤＳＡ５００はドキュメントオブジェクトに関連するレンダリングヒントを決定し、これらをコード化し、その結果、オブジェクトと対応するヒント５１０の組が得られる。次にこのデータは、８−ｎビットのビットマップレンダラープロセスを実行するＤＳＡレンダラー５２０に入力される。ＤＳＡレンダラー５２０は、このデータを８−ｎビットのカラー平面５３０にレンダリングし、上記のように対応するヒントに対しては下方のｎビット５４０を使用する。
【００５３】
図６は、ファームウェアレンダラープロセスにおいて、レンダリングヒントをリカバーし、処理する、プロセスの略フローチャートである。ここで、例えばカラーＭＦＰ内のファームウェアが、レンダリングヒントと共にコード化されたビットマップ６００を受信する。ＭＦＰは上記のように暗黙裏または明示的に、レンダリングヒントの位置を決定する。この位置が一旦決定されると、ファームウェアはビット平面セパレータプロセス６１０において、レンダリングヒント情報を抽出する。このレンダリングヒントのｎビットの平面６２０は、ラスター画像プロセッサＲＩＰ６３０に入力される。更に、６２２で表示されるようにコード化されたカラー／ビット平面をレンダリング動作からマスクすることができる。この結果得られるカラービットマップ平面は、特定のプリンティング／マーキングエンジンのためにハーフトーン化／カラー変換されているＣＭＹＫ画像のようなエンジンレディデータとなるようにラスター化すべき、対応する抽出されたヒントデータと共に、ＲＩＰへ入力される。対応するピクセルがどのようにレンダリングされるかに影響するよう、ラスター化プロセスによってレンダリングヒントを使用できる。  
【００５４】
本発明の基礎となる要旨から逸脱することなく、上記実施形態の細部について多くの変更を行うことができることは、当業者には明らかとなろう。例えば好ましい実施形態は、ビットマッププリントジョブをハードコピー出力に変換することについて述べているが、他の実施形態は、ソフトコピー出力、例えば外部向けファックス、フォーマット変換またはファイリングジョブもカバーできる。したがって、本発明の範囲は特許請求の範囲のみによって決定すべきである。
【符号の説明】
【００５５】
１００…入力デジタルドキュメント、１０２…プロセス、１０４…要素、１０６…ＰＤＬドライバー、１１２…プリントデータ、１１４…ファームウェアインタープリター、１１８…結果、１２０…ラスター画像プロセッサＲＩＰ、１３０…ラスター画像、１３６…ファームウェア、１４４…セグメント化、１４８…オブジェクト、１５０…レンダリングヒント、１５２…ラスター化ファームウェア、１５４…ラスター画像、２０２…アプリケーション、２０４…プリントオブジェクトデータ、２０８…カラービットマップドライバー、２１０…ビットマップ画像、３００…入力デジタルドキュメントファイル、３０２…アプリケーション、３１４…ビット平面、４０１…内部オブジェクト、４０４…グラフィックプリミティブ、４２０…ドライバーレンダラー、４３０…カラー平面、４４０…ｎビット、５００…ＤＳＡ、５０２…ビットマップ画像、５０４…セグメント化プロセス、５０４…画像セグメント化、５１０…ヒント、５２０…ＤＳＡレンダラー、５３０…カラー平面、５４０…ｎビット、６１０…ビット平面セパレータプロセス、６２０…ｎビットの平面、６３０…ラスター画像プロセッサＲＩＰ。
【図１ａ】
0004801748.tif 000002
【図１ｂ】
0004801748.tif 000003
【図１ｃ】
0004801748.tif 000004
【図１ｄ】
0004801748.tif 000005
【図２】
0004801748.tif 000006
【図３】
0004801748.tif 000007
【図４】
0004801748.tif 000008
【図５】
0004801748.tif 000009
【図６】
0004801748.tif 000010