(57)【特許請求の範囲】
【請求項１】
レンダリングシステム上でページ記述をレンダリングする方法であって、前記ページ記述は１つまたは複数のオブジェクトを含み、
(a)前記オブジェクトを下から上へのｚ順に順次受信するステップと、
(b)１つまたは複数のレンダ命令セットを生成するステップとを含み、前記生成するステップは、受信された各オブジェクトについて、
(ba)前記受信した現在のオブジェクトに対応するレンダ命令を、既に受信したオブジェクトのレンダリング待ちとなっているレンダ命令を格納している現レンダ命令セットに追加する際に、前記レンダリングシステムのリソースを越えるかどうかを決定するサブステップと、
(bb)前記リソースを越える場合、
(bba)前記リソースに空きを発生させるため、前記現レンダ命令セットにあるレンダ命令を、レンダリングエンジンに供給し、背景イメージとして描画させるサブステップと、
(bbb）前記描画された前記背景イメージへの参照する命令を、新しいレンダ命令セットに追加するサブステップと、
(bbc)前記受信した前記現在のオブジェクトに対応するレンダ命令を、前記新しいレンダ命令セットに追加するサブステップ
を実行するサブステップと、
(bc)前記リソースを越えない場合、
(bca)前記受信された現在のオブジェクトに対応するレンダ命令を、前記現レンダ命令セットに追加するサブステップ
を実行するサブステップとを有し、
(c)前記１つまたは複数のレンダ命令セットを、前記レンダリングエンジンを用いて、画素データとしてレンダリングするステップ
を備えることを特徴とする方法。
【請求項２】
前記リソースを越える場合、前記現レンダ命令セットをキューイングし、前記現レンダ命令セットの前記レンダリングの前記画素データを、メモリにおいて前記背景イメージのために予約された空間に格納するように要求するサブステップをさらに実行することを特徴とする請求項１に記載の方法。
【請求項３】
前記リソースを越える場合、
前記現レンダ命令セットをキューイングし、前記現レンダ命令セットの前記レンダリングの前記画素データを、メモリにおいて前記背景イメージのために予約された空間に格納するように要求するサブステップと、
メモリにおける前記空間を、先に割り振られていなかった場合、前記背景イメージのために割り振るサブステップと
をさらに実行することを特徴とする請求項１に記載の方法。
【請求項４】
前記リソースを越えない場合、かつ、前記現在の受信されたオブジェクトが前記ｚ順における最後のオブジェクトであった場合、
前記現レンダ命令セットをキューイングするサブステップをさらに実行することを特徴とする請求項１に記載の方法。
【請求項５】
前記生成するステップは、
前記現在の受信されたオブジェクトを、対応するレンダ命令に変換するサブステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記レンダリングするステップは、
(ca)前記現レンダ命令セットの実行によって出力される画素データが、メモリにおいて前記背景イメージのために予約された空間に格納されるかどうかを判別するサブステップと、
(cb)前記現レンダ命令セットの前記画素データが、前記メモリにおいて前記背景イメージのために予約された前記空間に格納される場合、
(cba)前記現レンダ命令セットを前記背景イメージとしてレンダリングするサブステップと、
(cbb)前記背景イメージを、前記メモリにおいて予約された前記空間に格納するサブステップとを実行するサブステップと、
(cc)前記現レンダ命令セットの前記画素データが、前記メモリにおいて前記背景イメージのために予約された前記空間に格納されていない場合、
(cd)現レンダ命令セットを出力デバイスへレンダリングするサブステップを実行するサブステップと
を備えることを特徴とする請求項１に記載の方法。
【請求項７】
前記出力デバイスはプリンタであることを特徴とする請求項６に記載の方法。
【請求項８】
前記出力デバイスは表示画面であることを特徴とする請求項６に記載の方法。
【請求項９】
前記現レンダ命令セットの実行によって出力される前記画素データが、前記背景イメージのために予約された前記メモリの前記空間に格納される場合、
前記背景イメージを、前記メモリにおいて予約された前記空間に格納する前に圧縮するサブステップをさらに実行することを特徴とする請求項６に記載の方法。
【請求項１０】
前記１つまたは複数のオブジェクトのうち１つまたは複数が、複数のプリミティブ・オブジェクトのグループを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
ページ記述をレンダリングする方法であって、前記ページ記述は１つまたは複数のオブジェクトを含み、
(a)レンダリング命令生成部が、前記オブジェクトを下から上へのｚ順に順次受信するステップを含み、前記受信された各オブジェクトについて、
(aa)前記レンダリング命令生成部が、前記受信されたオブジェクトを、現在のレンダリストに追加する際に、リソースを越えるかどうかを検査し、越える場合、前記現在のレンダリストをレンダリングエンジンに供給してフレーム・ストア上にレンダリングし、次いで前記現在のレンダリストを空に設定し、前記レンダリングエンジンを用いてレンダリングして得られたイメージの参照をレンダリングリストに追加するサブステップと、
(ab)前記レンダリング命令生成部が、前記受信されたオブジェクトを、現在のレンダリストに追加する際に、リソースを越えるかどうかを検査し、越えない場合、前記受信されたオブジェクトを前記現在のレンダリストに追加し、前記受信されたオブジェクトが前記ｚ順における最後のオブジェクトであった場合、
(aba)前記フレーム・ストア上のレンダリング済みが存在する場合、前記現在のレンダリストを前記レンダリングエンジンに供給して前記フレーム・ストアと組み合わせてレンダリングして、レンダリングされたページを形成し、前記フレーム・ストア上にレンダリング済みがない場合、前記現在のレンダリストを前記レンダリングエンジンに供給してレンダリングして、前記レンダリングされたページを形成するサブステップと
を実行することを特徴とする方法。
【請求項１２】
前記１つまたは複数のオブジェクトのうち１つまたは複数が、複数のプリミティブ・オブジェクトのグループを含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記空の現在のレンダリストが基本レンダ命令を含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
ページ記述をレンダリングするためのシステムであって、前記ページ記述は１つまたは複数のオブジェクトを含み、
前記オブジェクトを下から上へのｚ順に順次受信する手段と、
１つまたは複数のレンダ命令セットを生成する生成手段とを備え、当該生成手段は、
(i)前記受信された各オブジェクトについて、前記受信された現在のオブジェクトの対応するレンダ命令を、既に受信したオブジェクトのレンダリング待ちになっているレンダ命令を格納している現レンダ命令セットに追加する際に、前記レンダリングするためのシステムのリソースを越えるかどうかを判別する手段と、
(ii)前記リソースを越える場合、前記リソースに空きを発生させるため、前記現レンダ命令セットにあるレンダ命令を、レンダリングエンジンに供給し、背景イメージとして描画させる手段と、
(iii)前記リソースを越える場合、前記描画された前記背景イメージへの参照する命令を、新しいレンダ命令セットに追加する手段と、
(iv)前記リソースを越える場合、前記受信した前記現在のオブジェクトに対応するレンダ命令を、前記新しいレンダ命令セットに追加する手段と、
(v)前記リソースを越えない場合、前記受信された現在のオブジェクトに対応するレンダ命令を、前記現レンダ命令セットに追加する手段と
(vi)前記１つまたは複数のレンダ命令セットを、前記レンダリングエンジンを用いて、画素データとしてレンダリングする手段と
を備えることを特徴とするシステム。
【請求項１５】
前記生成手段は、
前記リソースを越える場合、前記現レンダ命令セットをキューイングし、前記現レンダ命令セットの前記レンダリングの前記画素データを、メモリにおいて前記背景イメージのために予約された空間に格納するように要求する手段をさらに備えることを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記生成手段は、
前記リソースを越える場合、前記現レンダ命令セットをキューイングし、前記現レンダ命令セットの前記レンダリングの前記画素データを、メモリにおいて前記背景イメージのために予約された空間に格納するように要求する手段と、
メモリにおける前記空間を、前記リソースを越える場合、先に割り振られていなかった場合、前記背景イメージのために割り振る手段と
を更に備えることを特徴とする請求項１４に記載のシステム。
【請求項１７】
前記生成手段は、
前記リソースを越えない場合、かつ、前記現在の受信されたオブジェクトが前記ｚ順における最後のオブジェクトであった場合、前記現レンダ命令セットをキューイングする手段
を更に備えることを特徴とする請求項１４に記載のシステム。
【請求項１８】
前記生成手段は、
前記現在の受信されたオブジェクトを、対応するレンダ命令に変換する手段をさらに備えることを特徴とする請求項１４に記載のシステム。
【請求項１９】
前記レンダリングする手段は、
前記現レンダ命令セットの実行によって出力される画素データが、メモリにおいて前記背景イメージのために予約された空間に格納されるかどうかを判別する手段と、
前記現レンダ命令セットの実行によって出力される前記画素データが、前記メモリにおいて前記背景イメージのために予約された前記空間に格納される場合、前記現レンダ命令セットを前記背景イメージとしてレンダリングする手段と、
前記レンダリングされた背景イメージを、前記メモリにおいて予約された前記空間に格納する手段と、
前記現レンダ命令セットの実行によって出力される前記画素データが、前記メモリにおいて前記背景イメージのために予約された前記空間に格納されない場合、前記現レンダ命令セットを出力デバイスへレンダリングする手段と
を備えることを特徴とする請求項１４に記載のシステム。
【請求項２０】
前記出力デバイスはプリンタであることを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記出力デバイスは表示画面であることを特徴とする請求項１９に記載のシステム。
【請求項２２】
前記レンダリングする手段は、
前記現レンダ命令セットの前記画素データが、前記メモリにおいて前記背景イメージのために予約された前記空間に格納される場合、前記背景イメージを、前記メモリにおいて予約された前記空間に格納する前に圧縮する手段
をさらに備えることを特徴とする請求項１９に記載のシステム。
【請求項２３】
ページ記述をレンダリングするためのシステムであって、前記ページ記述は１つまたは複数のオブジェクトを含み、
前記オブジェクトを下から上へのｚ順に順次受信する手段と、
受信された各オブジェクトについて、前記受信されたオブジェクトを、現在のレンダリストに追加する際に、リソースを越えるかどうかを検査し、越える場合、前記現在のレンダリストをフレーム・ストア上にレンダリングし、次いで前記現在のレンダリストを空に設定し、レンダリングして得られたイメージの参照をレンダリストに追加する手段と、
前記受信されたオブジェクトを、現在のレンダリストに追加する際に、リソースを越えるかどうかを検査し、越えない場合、前記受信されたオブジェクトを前記現在のレンダリストに追加する手段と、
前記フレーム・ストア上のレンダリング済みが存在する場合、前記現在のレンダリストを前記フレーム・ストアと組み合わせてレンダリングして、レンダリングされたページを形成し、前記フレーム・ストア上にレンダリング済みがない場合、前記現在のレンダリストをレンダリングして、前記レンダリングされたページを形成する手段と
を備えることを特徴とするシステム。
【請求項２４】
前記１つまたは複数のオブジェクトのうち１つまたは複数が、複数のプリミティブ・オブジェクトのグループを含むことを特徴とする請求項２３に記載のシステム。
【請求項２５】
前記空の現在のレンダリストが基本レンダ命令を含むことを特徴とする請求項２３に記載のシステム。
【請求項２６】
ページ記述をレンダリングするためのコンピュータプログラムであって、前記ページ記述は１つまたは複数のオブジェクトを含み、
コンピュータに、
(i)前記オブジェクトを下から上へのｚ順に順次受信する手順と、
(ii)１つまたは複数のレンダ命令セットを生成する手順とを含み、前記生成する手順は、
(ii-i)前記受信した現在のオブジェクトに対応するレンダ命令を、既に受信したオブジェクトのレンダリング待ちとなっているレンダ命令を格納している現レンダ命令セットに追加する際に、前記レンダリングシステムのリソースを越えるかどうかを決定する手順と、
(ii-ii)前記リソースを越える場合、前記リソースに空きを発生させるため、前記現レンダ命令セットにあるレンダ命令を、レンダリングエンジンに供給し、背景イメージとして描画させる手順と、
(ii-iii)前記リソースを越える場合、前記描画された前記背景イメージへの参照する命令を、新しいレンダ命令セットに追加する手順と、
(ii-iv)前記リソースを越える場合、前記受信した現在のオブジェクトに対応するレンダ命令を、前記新しいレンダ命令セットに追加する手順と、
(ii-v)前記リソースを越えない場合、前記受信された現在のオブジェクトに対応するレンダ命令を、前記現レンダ命令セットに追加する手順とを含み、さらに、
(iii)前記１つまたは複数のレンダリング命令セットを前記レンダリングエンジンを用いて画素データとしてレンダリングする手順
を実行させることを特徴とするコンピュータプログラム。
【請求項２７】
ページ記述をレンダリングするためのコンピュータプログラムであって、前記ページ記述は１つまたは複数のオブジェクトを含み、
コンピュータに、
前記オブジェクトを下から上へのｚ順に順次受信する手順と、
受信された各オブジェクトについて、前記受信されたオブジェクトを、現在のレンダリストに追加する際に、リソースを越えるかどうかを検査し、越える場合、前記現在のレンダリストをフレーム・ストア上にレンダリングし、次いで前記現在のレンダリストを空に設定し、レンダリングして得られたイメージの参照をレンダリングリストに追加する手順と、
前記受信された各オブジェクトについて、前記受信されたオブジェクトを、現在のレンダリストに追加する際に、リソースを越えるかどうかを検査し、越えない場合、受信されたオブジェクトを前記現在のレンダリストに追加する手順と、
前記受信されたオブジェクトが前記ｚ順における最後のオブジェクトであり、前記フレーム・ストア上にレンダリング済みが存在する場合、前記現在のレンダリストを前記フレーム・ストアと組み合わせてレンダリングして、レンダリングされたページを形成する手順と、
前記受信されたオブジェクトが前記ｚ順における前記最後のオブジェクトであり、前記フレーム・ストア上にレンダリング済みが無かった場合、前記現在のレンダリストをレンダリングして、前記レンダリングされたページを形成する手順
を実行させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ページ記述をレンダリングするための方法およびシステムに関する。本発明はまた、ページ記述をレンダリングするためのコンピュータ・プログラムにも関する。
【０００２】
【従来の技術】
比較的近年、印刷ページをプリンタ、表示画面および／または他のロケーション（たとえば、ファイル）にレンダリングするためのグラフィックス・パッケージが存在している。これらのいくつかのグラフィックス・パッケージは、典型的には、高レベルのページ記述言語を、印刷ページのレイアウトにおいて支援するために利用するものである。これらのグラフィックス・パッケージは典型的にはレンダリング・システムを含み、これがページ・レイアウトの高レベルのページ記述を、印刷及び／又は表示されるラスタ・データとして使用することができる画素データに変換する。
【０００３】
１つのこのようなレンダリング・システムは、ページまたは画面の画素に基づいたイメージを保持するためのフルページ・フレーム・ストアを含む。フルページ・フレーム・ストアはバッファであり、ページ全体についてプリンタに送信する必要のあるあらゆる画素のための空間を有する。これらのシステムでは、高レベルのページ記述において受信されるあらゆるオブジェクトを、直ちにレンダリングすることができる。このシステムの主要な問題は、フレーム・ストアのために必要となるメモリが非常に大きいことであり、特に、各画素を連続色調にする必要があり、これが関連付けられた透過値を有する可能性があるときにそうである。
【０００４】
【発明が解決しようとする課題】
オブジェクトをｚ順序で順次に適用するというより、むしろレンダリストに適用されたときに、速度においてもメモリ使用においてもより効率的に実行する既存のレンダリング・システムがる。このようなシステムは、レンダリストに必要とされる記憶装置が使用可能なリソース以内であるときに大変有利であるが、さらにリソースが必要となる場合、中断してしまう。たとえば、オブジェクト・レンダリストのサイズに制限がないのに対して、フレーム・ストアのサイズは大きいが制限されており、厳密に印刷ページの解像度およびサイズによって決まる。このようなシステムを使用するとき、これらは、使用可能なリソースを越えるレンダリストと共に提示されたときに障害を起こすか、あるいは、フレーム・ストアを使用したオブジェクト順次即時レンダリング方法へと劣化する。
【０００５】
本発明の一目的は、既存の構成の１つまたは複数の欠点を実質的に克服、あるいは少なくとも改良することである。
【０００６】
【課題を解決するための手段】
本発明の第１の態様によれば、レンダリングシステム上でページ記述をレンダリングする方法を提供する。ここで、ページ記述は１つまたは複数のオブジェクトを含むものであり、この方法は、オブジェクトを下から上へのｚ順に順次受信するステップと、１つまたは複数のレンダ命令セットを生成するステップとを含み、この生成するステップは、受信された各オブジェクトについて、現在の受信されたオブジェクトが対応するレンダ命令を現レンダ命令セットに追加することにより、レンダリング・システムのリソースを越えるかどうかを決定するサブステップと、リソースを越える場合、新しいレンダ命令セットを作成するサブステップと、レンダ命令を新しいレンダ命令セットに追加して現レンダ命令セットを背景イメージとして描画するサブステップと、新しいレンダ命令セットに、現在の受信されたオブジェクトが対応するレンダ命令を追加するサブステップとを実行するサブステップと、リソースを越えない場合、現在の受信されたオブジェクトが対応するレンダ命令を現レンダ命令セットに追加するサブステップを実行するサブステップとを実行し、さらに、１つまたは複数のレンダ命令セットを画素データとしてレンダリングするステップを含む。
【０００７】
本発明の第２の態様によれば、ページ記述をレンダリングする方法を提供する。ここで、ページ記述は１つまたは複数のオブジェクトを含むものであり、この方法は、オブジェクトを下から上へのｚ順に順次受信するステップを含み、この方法は、受信された各オブジェクトについて、受信されたオブジェクトが現在のレンダリストに追加された場合にリソースを越えるかどうかを検査し、そうであった場合、現在のレンダリストをフレーム・ストア上にレンダリングし、次いで現在のレンダリストを空に設定するサブステップと、受信されたオブジェクトを現在のレンダリストに追加し、受信されたオブジェクトがｚ順における最後のオブジェクトであった場合、フレーム・ストア上にレンダリングされた場合、現在のレンダリストをフレーム・ストアと組み合わせてレンダリングして、レンダリングされたページ記述を形成し、そうでない場合、現在のレンダリストをレンダリングして、レンダリングされたページ記述を形成するサブステップとを実行する。
【０００８】
本発明の第３の態様によれば、ページ記述をレンダリングするためのシステムを提供する。ここで、ページ記述は１つまたは複数のオブジェクトを含むものであり、このシステムは、オブジェクトを下から上へのｚ順に順次に受信する手段と、１つまたは複数のレンダ命令セットを生成する手段とを含み、この生成する手段は、受信された各オブジェクトについて、現在の受信されたオブジェクトが対応するレンダ命令を、現レンダ命令セットに追加することにより、レンダリングするためのシステムのリソースを越えるかどうかを決定する手段と、リソースを越える場合、新しいレンダ命令セットを作成する手段と、リソースを越える場合、レンダ命令を新しいレンダ命令セットに追加して現レンダ命令セットを背景イメージとして描画する手段と、リソースを越える場合、新しいレンダ命令セットに、現在の受信されたオブジェクトが対応するレンダ命令を追加する手段と、リソースを越えない場合、現在の受信されたオブジェクトの対応するレンダ命令を現レンダ命令セットに追加する手段と、１つまたは複数のレンダ命令セットを画素データとしてレンダリングする手段とを含む。
【０００９】
本発明の第４の態様によれば、ページ記述をレンダリングするためのシステムを提供する。ここで、ページ記述は１つまたは複数のオブジェクトを含むものであり、このシステムは、オブジェクトを下から上へのｚ順に順次受信する手段と、受信された各オブジェクトについて、受信されたオブジェクトが現在のレンダリストに追加された場合にリソースを越えるかどうかを検査し、そうであった場合、現在のレンダリストをフレーム・ストア上にレンダリングし、次いで現在のレンダリストを空に設定する手段と、受信されたオブジェクトを現在のレンダリストに追加する手段と、受信されたオブジェクトがｚ順における最後のオブジェクトであり、フレーム・ストア上にレンダリングされた場合、現在のレンダリストをフレーム・ストアと組み合わせてレンダリングして、レンダリングされたページ記述を形成する手段と、受信されたオブジェクトがｚ順における最後のオブジェクトであり、フレーム・ストア上にレンダリングされなかった場合、現在のレンダリストをレンダリングして、レンダリングされたページ記述を形成する手段とを含む。
【００１０】
本発明の第５の態様によれば、ページ記述をレンダリングするためのコンピュータ・プログラムを提供する。ここでページ記述は１つまたは複数のオブジェクトを含むものである。そして、このコンピュータ・プログラムは、コンピュータに、オブジェクトを下から上へのｚ順に順次に受信する手順と、１つまたは複数のレンダ命令セットを生成する手順とを含み、この生成するための手順は、受信された各オブジェクトについて、現在の受信されたオブジェクトが対応するレンダ命令を現レンダ命令セットに追加することにより、レンダリング・システムのリソースを越えるかどうかを決定する手順と、リソースを越える場合、新しいレンダ命令セットを作成する手順と、リソースを越える場合、レンダ命令を新しいレンダ命令セットに追加して現レンダ命令セットを背景イメージとして描画する手順と、リソースを越える場合、新しいレンダ命令セットに、現在の受信されたオブジェクトが対応するレンダ命令を追加する手順と、リソースを越えない場合、現在の受信されたオブジェクトの対応するレンダ命令を現レンダ命令セットに追加する手順とを含み、さらに、１つまたは複数のレンダリング命令セットを画素データとしてレンダリングする手順を実行させる。
【００１１】
本発明の第６の態様によれば、ページ記述をレンダリングするためのコンピュータ・プログラムを提供する。ここでページ記述は１つまたは複数のオブジェクトを含むものである。そして、このコンピュータ・プログラムは、コンピュータに、オブジェクトを下から上へのｚ順に順次受信する手順と、受信された各オブジェクトについて、受信されたオブジェクトが現在のレンダリストに追加された場合にリソースを越えるかどうかを検査し、そうであった場合、現在のレンダリストをフレーム・ストア上にレンダリングし、次いで現在のレンダリストを空に設定する手順と、受信されたオブジェクトを現在のレンダリストに追加する手順と、受信されたオブジェクトがｚ順における最後のオブジェクトであり、フレーム・ストア上にレンダリングされた場合、現在のレンダリストをフレーム・ストアと組み合わせてレンダリングして、レンダリングされたページ記述を形成する手順と、受信されたオブジェクトがｚ順における最後のオブジェクトであり、フレーム・ストア上にレンダリングされなかった場合、現在のレンダリストをレンダリングして、レンダリングされたページ記述を形成する手順を実行させる。
【００１２】
【発明の実施の形態】
本発明のいくつかの好ましい実施形態を、以下、図面を参照して記載する。
【００１３】
１つまたは複数の添付の図面のいずれにおいても、同じ参照番号を有するステップおよび／または機能を参照する場合、これらのステップおよび／または機能は、反対の意図が現れない限り、この説明のために同じ機能または動作を有する。
【００１４】
図１は、印刷されるラスタ・データとして使用される高レベルのページ記述を、画素にレンダリングかつ提示するために構成されるコンピュータ・システム１００を示している。コンピュータ・システム１００は、ホスト・プロセッサ１０２を含み、これはシステム・ランダム・アクセス・メモリ（ＲＡＭ）１０３、フォント・メモリ１０４、レンダ・エンジン１０５、出力デバイス１０６およびプリンタ・エンジン１０７に関連付けられる。コンピュータ・システム１００は、レンダリング命令生成部ソフトウェア・モジュール１０９、レンダリング命令ローダ・ソフトウェア・モジュール１１０、およびホスト・プロセッサ１０２上で動作するためのコンプレッサ・ソフトウェア・モジュール１１１も含む。レンダリング命令生成部ソフトウェア・モジュール１０９、レンダリング命令ローダ・ソフトウェア・モジュール１１０、およびコンプレッサ・ソフトウェア・モジュール１１１は、別法としてハードウェアにおいて実施することができ、バス・システム１０８に結合するか、あるいは、ローカル・バス（図示せず）と相互結合することができる。加えて、レンダ・エンジン１０５は、別法として、ホスト・プロセッサ１０２上で動作するためのソフトウェア・モジュールとして実施することができる。ＲＡＭメモリ１０３は、レンダリング命令生成部ソフトウェア・モジュール１０９によって生成された、１つまたは複数のレンダ命令セットの命令待ち行列１１２を格納するように適合される。フォント・メモリ１０４は、その中に１つまたは複数のフォントのフォント文字を格納しており、これらがレンダリング・エンジン１０５によって使用される。レンダ命令生成部１０９は、１つまたは複数のレンダリング命令セットを、高レベルのページ記述に応答して生成し、これらをＲＡＭメモリ１０３における命令待ち行列１１２上にキューイングする。レンダリング命令ローダ・ソフトウェア・モジュール１１０は、これらの命令セットを一度に一セット、命令待ち行列１１２から取り、これをレンダリング・エンジン１０５にロードし、これが、これらの命令を画素として出力デバイス１０６およびプリンタ・エンジン１０７へ出力する。レンダ・エンジン１０５は時として、命令セットを出力デバイス１０６へレンダリングする代りに、命令セットをイメージとしてコンプレッサ・ソフトウェア・モジュール１１１へレンダリングする。コンプレッサ・ソフトウェア・モジュール１１１はこのイメージを圧縮し、これをメモリ１０３における命令待ち行列１１２へ戻すように供給し、これが後にレンダ・エンジン１０５によって使用される。
【００１５】
上述のコンピュータ・システム１００のハードウェア構成要素は、バス・システム１０８を介して相互接続され、ＩＢＭ  ＰＣ／ＡＴタイプのパーソナル・コンピュータおよびそれから発展させられた構成、Ｓｕｎ  Ｓｐａｒｃｓｔａｔｉｏｎｓなど、当技術分野でよく知られているコンピュータ・システムの通常の動作モードにおいて動作可能である。コンピュータ・システム１００の構成要素は、分離したコンピューティング環境においても存在できる。これらのソフトウェア・モジュールは、フロッピー・ディスク、光ディスク、メモリ・カードまたは他の適切な媒体など、コンピュータ可読媒体上に格納できることが好ましい。
【００１６】
代替実施形態では、レンダ・エンジン１０５が生成した画素データを任意選択的に、直接、命令待ち行列１１２へ送信して圧縮しないようにすることができる。もう１つの実施形態では、画素データを、後にレンダ・エンジン１０５によって使用するために、レンダ・エンジン１０５自体内で保つことができる。命令待ち行列またはレンダ命令ローダがない、他の実施形態が可能である。これらの場合、レンダ命令生成部１０９が同期的に命令をレンダ・エンジン１０５にロードする。さらにもう１つの実施形態では、レンダ命令生成部１０９が、分離したコンピュータに位置し、ネットワークまたはある他の種類のデータ・リンクを介して、命令待ち行列１１２および／またはレンダ・エンジン１０５を含むコンピュータに結合されることが可能である。加えて、コンピュータ・システム１００は、ページ記述のためのフロー制御を利用することが好ましい。つまり、レンダ・リスト生成部１０９がページ記述データを受信できない場合、レンダ・リスト生成部１０９がそれを受信する準備ができるまで、ページ記述データが汚染されないように、データの損失がないようにされる。
【００１７】
高レベルのページ記述は、ＰＯＳＴＳＣＲＩＰＴ言語など、印刷ページのレイアウトをｚ順序で配列されたオブジェクトの形式で記述するための、いかなる知られている高レベルのページ記述言語にすることもできる。
【００１８】
このとき、図１Ｂを参照して、図１Ａのコンピュータ・システムの機能的データ・フローを示すブロック図を示す。ホスト・プロセッサ１０２が高レベルのページ記述１２０を受信する。このような高レベルのページ記述１２０は、ホスト・プロセッサ１０２上で動作するグラフィックス・パッケージによって、あるいは、ネットワークを介してこれに接続された、ある他のホスト・プロセッサ上のグラフィックス・アプリケーションから供給することができる。次いで、レンダ命令生成部１０９が１つまたは複数のレンダリング命令セット（１２２、１２４、１２６）を、高レベルのページ記述１２０に応答して生成し、これについては以下でより詳細に記載する。これらの１つまたは複数のレンダリング命令セット（１２２、１２４、１２６）が、メモリ１０３における命令待ち行列１１２上にキューイングされる。次いで、レンダ命令ローダ１１０が、これらの１つまたは複数のレンダリング命令セット（１２２、１２４、１２６）を一度に一セット、命令待ち行列１１２からロードし、これについては以下でより詳細に記載する。次いで、レンダ・エンジン１０５が１つまたは複数のレンダリング命令セットをレンダリングし、これについては以下でより詳細に記載する。レンダリング・エンジン１０５が出力画素（イメージ）を出力デバイス１０６およびプリンタ・エンジン１０７へ供給する。レンダリング・エンジン１０５は、ある条件において、出力画素（イメージ）を出力デバイス１０６へ供給する代りに、これらをコンプレッサ１１１へ供給する。コンプレッサ１１１はこのイメージ１２８を圧縮し、これが命令待ち行列１１２へ戻すように供給され、後にレンダ・エンジン１０５によって使用される。コンピュータ・システム１００はパイプライン方式で動作し、レンダ命令生成部１１０およびレンダリング命令ローダは、同時かつ非同期的な方法で動作することができる。
【００１９】
図１Ｃを参照すると、同図は図１Ａのコンピュータ・システムの動作を例示するための、例示的ページ記述のオブジェクトおよび対応する変換されたオブジェクトを示している。レンダ命令生成部１０９が、ページ記述のオブジェクト（０、１、２、３、４、５、６および７）を一度に１つ、最低オブジェクト（０）から開始してｚ順序の増分において（すなわち、下から上へ）受信する。レンダ命令生成部１０９は最初に、ページ記述のための最初のレンダリング命令セットを生成する。この最初の命令セットは、典型的には、ページのレンダリングに必要ないかなる基本命令をも含む。次いで、レンダ命令生成部１０９が、基本命令および最下位オブジェクト（０）に対応するレンダリング命令を含む命令セットがコンピュータ・システム１００のリソース制限を越えさせるかどうかを決定する。この例では、レンダ命令生成部１０９が、この命令セットではリソース制限を越えないと決定する。次いで、レンダ命令生成部１０９が、基本レンダリング命令、次の最低オブジェクト（１）に対応するレンダリング命令、および、最低オブジェクト（０）に対応するレンダリング命令を含む命令セットがコンピュータ・システム１００のリソース制限を越えさせるかどうかを決定する。この例では、レンダ命令生成部１０９が、この命令セットではリソース制限を越えないと決定する。レンダ命令生成部１０９は、リソース制限がこのセットによって越えられると決定するまで、命令をそのセットに追加し続ける。この例では、レンダ命令生成部１０９が、この組の命令が基本レンダリング命令およびオブジェクト（０、１、２、３、４、５および６）のためのレンダリング命令を含むとき、リソース制限を最初に越えると決定する。次いで、レンダリング命令生成部１０９が、基本レンダリング命令およびオブジェクト（０、１、２、３、４および５）のためのレンダリング命令を含む命令セットをレンダ・エンジン１０５へ、好ましくは命令待ち行列１１２およびレンダリング命令ローダ１１０を介して供給する。
【００２０】
次いで、レンダ命令生成部１０９が新しい初期の基本命令セットを作成し、最初にレンダリング命令を追加して、背景イメージを、オブジェクト（０、１、２、３、４および５）に対応するページ上に描画し、これを図１Ｃでオブジェクト０’として示す。これらのレンダリング命令は背景イメージ自体を含まないが、背景イメージへの参照を含み、これが続いてレンダ・エンジンによって生成される。次いで、レンダリング命令生成部１０９が進行して、上に記載したものと同じ方法で、オブジェクト６に対応するレンダリング命令を新規に作成されたセットに追加することによりリソース制限を越えさせるかどうかを決定する。この例では、レンダリング命令生成部１０９が、オブジェクト６および７のためのレンダリング命令を新規に作成されたセットに追加することによりリソース制限を越えさせないと決定する。
【００２１】
レンダ・エンジン１０５が、ある後の時間に、画素データを背景イメージの形式で、最初のレンダリング命令セット（すなわち、オブジェクト０、１、２、３、４および５に対応する）に応答して生成する。次いで、レンダ・エンジン１０５が画素データを、第２のレンダリング命令セット（すなわち、オブジェクト０’、６および７に対応する）に応答して、かつ、背景イメージすなわちオブジェクト０’のための第１のレンダリング命令セットに応答してレンダ・エンジン１０５によって生成された画素データを使用して、生成する。
【００２２】
このように、好ましい実施形態が、ページをレイヤ形式に生成する命令を作成することができる。最初にページ記述に到着したオブジェクトは、よってｚ順序において最低であり、これが命令に変換され、次いで、レイヤとして画素にレンダリングされる。これらの画素が、次のレイヤの背景イメージとして使用される。複雑なページ、または大規模オブジェクトを含むページを、幾つかのレイヤのフレーム・ストア上においてレンダリングすることができる。ページのいくつかの低い順序のオブジェクトで、著しいリソースを利用するものを、イメージとしてレンダリングすることができ、これは、ページのさらに高い順序のオブジェクトのための背景イメージとして使用することができる。これには、背景イメージ・オブジェクトが、その対応する数のオブジェクトよりも少ないリソースを利用することができる利点がある。多数のオブジェクトを含むページは、通常、システムのリソース制限を越えるものであり、これをレイヤに変換することができ、したがってリソース制限を越えないようにすることができる。
【００２３】
図２Ａは、好ましい実施形態による多数のページのキューイングの一例を例示するブロック図である。好ましい実施形態では、キューイングおよび待ち行列空間リソースの共有の機構により、多数のページを別々に準備かつレンダリングすることができる。好ましい実施形態では、命令待ち行列１１２が、固定あるいは制限された量のメモリにおいて機能する。好ましい実施形態では、ページ全体またはレイヤを、ページ内でｚ順序において表すレンダ命令セットが、命令待ち行列１１２においてキューイングされる。別法として、連続的に命令を流すことが可能であり、レンダ命令ローダ１１０はページまたはレイヤの間で区切りを決定し、ページまたはレイヤ全体がロードされたとき、レンダ・エンジンを開始する。
【００２４】
１つのレンダ命令セットが完全に準備され、次いでキューイングされることが好ましい。図２Ａは、命令待ち行列１１２の外観の一例であり、あらゆるページをレンダおよびシステム・リソースの制限内でレンダリングできるときの図である。この例では、各レンダ命令セットがページ全体を表す。これらが、ページ記述から受信される順序でキューイングされ、ページ１が最初、ページ２が２番目、ページ３が３番目などとなる。
【００２５】
図２Ｂは、好ましい実施形態による、多数のページのキューイングのもう１つの例を例示するブロック図である。図２Ｂは、命令待ち行列１１２の外観の一例であり、ページの１つが階層化を必要とするときの例を示している。多数のオブジェクトを含むページ１が、システムまたはレンダ・エンジンのリソース制限を越える。したがって、ページ１がページ１ａ、ページ１ｂおよびページ１ｃのレイヤに分割される。ページ１ａは、ページのもっとも不明瞭な（最下位の）レイヤである。これは、その背景が用紙なので、背景イメージを必要としない。ページ１ａ命令のレンダリングされた出力が、メモリ１０３においてページ１ｂのための背景イメージとして予約された空間１１３へ行く。メモリ１０３における予約された空間１１３は、ページ１ｂのための背景イメージのためのフレーム・ストアとして動作する。次いで、ページ１がもう１つのレイヤを必要とする場合、メモリ１０３において背景イメージのために予約された同じ空間１１３を、次のレイヤであるページ１ｃのための背景イメージのためのフレーム・ストアとして使用することができる。明瞭にするため、メモリ１０３においてページ１ｂおよび１ｃのための背景イメージのために予約された空間１１３を、別々に示す。ページ１ｂ命令のレンダリングされた出力が、ページ１ｂの背景イメージのために予約された空間１１３へ行く。これは、ページ１ｂのレンダリングされた出力がこれまで最初から描画されたページ全体の図であるので、適切に作用する。ページ１ａ命令によって生成された背景イメージは、この図の一部である。そのため、ページ１ａによって生成された背景イメージを保つ必要はない。ページ１ｃが、ページ１ｂによって生成された背景イメージを使用し、ページの最終的な図を生成し、これがプリンタに向けて送られる。ページ２は待ち行列上にあり、階層化の必要はない。
【００２６】
図２Ｃは、時間におけるさらなる段階の、図２Ｂにおけるページのキューイングを例示するブロック図である。特に、命令待ち行列１１２の外観の一例であり、２つのページで階層化が必要であり、両方のページが同時に待ち行列にあるときの図である。図２Ｃは、図２Ｂから時間的に連続したものであり、ページ１ａおよび１ｂがデキューされている。ページ１ｃは、メモリ１０３における空間がページ３ｂのための背景イメージのために予約されようとするときに、なお待ち行列上にある。メモリ１０３における同じ空間１１３が、ページ１ｃのための背景イメージのために予約されるように、ページ３ｂのための背景イメージのために予約される。明瞭にするため、メモリ１０３においてページ１ｃおよび３ｂのための背景イメージのために予約された空間１１３を、別々に示す。ページ３ａの出力がこの予約された空間に向けて送られ、ページ３ｂのための背景イメージがこの空間から読み取られる。
【００２７】
メモリ１０３において背景イメージのために予約された空間は、ページが異なるとサイズが変わる。たとえば、あるレイヤが白黒のオブジェクトのみを含む場合、このレイヤを表す圧縮された画素データが、圧縮されたフル・カラーのレイヤよりも少ない空間を取る。そのため、背景イメージのために予約された空間は、白黒またはモノトーンのレイヤではより小さい。これにより、背景イメージのための空間を共有することが少々困難になる。より早く生成されたレイヤがなお待ち行列にあるが、先に背景イメージのために予約された空間が不十分である場合、このレイヤのために必要とされる追加の量の空間が予約され、背景イメージのために保たれた空間上に追加される。予約されたメモリの元の部分もなお使用される。
【００２８】
好ましい実施形態における命令待ち行列の実施は、動的メモリ・アロケータを使用し、これが、背景イメージによって使用するために予約されたメモリ上で動作する。この動的メモリ・アロケータはスレッドセーフであり、レンダ命令生成部がメモリをその中に割り振ることができ、非同期的に動作するレンダ命令ローダがメモリを解放することができる。
【００２９】
好ましい実施形態では、メモリ１０３において背景イメージのために予約された空間が、それを必要とするすべてのレイヤの間で共有される。これは、レンダ命令ローダ１１０が各レイヤを、レンダ・エンジン１０５にロードするときに待ち行列から除去するので、可能である。レンダ命令ローダは、重複などのために適切でないページをデキューすることができる。後者の場合、十分なメモリを使用可能にしなければならず、適切でないもののデキューイングを、リソース計算において調節しなければならない。
【００３０】
しかし、いくつかの他の実施形態では、命令を待ち行列上で保つ必要がある可能性がある。たとえば、ページがエラーなく印刷されたことがわかるまで、命令を保つことができる。印刷または用紙のエラーがあった場合、命令をレンダ・エンジンに再ロードすることができ、ページを再度印刷することができる。完全な命令セットを保って各ページをレンダリングする１つの方法は、最後のレイヤ以外のすべてのレイヤを廃棄し、最後のレイヤに関連付けられた背景イメージを保つことである。このタイプのシステムでは、背景イメージのために予約された空間をページ内で共有することができるが、各ページのための背景イメージが、それ自体の別々の予約された空間を必要とし、これは、有効なデータが多数の背景イメージにおいて同時にある可能性があるためである。もう１つの可能な方法は、最後のレイヤをページのための背景イメージとしてレンダリングし、単にこのページのための背景イメージを保つことである。一般に、これにより空間が節約されるが、コンプレッサがプリンタと同期的に動作してプリンタと同じ速度でデータを受け入れることができない限り、時間が浪費される。次いで、用紙エラー回復のために使用されるイメージを、システム速度の損失なく生成することができる。背景イメージをなお、階層化ページごとに保つ必要がある。代替機構は、ページのすべてのレイヤのためのすべてのレンダ命令データを保つことである。次いで、背景イメージをすべてのページの間で共有することができる。しかし、レイヤを引き起こした制限が、レンダ命令待ち行列のために使用可能なメモリのサイズであった場合、そのレイヤを解放して他のジョブを印刷できるようにしなければならない。すべての上記の手法の混成が可能である。すなわち、用紙エラー回復のために保存されたメモリを最小にするが、スループット速度を最大にする混成機構である。
【００３１】
図３Ａおよび３Ｂは、図１Ａのレンダ命令生成部によって使用される、１つまたは複数のレンダリング命令セットを生成するための手順のフローチャートを示している。３００でレンダ命令生成部１０９が開始され、３０１で各単一の印刷ページについて初期化される。最初に、ステップ３０１で、新しい現レンダ命令セットを作成し、これが、常にあらゆるページで必要とされる基本レンダ命令を含む。レンダ命令生成部１０９がオブジェクトを１つずつページ記述から受信し、処理する。次に、ステップ３０２で、現レンダ命令セットによって利用された、すべてのレンダおよびシステム・リソースの現在の使用率を得る。次いで、レンダ命令生成部１０９がステップ３０３へ進行し、ページ記述における次のオブジェクトについての十分な情報を検索して、オブジェクトの複雑さおよびサイズを決定する。これが決定される方法については、更に、図４Ａ及び４Ｂを参照して後述する。
【００３２】
次いで、レンダ命令生成部１０９が判断ブロック３０４へ進行し、オブジェクトのレンダ命令を現レンダ命令セットに追加することにより、結果として生じる命令セットにリソース制限を越えさせるかどうかを照会する。特に、この結果として生じる命令セットがレンダ・エンジンの複雑さの制限またはメモリ容量のオーバーフローを引き起こすかどうか、あるいは、結果として生じる命令セットにレンダ命令待ち行列において過度なメモリを使用させるかどうかを検査する。
【００３３】
判断ブロック３０４がＦＡＬＳＥ（ＮＯ）を返し、すなわち制限を越えない場合、レンダ命令生成部がステップ３１２へ進行し、残りのオブジェクト・データが、必要な場合は受信される。次いで、レンダ命令生成部がステップ３１３へ進行し、これについては以下でより詳細に記載する。
【００３４】
他方では、判断ブロック３４０がＴＲＵＥ（ＹＥＳ）であり、すなわち制限を越える場合、レンダ命令生成部１０９がステップ３０５へ進行する。ステップ３０５で、現命令セット（結果として生じる命令セットではない）がレンダ命令ローダ１１０へ、命令待ち行列１１２を介して、ページレイヤとしてキューイングされる。加えて、命令が現命令セットに追加され、結果として生じるレンダリングされたページを、メモリにおいて次の命令セット（まだキューイングされていない）における背景画像のために予約される空間に置くことを要求する。ページのこの現レイヤをレンダリングすることによって生成された出力画素データが、ステップ３０８またはステップ３０９で後続のレイヤにおいて予約される空間に向けて送られる。出力画素データを圧縮あるいは劣化させて、使用可能な空間に適合させることができる。予約された空間のサイズは、背景イメージ画素データのために必要とされる圧縮率によって決定される。
【００３５】
ステップ３０５の後、レンダ命令生成部１０９がステップ３０６へ進行し、新しい現レンダ命令セットが作成される。この新しい現レンダ命令セットは、最初に基本レンダ命令を含み、これが常にあらゆるページで必要とされる。
【００３６】
ステップ３０６の後、レンダ命令生成部１０９が判断ブロック３０７へ進行し、すでに待ち行列のどこかで背景イメージのために予約された空間があるかどうかの検査が行われる。判断ブロック３０７がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令生成部１０９が、予約された空間に関連付けられた参照カウントを増分する（ステップ３０８）。判断ブロック３０７およびステップ３０８が非可分的に行われて、レンダ命令ローダ１１０が、予約された空間を、レンダ命令生成部がそれを参照しようとしている間に、デキューすることを防止する。判断ブロック３０７がＦＡＬＳＥ（ＮＯ）を返し、つまり待ち行列において背景イメージのための空間がまだ存在していない場合、レンダ命令生成部１０９がメモリにおいて空間を予約し、予約された空間に関連付けられた参照カウントを１に設定する（ステップ３０９）。
【００３７】
次いで、レンダ命令生成部１０９がステップ３１０へ進行する。ステップ３１０で、レンダ命令生成部１０９が、イメージをページ全体（背景イメージ）のサイズに描画するための命令を現在のレンダ命令に追加し、これは先にステップ３０６中に作成されたものである。次いで、結果として生じる現命令セットが、ページをレンダリングするための基本命令、および背景イメージを描画するための命令となる。背景イメージが、この命令セットがレンダ・エンジン１０７にロードされる準備ができるときまでに、予約された空間に位置付けられる。
【００３８】
ステップ３１０の後、レンダ命令生成部１０９がステップ３１２へ進行する。判断ブロック３０４がＦＡＬＳＥ（ＮＯ）を返した場合も、レンダ命令生成部１０９がステップ３１２へ進行する。ステップ３１２で、レンダ命令生成部１０９が残りの入力オブジェクトを、必要な場合は受信する。これについては、以下で図５Ａ，５Ｂを参照してより詳細に説明する。ステップ３１２の後、次いで、レンダ命令生成部１０９がオブジェクトをレンダ命令に変換し、これがページ記述の中間データ形式であり（ステップ３１３）、次いで、これらの変換されたレンダ命令を現レンダ命令セットに追加する（ステップ３１４）。リソース制限を越えた場合（３０４）、新しい現命令セットが作成されている。この場合、現セット（ステップ３１４）が新たな新しい命令セットとなる。他方では、リソース制限を越えていなかった場合（３０４）、現在のセット（ステップ３１４）が既存の命令セットである。
【００３９】
ステップ３１４の後、レンダ命令生成部１０９が判断ブロック３１５へ進行する。判断ブロック３１５で、現在のオブジェクトがページ上の最後のオブジェクトであるかどうかの検査が行われる。判断ブロック３１５がＴＲＵＥ（ＹＥＳ）を返した場合、現レンダ命令セットが、命令待ち行列１１２上で、レンダ命令ローダ１１０による後続のローディングのためにキューイングされる（ステップ３１６）。そうでない場合、判断ブロック３１５がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令生成部１０９がステップ３０２へ戻り、次のオブジェクトを受信し、処理が次のオブジェクトについて再度開始する。
【００４０】
好ましい実施形態では、システムに渡されたオブジェクトがテキスト文字または形状またはイメージである可能性がある。文字および経路を、一様な色、混合色、イメージ色データ（場合によってはタイル化）、またはパターン色データ（これも場合によってはタイル化）で満たすことができる。オブジェクトを使用してクリップ領域を定義することもできる。レンダ・エンジン１０５が、あらゆるオブジェクトについて、エッジによって境界を画することを必要とする。したがって、レンダ命令生成部１０９がすべての入力オブジェクトのためのエッジを、入力オブジェクトに明示的なアウトラインが定義されていなかった場合であっても、作成する。オブジェクトによって満たされた領域は、常にページ記述によって、明示的あるいは暗示的に定義される。レンダ命令生成部１０９がこの定義を使用してエッジを生成する。そのため、あらゆるオブジェクトがエッジを生成するので、あらゆるオブジェクトをクリップとして使用することができる。レンダ・エンジンはクリップをサポートする。大抵のクリップがただ１つのレベルを使用し、色スロットを使用しない。
【００４１】
このとき、図４Ａおよび図４Ｂを参照して、図３Ａに示すような、オブジェクトのサイズおよび複雑さを決定するためのステップ３０３のサブステップの流れ図を示す。この処理中に、レンダ命令生成部１０９がオブジェクトのためのデータの部分を受信し、この部分は、オブジェクトのサイズおよび複雑さを決定するために十分である。ステップ３０２の後、処理が判断ブロック４２０へ進行し、現在のオブジェクトが文字であるかどうかの検査が行われる。これが文字であった場合、判断ブロック４２０がＴＲＵＥ（ＹＥＳ）を返し、レンダ命令生成部が判断ブロック４２１へ進行する。判断ブロック４２１で、文字がすでにシステムにおいてフォント・メモリ１０４に格納されているかどうかの検査が行われる。判断ブロック４２１がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令生成部１０９がステップ４２２へ進行し、事前に計算された文字のサイズおよび複雑さが得られる。これが、判断ブロック３０４における後続の使用のために返される。次いで、レンダ命令生成部１０９がステップ４２９へ進行する。
【００４２】
判断ブロック４２１がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令生成部１０９が判断ブロック４２３へ進行し、文字がビット・マップであるかどうかの検査が行われる。判断ブロック４２３がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令生成部１０９がステップ４２４へ進行し、ビット・マップのサイズ（幅および高さ）が読み取られるが、ビット・マップ・データ自体は読み取られない。ステップ４２４の後、レンダ命令生成部１０９がステップ４２５へ進行し、レンダ命令生成部１０９が、文字によって生成されたエッジ・データのサイズの最悪の推定値を計算し、これは、１つのチェッカーボード状の画素または類似するものを仮定することによって行われる。これは、現在のオブジェクトのサイズおよび複雑さとして、判断ブロック３０４における後続の使用のために返される。ステップ４２５の後、レンダ命令生成部１０９がステップ４２９へ進行する。
【００４３】
判断ブロック４２３がＦＡＬＳＥ（ＮＯ）を返し、すなわち文字がビット・マップでなかった場合、レンダ命令生成部１０９がステップ４２７へ進行する。
【００４４】
判断ブロック４２０がＦＡＬＳＥ（ＮＯ）を返し、すなわちオブジェクトが文字でなかった場合、レンダ命令生成部１０９が判断ブロック４２６へ進行し、現在のオブジェクトが経路データによって定義された形状であるかどうかの検査が行われる。判断ブロック４２６がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令生成部がステップ４２７へ進行する。
【００４５】
ステップ４２７中に、レンダ命令生成部１０９が形状または文字のための経路データを読み取る。別法として、レンダ命令生成部１０９が経路データの読み取りを延期し、経路データのためのヘッダ内から、形状または文字のサイズおよび複雑さを決定するために十分な情報を検索することができる。これは、好ましい実施形態では実施されていない。これは、大抵の既存のページ記述言語がこの種類のヘッダ情報を含まないからである。ステップ４２７の後、レンダ命令生成部１０９がステップ４２８へ進行し、経路によって生成されるエッジ・データのサイズの最悪の推定値を、経路における点の数および経路の境界ボックスを使用して計算する。これは、現在のオブジェクトのサイズおよび複雑さの一態様として、判断ブロック３０４における後続の使用のために返される。ステップ４２８の後、レンダ命令生成部１０９がステップ４２９へ進行する。
【００４６】
判断ブロック４２６がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令生成部がステップ４３０へ進行する。現在のオブジェクトが文字または形状でなかった場合、これはイメージでなければならない。ステップ４３０中に、レンダ命令生成部１０９がイメージのためのヘッダを読み取り、これがイメージ・データのサイズ（幅および高さ）、および各画素のサイズを定義する（ステップ４３０）。ヘッダは、イメージに適用される変換も含む。ステップ４３０の後、次いで、レンダ命令生成部１０９が判断ブロック４３１へ進行する。
【００４７】
判断ブロック４３１で、イメージが圧縮されずに、待ち行列およびレンダ・エンジンにおいてイメージのために可能にされた最大メモリ内に適合するかどうかの検査が行われる。判断ブロック４３１がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令生成部１０９が、イメージの４つの隅の点をすべてイメージ変換によって変換することによって生成されるエッジ・データの量を計算する。ステップ４３２の後、レンダ命令生成部がステップ４２９へ進行する。
【００４８】
判断ブロック４３１がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令生成部１０９が判断ブロック４３３へ進行し、イメージが回転されるかどうかの検査が行われる。
【００４９】
イメージが回転されないか、あるいは、小さい角度のみ回転される場合、判断ブロック４３３がＦＡＬＳＥ（ＮＯ）を返し、レンダ命令生成部がステップ４３４へ進行する。ステップ４３４中に、レンダ命令生成部１０９がリソースを計算し、イメージが水平圧縮されたストリップに分割されることを知る。ステップ４３４の後、レンダ命令生成部１０９がステップ４３６へ進行する。
【００５０】
他方では、イメージが大幅な角度で回転される場合、判断ブロック４３３がＴＲＵＥ（ＹＥＳ）を返し、レンダ命令生成部１０９がステップ４３５へ進行する。ステップ４３５で、レンダ命令生成部１０９がリソースを計算し、イメージがタイル化圧縮されたフラグメントに分割されることを知る。ステップ４３５の後、レンダ命令生成部１０９がステップ４３６へ進行する。
【００５１】
ステップ４３６中に、レンダ命令生成部１０９が、イメージの総圧縮データが占有することができる、メモリの最大可能サイズを計算する。これは、現在のオブジェクトのサイズおよび複雑さの１つの特性として、判断ブロック３０４における後続の使用のために返される。ステップ４３６の後、レンダ命令生成部がステップ４３７へ進行し、レンダ・エンジン１０５において、バッファがイメージ・データを圧縮解除するために必要とされるメモリの量を計算する。これは、現在のオブジェクトのサイズおよび複雑さのもう１つの特性として、判断ブロック３０４における後続の使用のために返される。ステップ４３７の後、レンダ命令生成部１０９がステップ４３８へ進行し、水平ストリップまたはタイル化フラグメントのエッジ・データに必要とされる、メモリにおける空間を計算する。これは、現在のオブジェクトのサイズおよび複雑さのさらなる特性として、判断ブロック３０４における後続の使用のために返される。ステップ４３８の後、レンダ命令生成部１０９がステップ４２９へ進行する。
【００５２】
ステップ４２９中に、レンダ命令生成部１０９は、現在のオブジェクトが、好ましい実施形態ではレベルおよび／または色スロットであるいずれかの複雑さのリソースを、現在のレンダ命令におけるいずれかの以前のオブジェクトと共有できるかどうかを、その範囲および充填色に基づいて決定する。オブジェクトがレベルまたは充填色を以前のオブジェクトと共有できない場合、新しいレベルを、それが追加されたときにそれに割り振らなければならない。これらは、現レンダ命令セットに、レンダ・エンジン１０５の制限をオーバーフローさせる可能性がある。また、オブジェクトがある量のメモリをレンダ命令待ち行列およびレンダ・エンジンにおいて使い果たし、これは、レンダおよびシステム・リソースを、そのエッジの生成および追跡において使い果たす。オブジェクトを追加することによっても、これらの制限をオーバーフローする可能性がある。これらのすべての制限に加えて、システムまたはレンダ・エンジンのいずれかに存在する他のいかなる制限も、ステップ３０３で決定されたオブジェクトのサイズおよび複雑さと共に、図３Ａのステップ３０４で検査される。
【００５３】
このとき、図５Ａおよび図５Ｂを参照して、図３Ｂに示すような、現在のオブジェクトのデータの残りを受信するステップ３１２のサブステップの流れ図を示す。この副処理はステップ３１０で開始し、判断ブロック５４０へ進行し、現在のオブジェクトが文字かどうかの検査が行われる。判断ブロック５４０がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令生成部１０９が判断ブロック５４１へ進行し、なお受信するビット・マップ・イメージ・データがあるかどうかの検査が行われる。
【００５４】
判断ブロック５４１がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令生成部１０９がステップ５４２へ進行し、ビット・マップ・データが受信される。ステップ５４２の後、レンダ命令生成部がステップ５４３へ進行し、ビット・マップ・イメージを追跡してエッジ・データを生成する。次いで、５４４で、このエッジ・データがフォント・キャッシュ１０４に、このオブジェクトの文字定義を文字キーとして使用して格納される。このエッジ・データも、現レンダ命令セットの一部を形成する。
【００５５】
判断ブロック５４１がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令生成部１０９が判断ブロック５４５へ進行し、なおエッジへ変換する経路データがあるかどうかの検査が行われる。なお経路データがあった場合、判断ブロック５４５がＴＲＵＥ（ＹＥＳ）を返し、レンダ命令生成部１０９がステップ５４６へ進行し、経路データがエッジ・データに変換される。このエッジ・データも、現レンダ命令セットの一部を形成する。
【００５６】
判断ブロック５４０がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令生成部１０９が判断ブロック５４７へ進行し、現在のオブジェクトが形状であるかどうかの検査が行われる。現在のオブジェクトが形状であった場合、判断ブロック５４７がＴＲＵＥ（ＹＥＳ）を返し、レンダ命令生成部１０９がステップ５４６へ進行し、形状の経路データがエッジ・データに変換される。このエッジ・データも、現レンダ命令セットの一部を形成する。
【００５７】
判断ブロック５４７がＦＡＬＳＥ（ＮＯ）を返した場合、現在のオブジェクトがビットマップまたは形状ではなく、そのためイメージでなければならず、レンダ命令生成部１０９が判断ブロック５４８へ進行し、イメージを圧縮する必要があるかどうかが検査される。イメージを圧縮する必要がない場合、判断ブロック５４８がＦＡＬＳＥ（ＮＯ）を返し、レンダ命令生成部１０９がステップ５４９へ進行する。ステップ５４９中に、レンダ命令生成部がイメージ・データを直接現レンダ命令セットに読み込む。次いで、レンダ命令生成部１０９がステップ５５０へ進行し、イメージのためのエッジを生成する。このエッジ・データも、現レンダ命令セットの一部を形成する。
【００５８】
イメージが圧縮される場合、判断ブロック５４８がＴＲＵＥ（ＹＥＳ）を返し、レンダ命令生成部がステップ５５１へ進行する。ステップ５５１中に、レンダ命令生成部１０９がイメージ・データの水平ストリップを読み取る。ステップ５５１の後、レンダ命令生成部１０９が判断ブロック５５２へ進行し、イメージが水平ストリップにおいてのみ圧縮されるかどうかの検査が行われる。判断ブロック５５２がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令生成部１０９がステップ５５３へ進行し、ストリップが圧縮される。
【００５９】
判断ブロック５５２がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令生成部１０９がステップ５５４へ進行し、ストリップが垂直にタイル・フラグメントに分割される。ステップ５５４の後、命令生成部１０９がステップ５５５へ進行し、次いで、タイル・フラグメントが個別に圧縮される。
【００６０】
ステップ５５３またはステップ５５５の後、レンダ命令生成部１０９が判断ブロック５５６へ進行し、圧縮する水平ストリップがそれ以上あるかどうかの検査が行われる。判断ブロック５５６がＴＲＵＥ（ＹＥＳ）を返した場合、命令生成部がステップ５５１へ戻り、イメージ・データの次の水平ストリップが読み取られる。以前の水平ストリップを読み取るために使用されたものと同じバッファを、再使用することができる。
【００６１】
レンダ命令生成部１０９が、イメージ・データの水平ストリップの読み取りおよび処理を、それ以上イメージ・データがなくなるまで継続する。次いで、判断ブロック５５６がＦＡＬＳＥ（ＮＯ）を返し、レンダ命令生成部がステップ５５７に進む。ステップ５５７中に、レンダ命令生成部１０９がイメージにおけるすべてのストリップまたはフラグメントのためのエッジ・データを作成し、図３Ｂのステップ３１３の処理を継続する。
【００６２】
レンダ・システムの制約により、イメージをデシメートならびに圧縮しなければならない可能性があることが可能である。レンダ・エンジン１０５により、イメージをわずかに２倍まで縮小できることが好ましい。したがって、入力イメージがプリンタの解像度の２倍以上であった場合、画素を入力イメージから除去してその解像度を低下させなければならない。好ましい実施形態では、これが、ｘ方向における適切な数の画素を平均化し、ｙ方向における走査線を省くことによって達成される。解像度の制限は、システム内で処理される、もう１つのリソース制限である。
【００６３】
いくつかの状況では、圧縮されたイメージ・データが、可能にされた最大空間内に適合しない。これは、大抵のイメージ圧縮方式によって達成される圧縮率がデータ依存であり、所望の圧縮率を達成できないからである。また、イメージ全体を同じ方法において圧縮しなければならず、そうでないとアーチファクトが印刷ページにおいて可視となる。また、イメージ・データがページ記述から読み取られた後、これを再度読み取ることもできない。そのため、イメージの一部が圧縮され、圧縮されたデータが使用可能な空間に適合しないことが判明した場合、既存の圧縮データを圧縮解除し、再度圧縮して、より高い圧縮率を与えなければならない。これは、最初の場合よりも多くのリソースを使用せずに行われる。
【００６４】
図６Ａおよび図６Ｂを参照すると、同図は図１Ａのレンダ命令ローダによって使用される、１つまたは複数のレンダリング命令セットをロードするための手順の流れ図を示している。レンダ命令ローダは継続的にループし、１つまたは複数のレンダ命令セットが待ち行列に現れるまで待機し、それらを一度に１セットずつ処理し、次いで再度待機する。
【００６５】
レンダ命令ローダ１１０は、レンダ命令生成部１０９と同時に開始するが、それとは非同期的な方法で動作する。レンダ命令ローダがステップ６００で開始し、ステップ６６０へ進行し、レンダ命令セットが命令待ち行列１１２上に存在するまで待機する。レンダ命令セットが現れたとき、ステップ６６１で、レンダ命令ローダ１１０が現命令セットを即時にレンダ・エンジンにロードする。レンダ命令ローダがステップ６６２へ進行し、現レンダ命令セットをデキューし、制御情報を現レンダ命令セットのヘッダから抽出し、命令待ち行列１１２において現レンダ命令セットによって使用された空間を解放する。
【００６６】
ステップ６６２の後、レンダ命令ローダ１１０が判断ブロック６６３へ進行し、現レンダ命令セットが背景イメージを使用するかどうかの検査が行われる。すなわち、現命令セットが、背景イメージを描画するための命令を含むかどうかを検査する。判断ブロック６６３がＴＲＵＥ（ＹＥＳ）を返した場合、レンダ命令ローダがステップ６６４へ進行し、背景イメージの参照カウンタが減分される。この参照カウンタは、上で論じたレンダ命令生成部１０９によって使用されたものと同じカウンタであり、ローダ１１０によっても生成部１０９によってもアクセスすることができる。
【００６７】
ステップ６６４の後、レンダ命令ローダ１１０が判断ブロック６６５へ進行し、参照カウンタがゼロ（０）かどうかの検査が行われる。参照カウントがこのときゼロ（０）だった場合、これは、現在、待ち行列において、メモリにおいて現在の背景イメージと同じ空間を予約する他のレンダ命令セットがないことを意味し、そのため、メモリにおいて予約されたこの空間がもはや必要とされない。現在の背景イメージが、ステップ６６１中で、先にレンダ・エンジンにロードされたことに留意されたい。したがって、判断ブロック６６５がＴＲＵＥ（ＹＥＳ）を返したとき、レンダ命令ローダ１１０が、予約された空間を解放し、判断ブロック６６７に進む。判断ブロック６６５がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令ローダが直接判断ブロック６６７へ進行する。参照カウンタの減分および検査は、非可分動作において行われなければならず、非同期的にレンダ命令セットを待ち行列に追加するレンダ命令生成部１０９との正確な動作を保証しなければならない。もう１つの実施では、レンダ・エンジンが命令を直接待ち行列から実行し、命令のデキューおよび参照カウントの減分が、レンダリングが完了した後に行われるようにすることが可能である。
【００６８】
判断ブロック６６７で、現レンダ命令セットがレイヤ、すなわち、後続のレイヤのための背景イメージを生成するかどうかの検査が行われる。これは、現レンダ命令セットのヘッダに含まれた情報から決定することができ、これがレンダ命令生成部１０９によって追加される。判断ブロック６６７がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令ローダ１１０がステップ６６８へ進行し、レンダ・エンジン１０５の出力をプリンタ１０６に向けて送る。レンダ命令ローダ１１０がステップ６６９へ進行し、レンダ・エンジンを開始し、次いでステップ６７０へ進行し、現命令セットのレンダリングが終了するまで待機する。レンダリングが終了した後、レンダリング命令ローダがステップ６６０へ戻る。もう１つの実施形態では、レンダ命令ローダ１１０が、レンダ・エンジン１０５におけるメモリが使い尽くされるときのみ待機する。
【００６９】
他方では、判断ブロック６６７が、現レンダ命令セットがレイヤを生成すると決定した場合、レンダ命令ローダ１１０がステップ６７１へ進行する。ステップ６７１中に、レンダ命令ローダ１１０が、次の命令セットが命令待ち行列１１２に来るまで待機する。次のレンダ命令セットが待ち行列において受信されたとき、レンダ命令ローダ１１０がステップ６７２へ進行する。ステップ６７２で、レンダ命令ローダ１１０が、メモリにおいて次のレンダ命令セットのための背景イメージの位置を得る。この段階で、レンダ命令ローダ１１０は次のレンダ命令セットをデキューしないが、ステップ６７３へ進行し、レンダ・エンジン１０５に、現レンダ命令セットのための画素データの出力をコンプレッサ１１１へ向けて送るように命令する。次いで、レンダ命令ローダ１１０がステップ６７４へ進行し、コンプレッサ１１１に、現レンダ命令セットの圧縮された画素データのためのその出力を、メモリにおいて次のレンダ命令セットのための背景イメージのために予約された空間に向けて送るように命令する。次いで、レンダ命令ローダ１１０がステップ６７５へ進行し、レンダ・エンジン１０５に、現命令セットのレンダリングを開始するように命令する。これはまた、コンプレッサ１１１に、結果として生じる出力画素データを圧縮するように命令し、次いで、これをメモリにおいて予約された空間に格納する。次いで、ステップ６７６で、レンダリング命令ローダが、レンダリングおよび圧縮が完了するまで待機する。次いで、レンダ命令ローダが判断ブロック６７７へ進行し、圧縮されたレンダ出力画素が、背景イメージのために使用可能な空間に適合したかどうかの検査が行われる。判断ブロック６７７がＦＡＬＳＥ（ＮＯ）を返した場合、レンダ命令ローダ１１０がステップ６７８へ進行し、コンプレッサ１１１に、より高い圧縮率を達成するように指示する。ステップ６７８の後、レンダ命令ローダがステップ６７３へ戻る。他方では、判断ブロック６７７がＴＲＵＥ（ＹＥＳ）を返し、すなわち、圧縮されたレンダ出力画素が、背景イメージのために使用可能な空間に適合した場合、レンダ命令ローダ１１０がステップ６６１に進む。
【００７０】
レンダ・エンジン１１０を、いずれかの知られているレンダ・エンジンにいくらか変更を加えたものに基づかせることができる。レンダ・エンジンは、そのレンダリングされた画素データを、コンプレッサを介して命令待ち行列に戻すように送り直し、また、そのレンダリングされた画素データをプリンタへ向けて送る能力を有するべきである。コンプレッサを、いかなる知られているコンプレッサに基づかせることもできる。別法として、コンプレッサを省くこともでき、背景イメージが圧縮解除される結果となる。後者の状況では、これによりリソース制限がレンダリング・システム上に課せられる可能性がある。
【００７１】
好ましいコンピュータ・システムは、次のオブジェクトが適合するかどうかについて、それを中間データに変換する前に検査する利点を有する。時として、次のオブジェクトが適合するかどうかについての検査が、オブジェクトのためのデータがシステム全体によって受信される前であっても行われる。たとえば、大きいイメージが到着しようとしている可能性がある。システムが、このイメージによりシステムにおけるいずれかの制限が越えられるかどうかの検査を、イメージのためのデータが受信される前に行う。より小さいオブジェクト、形状または文字などでは、データがシステムによって受信されるが、オブジェクトが適合するかどうかについての検査が行われるときに、中間データに変換されない。このように、好ましいコンピュータ・システムは、リソースを効率的に使用することも、大きいかあるいは複雑なオブジェクトを正確に処理することもできる。さらに、好ましいコンピュータ・システムは、レンダ・エンジン内で著しいリソース制限を有し、これがオブジェクトおよびレンダ命令の、サイズよりもむしろ複雑さに関係付けられる。好ましいコンピュータ・システムは、入力オブジェクトがいずれかのシステムまたはレンダ・リソース制限を越えさせるかどうかを検査する。これは、オブジェクトがいずれかの制限を破らせる可能性がある場合、階層化機構を後押しする。加えて、好ましいコンピュータ・システムは、オブジェクトが受信されたちょうどそのときよりも使用可能になる可能性のある最大可能なメモリの量の知識を有し、最大量のメモリを越えるときにのみ階層化を実行する。これは、システムに、より多くのページ記述データを受信できるまで、ページの印刷を待機させる副作用を有する可能性がある。加えて、好ましいコンピュータ・システムは、背景画素データの圧縮を使用して、これをメモリ内に適合させる。圧縮は、有損失または無損失にすることができる。有損失圧縮はなお、わずかにイメージの外観を劣化させる可能性があるが、外観は、画素データを劣化させるよりもよくなる。無損失圧縮は、最終的なイメージの外観の劣化をまったく引き起こさない。
【００７２】
図７を参照すると、同図には図１Ａのレンダ命令生成部によって使用される、１つまたは複数のレンダリング命令セットを生成するための代替手順のフローチャートが示されている。この代替手順が図３Ａおよび図３Ｂの手順と異なるのは、代替手順が、１つの単一のｚレイヤにおいて合成演算子を使用して共に結合された、多数のプリミティブ・オブジェクトを含む合成オブジェクトを処理できることである。つまり、合成されたプリミティブ・オブジェクトのグループが、ペインターズ・アルゴリズムのために、単一のｚレイヤとみなされ、合成されたオブジェクトが、合成演算子、および／またはペインターズ・アルゴリズムと互換性のない構造を使用して結合される。したがって、合成されたプリミティブ・オブジェクトのグループが、階層化の視点から非可分的であるように扱われる。これは、合成されたオブジェクトのすべての構成要素が、オブジェクトを現レンダ命令セットに追加できるようになる前に、受信されなければならないという意味である。これにより、図３Ａおよび図３Ｂを参照して先に記載したような、１つまたは複数のレンダリング命令セットを生成するための手順がわずかに変更され、これについては以下で明らかになるであろう。しかし、これらの両方の手順には共通のステップが多数あり、理解を容易にするため、これらのステップを同じ参照番号によって参照する。
【００７３】
他方では、図３Ａおよび図３Ｂを参照して記載した手順は、ｚレイヤにつきただ１つの単一のプリミティブ・オブジェクトしか処理できない。この手順がｚレイヤにつきただ１つのプリミティブ・オブジェクトを必要とするので、プリミティブ・オブジェクトを受信し、オブジェクトをレンダ命令待ち行列に「ペイント」する動作（ステップ３１４）を、順次動作にすることができる。これは、オブジェクト・データを、レンダ命令に変換する前に格納する必要がないという意味である。しかし、代替手順では、ｚレイヤにつき多数のプリミティブ・オブジェクトを処理することができる。そのため、オブジェクト・データおよび関連付けられた合成演算を、それらが受信されるときに格納する必要がある。ｚレイヤに寄与するすべてのプリミティブ・オブジェクトが受信されたとき、次いで、これらが現在のレンダ命令セットに、一度にまとめて「ペイント」される（ステップ３１４）。
【００７４】
図７に戻り、１つまたは複数のレンダリング命令セットを生成するための代替手順を、以下でより詳細に記載する。レンダ命令生成部１０９が７００で開始され、各単一の印刷ページについて初期化される。次いで７０２で、代替手順が、ページ記述の次のコマンドを、ページ記述言語（たとえば、ＰｏｓｔＳｃｒｉｐｔ（商標））に従って処理する。次いで７０４で、代替手順が、コマンドがいくつかのタイプの１つであるかどうかを検査し、次いで代替手順が、コマンド・タイプに応じて、４つの異なる副手順７０６、７０８、７１０および７１２のいずれか１つへ進行する。スイッチ・タイプのステートメントが、フロー制御においてこの多数の分岐を実行することができる。
【００７５】
副手順７０６は、コマンド・タイプがプリミティブ・オブジェクトを追加するためのものであるときに活動化される。以下で明らかになるように、任意の数のプリミティブ・オブジェクトを受信し、構築中の合成オブジェクトに追加することができる。副手順７０８は、コマンド・タイプが合成演算子を変更するためのものであるときに活動化される。再度、任意の数のプリミティブ合成演算子を、合成オブジェクトを構築するために設定することができる。副手順７１０は、合成オブジェクトの構築が完了したときに活動化される。この副手順７１０は、ｚレイヤ内のコマンドがペインターズ・アルゴリズムと互換性がないときに、コマンド・タイプ上で活動化させることができる。副手順７１２は、コマンド・タイプが、他のユーティリティが活動化されるためのものであるときに、活動化される。このようなユーティリティには、クリッピング、診断、レンダ・モード調整などが含まれる可能性がある。
【００７６】
これらの４つの副手順が、７１４を介してステップ７０２へ戻り、７０２でページ記述の次のコマンドが処理される。代替手順がステップ７１６で、ペイント副手順７１０が最終的に完了した後に終了する。
【００７７】
図８Ａおよび図８Ｂを参照すると、同図には図７に示す手順で使用される、プリミティブ・オブジェクトを追加するための副手順７０６をより詳細に記載されている。プリミティブ・オブジェクトを追加するための副手順７０６がステップ８００で開始し、プリミティブ・オブジェクトに関する基本情報が検索される。副手順７０６が判断ブロック８０６へ進行し、現在のプリミティブ・オブジェクトで既存のオブジェクトを置換するかどうかの検査が行われる。判断ブロック８０６がＴＲＵＥ（ＹＥＳ）を返した場合、８０８で、プリミティブ・オブジェクトが合成オブジェクト内で置換される。たとえば、合成オブジェクトが、ＲＯＰ４演算子を使用するようにすることができる。これは、Ｓｏｕｒｃｅ、ＰａｔｔｅｒｎおよびＭａｓｋのオペランドを取る。Ｓｏｕｒｃｅ、ＰａｔｔｅｒｎまたはＭａｓｋは、ペイントされる最終的な結合が分かる前に数回置換することができる。プリミティブ・オブジェクトが置換中である場合、これが除去され（８０８）、これは、もはやこれが合成オブジェクトのための累積リソースに寄与しないからである。次に、ステップ３０２で、副手順７０６が、現レンダ命令セットによって利用された、すべてのレンダおよびシステム・リソースの現在の使用率を、図３Ａおよび図３Ｂを参照して記載したものと類似の様式で得る。次いで、副手順７０６がステップ３０３へ進行し、ページ記述における次のプリミティブ・オブジェクトについての十分な情報を検索し、プリミティブ・オブジェクトの複雑さおよびサイズを決定する。これが決定される方法は、図４Ａおよび図４Ｂの好ましい手順を参照して記載した方法に類似している。
【００７８】
次に、判断ブロック８１０で、このプリミティブ・オブジェクトを追加することによりホスト・メモリ制限を使い尽くすかどうかの検査が行われる。ホスト・メモリ制限が使い尽くされない場合、副手順７０６がステップ８１６へ進行する。ホスト・メモリ制限を越える場合、判断ブロック８１２で、副手順７０６が、階層化が支援する可能性があるかどうかを検査する。階層化は、すでにオブジェクトが現レンダ命令セットに存在する場合、支援する可能性があり、これは、背景レイヤにレンダリングされたときに、ホスト・メモリを解放する。階層化がメモリを解放しない場合、副手順７０６が、「オブジェクトが複雑すぎる」というエラー８１４信号を返す。他方では、階層化が支援する可能性がある場合、副手順７０６がステップ３０５から３１０（図８Ａ及び図８Ｂ）へ進行する。これらのステップ３０５から３１０（図８Ａ及び図８Ｂ）の動作は、図３Ａおよび図３Ｂのステップ３０５から３１０を参照して上で記載したものと実質的に同じであるので、その説明は省略する。
【００７９】
ステップ３１０（図８Ｂ）の後、あるいは、判断ブロック８１０（図８Ａ）がＦＡＬＳＥ（ＮＯ）を返したとき、副手順７０６がステップ８１６へ進行し、プリミティブ・オブジェクトのデータの残りが受信される。この代替手順では、このステップが失敗する可能性があることに留意されたい。プリミティブ・オブジェクトを受信するには不十分なホスト・メモリがある可能性がある。不十分なホスト・メモリがある場合、レンダ命令待ち行列が完全に空になるまで待機した後であっても、この実施形態が「オブジェクトが複雑すぎる」というエラーを返す。不十分なホスト・メモリがあった場合、８１８で、プリミティブ・オブジェクトが、その複雑さの情報、現在の合成演算子および他のいかなる関連情報と共に保存される。次いで、副手順７０６が８２０で終了し、７１４を介して、次のコマンドのためにステップ７０２へ戻る。
【００８０】
このとき、図９を参照して、図７に示す手順で使用される、合成演算子を変更するための副手順７０８の流れ図を示す。副手順７０８がステップ９００で開始し、合成演算子が検索される。検索される合成演算子のタイプは、ステップ７０２で処理されたコマンドのタイプによって決まる。次いで、この合成演算子が現在の合成演算子として保存される。次いで、副手順７０８が９０４で終了し、７１４を介して、次のコマンドのためにステップ７０２へ戻る。
【００８１】
図１０Ａおよび図１０Ｂを参照すると、これらには図７に示す手順で使用される、ペイントするための副手順７１０の流れ図が示されている。この副手順７１０は、ステップ７０２で処理されたコマンドがペインターズ・アルゴリズムと互換性があるときに開始する。これが起こったとき、先に副手順７０６および７０８によって受信かつ格納された、現在構築中のプリミティブ・オブジェクトのグループが完了する。１００２で、副手順７１０が最初に、構築されたプリミティブ・オブジェクトのグループのサイズおよび複雑さを決定する。これは、プリミティブ・オブジェクトの各構成要素の、知られているサイズおよび複雑さの合計に、場合によってはいくらかの追加リソース使用率を加えたものである。たとえば、ある実施では、プリミティブ・オブジェクトを共に合成するために追加のレベルが必要となる可能性がある。次いで、副手順７１０が、すべてのリソースの現在の使用率を、ステップ３０２（図３Ａ）に類似した様式で決定する。次いで、副手順が判断ブロック３０４へ進行し、リソース制限を越えるかどうかの検査が、判断ブロック３０４（図３Ａ）に類似した様式で行われる。判断ブロック３０４がＦＡＬＳＥ（ＮＯ）を返した場合、副手順がステップ３１３へ進行する。他方では、判断ブロック３０４がＴＲＵＥ（ＹＥＳ）を返した場合、副手順が判断ブロック１００４へ進行し、階層化が支援する可能性があるかどうかの検査が行われる。判断ブロック１００４が、階層化が支援しないと決定した場合、副手順が「オブジェクトが複雑すぎる」というエラー信号１００６を返す。判断ブロック１００４が、階層化が支援する可能性があると決定した場合、副手順７１０がステップ３０５から３１０（図１０Ｂ）へ進行する。これらのステップ３０５から３１０（図１０Ｂ）の動作は、図３Ａおよび図３Ｂのステップ３０５から３１０を参照して上に記載したものと実質的に同じであり、以下でさらに記載しない。ステップ３１０の後、副手順７１０がステップ３０２へ進行する。
【００８２】
判断ブロック３０４（図１０Ａ）がＦＡＬＳＥを返した場合、副手順がステップ３１３へ進行し、オブジェクト・データがレンダ命令に変換され、これはページ記述の中間データ形式であり、次いで３１４で、これらの変換されたレンダ命令を現レンダ命令セットに追加する。
【００８３】
ステップ３１４の後、副手順７１０が判断ブロック３１５へ進行する。判断ブロック３１５で、現在のグループのプリミティブ・オブジェクトが、ページ上のプリミティブ・オブジェクトの最後のグループであるかどうかの検査が行われる。判断ブロック３１５がＴＲＵＥ（ＹＥＳ）を返した場合、現レンダ命令セットが命令待ち行列１１２上で、レンダ命令ローダ１１０による後続のローディングのためにキューイングされる（ステップ３１６）。副手順７１０が３１７で終了し、次いで、代替手順が７１６で終了する。判断ブロック３１５がＦＡＬＳＥ（ＮＯ）を返した場合、副手順７１０がステップ３０２へ戻り、次のグループのプリミティブ・オブジェクトを受信し、処理が次のグループのプリミティブ・オブジェクトについて再度開始する。
【００８４】
このように、任意に複雑に構築されたオブジェクトをレンダリングすることができる。しかし、階層化は、ｚ順序付けが適用されるところでしか行うことができない。そのため、合成オブジェクト全体がホスト・メモリに一度に適合しなければならず、これはまた、合成オブジェクトを固定メモリおよび固定リソース環境内でレンダリングできるようにするため、１つのレイヤ内に（メモリおよび複雑さに関して）適合しなければならない。実際は、従来のページ記述言語を使用する際に、オブジェクトが複雑すぎてレンダリングできないことは稀である。
【００８５】
上述のように、命令待ち行列およびレンダ命令ローダを省くことができる。これらの場合、ただ１つのレンダリング命令セットしかなく、待ち行列の必要性がない。命令生成部が再度、受信されたオブジェクトが現レンダリング命令セットに追加された場合に使用可能なリソースを越えるかどうかを検査する。リソースを越える場合、命令生成部がレンダ・エンジンに、現セット（現在受信されたオブジェクトを含まない）を、メモリ（フレーム・ストア）において予約された背景イメージの空間上にレンダリングするように命令し、次いで、現在のレンダリストを空に設定する。しかし、この空の現レンダリング命令セットは、基本レンダ初期化命令を含む可能性がある。リソースを越えない場合、命令生成部は現レンダリング命令セットを変更しない。次いで、命令生成部が、受信されたオブジェクトを現レンダリング命令セットに追加する。受信されたオブジェクトがｚ順序における最後のオブジェクトであった場合、かつ、フレーム・ストア上にレンダリングされた場合、命令ローダがレンダ・エンジンに、現レンダリング命令セットをフレーム・ストアと組み合わせてレンダリングして、レンダリングされたページ記述を形成するように要求する。他方では、受信されたオブジェクトがｚ順序における最後のオブジェクトであった場合、かつ、フレーム・ストア上にレンダリングされなかった場合、命令ローダがレンダ・エンジンに、現セットをレンダリングして、レンダリングされたページ記述を形成するように要求する。
【００８６】
前述の好ましい方法は、特定の制御フローを含む。好ましい方法の他の多数の変形形態があり、これらは本発明の精神または範囲から逸れることなく、異なる制御フローを使用する。さらに、好ましい方法の１つまたは複数のステップを、順次ではなく並列に実行することができる。前述の好ましい方法を、コンピュータ・プログラムとして実施することができ、これをコンピュータ可読媒体上に格納することができる。方法のステップを、ホスト・プロセッサにこれらのステップの機能を実行させるように命令するためのプログラム・コードとして実施することができる。
【００８７】
＜産業上の利用可能性＞
上記から、本発明の実施形態がコンピュータ・グラフィックスおよび印刷産業に適用可能であることは明らかである。
【００８８】
前記では、本発明のいくつかの実施形態のみを記載し、本発明の範囲および精神から逸れることなく修正および／または変更をこれに行うことができ、これらの実施形態は例示的であり制限的なものではない。たとえば、好ましい実施形態を、表示画面へのレンダリングにおける使用に適合させることができる。
【図面の簡単な説明】
【図１Ａ】好適な実施形態を組み込む、ページ記述をレンダリングするためのコンピュータシステムの概略ブロック構成図である。
【図１Ｂ】好適な実施形態による、図１Ａのコンピュータ・システムの機能的データフローを示すブロック図である。
【図１Ｃ】図１Ａのコンピュータ・システムの動作を例示するための、例示的ページ記述のオブジェクトおよび対応する変換されたオブジェクトを示すブロック図である。
【図２Ａ】好適な実施形態による、多数のページのキューイングの一例を例示するブロック図である。
【図２Ｂ】好適な実施形態による、多数のページのキューイングのもう１つの例を例示するブロック図である。
【図２Ｃ】時間におけるさらなる段階の、図２Ｂにおけるページのキューイングを例示するブロック図である。
【図３Ａ】、
【図３Ｂ】図１Ａのレンダ命令生成部によって使用される、１つまたは複数のレンダリング命令セットを生成するためのフローチャートである。
【図４Ａ】、
【図４Ｂ】図３Ａに示すような、オブジェクトのサイズおよび複雑さを決定するステップのサブステップのフローチャートである。
【図５Ａ】、
【図５Ｂ】図３Ｂに示すような、現在のオブジェクトのデータの残りを受信するステップのサブステップのフローチャートである。
【図６Ａ】、
【図６Ｂ】図１Ａのレンダ命令ローダによって使用される、１つまたは複数のレンダリング命令セットをロードするためのフローチャートである。
【図７】図１Ａのレンダ命令生成部によって使用される、１つまたは複数のレンダリング命令セットを生成するためのもう１つのフローチャートである。
【図８Ａ】、
【図８Ｂ】図７に示す手順で使用される、プリミティブ・オブジェクトを追加するための副手順のフローチャートである。
【図９】図７に示す手順で使用される、合成演算子を変更するための副手順のフローチャートである。
【図１０Ａ】、
【図１０Ｂ】図７に示す手順で使用される、ペイントするための副手順のフローチャートである。
【図１Ａ】
0004817549.tif 000002
【図１Ｂ】
0004817549.tif 000003
【図１Ｃ】
0004817549.tif 000004
【図２Ａ】
0004817549.tif 000005
【図２Ｂ】
0004817549.tif 000006
【図２Ｃ】
0004817549.tif 000007
【図３Ａ】
0004817549.tif 000008
【図３Ｂ】
0004817549.tif 000009
【図４Ａ】
0004817549.tif 000010
【図４Ｂ】
0004817549.tif 000011
【図５Ａ】
0004817549.tif 000012
【図５Ｂ】
0004817549.tif 000013
【図６Ａ】
0004817549.tif 000014
【図６Ｂ】
0004817549.tif 000015
【図７】
0004817549.tif 000016
【図８Ａ】
0004817549.tif 000017
【図８Ｂ】
0004817549.tif 000018
【図９】
0004817549.tif 000019
【図１０Ａ】
0004817549.tif 000020
【図１０Ｂ】
0004817549.tif 000021