JP3872558B2

JP3872558B2 - メモリ削減技法を使用したページ生成のためのフォールバック処理

Info

Publication number: JP3872558B2
Application number: JP09434597A
Authority: JP
Inventors: デイヴィッド・ジェイ・チュラ; スティーブン・エル・シェイファー
Original assignee: ピアレス・システムズ・コーポレーション
Priority date: 1996-03-29
Filing date: 1997-03-31
Publication date: 2007-01-24
Anticipated expiration: 2017-03-31
Also published as: DE69730892T2; US5793937A; JPH10116160A; EP0798665A3; EP0798665B1; EP0798665A2; DE69730892D1

Description

【０００１】
【発明の属する技術分野】
本発明は、ラスタ・プリンタなどの連続同期ラスタ・イメージ出力装置用の複雑な高解像度ページ・イメージを生成するイメージ・レンダリングを行うために使用する装置および方法である。本方法および装置は、ページ記述言語のインタプリタがイメージ生成することができるすべてのページを、維持可能な最高の印刷品質で印刷することを可能にすると同時に、複雑さに関係なくすべてのページが確実に印刷されるようにする。
【０００２】
【従来の技術】
連続同期ラスタ・イメージ出力装置は、出力データを一定時間に送る必要がある。データが一定時間内に送られない場合、出力ページ・イメージが壊れたり、印刷することができなかったりする。本発明の方法および装置は、リアルタイム処理に適した一連のコンパクトなオーダまたはコマンドに基本グラフィックス機能を分解してから、出力ページ・イメージをオンザフライで生成するほかに、その複雑さに関係なく出力する各ページのイメージ生成の必要に応じて無損失および有損失圧縮を行う。
【０００３】
本発明の技法は、普通ならレンダリングされたイメージに必要になるメモリよりもはるかに少ないメモリで、しかも、出力装置が必要とする速度で処理し、出力装置に送ることができる形でページのグラフィック内容を決める。これを実現するために、グラフィクス機能を、本明細書でオーダと呼ぶ低レベル基本立体として表現して、リアルタイムでビットマップ・イメージに変換することができるように保証する。さらに、冗長または重複グラフィックス関数をなくすことによってオーダまたはコマンドの数を減らして、オーダによって使用されるメモリを最小限にする。
【０００４】
本発明は、ページ・イメージの小区画を一度に処理するリアルタイム出力プロセッサを使用する。このような区画をバンドと呼ぶ。バンドは所定の数の走査線から成る。各走査線は出力装置が必要とする速度で出力装置に送られる一連の画素である。第１のバンドを作成した後で、第２のバンドを作成すると同時に第１のバンドを印刷する。
【０００５】
【発明が解決しようとする課題】
本発明は、１９９４年７月２０日に出願された「ＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓＦｏｒＤｉｓｐｌａｙｉｎｇＡＰａｇｅＷｉｔｈＧｒａｐｈｉｃｓＩｎｆｏｒｍａｔｉｏｎＯｎＡＣｏｎｔｉｎｕｏｕｓＳｙｎｃｈｒｏｎｏｕｓＲａｓｔｅｒＯｕｔｐｕｔＤｅｖｉｃｅ」という名称の米国特許出願第０８／２７７７８８号で開示されている連続同期ラスタ・イメージ出力装置用イメージ生成の従来技術の技法に基づき、これに、複雑さに関係なくページが常に確実に印刷されるようにすると同時に、可能な最高の解像度を維持する機構を追加することによって成っている。すなわち、従来技術の技法を使用した場合、印刷エンジンが必要とする速度で送ることができるように、使用プリンタまたはその他の装置に全ピットマップまたはイメージのその他の表現を格納するのに十分なメモリがないため、複雑なグラフィックスを含むページを印刷することができない場合がある。このような事態が起こった場合、イメージを出力するために、通常は解像度、したがって出力品質を下げる必要がある。しかし、出力装置に送られるすぺてのページの解像度を下げる必要はなく、複雑度の高いグラフィクスを含むページの解像度を下げるだけでよい場合がある。本発明は、複雑さに関係なく文書の出力を可能にすると同時に、文書の各ページについて可能な最高の印刷品質を維持する機構を提供す。
【０００６】
【課題を解決するための手段】
ページ記述言語のインタプリタがイメージ生成することができるすべてのページを維持可能な最高の印刷品質で印刷することができるようにすると同時に、複雑さに関係なくすべてのページが確実に印刷されるようにするシステムを形成する方法および装置を開示する。
【０００７】
本発明のシステムには２つの主要構成要素がある。それは、ページをレンダリングするためのメモリの割り振りを行うメモリ管理機能と、メモリあふれ例外とビデオ不足例外の処理を行うフォールバック管理機能である。
【０００８】
図２に、本発明のシステムの様々な機能モジュールとそれらの相互関係を示す。全般的な流れは上から下、左から右の順であり、グラフィックス・サービス・インタフェースに対する呼出しから始まる。文字が付された矢印は、モジュールによってサービスが行われることを示している。
【０００９】
グラフィックス・サービス・インタフェース・モジュールは、主としてページへの描画から成るプリンタ言語インタプリタとの基本的対話を処理する。インタプリタは特定のページの始まりと終わりを識別しなければならず、グラフィックス・サービス・インタフェースは始まり（新規ページと呼ぶ）で新しいページ・インスタンスを初期設定し、完了すると（ページ終了と呼ぶ）そのページを印字のために印刷エンジンに渡す。３つの主要なインタフェース・モジュールがある。すなわち、新規ページ処理（新規ページ）、ページの終わり処理（ページ終了）、および描画（グラフィックス・オーダ生成）である。
【００１０】
新規ページ・モジュールは、そのページに描画するのに必要なすべての内部データ構造を初期設定する。新規ページ・モジュールは、メモリ管理モジュールがそれ自体を新規ページの解像度およびサイズに基づいて割り振り、構成することができるように、メモリ管理モジュールを初期設定する。
【００１１】
ページ終了モジュールは、すべての描画呼出しが完了すると稼働する。この処理には、損失検査モジュールおよびビデオ不足予測機能による最終検査が含まれる。損失検査モジュールは、有損失圧縮バンドがないか検査し、予測機能はページが印刷エンジンに渡される前に可能性のあるビデオ不足を予測する。これを行った後は、ページ終了によって印刷エンジン・ドライバにそのページが印字可能であることが通知される。その後で、印刷エンジン・ドライバが、レンダリング／圧縮解除エンジン・モジュールに対して実際のレンダリング済みバンドを要求する。
【００１２】
グラフィックス・オーダ生成モジュールはインタプリタによって行われた描画呼出しを処理して表示リスト・オーダを生成する。オーダ生成モジュールは、各描画タイプについて適切なオーダを生成する役割を果たす。生成される実際のオーダは基礎となるレンダリング／圧縮解除エンジンによって異なるため、各目的レンダリング／圧縮エンジンごとに異なるオーダ生成モジュールがある。これらのモジュールがすべて、グラフィックス・メモリ管理モジュールからのオーダにメモリを割り振る。
【００１３】
グラフィックス・メモリ管理モジュールは、オーダに対する空間の割り振りを行い、オーダを綴り合わせて１バンドごとに１リストずつのオーダ・リストにするメモリ管理機構として機能する。オーダ・リストの格納のために最適化された固有のヒープ構造体を管理する。フォールバック管理モジュールは、圧縮エンジン・モジュールを介して、ヒープ内のオーダ・リストを圧縮する実際のプロセスを実行する。このため、メモリ管理モジュールとフォールバック管理モジュールは密接に結合されており、ヒープ構造体を共有する。
【００１４】
ビデオ不足予測モジュールは、各ページの終わりで、印刷エンジンのために十分な速さでレンダリングすることができないバンドを識別する。フォール・バック管理モジュールが、十分高速にレンダリングすることができるようにそのバンドの表現を単純化する役割を果たす。これには通常、バンドをプリレンダリングして圧縮する必要がある。
【００１５】
フォールバック管理モジュールは、オーダ・リスト内のデータを圧縮することによってメモリあふれとビデオ不足を処理する役割を果たす。一般に、これはある種の圧縮を使用して行われる。したがって、圧縮解除オーダを生成しなければならない。
【００１６】
圧縮エンジンは、フォールバック管理機能の制御下でバンドとオブジェクトを圧縮する。
【００１７】
レンダリング／圧縮解除エンジン・モジュールは、ハードウェア・グラフィックス・レンダリング・エンジンのサポートによって、またはそのモジュール内で直接、オーダ・リストを解釈する。このモジュールは、フォールバック管理機能の必要に応じて、ページ全体を生成することも１つのバンド／オブジェクトのみを生成することもできる。
【００１８】
【発明の実施の形態】
ページ記述言語のインタプリタがイメージ生成することができるすべてのページを維持可能な最高の印刷品質で印刷することができるようにすると同時に、複雑さに関係なくすべてのページが確実に印刷されるようにする、グラフィックス・サブシステムを形成する方法および装置を開示する。
【００１９】
図１を参照すると、本発明はパーソナル・コンピュータまたはワークステーション１１と組み合わせて機能し、ラスタ・プリンタ１３などの連続同期ラスタ・イメージ出力装置用の出力を生成する。ワード・プロセッサなどのアプリケーション１５が所望の出力を生成し、それをプリンタ・ドライバ１７が処理してＰｏｓｔｓｃｒｉｐｔなどのページ記述言語のコマンドを生成する。ページ記述言語コマンドは、レーザ・プリンタ内のメモリ２０を含むコントローラ・サブシステム１９として示されている本発明のグラフィックス・サブシステムに渡され、そのサブシステムによってコマンドが適切なビットマップに変換されて印刷エンジン２１に渡され、所望の出力を含むページを「印字」する。
【００２０】
コントローラ・サブシステムは、ページ・イメージのレンダリング、印刷エンジン２１へのイメージの供給を処理する。グラフィックス・サービス・インタフェースは、基礎となるハードウェア・サポートに関係なく同じである。コントローラ内のグラフィックス・サービス・インタフェースのグラフィックス・サービス・ルーチンが、目的ビットイメージの座標系で動作する。イメージの座標系の原点はビットイメージの最初の画素に対応する。
【００２１】
次に図２を参照すると、本発明のグラフィックス・サブシステムを形成するコントローラ１９の各モジュールが図示されている。プリンタまたはページ記述言語インタプリタ２５の出力が、幅と長さを示すことによって印刷するページ・イメージのサイズを指定する。プリンタ言語インタプリタの出力は、典型的には画素数単位で表される上部および左マージン・パラメータを指定することによって物理ページ内のイメージの配置も指定する。
【００２２】
グラフィックス・サービス・インタフェース２７は、ページに関する呼出しとビットイメージを描画する呼出しの、２つのタイプの呼出しを処理する。描画ビットイメージ呼出しは５つのクラスに分かれる。一般に、各クラスは少なくとも２つの呼出しを有する。１つはシステムが管理するページ・イメージ・ビットマップを作成するための呼出しで、もう一方は、インタプリタが管理する宛先のための呼出しである。これらの呼出しは新規ページ・モジュール３１と、グラフィックス・オーダ生成モジュール３３と、ページ終了モジュール３５とによって処理される。
【００２３】
表１に、インタプリタ２５からのコマンドに基づいてグラフィックス・サービス・インタフェースによって行われる様々な呼出しを示す。
【表１】

