JP2008117379A - エンコードされたラスタ文書を生成するシステム、方法およびコンピュータプログラム - Google Patents

Abstract

【課題】固定的な部分と動的な部分を有する文書をレンダリングするシステム、方法およびコンピュータプログラムを提供する。
【解決手段】先ず、電子文書が、プライマリラスタコードとして保存される。例えば、フォームのような所定の文書の走査線に対する命令を含んでいる。次いで、オーバーレイデータが受信され、セカンダリラスタコードに変換される。次いで、プライマリラスタコードおよびセカンダリラスタコードが出力され、この際、プライマリおよびセカンダリラスタコードの組み合わせからビットマップ画像文書が生成される。
【選択図】図１５

Description

本発明は、文書をレンダリングするシステム、方法およびコンピュータプログラムに関し、特に、フォームを備えた固定的な部分と動的な部分を有する文書をレンダリングするシステム、方法およびコンピュータプログラムに関する。

電子文書は、通常、ワードプロセッサ、描画パッケージ、またはグラフィカルデザインパッケージ等のアプリケーションによって生成される。多数のソフトウェアアプリケーションが存在しているが、よく知られ、現在入手可能なアプリケーションの中には、Microsoft（登録商標）Office製品やAdobe Acrobatを含むAdobe Systems社の製品が含まれている。電子文書は、多くの場合、ページ記述言語（Page Description Language：以下、ＰＤＬという）として出力され、ＰＤＬは、通常、対応する画像のレイアウトを記述した命令から形成されている。

電子ＰＤＬ文書は、印刷または閲覧するために、デコードされなければならない。プリンタによるもの等のハードコピー出力は、通常、レンダリングプロセスにおいて、ラスタ画像処理を含むビットマップ化画像へのＰＤＬのデコーディングを必要とする。ＰＤＬからビットマップへの変換には、かなりの処理が必要である。これは、フォームの記入および生成の際のように、一連の文書を出力しなければならない場合に特に問題となる。

一般的なフォーム生成動作は、通常は、ＰＤＬフォーマットである、固定的なフォームから始まる。また、ＰＤＬフォームコンテンツへの追加または変更により、フォームを完成させる補完的なコンテンツが実現される。完成すると、ＰＤＬ文書全体をビットマップ化画像に変換する必要がある。大量の郵便物や請求書の生成、または任意のその他の反復的な文書生成タスク等の多くのフォームの場合には、それぞれのＰＤＬ文書をビットマップ化された形態に変換するために、かなりの処理時間が必要であることが理解されよう。

前述の動作を代替する選択肢は、固定的なフォームコンテンツのビットマップ化された画像を生成して保存するという方法である。そして、補完情報をビットマップ化した後に、固定的なフォームビットマップに対してオーバーレイとして追加する。この動作によれば、それぞれの出力ごとの固定的なフォームコンテンツのレンダリングが回避されるが、ビットマップ化された、あるいはレンダリングされたデータは、通常、特に、高解像度または多色文書の場合に非常に大きいため、大量の記憶容量を必要とする。

ビットマップを再使用するための大量の記憶容量の必要性を回避しつつ、それぞれの出力ごとに固定的なフォームコンテンツと関連したＰＤＬを完全にデコードおよびラスタ化するためのニーズを除去するシステム、方法およびコンピュータプログラムが望まれている。
特開２００７−２４５７２３号公報

本発明は、上記の従来の問題点に鑑みてなされたもので、固定的な部分と動的な部分を有する文書をレンダリングするシステム、方法およびコンピュータプログラムを提供することを目的とする。また、本発明は、２またはそれ以上の部分を電子的に組み合わせて一つの文書出力を形成する、文書レンダリングのためのシステム、方法およびコンピュータプログラムを提供することを目的とする。さらに、本発明は、ビットマップを再使用するための大量のストレージの必要性を回避しつつ、それぞれの出力ごとに固定的なフォームコンテンツに関連するＰＤＬをすべてデコードおよびラスタ化するニーズを除去するシステム、方法およびコンピュータプログラムを提供することを目的とする。

本発明によるエンコードされたラスタ文書を生成するシステムは、電子文書を、文書出力エンジンによる前記電子文書のレンダリングにおけるドット配置を表す命令を含む、プライマリラスタコードとして保存する記憶手段を有する。本システムは、また、前記電子文書に対応するオーバーレイデータを受信する手段と、受信したオーバーレイデータをセカンダリラスタコードに変換する変換手段を有する。例えば、プライマリラスタコードは、会計フォーム、記録管理フォーム、レターヘッド等の複数の文書処理動作に必要なフォームを表すことができ、セカンダリラスタコードはオーバーレイデータを表すことができる。本システムは、さらに、前記プライマリラスタコードおよび前記セカンダリラスタコードを、これらの組み合わせからビットマップ化画像出力を生成するために、出力する手段を有する。

一実施形態において、本システムは、ページ記述言語にエンコードされた電子ページ記述言語文書を受信する手段を、さらに、含む。また、本システムは、受信した電子ページ記述言語文書にしたがってプライマリラスタコードを生成する変換手段と、生成されたプライマリラスタコードを記憶手段に伝達する手段も含む。

好ましくは、ページ記述言語は、Portable Document FormatまたはPOSTSCRIPT（登録商標）エンコーディングから構成されている。

他の実施形態において、本システムは、プライマリラスタコードおよびセカンダリラスタコードをビットマップ化文書画像にデコードするデコーディング手段と、それから有形の文書（tangible document）を生成するために、ビットマップ化文書画像を関連する文書出力エンジンに伝達する手段をも含む。

さらに他の実施形態においては、本システムは、単一のラスタコード文書を形成するように、セカンダリラスタコードをプライマリラスタコードに付加する手段を、さらに、含む。好ましくは、セカンダリラスタコードは、電子文書の少なくとも一部を上書きする。

本発明によるエンコードされたラスタ文書を生成する方法は、電子文書を、文書出力エンジンによる前記電子文書のレンダリングにおけるドット配置を表す命令を含む、プライマリラスタコードとして記憶装置に保存するステップと、前記電子文書に対応するオーバーレイデータを受信するステップと、受信したオーバーレイデータをセカンダリラスタコードに変換するステップと、前記プライマリラスタコードおよび前記セカンダリラスタコードを、これらの組み合わせからビットマップ化画像出力を生成するために、出力するステップとを含む。

エンコードされたラスタ文書を生成するコンピュータプログラムは、プロセッサに、以下の命令を実行させる。すなわち、命令は、電子文書を、文書出力エンジンによる前記電子文書のレンダリングにおけるドット配置を表す命令を含む、プライマリラスタコードとして記憶装置に保存する命令と、前記電子文書に対応するオーバーレイデータを受信する命令と、受信したオーバーレイデータをセカンダリラスタコードに変換する命令と、前記プライマリラスタコードおよび前記セカンダリラスタコードを、これらの組み合わせからビットマップ化画像出力を生成するために、出力する命令とを含む。

本発明によれば、固定的な部分と動的な部分を有する文書をレンダリングするシステム、方法およびコンピュータプログラムが提供される。

また、本発明によれば、２またはそれ以上の部分を電子的に組み合わせて一つの文書出力を形成する、文書レンダリングのためのシステム、方法およびコンピュータプログラムが提供される。

さらに、本発明によれば、ビットマップを再使用するための大量のストレージの必要性を回避しつつ、それぞれの出力ごとに固定的なフォームコンテンツに関連するＰＤＬをすべてデコードおよびラスタ化するニーズを除去するシステム、方法およびコンピュータプログラムが提供される。

以下、適宜、図面を参照しながら本発明による実施形態の説明を行う。図１に本発明による実施形態のシステム例の機能ブロックダイアグラムが示されている。

以下に詳述する図１のシステムは、いくつかの主要な機能を円滑に実行する。主要な機能には、順序付けられた命令シーケンスに基づいて部分的にレンダリングされた走査線を取得する能力が含まれている。また、これには、ハイレベルレンダリング、ローレベルレンダリングにおいて出会うような２経路レンダリングのためのシステムも含まれている。さらには、本システムは、その特性がフィードフォワードであるため、効率的なレンダリング動作が可能である。図１のシステムは、ローレベルのディスプレイリストレンダリングを提供する。これは、そのローレベルにおけるラスタ画像処理（Raster Image Processing；以下、ＲＩＰという）との関連において有効に使用される。本システムは、ＲＩＰがページ上のピクセルのマーキングを処理する時点において適切に実行（implement）される。このようなローレベル動作には、指定された色の走査線ｙにおけるｘからｘ１までのピクセルのバンドのレンダリング等の機能が含まれる。他の適切なローレベル動作は、指定された色の走査線ｙにおけるｘからｘ１までのグリフビットマップの行のレンダリングである。さらに他の適切なローレベル動作には、指定された色の走査線ｙにおけるｘからｘ１までの擬似的にランレングスエンコードされた（run length encoded；以下、ＲＬＥという）ピクセルグループのレンダリングが含まれる。

図１の全体的なシステムの説明において、処理は、ブロック１０における、例えば、電子文書、ページ記述言語文書、テキスト等を含む（但し、これらに限定されない）入力によって始まる。この入力、例えば、ページ記述言語（page description language；以下、ＰＤＬという）文書は、ブロック１２においてインタープリタに伝達される。ブロック１２において解釈された命令（instructions）は、ブロック１４における走査線レンダリング命令の生成のために伝達される。次いで、これらの走査線命令は、ブロック１６においてバッファリングされ、ブロック１８において走査線レンダリング命令リストを生成する。本発明の一実施形態によれば、ブロック１０における受信された入力による判定によって、POSTSCRIPT（登録商標）フォーム（form）のようなフォームに遭遇した場合には、このフォームは、好ましくは、ブロック２８においてフォームキャッシュ装置に対してレンダリングされる。当業者であれば、このようなレンダリングは、結果的に、ＰＤＬ文書のハイレベル動作をローレベルレンダリングプリミティブに変換する変換をもたらし、これら変換されたローレベルレンダリングプリミティブは、ブロック２８においてフォームキャッシュ装置に保存されることを理解するであろう。したがって、これらのフォームをブロック２８のフォームキャッシュ装置から取得可能であり、これらを使用することにより、図１に示されているように、ブロック１８において走査線レンダリング命令リストを生成可能である。フォームキャッシュ装置ブロック２８の動作については、後ほどさらに詳しく説明する。このような命令は、ブロック２４におけるレンダラに適切に、直接、伝達されるか、あるいはディスク２２またはその他の揮発性または不揮発性のメモリ等の適切な記憶システムと協働するブロック２０におけるディスク入出力マネージャに伝達される。次いで、ブロック２４において参照されているレンダラは、レンダリングされた文書を、出力装置によるブロック２６における出力のために伝達する。適切な出力装置は、レーザープリンタ、インクジェットプリンタ、ファクシミリ装置等の任意のドットマトリックスまたはピクセルに基づいた出力と、後にレンダリングするために、任意の適切なメモリへのビットマップ画像の保存とを含んでいる。

インタープリタ１２、ディスク入出力マネージャ２０、レンダラ２４等の機能は、プロセッサ、ＲＯＭ、ＲＡＭ、オペレーティングシステム等からなる適切なプラットフォーム上で、前述した処理およびその他の処理を実行するコンピュータプログラムによって実行させることができる。

次に図２を参照すると、本発明による一実施形態との関連において使用されるページ表現フォーマットが示されている。前述のように、本システムは、有利には、ローレベルディスプレイリストを使用している。ピクセルを実際にレンダリングするのではなく、本システムは、それぞれのページを記述しているレンダリング命令の保存と、画像を出力エンジンに対してバンドの形態で出力する（band out）時点においてこれらの命令を再生する方法とを提供する。

本システムは、１つのページを走査線のアレイとして取り扱う。本明細書において使用されている「走査線」とは、出力ページ上におけるピクセルの完全な行のことである。それぞれの走査線は、結果的にその走査線のレンダリングをもたらすエンコードされた命令のシーケンスによって適切に表される。走査線レンダリング命令は、１つまたは複数の命令ブロック内に保存されており、これらの命令ブロックは、関連するメモリプールから割り当てられた適切な固定サイズのメモリブロックである。

図２の内容から、ページ３０は、一連の走査線ｙ＝０〜ｙ＝ｎとして表されており、ここで、ｎは、ページ３０に関連する走査線の数として定められていることを理解されたい。

代表的な走査線３２を参照すれば、この走査線は、ページ３０上のｙ＝０において完成されていることに留意されたい。走査線ｙ＝０は、一連の命令３３として表されており、その多くは、以下の説明を理解することによって判明するように、走査線３２から明らかである描画に対応している。図２の表現においては、このような命令は、走査線ｙ＝０に合致しており、命令３３ａ、３３ｂ、３３ｃ、および３３ｄを含んでいる。類似の命令の組が、このページ３０のページ全体におけるそれぞれの走査線ｙと関連付けられていることを理解されたい。さらには、以下の内容を参照することによって理解されるように、走査線と関連したコンテンツの複雑さに応じて、さらに少ないまたはさらに多くの数の命令が必要とされるであろうことについても理解されたい。上記の内容に加え、それぞれの走査線は、次の命令を追加する命令ブロックの次の利用可能な領域をポイントするべく機能するポインタデータをも含んでいる。好適な実施形態においては、それぞれの走査線は、その走査線と関連する指定されたグラフィックパラメータの現在の状態に関する情報を保存するべく機能するグラフィック状態をも含んでいる。

ＲＩＰプロセスにおいては、特定の命令ブロックと関連した以前の命令に続いて、命令が走査線に対して追加または付加される。図２の走査線３６（この場合には、ｙ＝６である）に示されているように、走査線が空である場合には、本システムは、新しい空の命令ブロックを適切に割り当てる。好適な実施形態においては、本システムは、エンコーディングまたは変換プロセスにおいて、命令ブロックからの判読を必要としておらず、それぞれのインスタンス内に命令を付加するべく動作しているのみである。出力コントローラに対してページのバンド形成（banding）を実行する時点において、本システムは、命令を再生して個他の走査線をレンダリングし、この後に、これらを、それからの出力のためにプリンタシステムに対して伝達するべく機能していることを理解されたい。