【００２４】
以下に、本発明を理解するために必要な新規ページおよびページ終了モジュールについて説明する。個々の描画呼出しと、グラフィックス・オーダ生成モジュール３３による処理の詳細は、本発明を理解するために必要なものではない。そのため、描画呼出しについては具体的には説明せず、概説的に説明する。新規ページ・ハンドラ、グラフィックス・オーダ生成およびページ終了ハンドラを使用する典型的なグラフィックス・サービス・インタフェースの詳細な実施態様は、１９９４年７月２０日出願のＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓＦｏｒＤｉｓｐｌａｙｉｎｇＡＰａｇｅＷｉｔｈＧｒａｐｈｉｃｓＩｎｆｏｒｍａｔｉｏｎＯｎＡＣｏｎｔｉｎｕｏｕｓＳｙｎｃｈｒｏｎｏｕｓＲａｓｔｅｒＯｕｔｐｕｔＤｅｖｉｃｅという名称の米国特許出願第０８／２７７７８８号に記載されている。
【００２５】
新規ページ
新規ページ・モジュール３１は、それに続くグラフィックス・コマンドによって生成するページを定義する。この呼出しの引数には、「印字」する領域の寸法、マージン、およびオプションが含まれる。グラフィックス・サブシステムは、幅パラメータと長さパラメータを使用してページ・イメージの大きさを決定する。また、上部マージン・パラメータと左マージン・パラメータを使用して、印刷エンジン・ドライバ３９に物理ページ内の画像の配置を通知する。

【００２６】
この要求は、新規ページ・イメージの作成を開始しようとする呼出し側の意図を宣言している。グラフィックス・サブシステムは、特定の内部資源を割り振り、それに続くグラフィックス要求で使用する固有のページ・タグを返す。処理することができるのは一度に１つのページ・イメージだけである。
【００２７】
ページ長および幅パラメータによって、作成するイメージの寸法を定義する。ページ・イメージに書き込む画素はその寸法にクリップされる。
【００２８】
オプションは、ページ・イメージ・メモリの初期設定と使用可能なメモリがない場合の新規ページの反応を制御する。グラフィックス・サービス・インタフェース２７がＧＲＳ＿ＮＯＷＡＩＴフラグを立てた場合、新規ページは必要なメモリを割り振ることができない場合にエラー・コードを返す。ＧＲＳ＿ＮＯＷＡＩＴフラグがゼロの場合、新規ページは現在使用中の資源が使用可能になるまで待つ。
【００２９】
オプション・フラグＧＲＳ＿ＰＧ＿ＭＩＲＲＯＲ＿Ｙが１の場合、ビット・イメージはビット・イメージのＹ軸で鏡映されてから印刷エンジン・ドライバに送られる。オプション・フラグＧＲＳ＿ＰＧ＿ＭＩＲＲＯＲ＿Ｘが１の場合、ビット・イメージはビット・イメージのＸ軸で鏡映されてから印刷エンジン・ドライバに送られる。ＧＲＳ＿ＰＧ＿ＭＩＲＲＯＲ＿ＹとＧＲＳ＿ＰＧ＿ＭＩＲＲＯＲ＿Ｘの組合せはページの１８０度の回転を指定するために使用する。この２つのオプションはハードウェアがサポートしない場合は個別に使用することができない。
【００３０】
ページ終了
グラフィックス・サービス・インタフェースは、ページ終了モジュール３５を呼び出して、グラフィックス・サブシステムに現行ページの処理が完了したことを通知する。システムは、そのページを印刷し、印刷が行われると任意選択によりインタプリタ完了関数を呼び出す。部数値（ｃｐｙｃｎｔ）が１より大きい場合、最後の一部が印刷された後に完了関数が呼び出される。グラフィックス・サービス・インタフェース２７がページの印刷を抑止したい場合は、ページ打切りを呼び出す。

【００３１】
ＥＮＤ＿ＰＡＧＥ関数によって、グラフィックス・サービス・インタフェース２７は印刷するページがあることを印刷エンジン・ドライバ３９に通知する。ＥＮＤ＿ＰＡＧＥ要求は、印刷要求を待ち行列に入れた直後に返って、印刷段階中にインタプリタが実行を継続することができるようにする。最後のイメージ・コピーが印刷されたときやエラー時には、指定された完了関数が呼び出される。完了ルーチンは以下のようにして呼び出される。

【００３２】
グラフィックス・オーダ生成
一般に、グラフィックス・オーダ生成モジュール３３によって処理される描画呼出しは入力データとしてビットマップ記述を予期する。この記述子の最も単純な形は、ビットマップ原点アドレスと、画素数単位のビットマップ幅と、走査線数単位のビットマップ高とを含む。ハーフトーン・パターンのビットマップ記述子は、いくつかの追加のフィールドを有し、ワード数単位のビットマップ・サイズと宛先ｘ原点、および宛先ｙ原点を指定する。
【００３３】
ハーフトーンの宛先ｘおよびｙ原点パラメータは、ハーフトーン・ビットマップ内の宛先の原点を指定する。ハーフトーン・ビットマップが宛先より小さい場合は、それが宛先内に複製される。
【００３４】
ビットマップ記述子は呼出し中にのみ使用される。アプリケーションは、前のサービス要求に影響を与えずに、後の呼出しのためにその内容を変更し、再使用することができる。
【００３５】
画素を書き込むすべてのサービス要求には「ｐｉｘｏｐ」パラメータが与えられる。ユーザは、宛先のみ、供給源／宛先、ハーフトーン／供給源／宛先という関係する画素のブール組合せを指定する。
【００３６】
グラフィックス・メモリ管理
グラフィックス・メモリ管理モジュール４１の目的は、記憶域割り振り機構にグラフィックス・オーダを与えることである。このモジュールは、フォールバック管理モジュール４５が中間記憶装置なしにページ上のすべてのバンドを圧縮するのに必要な処置をとることができるように、固定量のメモリを管理する。グラフィックス・メモリ管理モジュールは、固定量のメモリをフレームに分割し、各フレームは圧縮されたバンドに必要な大きさである。１バンドについて正確に１つのフレームがあり、したがってバンドが有損失圧縮された場合、そのバンドはそのバンドに付随するフレームに格納される。グラフィックス・メモリ管理モジュール４１は、各フレーム内のメモリを占有するすべてのバンドのリストを維持する。フレーム内の空間を占有する各バンドをフレームの従属者と呼ぶ。バンドを圧縮するためには、そのバンドのフレームは従属者を持っていてはならない。フォールバック管理機能は従属関係情報を使用してすべてのバンドを圧縮する順序を識別する。
【００３７】
たとえば、５つのバンドがあり、したがって５つのフレームがあって、以下の従属関係があるとする。
フレーム１は従属者を持たない
フレーム２＜−３（フレーム２はバンド３のオーダ・リスト・ブロックを持つ）
フレーム３＜−４、５（フレーム３はバンド４のオーダ・リスト・ブロックとバンド５のオーダ・リスト・ブロックを持つ）
フレーム４は従属者を持たない
フレーム５は従属者を持たない
【００３８】
従属関係は、以下のように、従属者を枝、従属者がないフレームを葉として、１フレームに１つずつ１組のツリーとして表すこともできる。
【数１】