好適な実施形態においては、それぞれの走査線と関連したメモリは、グラフィック状態情報を保存するべく機能する。この状態情報は、走査線に対して命令を追加するプロセスと、最終的なレンダリングプロセスの両方において、適切に使用される。但し、特定の状況においては、性能上の理由から、選択された情報の局所化されたキャッシュを生成することが有利であることを理解されたい。このグラフィック状態に関する適切な情報には、走査線と関連する現在の色が含まれている。適切な既定の色は、適切には、黒である。

また、グラフィック状態情報には、走査線と関連する現在の不透明度も適切に含まれている。好適な実施形態においては、既定の不透明度は、完全な不透明である。また、グラフィック状態情報には、プリンタ制御言語（Printer Control Language：以下、ＰＣＬという）との関連において使用されるもの等の現在のラスタ演算子（Raster Operator：以下、ＲＯＰという）も適切に含まれている。任意の適切なプリンタ制御言語が好適である。但し、好ましい実施形態は、Hewlett-Packard社によって普及されている（従来、ＰＣＬ６と呼ばれていた）ＰＣＬ／ＸＬを利用する。適切な既定のＲＯＰは、０である。追加の状態エントリは、適切には、現在のパターンであり、適切な既定値は、「パターンなし」である。以下において理解されるように、本システムは、このようなグラフィック状態要素の変更および使用法について開示している。

本システムにおいては、バイトコードスタイルの命令フォーマットが適切に採用されている。これは、通常１バイトであるｏｐＣｏｄｅから構成される。ｏｐＣｏｄｅには、１つまたは複数のパラメータバイトと、任意選択の埋め込みデータが適切に後続している。選択されたｏｐＣｏｄｅは、選択された状態情報を適切に含んでいる。このようなｏｐＣｏｄｅタイプは、走査線のグラフィック状態を変更するｏｐＣｏｄｅ等のすべての後続する命令に対して影響を与える変化を適切に実現する。

本システムは、有利には、４つのｏｐＣｏｄｅを使用する。ラインアート等の表現には、一般的なバンドレンダリングが好適である。グラフィック状態は、現在の色、ＲＯＰ、ＴＲＯＰ（ternary ROP）、パターン等を設定するのに適している。バッチピクセルレンダリングおよびキャッシングのために、ｏｐＣｏｄｅが適切に提供される。これにより、画像レンダリング、パターン、POSTSCRIPT（登録商標）シェーディング、ポータブルドキュメントフォーマット（Portable Document Format；以下、ＰＤＦ（登録商標）という）シェーディング等が円滑に実行される。さらには、テキストレンダリングに対応するべく、ｏｐＣｏｄｅが適切に提供される。このような多くのｏｐＣｏｄｅは、POSTSCRIPT（登録商標）、ＰＣＬ、POSTSCRIPT（登録商標）および任意のその他の適切な文書言語との関連において使用されるべく定期的に公開および更新された状態において入手可能であることを理解されたい。

次に、図３を参照し、代表的なサンプル画像４０を使用することにより、本システムによる実施形態を使用した代表的なレンダリングについて説明することとする。本システムは、ディスク入出力（以下、Ｉ／Ｏともいう）およびメモリサブシステムの初期化と、（走査線グラフィック状態を含む）走査線アレイの既定のまたは空の値に対する割り当ておよび初期化によって始まっている。適切なディスクおよびメモリシステムについては、後程、さらに詳しく説明することとする。図３の代表的な画像には、４つの要素が示されている。第１要素は、月面上におけるNeil Armstrongを描いた画像４２の要素である。図３の画像４０は、白黒であるが、本レンダリングは、有色並びに白黒の画像において機能することを理解されたい。尚、本明細書における説明においては、本発明に関する明瞭な理解を促進するべく、画像４２がグレイカラーであるものと仮定されている。次に、画像４０は、（画像４０の底部に位置した矩形部分４４として示されている）ベクトルグラフィック要素４４を含んでいる。また、本システムは、２つのテキストオブジェクトをも示しており、第１オブジェクト４６は、写真領域４２上に重畳された「Neil Armstrong」であり、第２オブジェクト４８は、白でレンダリングされており、かつ、矩形エリア４４上に重畳されている「On The Moon」という言葉である。

図３においては、説明のために、２つの代表的な走査線ｙ＝６００およびｙ＝７０００が選択されている。走査線ｙ＝６００は、画像４２およびテキスト４６の両方と交差している。走査線ｙ＝７０００は、画像４２、矩形４４、およびテキスト４８と交差している。まず、各部分（グラフィック、形状、およびテキスト）のそれぞれの記述について個別に説明することとする。

まず、Neil Armstrong４２の画像を参照し、記述を実現するための適切なメカニズムについて説明することとする。４２のもの等の写真画像は、左から右へのフォーマットにおいて適切に表されている。ラスタ画像処理動作においては、純粋な画像レンダリングのケースに頻繁に遭遇する。本明細書における説明においては、ソース画像が、プリンタ等の文書出力装置の解像度と同一の解像度を有しているものと仮定している。一例に過ぎないが、このような解像度は、適切には、６００ｄｐｉ（dot per inch）である。但し、入力および出力解像度レベルの両方について、任意の解像度を適切に利用可能であることを理解されたい。また、入力と出力の解像度間における変換も想定されており、かつ、これは、本明細書から理解されるように、スケーリング命令によって適切に実現されることについても理解されたい。また、例示を目的として、適切な８ビットのグレイ画像が提示されている。ＣＭＹ、ＣＭＹ（Ｋ）、ＲＧＢ、または任意の加算または減算的なプライマリカラーセット等の任意の適切なパレット表現が適切に使用されることをさらに理解されたい。一般的なルールとして、加算的なプライマリカラーセットは、ビデオディスプレイ装置等の能動的な表示生成器において有利に使用されており、減算的なカラーセットは、プリントアウト等の受動的な表示において有利に使用される。

図４には、図３の画像表現の構築における開始時点が示されており、画像は、参照符号４０’の電子文書として表されている。参照符号４９は、走査線のアレイを示しており、このそれぞれは、図３に示されている写真４０に対応した電子ページ４０’と関連付けられている。電子ページ４０’によって表されている画像の記述を構築する開始時点においては、命令ブロックは、まだ割り当てられておらず、アレイ４９内のすべての走査線構造は、既定の値に設定されている。

図５Ａのフローチャートの更なる検討により、この画像の構築プロセスについて詳述することとする。このフローにおいては、ステップ５０において、画像を受信する。ステップ５２において、ソース画像の行をデコードすることにより、ステップ５４に示されている未加工の画像行を形成する。次いで、ステップ５６において、スケーリングと、ランレングスの判定を実行する。これが完了すると、ステップ５８に進み、この時点において、一連の入力色値およびピクセルランを含むバッファリングを実行する。その後、ステップ６０において、出力と関連した装置固有の色空間に対する色値の変換を実行する。ステップ６２において、この値を一連の装置色値およびピクセルランに変換する。次に、ステップ６４において、特定の行の影響を受けるそれぞれの走査線に対して、関連する色およびランレングスバッファと関係した命令を付加する。次に、ステップ６６において、画像のそれぞれの行が完了しているかどうかに関する判定を実行する。完了していない場合には、フローは、次の行を処理するべくステップ５２に戻る。最後の行が完了した際には、手順は、ステップ６８において終了することになる。

要すれば、代表的な写真等のソース画像用の処理は、ソース画像のそれぞれのピクセル行ごとに進行する。必要に応じて、スケーリングを実行する。この例においては、画像の入力と出力は、いずれも、対応する６００ｄｐｉにおいて固定されている。したがって、このような状況においては、スケーリングは不要であろう。色値および対応するランレングスをバッファリングする。これらの値を代表的な出力であるＣＹＭＫ等の関連する出力の色空間に変換する。本システムは、レンダリング対象行の影響を受ける走査線を算出する。そのソース画像行をレンダリングする対応した命令を、その走査線と関連した命令ブロックに対して付加する。このプロセスは、それぞれの行ごとに実行される。

図３の代表的な画像においては、写真部分４２は、ｙ＝６００およびｙ＝７０００における走査線の両方に影響を与えている。したがって、画像４０の全体と関連したデータを変換する際には、なんらかの点において、部分４２と関係したレンダリングにより、これらの走査線に命令が配置されるという結果がもたらされることになる。

ｙ＝６００における代表的な走査線を参照すれば、ソースから（レンダリング対象である入力から）グレイ画像行等の画像が取得されることになる。この例においては、入力と出力の両方が６００ｄｐｉに設定されているため、スケーリングは不要である。ｙ＝６００における走査線の多くの部分は、黒であり、かつ、特徴なしとなる。これに、ヘルメットの上部におけるなんらかの詳細が後続しており、これに、はるか右におけるさらに黒いスペースと月の詳細が後続することになろう。このラインが完了したら、図６Ａに示されている適切な表現が生成されることになる。この記述は、実際の表現の複雑性によって変化することになるが、好適な実施形態の例示としては、十分であろう。

次に、図７Ａを参照すれば、適切な出力装置の色空間への変換が完了した際の表現が例示されている。尚、図６Ａにおけると同様に、この表現は、例示を目的として提供されているものに過ぎない。実際の記述は、入力および出力画像のさらに正確な詳細および特性との関係において変化することになる。図７Ａの情報は、ｙ＝６００における走査線に対応した選択座標において始まっており、画像ページにしたがって適切に編成される。命令ブロックを割り当てる。この命令ブロックは、適切なｏｐＣｏｄｅを意味する１バイトコードを適切に含んでいる。第１命令ブロック内において、適切な値は、開始ｏｐＣｏｄｅを表している。画像の開始ｘ座標を設定する次のｏｐＣｏｄｅを形成する。次に、図７Ａに示されているもの等の値を適切な画像データエンコーディング方式に変換する。このプロセスを、画像全体の処理が完了するまで、画像と関連したそれぞれの行ごとに実行する。

図６Ｂおよび図７Ｂは、前述の図６Ａおよび図７Ａとの関連において示されているものに代わる実施形態を示している。図６Ｂは、カラー画像におけるソース値の代替エンコーディングを示しており、図７Ｂは、適切な出力装置の色空間への変換後の代替エンコーディングを示している。いずれの場合にも、２つのパラレルアレイを使用して値をエンコードする。いずれの場合にも、第１アレイは、ランレングスのアレイであり、第２のものは、色値のアレイである。この実施形態においては、関連する画像ランのページ座標として定義された次のようなアレイフォーマットにおいて、図７Ｂのページ座標値がエンコードされていることを理解されたい。

ｘ_０，ｙ_０
ｘ_１，ｙ_１
したがって、黒値（これは、８ビット表現においては、適切には、２５５である）の第１画像ランは、ｘ＝１００〜２４９９であり、これは、ｙ＝６００において１ピクセルの高さである。対応するランの高さがｙ_１−ｙ_０となり、幅がｘ_１−ｘ_０となるように、ｘ_１およびｙ_１の値は含まれていない。

図６Ｃおよび図７Ｃは、図６Ｂおよび図７Ｂの実施形態に対応する実施形態を示しており、この場合には、グレイスケール画像がエンコードされる。この実施形態においては、Ｃ、Ｙ、Ｍ値がすべてゼロであり、したがって、出力は、グレイスケールになると考えられる。したがって、すべての実施形態は、カラーまたはグレイスケールのレンダリングを想定していることを理解されたい。

図５Ｂは、前述の図６Ｂ、図７Ｂ、および図６Ｃ、図７Ｃとの関連において示されているパラレルアレイフォーマットにおける画像構築プロセスのフローチャートを示している。このフローチャートにおいては、ステップ７０において、画像を受信する。ステップ７２において、ソース画像の行をデコードすることにより、ステップ７４に示されている未加工の画像行を形成する。次に、ステップ７６において、スケーリングと、ランレングスの判定を実行する。これが完了したら、ステップ７８に進み、この時点において、一連の入力色値およびピクセルランを含むバッファリングを実行する。この実施形態においては、パラレルアレイが形成されていることに留意されたい。その後、ステップ８０において、出力と関連する装置固有の色空間への色値の変換を実行する。ステップ８２において、この値を、一連の装置色値およびピクセルランにバッファリングしており、こちらもパラレルアレイとして形成される。次いで、ステップ８４において、特定の行の影響を受けるそれぞれの走査線に対して、関連する色およびランレングスバッファと関係した命令を付加する。次に、ステップ８６において、画像のそれぞれの行が完了しているかどうかに関する判定を実行する。完了していない場合には、フローは、新しい行を処理するべくステップ７２に戻る。最後の行が完了した際に、手順は、ステップ８０において終了することになる。

図８を参照すれば、ｙ＝６００およびｙ＝７０００の場所によって表されている画像部分４２を含む完全な表現の一部が示されている。画像４２のすべての側面が、対応するエントリをそれぞれの走査線内に具備することになることを理解されたい。図９を参照し、図３の矩形４４との関連において説明することとする。この例においては、グレイの矩形４４は、ベクトルの形態において適切に表されている。適切なベクトルレンダリングにおいては、台形、次いで、単一の走査バンドへの形状の分解を実行する。但し、多くのその他のケースにおいては、一例として、複雑な形状は、個々の１ピクセルの高さのバンドを描画する一連の要求を結果的にもたらすことになることを理解されたい。

ベクトル矩形のレンダリングは、単純である。走査変換は、１つの出力走査線当たりに１つのバンドをレンダリングする要求を結果的にもたらすことになり、それぞれのバンドは、同一の開始ｘ座標および幅ｗを具備している。本システムは、矩形が（前述のもの４２等の）画像の一部とオーバーラップしているかどうかを気にする必要はない。例えば、画像データおよびベクトルデータを含む複合画像の場合には、その走査線用の画像データおよび命令ブロックの後に、矩形記述等のベクトルデータが付加されることになる。この記述においては、レンダリングの後に、基礎をなすオブジェクトの上または下のいずれに描画が表れるのかを判定または規定する必要はない。