【００３９】
フレーム１、４、および５は従属者を持たず、したがって枝を持たない。このツリー構造を仮定すると、すべてのバンドを圧縮するプロセスは、すべての従属関係ツリーをたどることであり、葉によって行うべき圧縮が識別される。バンドは圧縮された後はどのフレームの従属者でもなくなり、したがってツリー構造から除去される。すべてのバンドを圧縮するプロセスは、以下の順序（左から右の順）で行われる。
【数２】

【００４０】
グラフィックス・メモリ管理モジュールは、上述の従属関係ツリーが決して以下のように循環しないように、割り振るフレームを選定しなければならない。
【数３】

【００４１】
このツリーは循環しており、したがって単純な走査が決して終了しない。グラフィックス・メモリ管理機能は、フレーム従属関係ツリーが循環しないようにしてのみメモリを割り振る。そのように仮定して、フォールバック管理機能は従属関係ツリー走査のプロセスを使用してページを有損失圧縮することができる。
【００４２】
グラフィックス・メモリ管理モジュール４１は、表示リスト・オーダとそれに付随するデータに記憶空間を割り振る機能を果たす。従来のグラフィックス・メモリ管理と異なる点は、構成時にきわめて大きなヒープを割り振り、そのヒープを印刷環境の需要を満たすように内部的に管理することである。グラフィクス・メモリ管理モジュール４１はそのヒープを使い果たすと、オブジェクトまたはバンドあるいはその両方の圧縮をフォールバック管理機能に依存して記憶空間を再生する。したがって、グラフィックス・メモリ管理モジュールとフォールバック管理機能は両方ともこのヒープ・データ構造体と内容へのアクセスを必要とする。ヒープに加えて、グラフィックス・メモリ管理モジュール４１はレンダリング／圧縮解除エンジン・モジュール５５と１組のフルサイズ・バンド・バッファも共有する。
【００４３】
グラフィックス・サブシステムは基本的にバンド化システムであり、１組のオーダを使用して、ページとそのページを印字するために使用するいくつかのバンド・バッファをレンダリングする。グラフィックス・サブシステム内で管理されるメモリは、オーダといくつかのバンド・バッファとを保持するヒープである。どのような構成でも最低２つのバンド・バッファが必要である。グラフィックス・メモリ管理モジュールは、構成（二重設定、解像度およびプリンタ内の合計メモリ量）に基づいてヒープ・サイズとバンド・バッファの数を決定する。
【００４４】
グラフィックス・メモリ管理モジュール４１は、オーダ・リストの記憶と管理用に最適化された固有のヒープ構造体からすべてのオブジェクトを割り振る。グラフィックス・メモリ管理モジュールを構成するときに、すべてのページを印刷する最低サイズの永続ヒープを割り振る。この永続ヒープが使い果たされると、グラフィックス・メモリ管理モジュールは、フォールバック管理モジュールを呼び出す前に、ブロック・メモリ管理機能５１から直接さらにメモリを割り振ろうとする。これは、最低サイズを超えるプリンタ内のメモリを利用する。ここに割り振られるメモリは、永続ヒープと同様に使用されるが、システム内の他の構成要素がメモリを使い果たした場合に要求に応じて使用されることになるため、一時ヒープと呼ばれる。
【００４５】
ビデオ不足予測機能
ビデオ不足予測機能４７は、組込みメトリックを使用して、バンドのオーダの実行の結果としてビデオ不足になるかどうかを判断する。ビデオ不足は、グラフィックス・オーダ生成モジュール３３が、連続同期出力装置のためにビデオ・ストリームを生成するのに必要な時間内にすべてのオーダを実行することができない場合に発生する。予測に使用されるメトリックは、オーダ実行手段が許容時間内に実行すると予測することができるオーダ数の単純な最大値とすることができる。それよりやや複雑なメトリックとしては、最大オーダ限界や最大メモリ・アクセス値がある。
【００４６】
単純なメトリックを使用して、ビデオ不足予測機能はオーダ・リストを読み取り、各バンドの個々のオーダ数を限界値と比較する。バンドのオーダ数が限界値を超える場合、予測機能はそのバンドのオーダを実行すればビデオ不足になると結論づける。
【００４７】
損失検査
損失検査モジュール４９は、いずれかのバンドがすでに有損失圧縮済みになっていないかどうかを調べる。そのような条件があると、このモジュールは現行ページのすべてのバンドの有損失圧縮を強制して、ページ品質を一貫させる。
【００４８】
ブロック・メモリ管理機能５１は、永続ヒープを使い果たしたときに前記のようにグラフィックス・メモリ管理モジュール４１によって呼び出される。本発明を理解するのに、適合するブロック・メモリ管理機能の詳細は不要である。機能的には、ＵｎｉｘＭＡＬＬＯＣ操作に相当することを行う。
【００４９】
圧縮エンジン・モジュール５３とレンダリング／圧縮解除エンジン５５が、フォールバック管理モジュール４５の必要に応じて実際の圧縮とレンダリング／圧縮解除を行う。本発明を理解するのにこれらのモジュールの特定の実施態様の詳細は不要である。しかし、適合する圧縮およびレンダリング／圧縮解除実施態様については、１９９４年１０月１８日出願のＢｉ−ｌｅｖｅｌＩｍａｇｅＣｏｍｐｒｅｓｓｉｏｎＢｙＧｒａｙｓｃａｌｅＥｎｃｏｄｉｎｇという名称の同時係属出願第０８／３２４６８２号と、１９９６年１月２日出願のＭｅｔｈｏｄａｎｄＡｐｐａｒａｔｕｓＦｏｒＤｏｕｂｌｅＲｕｎ−ＬｅｎｇｔｈＥｎｃｏｄｉｎｇＯｆＢｉｎａｒｙＤａｔａという名称の同時係属出願第０８／５８２１５０号に記載されている。二階調以外のデータにはその他の適合する圧縮方法が使用可能である。
【００５０】
本発明を理解するのに印刷エンジン・ドライバ３９の適合する実施態様の詳細は不要である。しかし、そのような詳細は、このドライバを必要とする特定の印刷エンジンを知っている当業者には容易にわかるはずである。
【００５１】
フォールバック管理モジュール
フォールバック管理モジュール４５は、メモリあふれと予測ビデオ不足を処理する。
【００５２】
メモリあふれの解決策
オーダ構築中にメモリあふれが起こることがある。その場合、オーダ構築によってフォールバック管理機能が呼び出され、メモリを解放することによってその状況を解消する。フォールバック管理機能がメモリあふれを解決する方法は５通りある。フォールバック管理機能はそれらの方法を以下に示す順序で採用する。第１の方法で問題が解決した場合は、第２の方法に進む必要はない。
１．１つまたは複数のラスタの無損失圧縮
２．すべてのラスタの有損失圧縮
３．オーダ・リストがバンドより大きい場合はバンドのプリレンダリング
４．一部のバンドの無損失圧縮
５．すべてのバンドの有損失圧縮
【００５３】
フォールバック管理機能は、まず、オーダ・リスト内のラスタ・オブジェクトの表現を変更して、それらのラスタ・オブジェクトの現行ビットマップまたは走査線テーブル表現にテキストとライン・アート・オブジェクトを残すことによって、メモリあふれの解決を試みる。この手法によって、テキストおよびコンピュータ描画（ライン・アート）オブジェクトの解像度と印刷品質が保持される。無損失圧縮を適用してラスタのサイズを縮小することができる場合は、それらの品質も保持される。
【００５４】
必要なメモリを獲得するためにラスタに有損失圧縮を適用しなければならない場合でも、テキストとコンピュータ描画オブジェクトの品質は維持される。さらに、オーダ・リストには各オブジェクトの識別情報も維持される。１つのラスタを有損失圧縮すると、そのページの一貫した品質を確保するためにすべてのラスタを有損失圧縮しなければならない。
【００５５】
フォールバック管理機能は、方法１または２を使用して必要なメモリを獲得できない場合、オーダ・リストの実行を開始してレンダリングされたバンドを作成することによって、バンドのオーダ・リストを解放しなければならない。これが方法３である。
【００５６】
方法３で不十分な場合、フォールバック管理機能は方法４に進んで、バンドの無損失圧縮を開始する。その場合でも品質は保持されるが、オブジェクト・タイプ間の区別は失われる。
【００５７】
方法４でも不十分な場合、フォールバック管理機能は方法５に進む。方法５によってバンド・イメージが変わるため、有損失バンドに適用されるそれ以降のオーダは、まずそのバンドを圧縮解除してからでなければ実行することができない。１つのバンドが有損失圧縮される場合、ページ全体の一貫した品質を確保するために、印刷する前にすべてのバンドを有損失圧縮しなければならない。このステップは、ページ終了まで据え置くことができる。方法５はメモリあふれの解決に常に成功する。
【００５８】
ビデオ不足の解決策
すべてのオーダが構築され、インタプリタがＥＮＤＰＡＧＥ（ページ終了）を呼び出した後、ＥＮＤＰＡＧＥはビデオ不足予測機能を呼び出してビデオ不足の可能性がないか検査する。あるバンドについてビデオ不足が予測される場合、フォールバック管理機能にはビデオ不足を解決する方法が３通りある。フォールバック管理機能はそれらの方法を以下に示す順序で採用する。第１の方法で問題が解決された場合は、第２の方法に進む必要はない。
１．ビデオ不足が予測されたバンドをプリレンダリングする
２．ビデオ不足が予測されたバンドを無損失圧縮する
３．すべてのバンドを有損失圧縮する
【００５９】
方法１では、フォールバック管理機能は、ビデオ不足が予測されるバンドに関するオーダ・リストの実行を開始する。圧縮せずにこのプロセスを完了するのに使用可能な十分なメモリがない場合、フォールバック管理機能は方法２に進む。
【００６０】
方法２では、フォールバック管理機能は方法１でプリレンダリングされた１つまたは複数のバンドの無損失圧縮を開始する。フォールバック管理機能は、不足が予測されたすべてのバンドがプリレンダリングされるまで方法１と２の間を反復する。無損失圧縮ができなかった場合、フォールバック管理機能は方法３に進む。
【００６１】
方法３で使用される有損失圧縮によって、使用可能なメモリ内ですべてのバンドを圧縮することができるように保証されるため、この方法は失敗することがない。
【００６２】
ラスタ圧縮
ラスタ圧縮は、フォールバック管理機能の要求に応じて圧縮エンジン５３によって行われる。ラスタ圧縮の目的は、オーダ構築をさらに行うと同時にオーダ・リストを維持するために、メモリを解放することである。
【００６３】
無損失ラスタ圧縮
無損失圧縮は、未圧縮ラスタのみに対して行われる。この圧縮は、フォールバック管理機能の指示により圧縮エンジン５３が行う。フォールバック管理機能は、解放する目標バイト数を持っており、そのバイト数が解放されるかまたは無損失圧縮が失敗するまでラスタの圧縮を続ける。また、フォールバック管理機能は、圧縮されたラスタを、グラフィックス・メモリ管理機能によってラスタが存在するフレームに割り振られた空間内のホールまたは未使用メモリに入れようとする。未使用空間またはホールが見つからない場合、圧縮出力データに一時的なスクラッチ空間が使用される。ラスタ・オブジェクトが圧縮されると、未圧縮の供給源が解放され、プロセスを継続した場合にその後で使用するための未使用空間またはホールができる。
【００６４】
圧縮プロセスには以下の規則と優先順位が適用される。
１．まず、前に圧縮されていない最大ラスタ数を有する１つまたは複数のフレーム内のラスタを圧縮する。
２．ホールに近接するラスタを先に圧縮してより大きなホールを作る。
３．フレームの上から下の順にラスタを圧縮し、それによって、ホールができるときにラスタのセットがフレームの先頭方向に縮められるようにする。
４．ホールが存在しない場合、ラスタをスクラッチ空間に圧縮し、次に、未圧縮ラスタが前に占有していた場所に圧縮済み出力を戻す。これによって、未圧縮ラスタと圧縮済みラスタとの間の差のサイズのホールができる。
【００６５】
有損失ラスタ圧縮
有損失ラスタ圧縮は、無損失ラスタ圧縮と同様に機能するが、結果が予測可能であり、圧縮できないことがない点が異なる。
【００６６】
バンドのプリレンダリング
バンドのプリレンダリングは、バンドのオーダ・リストを実行してそのバンドの印刷可能イメージを作成することから成る。この操作はレンダリング・エンジン５５が行う。オーダ・リストの実行は、バンドがＥＮＤＰＡＧＥの後にレンダリングされた場合と同じである。
【００６７】
バンド圧縮
バンド圧縮とは、レンダリング済みバンドの圧縮を指す。すなわち、バンドのオーダ・リストを実行し、その結果のバンド・バッファを圧縮しなければならない。レンダリング・エンジン５５がオーダ・リストを実行し、圧縮エンジン５３が圧縮を行う。ラスタ圧縮の場合と同様、有損失バンド圧縮に進む前に無損失バンド圧縮を試みる。いずれかのバンドが有損失圧縮されると、ページ・イメージ全体で一貫した品質が得られるようにすべてのバンドを有損失圧縮しなければならない。
【００６８】
バンド圧縮は、より優先される方法が失敗した場合にメモリあふれに応答してオーダ構築中に使用されるか、またはビデオ不足が予測された場合にＥＮＤＰＡＧＥ処理中に使用される。いずれの場合も、バンド圧縮の目的はプロセスの継続を可能にするのに必要なメモリ量を解放することである。
【００６９】
無損失バンド圧縮
バンド圧縮が必要な場合は無損失バンド圧縮が好ましいが、それは印刷品質が維持され、したがってフォールバック管理機能にすべてのバンドを強制的に圧縮させないためである。メモリあふれの場合、バンド圧縮によってメモリが解放され、それをヒープ内のオーダ・リストに追加のオーダを収容するために使用することができる。これは、以下の２通りの方法で行うことができる。
１．新しいオーダを格納するのに十分な空間が解放されるまでバンドを圧縮する
２．新しいオーダをただちにバンド・バッファにレンダリングしてバンドを圧縮し、新しいオーダの出力を組み込む。
【００７０】
第１の方法の方が、多くの新しいオーダを収容するのに十分なメモリを迅速に解放することができるため、好ましい。第２の方法は、本質的にページ上のいくつかのバンド・バッファをキャッシュする（他のすべてのバンドは圧縮される）ため、バンド・キャッシングと呼ぶ。効率的に機能するためには、キャッシュされたバンドに新しいオーダが頻繁にヒットしなければならず、そうでない場合には圧縮／圧縮解除シーケンスが頻繁になる。最小メモリ構成では、１つのキャッシュ・バンドのみが使用可能である。
【００７１】
１つのバンドしかキャッシュすることができないと仮定すれば、無損失バンド圧縮は主として方法１に依存するが、実際には両方の方法の組合せである。バンドが圧縮された後、そのバンドの新しいオーダ・リストには１つの圧縮解除オーダがある。メモリが使用可能な限りは、そのバンドの新しいオーダが単にリストに追加されるだけである。メモリが使い果たされた場合、レンダリングされたバンド・バッファは、その新しいオーダがレンダリングされるだけでよい。その後、バンド・バッファを再圧縮して、（方法２で行われるように）すべての新しいオーダを組み込むことができる。したがって、アルゴリズムは厳密には方法１から着手するが、その後で方法２に移行し、圧縮データをヒープに戻して収まり切らない場合には、最終的に失敗することがある。その時点で有損失バンド圧縮が開始される。
【００７２】
バンド圧縮を使用してビデオ不足を解決する場合、元のオーダ・リストを置き換えなければならない。無損失圧縮されたバンドは依然としてビデオ不足の場合がある。その場合、完全にレンダリングされたバンド自体が、可能なバンドの唯一の無損失表現である。圧縮エンジン５３が使用するバンド圧縮アルゴリズムは、この状況を識別して、レンダリングされたバンド全体が収まるように空間を解放しようとする。
【００７３】
有損失バンド圧縮
無損失バンド圧縮から有損失バンド圧縮への移行は、圧縮エンジン５３の無損失アルゴリズムの１つが、必要なメモリ量を解放することができない場合に起こる。有損失バンド圧縮では、ネイティブ・フレームを使用して圧縮済みバンドを保持する。フレーム・サイズは有損失圧縮比と整合するため、収容されることがわかる。さらに、有損失圧縮されたバンドにはビデオ不足はない。これは、ページの最終表現であり、基礎となるハードウェアによって成功が保証される。有損失バンド圧縮の主な目的は、デッドロックなしに、最小量のデータ・ブロック・コピーですべてのバンドを圧縮することができるように保証することである。有損失バンド圧縮は、まだヒープに収まらないバンドが１つある状態で開始されることに留意されたい。これが以下のアルゴリズムによって得られる有損失バンド圧縮の開始対象である。
【００７４】
本発明と共に使用するのに適したフォールバック管理モジュールの実施態様に関する本発明の動作態様および詳細について、図３、図４、および図５を参照しながら以下に説明する。
【００７５】
まず図３を参照し、以下の略語が使用されていることに留意されたい。
ＥＮＤＰＧ＝オーダ生成完了
ＯＭ＝メモリ切れ条件検出
ＶＵ＝ビデオ不足予測
【００７６】
状態６１は、プリンタ言語インタプリタ２５がＥＮＤＰＧコマンドを発行するまでグラフィックス・オーダ生成モジュール３３によってオーダ・リストにオーダが追加される、正常なオーダ構築状態である。ＥＮＤＰＧが発生すると、ビデオ不足の可能性がないか検査される。ビデオ不足予測機能４７がビデオ不足条件が存在する可能性があると判断した場合、状態６３への移行が行われる。
【００７７】
メモリ切れ条件が生じた場合、オーダ・リストにラスタがないか検査される。ラスタは画素値の配列である。どのような画像もラスタとして表現することができるが、パーソナル・コンピュータまたはワークステーションのドライバ１７（図１参照）は典型的にはプリンタに写真イメージを送るためにラスタを使用する。二階調イメージの場合、ラスタ内の画素値はそれぞれ１ビットであり、０または１の値を有する。１画素当たり複数画素のグレイスケールまたはカラーのイメージの場合、画素値は０から、１画素当たりビット数単位で表すことができる最大値（典型的には１６、６４、２５６など）までの範囲である。
【００７８】
本発明によると、インタプリタは以下の呼出しを使用してシステムにラスタを供給する。
【表２】