矩形４４の例においては、変換により、最終的に、１ピクセルの高さのバンドを描画する一連の要求が結果的にもたらされることになる。それぞれの要求ごとに、有効な走査線に対して命令ブロックが割り当てられているかどうかをチェックするための判定を実行する。これが実行されていない場合には、命令ブロックを割り当てる。次に、走査線用の現在の色が、レンダリング対象のものと整合しているかどうかに関する判定を実行する。整合していない場合には、適切なｏｐＣｏｄｅを設定して必要な色を選択する。次いで、開始ｘ座標および対応するバンドの長さと関連したそれぞれの影響を受けるラインに対して、レンダリングと関連するｏｐＣｏｄｅを付加する。矩形部分４４内においては、処理は、最終的にｙ＝７０００等の走査線に結び付くことになり、この場合には、メモリが既に割り当てられており、したがって、このようなメモリを再度割り当てる必要はない。前述の画像の部分４２と同様に、黒等の既定の色を選択し、かつ、必要に応じて、命令を付加することにより、適切な色を設定することになる。一例として、グレイ矩形は、４バイトによって定義された８ビットコンポーネントレベルのＣＹＭＫグレイを定義する０、０、０、１２８の値を適切に設定することになる。走査線７０００に関して継続すれば、バンドをレンダリングするためのｏｐＣｏｄｅのバイトコード（「ｏｐＲｅｎｄｅｒＢａｎｄ」）が命令ブロックに対して適切に付加され、この後には、開始ｘ座標（適切には、２バイト）と、幅ｗ（こちらも、適切には、２バイト）が後続している。

したがって、以上の内容から、本表現は、写真部分４２と矩形部分４４の両方に関する情報を含んでいることを理解されたい。次に、テキスト空間要素の構築について説明することとする。

図３のサンプル画像４０には、テキストの観点において、ストリング４６および４８が含まれている。テキスト情報をレンダリングするには、まず、必要な文字を必要なサイズにおいてメモリ内の１ビットグリフ内にレンダリングするべく要求する。グリフビットマップ内のそれぞれの行ごとに、その行を必要な色において適切な出力走査線にレンダリングする命令を追加する。したがって、このような命令の前に、必要に応じて、現在の色を選択する。代表的な例においては、すべての走査線の既定の色は黒であるという観点において、ストリングのテキスト４６については、これを白に設定しなければならない。これは、ｏｐＣｏｄｅ（例えば、選択された値に対するｏｐＳｅｔＣｏｌｏｒ等の１バイトコード）によって適切に実現される。一例として、ＣＹＭＫ色空間において、０，０，０，０は、白の４バイト値を適切に表している。図１２の走査線６００内においては、ｏｐＧｌｙｐｈＢａｎｄ用の１バイトコード、グリフが始まる次の座標用の２バイト、およびグリフの幅用の２バイトが付加されている。

図１０を参照すれば、テキストストリング４６内の第１の文字に対応した文字「Ｎ」が示されている。図１０は、この文字と関連する適切な１ビットのグリフ画像を示している。図１１には、前述の走査線６００における「Ｎ」グリフの一部が示されている。着色されていない単一ビット画像の場合には、黒で示されているビットマップの各部分は、白として描画され、白の部分は、透明として適切に示される。次いで、この情報が、グラフィックおよびベクトルに基づいた画像について構築された以前の表現に対して、それぞれの走査線ごとに付加される。前述のように、命令ブロックがｙ＝６００に対してまだ割り当てられていない場合には（この走査線は、端部とオーバーラップしている）、命令ブロックが割り当てられることになる。

レンダリングが完了したら、本システムは、グリフデータの対応する行を再生成するための十分な記録情報を具備する。

それぞれのテキストストリング内の残りの文字を前述のように処理する。同一のテキストストリング内の後続の文字は、以前の文字について色が設定されており、かつ、その以前のものと異なる色を具備するように次の文字が選択されていない限り、色を設定する必要がないことを理解されたい。

１つまたは複数の画像部分を含む画像の完全な記述が完了したら、本システムは、出力を実現するべく画像のバンド形成ステップ（banding）に進む。このステップにおいては、本システムは、現在の実施形態においては、通常、長さが１２８本の走査線である完全な圧縮されていないバンド用の十分なメモリを適切に提供している。バンドは、このバンド内に含まれるそれぞれの標準走査線と、これらの走査線と関連するｏｐＣｏｄｅ命令を見出すことにより、充填される。

図１３は、先ほど詳述したサンプル画像におけるｙ＝７０００と関連した命令の例を提供している。図に示されているのは、この走査線と関連した命令を含む適切なバッファのコンテンツである。レンダリングプロセスにおいては、関連するエンジンには、関連した走査線をレンダリングするためのメモリブロックに対するポインタが付与される。これは、その走査線と関連した命令を処理することによって完了する。レンダリングは、まず、走査線グラフィックプロセッサをリセットして既定値を選択することによって始まることになる。次いで、命令を対応するブロックから取得し、実行することにより、宛先メモリブロック内へのレンダリングが完了する。図１３の走査線ｙ＝７０００の例においては、まず、第１のｏｐＣｏｄｅが取得される（これは、ｏｐＢｅｇｉｎＩｍａｇｅである）。このｏｐＣｏｄｅは、開始ｘ座標である最初の２バイトを適切にアドレス指定する。この値がフェッチされたら、本システムは、関連する命令バッファ内のエンコードされた画像データを通じて反復することにより、対応する宛先メモリブロック内においてピクセルをプロットする。

図示の例においては、この時点において、宛先メモリブロックは、Neil Armstrongの足下の月の１ピクセルの高さのスライスを有する走査線を含んでいる。次いで、ｏｐＳｅｔＣｏｌｏｒを取得して色を設定する。この例においては、これは、前述の矩形のグレイを規定している０，０，０，１２８値である。次に定義されているｏｐＣｏｄｅは、開始ｘ座標およびバンド幅を取得するｏｐＲｅｎｄｅｒＢａｎｄであり、これは、以前にレンダリングされた写真画像上にグレイの矩形のバンドをレンダリングする手順を結果的にもたらすことになる。次いで、グリフデータ（これは、コード「Ｏ」文字のスライスであり、これは、選択色が白である）をレンダリングするｏｐＣｏｄｅを取得する。このレンダリングを宛先メモリブロックに対して伝達する。最後に、このバンドに対して影響を与えるすべての残りの文字について、テキスト文字のレンダリングを実行する。関連するバンドのすべてのレンダリングが完了したら、最終ページ上に印刷するための（あるいは、さもなければ、文書出力装置に対して出力するための）準備が整っている。この例においては、ｙ＝７０００に関するレンダリングが完了したら、ｙ＝７００１における走査線に進み、ページが完全にレンダリングされて最終的な出力のためのシステムに対して完全に伝達されるまで、以下同様に継続することになる。

まず、図１を再度参照した後に、図１４を参照することにより、当業者には、図１のシステムが、動的な部分と固定的な部分を有していることが明らかとなろう。動的な部分は、ブロック１０〜２６によって適切に表されており、固定的な部分は、有利には、ブロック２８によって表されている。例えば、固定的な部分は、フォームを表現可能であり、動的な部分は、保存されたフォーム上に内蔵されるオーバーレイデータを表している。次に、図１４を参照すれば、本発明によるフォームキャッシュ装置２８の一実施形態を示す機能ブロックダイアグラムが示されている。図１４に示されているように、フォームキャッシュ装置２８は、文書処理動作において使用される１つまたは複数のフォームを保存するべく適合された様々なコンポーネントを適切に有している。当業者であれば、本発明の動作の際に、１つまたは複数のフォームに対応する１つまたは複数のフォームキャッシュ装置を実装可能であることを理解するであろう。好ましくは、フォームキャッシュ装置２８、並びに、その構成コンポーネントは、ハードウェア、ソフトウェア、またはこれらの適切な組み合わせとして実装可能である。フォームキャッシュ装置２８は、当業者には明らかなように、フォームキャッシュ装置２８の動作を制御するために適切に適合されたフォームコントローラ１４０２を含んでいる。好ましくは、フォームコントローラ１４０２は、プリミティブ変換、レンダラブロック１４０８、およびバンド生成器ブロック１４１２を管理する。

プリミティブ変換ブロック１４０４は、先ほど詳述したように、ローレベルなレンダリングプリミティブをｏｐＣｏｄｅに変換する。好ましくは、プリミティブと関連するオブジェクトタグは、ｏｐＣｏｄｅ内において黙示的であり、かつ、別個のデータとして保存されてはいない。当業者であれば、不透明度値は、色表現にしたがって別個のチャネル内に保存可能であることを理解するであろう。

中間レンダリングコンポーネントブロック１４０６は、プリミティブ変換ブロック１４０４において生成されたｏｐＣｏｄｅによって表されるフォームデータを保存するべく有利に適合されている。図１との関連において前述したように、本システムは、ＲＩＰがページ上のピクセルのマーキングを処理する時点において有効に実行される。したがって、ＲＩＰが、キャッシュされているフォームを使用するようにフォームコントローラブロック１４０２に対して通知した場合に、コントローラブロック１４０２は、レンダラ１４０８を起動することにより、図１４にキャッシュブロック１４１０として示されている一時的な単一の走査線バッファ内にｏｐＣｏｄｅを走査線ごとにレンダリングする。走査線バッファブロック１４１０が一杯になったら、ブロック１４１０内のデータは、ブロック１４１２におけるバンド生成器に転送される。したがって、当業者であれば、ｏｐＣｏｄｅがレンダラブロック１４０８を介してピクセルデータに変化していることを理解するであろう。次いで、バンド生成器ブロック１４１２は、バンドごとのオブジェクトタグと共に、ピクセルデータを、不透明度を含むカラーバンドに連結する。ＲＩＰは、カラーバンドを適切な出力装置に送付することにより、これらのバンドを消費し、この結果、フォームが実際の出力媒体にレンダリングされることになる。当業者であれば、バンド生成器ブロック１４１２によって出力されるカラーバンドは、ｏｐＣｏｄｅ表現内に保存されるローレベルのレンダリングプリミティブとして他のフォームキャッシュ装置に送付可能であることを理解するであろう。

当業者であれば、図１４のフォームキャッシュ装置２８の表現は、例示を目的としたものにすぎないことを理解するであろう。代替実施形態によれば、フォームキャッシュ装置２８は、走査線レンダリング命令のみから構成可能であり、次いで、これらが、図１のシステムにしたがって、さらに取得および処理されることになる。したがって、当業者であれば、図１および図１４に示されているフォームキャッシュ装置２８は、スタンドアローン動作と、動的な部分との関連における動作との能力を有していることを理解するであろう。

本発明による一実施形態によれば、図１において前述したシステムは、フォームキャッシュ装置２８からの電子文書を保存および取得するべく適切に適合されている。好ましくは、電子文書は、図２との関連において前述したもの等の中間フォーマットにおいて保存される。当業者であれば理解するように、図２によって表されている部分的にレンダリングされたフォーマットは、その文書の対応するビットマップフォーマットよりも少ない量の記憶空間を必要としている。当業者であれば、このような記憶装置は、有利には、同一のフォームが関連する文書出力装置によって反復的に出力されるフォーム処理において使用するのに適していることを理解するであろう。電子文書は、まず、電子ＰＤＬ文書の形態において受信され、これがインタープリタによって解釈されることにより、プライマリラスタコードが結果的に得られる。このプライマリラスタコードは、同一のフォームを呼び出す後続の文書処理動作において取得可能である。プライマリラスタコードは、先ほど詳述したように、順序付けされた命令シーケンスに基づいて部分的にレンダリングされた走査線を表している。

フォームとの関連において新しい題材を構成するグラフィカルオブジェクト等のオーバーレイデータは、任意の適切な手段を介して取得される。例えば、フォームに記入するテキスト、レターヘッドの下の追加の図等が、適切なオーバーレイデータを表している（但し、これらに限定されない）。次いで、前述の方法を介してオーバーレイデータをセカンダリラスタコードに変換する。本発明による一実施形態によれば、セカンダリラスタコードをプライマリラスタコードに対して付加することにより、単一のラスタコード文書を結果的に得ている。当業者には明らかなように、このようなイベントは、プライマリラスタコードの１つまたは複数の部分がセカンダリラスタコードによって上書きされるという結果を生成可能である。

次いで、最終的な文書のビットマップ画像を生成するべく、プライマリラスタコードとセカンダリラスタコードを出力する。中間ラスタコードを使用するビットマップの生成に関する方法については、先ほど詳述しており、かつ、これは、ここに記述されている方法に対して同様に適用可能である。その後、ビットマップ画像は、有形の文書を生成するために、出力装置に転送される。

次に、図１５を参照すれば、本発明にしたがった実施形態によるエンコードされたラスタ文書を生成する動作を示すフローチャートが示されている。処理は、ステップ１５０２において、電子文書をプライマリラスタコードとして保存することにより、始まっている。好ましくは、プライマリラスタコードは、フォーム等の所与の文書のそれぞれの走査線用の命令を有する。次いで、ステップ１５０４において、オーバーレイデータを受信しており、次いで、ステップ１５０６において、これをセカンダリラスタコードに変換する。次いで、ステップ１５０８において、プライマリおよびセカンダリラスタコードを出力しており、この結果、ステップ１５１０において、組み合わせられたプライマリラスタコードおよびセカンダリラスタコードからビットマップ画像文書を生成する。

次に、図１６を参照すれば、本発明にしたがった一実施形態によるエンコードされたラスタ文書を生成する動作を示すフローチャートが示されている。先ずステップ１６０２で、電子ページ記述言語文書を取得する。好ましくは、ページ記述言語は、ポータブルドキュメントフォーマットまたはPOSTSCRIPT（登録商標）エンコーディングである。次いで、ステップ１６０４において、図１〜図１２において前述した方法にしたがい、受信した電子ページ記述言語文書に基づいて、プライマリラスタコードを生成する。次いで、ステップ１６０６において、プライマリラスタコードを関連する記憶装置またはこのようなコードのキャッシュに伝達する。ステップ１６０８において、伝達されたプライマリラスタコードを関連する記憶装置に保存する。したがって、本発明の一実施形態によれば、プライマリラスタコードは、例えば、会計フォーム、記録管理フォーム、レターヘッド等の複数の文書処理動作に必要なフォームに対応する。