ラスタがある場合、状態６５への移行が行われる。ラスタがない場合、状態６３への移行が行われる。
【００７９】
状態６５の間に、圧縮エンジン５３によってラスタが空きメモリと比較され、グラフィックス・オーダ生成モジュール３３によってオーダ・リストにオーダの追加が続けられる。メモリ切れ条件が発生すると、状態６７への移行が起こる。ビデオ不足予測機能４７によってＥＮＤＰＧでビデオ不足条件の可能性が検出された場合には、状態６７への移行も行われる。
【００８０】
状態６７では、圧縮エンジン５３によって無損失圧縮が行われ、メモリを解放するために１つまたは複数のバンドが圧縮される。成功した場合、グラフィックス・オーダ生成モジュール３３はオーダ・リストへのオーダの追加を続ける。無損失圧縮によってバンド・バッファにあふれが生じた場合、状態６９への移行が行われる。なお、無損失圧縮の有効性はデータによって異なることに留意されたい。場合によっては、無損失圧縮方法によって、入力データより大きな出力データが生じることがある。これは、無損失圧縮の失敗を引き起こす原因である。１９９４年１０月１８日出願のＢｉ−ｌｅｖｅｌＩｍａｇｅｃｏｍｐｒｅｓｓｉｏｎＢｙＧｒａｙｓｃａｌｅＥｎｃｏｄｉｎｇという名称の同時係属出願第０８／３２４６８２号に記載されているグレイスケール・コード化圧縮のような有損失圧縮は、予測可能なより小さい出力データを生じさせる。
【００８１】
状態６３には前述のように移行する。状態６７の場合と同様に、バンドの無損失圧縮の失敗によって、状態６９への移行が起こる。
【００８２】
状態６９は、圧縮エンジン５３によって行われる有損失バンド圧縮を使用して、ページ・データをメモリに収めることができ、リアルタイムでイメージ生成することができるように保証されるため、失敗はあり得ない。この状態になった後は、ページ全体が有損失圧縮を使用して圧縮されることになる。しかし、この最終ステップは、ＥＮＤＰＧに達するまで据え置かれる。目標バンド・バッファを圧縮解除してただちにイメージ生成するよりも、オーダ・リストに追加する方が効率的である。
【００８３】
状態７１で、圧縮エンジン５３とレンダリング／圧縮解除エンジン５５によって有損失バンド圧縮の完了が処理される。
【００８４】
無損失圧縮の有効性はデータにより異なる。場合によっては無損失圧縮方法によって入力データより大きな出力データが生成されることがある。
【００８５】
図４に、グラフィックス・オーダ生成処理中にフォールバック管理モジュール４５がメモリあふれを処理するために用いる流れを示す。グラフィックス・メモリ管理モジュール４１の判断により呼出しによってメモリあふれが生じる場合（ブロック８１）、待つことによってメモリが使用可能になるかどうかが判断される（ブロック８３および８５）。この判断は、現在イメージ生成と印刷が行われている前のページがあるかどうかを調べることによって行われる。進行中の前のページがある場合、それらのページの印字と出力が行われればメモリが使用可能になる。ページに圧縮可能なラスタがある場合（ブロック８９）、圧縮エンジン５３は可能であれば無損失圧縮を行い、無損失圧縮が可能でない場合には有損失圧縮を行う（ブロック９１）。ページに圧縮可能ラスタがあるかどうかの判断は、オーダ・リストを探索して未圧縮ラスタを探すことによって行われる。ページに圧縮可能ラスタがない場合（ブロック８９）、圧縮エンジン５３は可能であれば無損失バンド圧縮を行い、無損失バンド圧縮が可能でない場合は有損失バンド圧縮を行う（ブロック９１）。バンドについてこの圧縮が行われた後、フォールバック管理機能が、空きメモリが次のオーダを追加するのに必要な最小値を超えているか調べる（ブロック９３）。空きメモリが最小値を超えると、グラフィックス・オーダ生成モジュール３３によって次のオーダを処理することができる（ブロック９５）。空きメモリが最小値を超えない場合、さらに圧縮が行われる（ブロック９１）。
【００８６】
図５に、ページ終了処理中にフォールバック管理モジュール４５が可能性のあるビデオ不足を解消するために用いる流れを示す。損失検査４９によってバンドの有損失圧縮が必要であると判断された場合（ブロック１０１）、圧縮エンジン５３とレンダリング／圧縮解除エンジン５５がすべてのバンドを有損失圧縮する（ブロック１０３）。次に、ビデオ不足予測機能４７がビデオ不足バンドを予測した場合（ブロック１０５）、グラフィックス・メモリ・モジュール４１がビデオ不足バンドを完全にイメージ生成するのに十分なメモリがあるかどうかを調べる（ブロック１０７）。十分なメモリがある場合、圧縮エンジン５３とレンダリング／圧縮解除エンジン５５は予め不足のバンドをプレレンダリングする（ブロック１０９）十分なメモリがない場合、グラフィックス・メモリ管理モジュールを使用して、ビデオ不足バンドを無損失圧縮するのに十分なメモリがあるかどうかを判断する（ブロック１１１）。ある場合には、圧縮エンジン５３とレンダリング／圧縮解除エンジン５５が不足バンドを無損失圧縮する（ブロック１１３）。ない場合には、圧縮エンジン５３とレンダリング／圧縮解除エンジン５５はすべてのバンドを有損失圧縮する（ブロック１０３）。
【図面の簡単な説明】
【図１】本発明を使用することができるシステム全体を示すブロック概要図である。
【図２】本発明のサブシステムのモジュールを示すブロック図である。
【図３】本発明のサブシステムによる処理を示す状態図である。
【図４】グラフィックス・オーダ生成呼出しのために本発明のサブシステムのフォールバック管理モジュールによって行われる処理を示すブロック図である。
【図５】ページ終了呼出しのために本発明のサブシステムのフォールバック管理モジュールによって行われる処理を示すブロック図である。
【符号の説明】
１１パーソナル・コンピュータまたはワークステーション
１３ラスタ・プリンタ
１５アプリケーション
１７プリンタ・ドライバ
１９コントローラ・サブシステム
２１印刷エンジン
２５ページ記述言語インタプリタ
２７グラフィックス・サービス・インタフェース
３１新規ページ・モジュール
３３グラフィックス・オーダ生成モジュール
３５ページ終了モジュール
３９印刷エンジン・ドライバ
４１グラフィックス・メモリ管理モジュール
４５フォールバック管理モジュール
４７ビデオ不足予測機能
４９損失検査モジュール
５１ブロック・メモリ管理機能
５３圧縮エンジン・モジュール
５５レンダリング／圧縮解除エンジン・モジュール