次いで、ステップ１６１０において、オーバーレイデータを当技術分野において既知の適切な手段を介して受信する。好ましくは、オーバーレイデータは、以前に保存されているフォーム上に挿入されるテキストまたはグラフィカルオブジェクト等の既存のフォームに追加される追加データに対応している。次いで、ステップ１６１２において、図１〜図１２との関連において前述した方法により、オーバーレイデータをセカンダリラスタデータに変換する。その後、ステップ１６１４において、プライマリラスタコードおよびセカンダリラスタコードを出力しており、この結果、ステップ１６１６において、ビットマップ画像文書が生成される。好ましくは、このビットマップ画像文書は、組み合わせられたプライマリラスタコードとセカンダリラスタコードにしたがって生成される。

次に図１７を参照すれば、本発明の一実施形態によるエンコードされたラスタ文書を生成する動作を示すフローチャートが示されている。ステップ１７０２において始まり、電子文書を関連する記憶装置またはキャッシュ内にプライマリラスタコードとして保存する。好ましくは、プライマリラスタコードは、フォームを表しており、これは、追加またはオーバーレイデータを伴う複数の文書処理動作に使用可能である。当業者であれば、このようなプライマリラスタコードは、好ましくは、先ほど詳述した方法にしたがって生成されていることを理解するであろう。次いで、ステップ１７０４において、オーバーレイデータを受信しており、ステップ１７０６において、セカンダリラスタデータに変換する。当業者には、このオーバーレイデータのセカンダリラスタコードへの変換は、前述の方法によって有利に実現されていることが明らかであろう。

ステップ１７０８において、単一のラスタコード文書を生成するべく、セカンダリラスタコーをプライマリラスタコードに対して付加するべきであるかどうかに関する判定を実行する。セカンダリラスタコードをプライマリラスタコードに対して付加するべきであると判定された場合には、フローは、ステップ１７１０に進み、この結果、セカンダリラスタコードがプライマリラスタコードに付加され、結果的に単一のラスタコード文書が得られることになる。当業者であれば、前述のように、本発明によって採用されている方法によれば、プライマリラスタコードの一部にセカンダリラスタコードの１つまたは複数の部分を上書き可能であることを理解するであろう。例えば、セカンダリラスタコードがプライマリラスタコードに付加されることに伴って、セカンダリラスタコード内に表されているそれぞれの走査線用の命令が、プライマリラスタコードの対応する走査線用の命令の末尾に追加される。当業者であれば、このような付加の結果として、プライマリおよびセカンダリラスタコードの両方を使用してそれぞれの走査線が完全にレンダリングされることにより、基本的に、プライマリラスタコードによって表されたフォームに、セカンダリラスタコードによって表されたテキストまたはグラフィカルオブジェクトオーバーレイデータが記入された出力文書が得られることを理解するであろう。次いで、ステップ１７１２において、この単一のラスタコード文書を当技術分野において既知の任意の適切な手段によって出力する。

ステップ１７１４において、単一のラスタコード文書をデコードしており、この結果、ステップ１７１６において、デコードされた単一のラスタコード文書にしたがって、ビットマップ画像文書を生成する。次いで、フローはステップ１７２４に進み、ここで、ビットマップ画像文書を関連する文書出力エンジンに伝達する。ステップ１７２６において、ビットマップ画像に基づいて、有形の文書を関連する文書出力エンジンによって出力する。

ステップ１７０８を再度参照し、セカンダリラスタコードがプライマリラスタコードに対して付加されるべきではないと判定された場合には、フローはステップ１７１８に進み、ここで、プリマリおよびセカンダリラスタコードを任意の適切な手段によって出力する。次いでステップ１７２０において、プライマリラスタコード文書およびセカンダリラスタコード文書をデコードしており、この結果、ステップ１７２２において、組み合わせられたプライマリラスタコードおよびセカンダリラスタコードからビットマップ画像文書が生成される。次いで、ステップ１７２４において、ビットマップ画像文書を関連する文書出力エンジンに対して伝達する。その後、ステップ１７２６において、ビットマップ化画像文書を有形の文書として出力する。

本発明は、ソースコード、オブジェクトコード、コード中間ソース、および部分的にコンパイルされたオブジェクトコードの形態、あるいは、本発明の実装において使用するのに好適な任意のその他の形態のコンピュータプログラムをも含んでいる。コンピュータプログラムは、好適には、スタンドアローンのアプリケーション、ソフトウェアコンポーネント、スクリプト、またはその他のアプリケーションに対するプラグインとすることができる。本発明が組み込まれているコンピュータプログラムは、有利には、担体上において実施されており、この担体は、例えば、ＲＯＭまたはＲＡＭ等の記憶媒体、ＣＤ−ＲＯＭ等の光学記録媒体、またはフロッピー（登録商標）ディスク等の磁気記録媒体等のコンピュータプログラムを搬送する能力を有する任意のエンティティまたは装置である。担体は、電気または光ケーブルによって、あるいは、無線またはその他の手段によって、伝達される電気または光信号等の任意の伝送可能な担体である。コンピュータプログラムは、好適には、サーバからインターネットを介してダウンロードされる。また、コンピュータプログラムは、集積回路に組み込むことも可能である。前述の本発明の原理をコンピュータに実質的に実行させるコードを収容するそのような任意およびすべての実施形態は、本発明の範囲にある。

本発明の好ましい実施形態の以上の説明は、例示と説明のために行った。説明は網羅的ではなく、本発明を開示した形態に限定しようとするものでもない。以上の開示内容に鑑み、明らかな変更または変形が可能である。例えば、本発明は、２あるいはそれ以上の部分が電子的に組み合わされ、一つの文書出力を形成する、任意の文書レンダリングに適用可能である。実施形態は、本発明の原理とその実際的な応用例を最もよく示し、それにより当業者が、本発明を、意図された特定の使用に適した様々な実施形態において様々な修正で使用できるように選択され説明された。このような変更および変形のすべては、正しく、適法に、かつ、公正に付与された範囲にしたがって解釈された際に添付する特許請求の範囲の請求項によって定められる本発明の範囲にある。

本発明による実施形態のシステム例の機能ブロックダイアグラムである。 本発明による実施形態との関連において使用されるページ表現フォーマットの例である。 本発明による実施形態におけるレンダリングを説明するためのサンプル画像である。 図３に示したサンプル画像をレンダリングするための開始ページ表現である。 本発明による実施形態におけるレンダリングの動作例を示すフローチャートである。 本発明による実施形態におけるレンダリングの動作例を示すフローチャートである。 本発明による実施形態における例示的なレンダリングの未加工ピクセルとランレングスを示す図である。 本発明による実施形態における例示的なレンダリングの未加工ピクセルとランレングスを示す図である。 本発明による実施形態における例示的なレンダリングの未加工ピクセルとランレングスを示す図である。 本発明による実施形態における例示的なレンダリングのＣＹＭＫピクセルおよびランレングスを示す図である。 本発明による実施形態における例示的なレンダリングのＣＹＭＫピクセルおよびランレングスを示す図である。 本発明による実施形態における例示的なレンダリングのＣＹＭＫピクセルおよびランレングスを示す図である。 本発明による実施形態におけるサンプル画像の表現を示す図である。 本発明による実施形態における他のサンプル画像の表現を示す図である。 本発明による実施形態における文字「Ｎ」のビットマップを示す図である。 本発明による実施形態における文字「Ｎ」ののビットマップラインを示す図である。 本発明による実施形態におけるテキスト要素の表現を示す図である。 本発明による実施形態における走査線と関連した命令を含むバッファのコンテンツの例を示す図である。 本発明による実施形態におけるフォームキャッシュ装置の機能ブロックダイアグラムの例である。 本発明による実施形態において、エンコードされたラスタ文書を生成する動作を示すフローチャートである。 本発明による実施形態において、エンコードされたラスタ文書を生成する動作を示すフローチャートである。 本発明による実施形態において、エンコードされたラスタ文書を生成する動作を示すフローチャートである。

Claims (18)

1. 電子文書を、文書出力エンジンによる前記電子文書のレンダリングにおけるドット配置を表す命令を含む、プライマリラスタコードとして保存する記憶手段と、
   前記電子文書に対応するオーバーレイデータを受信する手段と、
   受信したオーバーレイデータをセカンダリラスタコードに変換する変換手段と、
   前記プライマリラスタコードおよび前記セカンダリラスタコードを、これらの組み合わせからビットマップ化画像出力を生成するために、出力する手段と
   を有することを特徴とするエンコードされたラスタ文書を生成するシステム。
2. ページ記述言語にエンコードされた電子ページ記述言語文書を受信する手段と、
   前記受信した電子ページ記述言語文書にしたがって前記プライマリラスタコードを生成する変換手段と、
   生成されたプライマリラスタコードを前記記憶手段に伝達する手段と
   を、さらに、有することを特徴とする請求項１に記載のエンコードされたラスタ文書を生成するシステム。
3. 前記プライマリラスタコードおよび前記セカンダリラスタコードをビットマップ化文書画像にデコードするデコーディング手段と、
   ビットマップ化文書画像から有形の文書を生成するために、前記ビットマップ化文書画像を文書出力エンジンに伝達する手段と
   を、さらに、有することを特徴とする請求項１に記載のエンコードされたラスタ文書を生成するシステム。
4. 単一のラスタコード文書を形成するように前記セカンダリラスタコードを前記プライマリラスタコードに付加する手段を、さらに、有することを特徴とする請求項１に記載のエンコードされたラスタ文書を生成するシステム。
5. 前記セカンダリラスタコードは、前記電子文書の少なくとも一部を上書きすることを特徴とする請求項４に記載のエンコードされたラスタ文書を生成するシステム。
6. 前記ページ記述言語は、Portable Document Formatエンコーディングから構成されることを特徴とする請求項２に記載のエンコードされたラスタ文書を生成するシステム。
7. 電子文書を、文書出力エンジンによる前記電子文書のレンダリングにおけるドット配置を表す命令を含む、プライマリラスタコードとして記憶装置に保存するステップと、
   前記電子文書に対応するオーバーレイデータを受信するステップと、
   受信したオーバーレイデータをセカンダリラスタコードに変換するステップと、
   前記プライマリラスタコードおよび前記セカンダリラスタコードを、これらの組み合わせからビットマップ化画像出力を生成するために、出力するステップと
   を含むことを特徴とするエンコードされたラスタ文書を生成する方法。
8. ページ記述言語にエンコードされた電子ページ記述言語文書を受信するステップと、
   受信した前記電子ページ記述言語文書にしたがって前記プライマリラスタコードを生成するステップと、
   生成されたプライマリラスタコードを前記記憶装置に伝達するステップと
   を、さらに、含むことを特徴とする請求項７に記載のエンコードされたラスタ文書を生成する方法。
9. 前記プライマリラスタコードおよび前記セカンダリラスタコードをビットマップ化文書画像にデコードするステップと、
   ビットマップ化文書画像から有形の文書を生成するために、前記ビットマップ化文書画像を文書出力エンジンに伝達するステップと
   を、さらに、含むことを特徴とする請求項７に記載のエンコードされたラスタ文書を生成する方法。
10. 単一のラスタコード文書を形成するように前記セカンダリラスタコードを前記プライマリラスタコードに付加するステップを、さらに、含むことを特徴とする請求項７に記載のエンコードされたラスタ文書を生成する方法。
11. 前記セカンダリラスタコードは、前記電子文書の少なくとも一部を上書きすることを特徴とする請求項１０に記載のエンコードされたラスタ文書を生成する方法。
12. 前記ページ記述言語は、Portable Document Formatエンコーディングから構成されることを特徴とする請求項８のエンコードされたラスタ文書を生成する方法。
13. プロセッサに、
    電子文書を、文書出力エンジンによる前記電子文書のレンダリングにおけるドット配置を表す命令を含む、プライマリラスタコードとして記憶装置に保存する命令と、
    前記電子文書に対応するオーバーレイデータを受信する命令と、
    受信したオーバーレイデータをセカンダリラスタコードに変換する命令と、
    前記プライマリラスタコードおよび前記セカンダリラスタコードを、これらの組み合わせからビットマップ化画像出力を生成するために、出力する命令と
    を実行させることを特徴とするエンコードされたラスタ文書を生成するコンピュータプログラム。
14. プロセッサに、
    ページ記述言語にエンコードされた電子ページ記述言語文書を受信する命令と、
    受信した前記電子ページ記述言語文書にしたがって前記プライマリラスタコードを生成する命令と、
    生成されたプライマリラスタコードを前記記憶装置に伝達する命令と
    を、さらに、実行させることを特徴とする請求項１３に記載のエンコードされたラスタ文書を生成するコンピュータプログラム。
15. プロセッサに、
    前記プライマリラスタコードおよび前記セカンダリラスタコードをビットマップ化文書画像にデコードする命令と、
    ビットマップ化文書画像から有形の文書を生成するために、前記ビットマップ化文書画像を文書出力エンジンに伝達する命令と
    を、さらに、実行させることを特徴とする請求項１３に記載のエンコードされたラスタ文書を生成するコンピュータプログラム。
16. プロセッサに、単一のラスタコード文書を形成するように前記セカンダリラスタコードを前記プライマリラスタコードに付加する命令を、さらに、実行させることを特徴とする請求項１３に記載のエンコードされたラスタ文書を生成するコンピュータプログラム。
17. 前記セカンダリラスタコードは、前記電子文書の少なくとも一部を上書きすることを特徴とする請求項１６に記載のエンコードされたラスタ文書を生成するコンピュータプログラム。
18. 前記ページ記述言語は、Portable Document Formatエンコーディングから構成されることを特徴とする請求項１４に記載のエンコードされたラスタ文書を生成するコンピュータプログラム。