Claims

ラスタ表現を生じさせるラスタ・オブジェクトを含む基本イメージ表現をそれぞれ生じさせる複数のオブジェクトを含むオーダ・リストをそれぞれ有する複数のバンドからなるイメージ・データであって、メモリに格納されたイメージ・データを、連続同期ラスタ・イメージ出力装置に出力するよう構成したシステムにおいて、
前記メモリが前記イメージ・データを格納するに十分な大きさを有しているか否かを判断する判断手段と、
この判断手段が「不十分」と判断したときに、該イメージ・データを、
（１）１つまたは複数のラスタ・オブジェクトの無損失圧縮、
（２）すべてのラスタ・オブジェクトの有損失圧縮、
（３）前記（１）、（２）でなお不十分な場合は該イメージ・データ内のバンドのプリレンダリング、
（４）前記イメージ・データ内の一部のバンドの無損失圧縮、および
（５）該イメージ・データ内のすべてのバンドの有損失圧縮
の順で処理する圧縮手段と
を備え、さらに、
この圧縮手段は、前記（１）〜（４）のいずれかの処理により前記「不十分さ」が解消した場合にはそれ以降の処理を行わないことを特徴とするシステム。
請求項１記載のシステムにおいて、さらに、
前記イメージ・データのいずれかのバンドがビデオ不足を生じるか否かを判断する判断手段と、
この判断手段が「ビデオ不足を生じる」と判断したときに、
（１）ビデオ不足が予測されたバンドをプリレンダリングする
（２）ビデオ不足が予測されたバンドを無損失圧縮する
（３）すべてのバンドを有損失圧縮する
の順で、前記イメージ・データを処理して「ビデオ不足」を解決するビデオ不足解決手段と
を備え、さらに、
このビデオ不足解決手段は、前記（１）〜（２）のいずれかの処理により前記「ビデオ不足」が解決した場合にはそれ以降の処理を行わないことを特徴とするシステム。
コンピュータ・プログラムによって生成された記述データから、連続同期ラスタ・イメージ出力装置のドライバによって使用されるイメージ・データを生成する方法であって、
ａ）前記記述データ内のコマンドを受け取り、前記コマンドのそれぞれを新規ページ・コマンドと描画コマンドとページ終了コマンドとのうちの１つとしてコマンド処理手段に渡すステップと、
ｂ）前記コマンド処理手段によって、前記新規ページ・コマンドを処理するステップと、
ｃ）前記コマンド処理手段によって、前記描画コマンドを処理し、前記イメージ・データのバンドを表すグラフィックス命令を生成するステップと、
ｄ）前記コマンド処理手段によって、前記ページ終了コマンドを処理するステップと、
ｅ）メモリ管理手段により、前記描画コマンドの処理において使用されるようにメモリの割り振りを管理するステップであって、このステップが、
ｆ１）前記イメージデータのバンドを前記出力装置のドライバに、該出力装置が必要とする速度で供給することができるようにするために、前記メモリに前記バンドを記憶する際に、無損失圧縮および有損失圧縮を行うよう構成された圧縮手段によって、該バンドを圧縮する必要があるか否かを判断するステップをさらに有し、
ｆ２）この判断ステップにおいて、「圧縮が必要」と判断されたときに、前記バンドを含むイメージ・データを、
（１）１つまたは複数のラスタ・オブジェクトの無損失圧縮、
（２）すべてのラスタ・オブジェクトの有損失圧縮、
（３）前記（１）、（２）でなお不十分な場合はバンドのプリレンダリング、
（４）一部のバンドの無損失圧縮、および
（５）すべてのバンドの有損失圧縮
の順で処理する圧縮ステップ
を実行するよう構成され、さらに、
この圧縮ステップにおいて、前記（１）〜（４）のいずれかの処理により「さらなる圧縮は不要」となった場合にはそれ以降の処理を行わないことを特徴とする方法。
請求項３記載の方法において、前記ページ終了コマンドを処理するステップが、さらに、
前記イメージ・データのいずれかのバンドがビデオ不足を生じるか否か判断する判断ステップを有し、
この判断ステップにおいて「ビデオ不足を生じる」と判断されたときに、
（１）ビデオ不足が予測されたバンドをプリレンダリングする
（２）ビデオ不足が予測されたバンドを無損失圧縮する
（３）すべてのバンドを有損失圧縮する
の順で、前記イメージ・データを処理して「ビデオ不足」を解決するビデオ不足解決ステップ
を実行するよう構成され、さらに、
このビデオ不足解決ステップにおいては、前記（１）〜（２）のいずれかの処理により前記「ビデオ不足」が解決した場合にはそれ以降の処理を行わないことを特徴とする方法。
請求項３記載の方法において、
前記ページ終了コマンドを処理するステップが、オーダ・リスト状態、有損失ラスタ＋オーダ・リスト状態、有損失ラスタ＋無損失バンド＋オーダ・リスト状態、すべての有損失バンド状態のいずれかを経てページを印字するステップを含む方法。
請求項３記載の方法において、
前記コマンド処理手段が、ページ記述言語の呼出しを処理すると共に該呼出しを新規ページコマンド処理手段、描画コマンド処理手段及びページ終了コマンド処理手段によって使用可能な形式に変換する手段を有する方法。
請求項６記載の方法において、
前記新規ページ・コマンド処理手段が、後続のグラフィックス・コマンドによって生成されるページを定義するモジュールを有する方法。
請求項６記載の方法において、
前記描画コマンド処理手段が、ビットマップ記述子をグラフィックス命令に変換するモジュールを有する方法。
請求項３記載の方法において、
前記メモリの割り振りを管理するステップが、表示リスト命令及びその関連データとして表されるグラフィックス情報バンドを生成することと、出力すべきイメージ・データの全ページが前記出力装置に出力されるよう事前構成されたヒープを管理することを含んでいる方法。
請求項３記載の方法において、
処理済みのイメージ・データの前記出力装置による出力を待ったとしても前記メモリが十分にならない場合に圧縮を行う方法。