JP2006345197A - 印刷装置 - Google Patents

Abstract

【課題】 ＰＤＬ文書でアルファブレンドレンダリングが必要な場合に、より適切にカラーマッチングを行なえ、さらに、このカラーマッチングを効率よく行なえるようにする。
【解決手段】 ＰＤＬ文書をレンダリングするレンダリング手段と、ＰＤＬ文書で指定された色情報を、ＰＤＬ文書を印刷する印刷デバイス用の色情報に変換するカラーマッチング手段と、ＰＤＬ文書でアルファブレンドレンダリングが必要な場合、カラーマッチング手段による変換をレンダリング前に行なうかレンダリング後に行なうかを判断し、より適切な方を選択する選択手段とを備える。
【選択図】 図４

Description

本発明は、印刷装置におけるレンダリングとカラーマッチングの技術に関し、特にＰＤＬ文書等の各レンダリング命令のレンダリングとカラーマッチングの技術に関する。

従来、ＰＤＬ（Ｐａｇｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ；ページ記述言語）文書の各レンダリング命令に指定された色をモニタやプリンタに出力する際には、出力先デバイスのプロファイルを使用して、そのデバイスの色域（ｇａｍｕｔ）に圧縮・変換してから出力することが行なわれている。この方法については、例えば特許文献１に記載がある。

また、特許文献２では、異なる属性（色空間など）を持つオブジェクトに対し、それぞれに最適な画像データ構造に変換し、適用するカラーマッチング処理をリアルタイムで切り替え可能にする方法についての記載がある。

特開平７−１０７３１２号公報 特開平８−２３５３４６号公報

ＰＤＬ文書の色指定に不透明度（アルファ値）が含まれる場合は、それらの色がお互いに重なる場合にアルファブレンド処理が必要になる。この際、アルファブレンド処理の前にデバイスの色域に圧縮するか、デバイスの色域に圧縮してからアルファブレンド処理を行なうかによって、レンダリング結果が異なる。しかしながら、圧縮をどのタイミングで行なう方がよいかは一意に決定できず、指定された色とアルファ値、出力デバイス、色圧縮時に使用するプロファイルおよびレンダリングインテント等の影響を受ける。

本発明は以上の事情に鑑みてなされたものであり、ＰＤＬ文書等のレンダリング命令をレンダリングする際にアルファブレンドレンダリングが必要な場合に、より適切にカラーマッチングを行なえるようにすることを課題とする。
さらに、上記カラーマッチングを効率よく行なえるようにすることを課題とする。

上記課題を解決するために、本発明に係る印刷装置は、記述言語文書をレンダリングするレンダリング手段と、前記記述言語文書で指定された色情報を、前記記述言語文書を印刷する印刷デバイス用の色情報に変換するカラーマッチング手段と、前記記述言語文書でアルファブレンドレンダリングが必要な場合、前記カラーマッチング手段による前記変換を前記レンダリング前に行なうか前記レンダリング後に行なうかを判断し、該判断結果によりいずれかを選択する選択手段と、を備えることを特徴とする。

また、上記印刷装置において、前記選択手段による選択は、前記カラーマッチング手段による前記変換を、前記レンダリング前に行なった場合と前記レンダリング後に行なった場合の結果を検証し、前記選択をすることを特徴とする。

また、上記印刷装置は、前記選択手段における選択に使用した条件と選択結果とを保持しておく保持手段と、次回以降のアルファブレンドレンダリングの際、前記保持手段で保持した情報を利用する利用手段と、をさらに備えることを特徴とする。

また、本発明は、印刷装置の制御方法であって、記述言語文書をレンダリングするレンダリングステップと、前記記述言語文書で指定された色情報を、前記記述言語文書を印刷する印刷デバイス用の色情報に変換するカラーマッチングステップと、前記記述言語文書でアルファブレンドレンダリングが必要な場合、前記カラーマッチングステップによる前記変換を前記レンダリング前に行なうか前記レンダリング後に行なうかを判断し、該判断結果によりいずれかを選択する選択ステップと、を備えることを特徴とする。

また、上記印刷装置において、前記選択ステップによる選択は、前記カラーマッチングステップによる前記変換を、前記レンダリング前に行なった場合と前記レンダリング後に行なった場合の結果を検証し、前記選択をすることを特徴とする。

また、上記印刷装置の制御方法は、前記選択手段における選択に使用した条件と選択結果を保持しておく保持ステップと、次回以降のアルファブレンドレンダリングの際、前記保持手段で保持した情報を利用する利用ステップと、をさらに備えることを特徴とする。

また、本発明は、印刷装置の制御プログラムであって、記述言語文書をレンダリングするレンダリングステップと、前記記述言語文書で指定された色情報を、前記記述言語文書を印刷する印刷デバイス用の色情報に変換するカラーマッチングステップと、前記記述言語文書でアルファブレンドレンダリングが必要な場合、前記カラーマッチングステップによる前記変換を前記レンダリング前に行なうか前記レンダリング後に行なうかを判断し、該判断結果によりいずれかを選択する選択ステップと、を備えることを特徴とする。

また、上記印刷装置の制御プログラムは、前記選択ステップによる選択は、前記カラーマッチングステップによる前記変換を、前記レンダリング前に行なった場合と前記レンダリング後に行なった場合の結果を検証し、前記選択をすることを特徴とする。

また、上記印刷装置の制御プログラムは、前記選択ステップにおける選択に使用した条件と選択結果を保持しておく保持ステップと、次回以降のアルファブレンドレンダリングの際、前記保持手段で保持した情報を利用する利用ステップと、をさらに備えることを特徴とする。

また、上記印刷装置の制御プログラムは、コンピュータ読み取り可能な記憶媒体、Ｗｅｂサーバに格納することができる。

本発明によれば、記述言語文書でアルファブレンドレンダリングが必要な場合に、より適切にカラーマッチングを行なえる。
さらに、二回目以降の選択では保持しておいた情報を利用することができるので効率がよい。

以下、本発明における一実施形態について図面を参照して詳細に説明する。
［本実施形態の概要］
本実施形態では、ＰＤＬとしてＳＶＧ １．１を使用する。ＳＶＧ １．１の仕様はＳＶＧ １．１ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ｈｔｔｐ:／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ＳＶＧ１１／）に示されている。ユーザＰＣ（クライアント）において、 ＳＶＧ（Ｓｃａｌｅａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃ）文書ファイルをインタプリタが中間コードデータに変換する。続いて、レンダラーが中間コードデータをビットマップデータに変換するが、この際、レンダリング前カラーマッチングとレンダリング後カラーマッチングの精度を測定し、精度の高いほうを選択する。この選択結果は保存しておいて、本レンダリングセッションに限らず以降のレンダリングで使用できるようにする。プリンタはビットマップデータを使用して出力を行ない、印刷結果を得る。

［全体構成］
まず、図１を参照して本実施形態の全体構成を説明する。

１０１はユーザが操作を行なうクライアントＰＣであり、ネットワークインタフェースを経由してネットワーク１０３に接続されている。１０２はネットワーク経由で印刷指示を受け付けるプリンタであり、同じくネットワークインタフェースを経由してネットワーク１０３に接続されている。ＰＣ１０１はネットワーク１０３を通じてプリンタ１０２に印刷指示を送信することが可能である。

［コンピュータ装置およびプリンタの構成］
次に、図２と図３を参照して、本実施形態で使用するコンピュータ装置およびプリンタの構成について説明する。

図２は、クライアント１０１の構成の一例を示すブロック図である。２０１はＲＡＭ２０２に格納されている制御プログラムに従って本装置全体の制御を行なうＣＰＵである。２０２はＣＰＵ２０１が実行する本装置の制御プログラムや、文書画像等のデータを格納するＲＡＭ等の内部記憶部である。２０３はＣＰＵ２０１の制御の下にネットワークとの接続を行なってデータ等を送受信するネットワークインタフェースである。２０４はデータを保存する磁気ディスク等の外部記憶装置である。２０５はディスプレイ、２０６はキーボード、２０７はマウス等のポインティングデバイスである。ＲＡＭ２０２に格納されているプログラムは、同じくＲＡＭ２０２に格納されているＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の機能を必要に応じて使用し、ＲＡＭ２０２に一時記憶するデータの内容を読み書きしたり、外部記憶装置 ２０４上でデータを読み書きしたり、ネットワークインタフェースを通じてデータの送受信を行なったり、キーボード２０６やポインティングデバイス２０７からの入力を受け取ったり、ディスプレイ２０５に表示を行なったりすることで、所定の動作を行なう。

図３は、プリンタ１０２の構成の一例を示すブロック図である。２０８、２０９、２１０、２１１は図２の２０１、２０２、２０３、２０４に示したのと同じくそれぞれＣＰＵ、ＲＡＭ、ネットワークインタフェース、外部記憶装置である。２１２は印刷を行なうプリンタエンジンである。ＲＡＭ２０９に格納されているプログラムは、ネットワークインタフェース２１０を通じて受信した印刷指示にしたがって、プリンタエンジン２１２を制御して印刷を行なう。その際、ＲＡＭ２０９に一時記憶するデータの内容を読み書きしたり、外部記憶装置２１１上でデータを読み書きしたりすることができる。

［全体のブロック図］
次に、図４を参照して、本実施形態で使用するコンピュータ装置内のブロック構成について説明する。

図４は、物理的に図１のような構成を取るクライアント１０１、プリンタ１０２、ネットワーク１０３において、本実施形態の動作に主として関わる論理ブロック、すなわちプログラムモジュール、ファイルエンティティ、メモリデータ、および通信経路の構成を示すブロック図である。

３０１はクライアント１０１のブロック境界を表わし、ここではＯＳの制御下にある環境を指す。インタプリタ３０９、レンダラー３１０、ＣＭＭ（Ｃｏｌｏｒ Ｍａｎａｇｅｍｅｎｔ Ｍｏｄｕｌｅ）３１１は、通常は外部記憶装置２０４に保存されているが、ユーザ、ＯＳ、あるいは別のプログラムから実行が指示されると、ＯＳの制御によりＲＡＭ２０２に読み込まれ、実行可能な状態となる。３０２は外部記憶装置２０４に保存されているＳＶＧ文書ファイルであり、インタプリタ３０９を含むプログラムはＯＳの機能を利用してＳＶＧ文書ファイル３０２の内容を読み書きすることが可能である。

３０３はＲＡＭ２０２に格納される中間コードデータであり、インタプリタ３０９、レンダラー３１０を含むプログラムは同じくＯＳの機能を利用して中間コードデータ３０３の内容を読み書きすることが可能である。３０４はＲＡＭ２０２に格納されるビットマップデータであり、レンダラー３１０を含むプログラムは同じくＯＳの機能を利用してビットマップデータ３０４の内容を読み書きすることが可能である。

インタプリタ３０９はＳＶＧ文書ファイル３０２から中間コードデータ３０３への変換を行なうが、この変換動作は両言語の仕様から機械的に決定できるものである。したがって、本実施形態ではインタプリタ３０９の動作について詳述はせず、変換内容の提示のみ行なう。レンダラーは中間コードデータ３０３からビットマップデータ３０４を作成し、ネットワーク１０３を経由してプリンタ３１３のコントローラ３１４に送信する。この際、カラーマッチングのためにＣＭＭ３１１の機能を利用する。

ＣＭＭ３１１は必要なカラーマッチングを行なうため、ＳＶＧ文書ファイル３０２および中間コードデータ３０３の入力カラースペースを表わす入力プロファイル３０５、レンダラー３１０のレンダリングカラースペースを表わすレンダリングプロファイル３０６、プリンタ３１３のデバイスカラースペースを表わすプリンタプロファイル３０７、カラーマッチング時のマッチング方法を指定するレンダリングインテント３０８を入力として使用する。

ＣＭＭは通常ＯＳの一部あるいはＯＳによって利用可能なライブラリとして提供され、プログラムからはその機能を利用するのみであるので、本実施形態ではＣＭＭ３１１の動作について詳述はせず、その機能と利用例のみ示す。３１２は外部記憶装置２０４上にデータベースプログラム（図示しない）が構成した検証結果ＤＢである。レンダラー３１０を含むプログラムはデータベースドライバ（図示しない）の機能を利用して、検証結果ＤＢ３１２の内容を読み書き可能である。

３１３はプリンタ１０２のブロック境界を表わす。コントローラ３１４はＲＡＭ２０９に格納され、常に実行可能な状態にあるプログラムである。コントローラ３１４はネットワークインタフェース２１０を通じてレンダラー３１０からビットマップデータ３０４を受信すると、ＲＡＭ２０９にビットマップデータ３１５として格納し、その情報にしたがってプリンタエンジン２１２を制御して印刷を行なう。

［ＳＶＧ文書ファイル］
次に、図５〜図６を参照して、本実施形態で使用するＳＶＧ文書ファイルについて説明する。
図５は、本実施形態で使用するＳＶＧ文書ファイル３０２の内容を示す図である。

１行目はＸＭＬ宣言（ＸＭＬ Ｄｅｃｌａｒａｔｉｏｎ）であり、本ＳＶＧ文書ファイルがＸＭＬ １．０仕様にしたがって記述されていることを示す。
２〜３行目は文書型宣言（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｃｌａｒａｔｉｏｎ）であり、外部サブセットとしてＳＶＧ １．１の文書型定義（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ；ＤＴＤ）を参照している。

４〜５行目はルート要素としての ＜ｓｖｇ＞ 要素の開始タグである。＜ｓｖｇ＞ 要素の幅・高さとしてそれぞれ２１．０ｃｍと２９．７ｃｍ（Ａ４サイズ）、ユーザ座標系として（０、０）−（２１０、２９７）を指定しているほか、ＳＶＧ名前空間と、準拠するＳＶＧのバージョン番号を指定している。

６行目は ＜ｄｅｓｃ＞ 要素であり、本ＳＶＧ文書ファイルについての説明を記述する。＜ｄｅｓｃ＞ 要素の内容はＳＶＧ文書のレンダリングには使用されない。
７、１０、１３行目はコメント要素である。コメント要素の内容もＳＶＧ文書のレンダリングには使用されない。

８〜９行目は一つ目の円をレンダリングするための＜ｃｉｒｃｌｅ＞要素である。中心座標の値はユーザ座標系において（８０、８０）を指定し、半径の値はユーザ座標系において５０を指定している。円内部の塗りつぶしの色は“ｙｅｌｌｏｗ”（黄色）で不透明度（アルファ値）が０．７、円の外形線の色は“ｂｌｕｅ”（青色）、外形線の幅はユーザ座標系において２と指定している。

１１〜１２行目は二つ目の円をレンダリングするための＜ｃｉｒｃｌｅ＞要素である。中心座標の値はユーザ座標系において（１４０、８０）を指定し、半径の値はユーザ座標系において５０を指定している。円内部の塗りつぶしの色は“ｒｅｄ”（赤色）で不透明度（アルファ値）が０．５、円の外形線の色は“ｂｌｕｅ”（青色）、外形線の幅はユーザ座標系において２と指定している。

１４〜１５行目は三つ目の円をレンダリングするための＜ｃｉｒｃｌｅ＞要素である。中心座標の値はユーザ座標系において（１１０、１３０）を指定し、半径の値はユーザ座標系において５０を指定している。円内部の塗りつぶしの色は“ｇｒｅｅｎ”（緑色）で不透明度（アルファ値）が０．３、円の外形線の色は“ｂｌｕｅ”（青色）、外形線の幅はユーザ座標系において２と指定している。
１６行目はルート要素としての＜ｓｖｇ＞要素の終了タグであり、４〜５行目の開始タグに対応するものである。

図５に示したＳＶＧ文書ファイルをレンダリングした例を図６に示す。５０１が８〜９行目の＜ｃｉｒｃｌｅ＞ 要に対応する一つ目の円、５０２が１１〜１２行目の＜ｃｉｒｃｌｅ＞要素に対応する二つ目の円、５０３が１４〜１５行目の＜ｃｉｒｃｌｅ＞要素に対応する三つ目の円である。５０４はＳＶＧ文書全体の外接矩形を示している。外接矩形５０４のサイズは幅２１．０ｃｍ、高さ２９．７ｃｍである。縦横の破線、破線交点の円、破線交点付近の座標値表示は、ポイントとなる座標の座標値を図示するためのものであり、実際のレンダリングには含まれない。

［中間コード］
次に、図７〜８を参照して、本実施形態で使用する中間コードについて説明する。
図７は、本実施形態で使用する中間コードの仕様を示す図である。

６０１はレンダリング命令を表わすオペコードであり、数字で指定する。本実施形態では９種類のオペコードを定義している。オペコードは１バイト整数として中間コードデータ３０３に格納される。
６０２はオペコードを人間が識別しやすくするためのニーモニックである。ニーモニックは中間コードの内容をダンプして示すような場合にのみ使用し、中間コードデータ３０３には含まれない。
６０３はオペコードに対する引数を表わすオペランドである。オペランドの数とその意味はオペコードによって異なる。オペランドは２バイト浮動小数点数として中間コードデータ３０３に格納される。

本実施形態で使用する中間コードでは、単位系としてｍｍのみを使用する。オペランドに座標や長さを指定する場合は、すべてｍｍに換算した値を指定する。座標値はページ左上を原点とする絶対値で表わす。オペランドに色を指定する場合はＲＧＢ（赤・緑・青）あるいはＲＧＢＡ（赤・緑・青・アルファ値）で表わし、Ｒ（赤）、Ｇ（緑）、Ｂ（青）、Ａ（アルファ値）の値をそれぞれ０．０〜１．０の範囲で指定する。ＲＧＢによる色の指定では、アルファ値を１．０として扱う。

オペコード０（ニーモニックＰａｇｅＳｔａｒｔ）はページの開始を表わす。オペランドはページの幅Ｗ（ｍｍ）とページの高さＨ（ｍｍ）である。
オペコード１（ニーモニックＰａｇｅＥｎｄ）はページの終了を表わす。オペランドはない。
オペコード２（ニーモニックＦｉｌｌ）は塗りつぶしの色の指定である。Ｆｉｌｌで指定する塗りつぶしは以降のレンダリング命令すべてに適用される。オペランドは塗りつぶしの色ＲＧＢＡである。

オペコード３（ニーモニックＳｔｒｏｋｅ）は外形線の指定である。Ｓｔｒｏｋｅで指定する外形線は以降のレンダリング命令すべてに適用される。オペランドは外形線の色ＲＧＢと、外形線の幅Ｗ（ｍｍ）である。本実施形態では外形線の色を暗黙的にアルファ値１．０とする。
オペコード４（ニーモニックＰａｔｈＳｔａｒｔ）はパスの開始を表わす。オペランドはない。

オペコード５（ニーモニックＰａｔｈＥｎｄ）はパスの終了を表わす。オペランドはクローズフラグＦであり、“１”が指定された場合はパスの終了位置から開始位置まで直線をレンダリングすることで、パスを閉じることを表わす。“０”が指定された場合は何もしない。

オペコード６（ニーモニックＰａｔｈＭｏｖｅＴｏ）はパスのレンダリング位置の移動を表わす。ＰａｔｈＳｔａｒｔ命令とＰａｔｈＥｎｄ命令の間でのみ有効である。ＰａｔｈＭｏｖｅＴｏはレンダリング位置を移動するだけで、実際のレンダリングは行なわない。オペランドは移動位置座標をＸ（横方向）（ｍｍ）とＹ（縦方向）（ｍｍ）の値で指定する。

オペコード７（ニーモニックＰａｔｈＬｉｎｅＴｏ）はパスの現在位置からオペランドで指定された位置まで直線をレンダリングする。ＰａｔｈＳｔａｒｔ命令とＰａｔｈＥｎｄ命令の間でのみ有効である。オペランドは直線終端座標をＸ（横方向）（ｍｍ）とＹ（縦方向）（ｍｍ）の値で指定する。

オペコード８（ニーモニックＰａｔｈＡｒｃ）はパスの現在位置から円弧をレンダリングする。ＰａｔｈＳｔａｒｔ命令とＰａｔｈＥｎｄ命令の間でのみ有効である。ＰａｔｈＡｒｃは常に時計回り方向に円弧をレンダリングする。オペランドは円弧中心座標のＸ（横方向）（ｍｍ）とＹ（縦方向）（ｍｍ）の値、および、円弧の長さ（角度Ｄ（°）で指定する）である。

図８は、図５に示した内容のＳＶＧ文書ファイル３０２をインタプリタ３０９が変換した中間コードデータ３０３の内容を示す図である。中間コードデータ３０３は１バイト整数のオペコードと２バイト浮動小数点数のオペランドのみが格納されたバイナリデータであるが、図８に示すのはそれを人間が識別しやすくするためにダンプ表示し、ニーモニックも付記したものである。

１行目はページ開始命令で、オペランドでページの幅と高さを２１０．０ｍｍと２９７．０ｍｍに指定している。図５の＜ｓｖｇ＞要素の開始タグに相当し、長さ指定をｃｍからｍｍに換算している。

２行目は以降のレンダリングに使用する塗りつぶし命令で、オペランドで塗りつぶしの色を黄色・アルファ値０．７、すなわち（Ｒ，Ｇ，Ｂ，Ａ）＝（１．０，１．０，０．０，０．７）に指定している。図５の一つ目の＜ｃｉｒｃｌｅ＞要素のｆｉｌｌおよびｆｉｌｌ−ｏｐａｃｉｔｙ属性に相当し、文字列表記の色指定と数値表記の不透明度からＲＧＢＡ表記に変換している。

３行目は以降のレンダリングに使用する外形線命令で、オペランドで外形線の色を青色、すなわち（Ｒ，Ｇ，Ｂ）＝（０．０，０．０，１．０）に指定し、線幅を２．０ｍｍに指定している。図５の三つの＜ｃｉｒｃｌｅ＞要素のｓｔｒｏｋｅ属性およびｓｔｒｏｋｅ−ｗｉｄｔｈ属性に相当し、文字列表記の色指定からＲＧＢ表記に変換するとともに、長さ指定をユーザ座標系からｍｍに換算している。

４〜７行目は円のレンダリングを行なう命令群である。５行目のレンダリング位置移動命令および６行目の円弧レンダリング命令によって、座標（８０．０ｍｍ，８０．０ｍｍ）を中心とし、座標（８０．０ｍｍ，３０．０ｍｍ）から始まる、角度３６０．０度の円がレンダリングされる。円内部は２行目の命令により黄色・アルファ値０．７で塗りつぶされ、外形線は３行目の命令により青色かつ線幅２ｍｍでレンダリングされる。図５の一つ目の＜ｃｉｒｃｌｅ＞要素および図６のレンダリング結果５０１に相当し、座標指定や長さ指定をユーザ座標系からｍｍに換算している。

８行目は以降の塗りつぶしに使用する塗りつぶし命令で、オペランドで塗りつぶしの色を赤色・アルファ値０．５、すなわち（Ｒ，Ｇ，Ｂ，Ａ）＝（１．０，０．０，０．０，０．５）に指定している。図５の二つ目の＜ｃｉｒｃｌｅ＞要素のｆｉｌｌおよびｆｉｌｌ−ｏｐａｃｉｔｙ属性に相当し、文字列表記の色指定と数値表記の不透明度からＲＧＢＡ表記に変換している。

９〜１２行目は円のレンダリングを行なう命令群である。１０行目のレンダリング位置移動命令および１１行目の円弧レンダリング命令によって、座標（１４０．０ｍｍ，８０．０ｍｍ）を中心とし、座標（１４０．０ｍｍ，３０．０ｍｍ）から始まる、角度３６０．０度の円がレンダリングされる。円内部は８行目の命令により赤色・アルファ値０．５で塗りつぶされ、外形線は３行目の命令により青色かつ線幅２ｍｍでレンダリングされる。図５の二つ目の＜ｃｉｒｃｌｅ＞要素および図６のレンダリング結果５０２に相当し、座標指定や長さ指定をユーザ座標系からｍｍに換算している。

１３行目は以降の塗りつぶしに使用する塗りつぶし命令で、オペランドで塗りつぶしの色を緑色・アルファ値０．３、すなわち（Ｒ，Ｇ，Ｂ，Ａ）＝（０．０，１．０，０．０，０．３）に指定している。図５の三つ目の＜ｃｉｒｃｌｅ＞要素のｆｉｌｌおよびｆｉｌｌ−ｏｐａｃｉｔｙ属性に相当し、文字列表記の色指定と数値表記の不透明度からＲＧＢＡ表記に変換している。

１４〜１７行目は円のレンダリングを行なう命令群である。１５行目のレンダリング位置移動命令および１６行目の円弧レンダリング命令によって、座標（１１０．０ｍｍ，１３０．０ｍｍ）を中心とし、座標（１１０．０ｍｍ，８０．０ｍｍ）から始まる、角度３６０．０度の円がレンダリングされる。円内部は１３行目の命令により緑色・アルファ値０．３で塗りつぶされ、外形線は３行目の命令により青色かつ線幅２ｍｍでレンダリングされる。図５の三つ目の＜ｃｉｒｃｌｅ＞要素および図６のレンダリング結果５０３に相当し、座標指定や長さ指定をユーザ座標系からｍｍに換算している。

［レンダラーの動作概要］
次に、図９〜図１０を参照して、レンダラー３１０の動作の概要について説明する。

図９〜図１０はレンダラー３１０が中間コードデータ３０３をレンダリングしてビットマップデータ３０４を作成し、プリンタ３１３のコントローラ３１４に送信する動作を示すフローチャートである。

ステップＳ８０１は動作の開始である。
ステップＳ８０２は変数の初期化処理である。ＳＶＧ文書ファイル３０２を変換した中間コードデータ３０３を変数ｄｌｃに読み込む。ｆｉｌｌはレンダリング命令に適用される塗りつぶしに使用する色を保持する変数で、（ｒ，ｇ，ｂ，ａ）はＲＧＢＡ表記の色の各要素を表わす。初期値は（１．０，１．０，１．０，１．０）、すなわち完全不透明（アルファ値１．０）の白色である。ｓｔｒｏｋｅはレンダリング命令に適用される外形線に使用する色と線幅を保持する変数で、（ｒ，ｇ，ｂ，ｗ）はＲＧＡ表記の色の各要素と線幅（ピクセル）を表わす。初期値は（０．０，０．０，０．０，１）、すなわち黒色・線幅１ピクセルである。

ステップＳ８０３は中間コードデータｄｌｃから次のオペコードとオペランドを取得する処理である。取得したオペコードとオペランドをそれぞれ変数ｏｐとｏｐｅｒａｎｄに格納する。
ステップＳ８０４、Ｓ８０６、Ｓ８０９、Ｓ８１１、Ｓ８１３、Ｓ８１６、Ｓ８２１、Ｓ８２３、Ｓ８２５は、オペコードｏｐの種別を判定し、それぞれのオペコードに応じて適切な処理を行なえるようにしている。

ステップＳ８０４でオペコードｏｐが０（ニーモニックＰａｇｅＳｔａｒｔ）であればステップＳ８０５に進む。それ以外の場合はステップＳ８０６に進む。

ステップＳ８０５はビットマップデータ３０４を格納するための変数ｂｍｐの準備処理である。ここでｂｍｐの要素ｗはビットマップデータの幅（ピクセル）を表わす。オペランドｏｐｅｒａｎｄのページ幅Ｗ（ｍｍ）をビットマップの単位系（ピクセル）に変換するために、出力解像度ｒｅｓを乗算する。ｂｍｐの要素ｈはビットマップデータの高さ（ピクセル）を表わす。オペランドｏｐｅｒａｎｄのページの高さＨ（ｍｍ）をビットマップの単位系（ピクセル）に変換するために、出力解像度ｒｅｓを乗算する。ｂｍｐの要素ｒｅｓはプリンタ３１３の出力解像度をＰＰＭ（Ｐｉｘｅｌｓ Ｐｅｒ Ｍｉｌｌｉｍｅｔｅｒ）で表わす。

ｂｍｐの要素ｄａｔａ［］はビットマップデータを格納する配列で、大きさは横ｗ（ピクセル），縦ｈ（ピクセル）である。ｄａｔａ［］の各要素（ｒ，ｇ，ｂ，ａ）は各ピクセルの色をＲＧＢＡ表記で表わす。ｄａｔａ［］の各要素の値は現在のｆｉｌｌの値、すなわち完全不透明（アルファ値１．０）の白色で初期化される。ｂｍｐの要素ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］はビットマップの各ピクセルに対して、レンダリング前カラーマッチングを行なったか、レンダリング後カラーマッチングを行なったかを格納する配列で、大きさは配列ｄａｔａ［］と同じである。レンダリング前カラーマッチングを行なった場合は値としてｐｒｅを保持し、レンダリング後カラーマッチングを行なった場合は値としてｐｏｓｔを保持する。初期値はｐｏｓｔである。処理が終了すればステップＳ８０３に戻る。

ステップＳ８０６でオペコードｏｐが１（ニーモニックＰａｇｅＥｎｄ）であればステップＳ８０７でプリンタ出力の定義済み処理を呼び出し、ステップＳ８０８で終了する。それ以外の場合はステップＳ８０９に進む。なお、プリンタ出力の定義済み処理については図１４を参照して後述する。

ステップＳ８０９でオペコードｏｐが２（ニーモニックＦｉｌｌ）であればステップＳ８１０に進む。それ以外の場合はステップＳ８１１に進む。

ステップＳ８１０は変数ｆｉｌｌの更新処理である。オペランドｏｐｅｒａｎｄで指定された色（Ｒ，Ｇ，Ｂ，Ａ）を変数ｆｉｌｌの各要素（ｒ，ｇ，ｂ，ａ）に格納する。処理が終了すればステップＳ８０３に戻る。

ステップＳ８１１でオペコードｏｐが３（ニーモニックＳｔｒｏｋｅ）であればステップＳ８１２に進む。それ以外の場合はステップＳ８１３に進む。

ステップＳ８１２は変数ｓｔｒｏｋｅの更新処理である。オペランドｏｐｅｒａｎｄで指定された色（Ｒ，Ｇ，Ｂ）と線幅（Ｗ）を変数ｓｔｒｏｋｅの各要素（ｒ，ｇ，ｂ，ｗ）に格納する。この際、オペランドの単位系（ｍｍ）をビットマップの単位系（ピクセル）に変換するために、出力解像度ｂｍｐ．ｒｅｓを乗算する。処理が終了すればステップＳ８０３に戻る。

ステップＳ８１３でオペコードｏｐが４（ニーモニックＰａｔｈＳｔａｒｔ）であればステップＳ８１４に進む。それ以外の場合はＳ８１５からステップＳ８１６に進む。

ステップＳ８１４はパスレンダリング用の変数ｐａｔｈ［］とｃｕｒｓｏｒの準備処理である。ｐａｔｈ［］はパスの座標値を格納する配列である。ｐａｔｈ［］の各要素（ｘ，ｙ）はピクセル単位で表わした座標値である。ｃｕｒｓｏｒはパスの現在のレンダリング位置を格納する変数で、要素（ｘ，ｙ）は同じくピクセルで表わした座標値である。処理が終了すればステップＳ８０３に戻る。

ステップＳ８１６でオペコードｏｐが５（ニーモニックＰａｔｈＥｎｄ）であればステップＳ８１７に進む。それ以外の場合はステップＳ８２１に進む。

ステップＳ８１７はオペランドｏｐｅｒａｎｄが１かどうかの判定処理である。１であればステップＳ８１８に進み、それ以外の場合はステップＳ８１９に進む。

ステップＳ８１８は閉パスのレンダリング処理である。変数ｄｌｃの現在の読み込み位置に、オペコード７（ニーモニックＰａｔｈＬｉｎｅＴｏ）を挿入する。オペランドは現在のパスの開始位置であるｐａｔｈ［０］であるが、ビットマップの単位系（ピクセル）からオペランドの単位系（ｍｍ）に変換するために、出力解像度ｂｍｐ．ｒｅｓで除算する。また、再度パスの終了処理を行なうため、オペコード５（ニーモニックＰａｔｈＥｎｄ）も挿入する。今度は閉パスのレンダリング処理は必要ないので、オペランドは０とする。処理が終了すればＳ８２７からステップＳ８０３に戻る。

ステップＳ８１９はパスの塗りつぶしが必要かどうかを判定する処理である。パスの現在のレンダリング位置を表わす変数ｃｕｒｓｏｒの値と、パスの開始位置である変数ｐａｔｈ［０］ の値とを比較し、等しければ閉パスなので塗りつぶしが必要であると判定し、ステップＳ８２０に進む。それ以外の場合はＳ８２７からステップＳ８０３に戻る。

ステップＳ８２０はパスの塗りつぶしの定義済み処理を呼び出す処理である。このパスの塗りつぶしの定義済み処理については図１１を参照して後述する。

ステップＳ８２１でオペコードｏｐが６（ニーモニックＰａｔｈＭｏｖｅＴｏ）であればステップＳ８２２に進む。それ以外の場合はステップＳ８２３に進む。

ステップＳ８２２はパスの現在のレンダリング位置を表わす変数の更新処理である。オペランドｏｐｅｒａｎｄで指定された座標値（Ｘ，Ｙ）を変数ｃｕｒｓｏｒの各要素（ｘ，ｙ）に格納する。この際、オペランドの単位系（ｍｍ）をビットマップの単位系（ピクセル）に変換するために、出力解像度ｂｍｐ．ｒｅｓを乗算する。処理が終了すればＳ８２７からステップＳ８０３に戻る。

ステップＳ８２３でオペコードｏｐが７（ニーモニックＰａｔｈＬｉｎｅＴｏ）であればステップＳ８２４に進む。それ以外の場合はステップＳ８２５に進む。

ステップＳ８２４はビットマップデータｂｍｐに直線をレンダリングする処理である。開始点はパスの現在のレンダリング位置であるｃｕｒｓｏｒ（ｘ，ｙ）である。終了点はオペランドｏｐｅｒａｎｄで指定された座標値（Ｘ， Ｙ）であるが、オペランドの単位系（ｍｍ）をビットマップの単位系（ピクセル）に変換するために、出力解像度ｂｍｐ．ｒｅｓを乗算する。外形線は変数ｓｔｒｏｋｅの色（ＲＧＢ）と線幅（ピクセル）を使用する。レンダリングした直線の各座標値（ピクセル）を変数ｐａｔｈ［］ に追加し、最後に追加した座標値（直線終了点）を変数ｃｕｒｓｏｒに格納する。処理が終了すればＳ８２７からステップＳ８０３に戻る。

ステップＳ８２５でオペコードｏｐが８（ニーモニックＰａｔｈＡｒｃＴｏ）であればステップＳ８２６に進む。それ以外の場合は図７に示した中間コード仕様に存在しないので、処理をスキップしてＳ８２７からステップＳ８０３に戻る。

ステップＳ８２６はビットマップデータｂｍｐに円弧をレンダリングする処理である。開始点はパスの現在のレンダリング位置であるｃｕｒｓｏｒ（ｘ，ｙ）である。中心点はオペランドｏｐｅｒａｎｄで指定された座標値（Ｘ， Ｙ）であるが、オペランドの単位系（ｍｍ）をビットマップの単位系（ピクセル）に変換するために、出力解像度ｂｍｐ．ｒｅｓを乗算する。角度はオペランドｏｐｅｒａｎｄで指定された角度Ｄ（°）である。外形線は変数ｓｔｒｏｋｅの色（ＲＧＢ）と線幅（ピクセル）を使用する。レンダリングした円弧の各座標値（ピクセル）を変数ｐａｔｈ［］に追加し、最後に追加した座標値を変数ｃｕｒｓｏｒに格納する。処理が終了すればＳ８２７からステップＳ８０３に戻る。

レンダラー３１０の動作の一例については図８および図１５、図１６を参照して後述する。

［パスの塗りつぶし］
次に、図１１を参照して、パス塗りつぶしの動作について説明する。
図１１は、パスの塗りつぶしを行なう定義済み処理の動作を示すフローチャートである。本定義済み処理は図９に示すフローチャートのステップＳ８２０から呼び出される。

ステップＳ９０１はパス塗りつぶし動作の開始である。ｂｍｐ、ｐａｔｈ、ｆｉｌｌは本定義済み処理呼び出し時の引数である。引数ｂｍｐは、図９〜図１０において、ステップＳ８０５で初期化し、ステップＳ８２０、Ｓ８２４、Ｓ８２６で更新した変数ｂｍｐと同じ値を有する。引数ｐａｔｈは、図９〜図１０において、ステップＳ８１４で初期化し、ステップＳ８２４およびステップＳ８２５で更新した変数ｐａｔｈと同じ値を有する。引数ｆｉｌｌは、図９〜図１０において、ステップＳ８０２で初期化し、ステップＳ８１０で更新した変数ｆｉｌｌと同じ値を有する。

ステップＳ９０２は変数の初期化処理である。ｃｏｏｒｄはビットマップデータｂｍｐ．ｄａｔａ［］を左上から右下に向かってスキャンする際の座標値を保持する変数で、（ｘ，ｙ）はピクセル単位の座標値を表わす。初期値は（０，０）で、ビットマップデータｂｍｐ．ｄａｔａの左上を表わす。図１１に示したフローチャートは変数ｃｏｏｒｄをループ変数とするループ処理になっている。

ステップＳ９０３は変数ｃｏｏｒｄが表わす座標値が変数ｐａｔｈが表わすパス内かどうかを判定する処理である。ステップＳ８１９で変数ｐａｔｈが閉パスと判断された場合のみステップＳ８２０で本処理が呼び出されるので、変数ｐａｔｈが表わすパスは必ず閉パスであり、任意の座標値についてパス内かどうかを判定することができる。パス内と判定された場合はステップＳ９０４に進む。パス内でない場合はステップＳ９０８に進む。

ステップＳ９０４は変数ｆｉｌｌが表わす色のアルファ値が１．０（完全不透明）かどうかを判定する処理である。アルファ値が１．０（完全不透明）であればアルファブレンドは必要ないと判断し、ステップＳ９０５に進む。アルファ値が１．０以外（透明）であればアルファブレンドの必要があると判断し、ステップＳ９０７に進む。

ステップＳ９０５は変数ｆｉｌｌのアルファ値が１．０（完全不透明）の場合の塗りつぶし処理である。アルファブレンドは必要ないので、ビットマップデータｂｍｐ．ｄａｔａ［］の座標位置ｃｏｏｒｄの色を、変数ｆｉｌｌが表わす色で置き換える。

ステップＳ９０６は変数ｆｉｌｌのアルファ値が１．０以外（透明）の場合に、アルファブレンドの定義済み処理を呼び出す処理である。アルファブレンドの定義済み処理は、戻り値として、アルファブレンド後の色（ＲＧＢＡ）と、レンダリング前カラーマッチングを行なったかレンダリング後カラーマッチングを行なったかのフラグ（ｐｒｅまたはｐｏｓｔ）とを返すので、ビットマップデータｂｍｐ．ｄａｔａ［］およびフラグｂｍｐ．ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］の、座標位置ｃｏｏｒｄの値をそれぞれ戻り値で置き換える。アルファブレンドの定義済み処理については図１２〜図１３を参照して後述する。

ステップＳ９０７〜Ｓ９１０はループ処理である。
ステップＳ９０７は変数ｃｏｏｒｄの横方向の値ｃｏｏｒｄ．ｘを１加算する処理である。

ステップＳ９０８は変数ｃｏｏｒｄの横方向の値ｃｏｏｒｄ．ｘがビットマップデータの横方向の大きさｂｍｐ．ｗと等しくなったかどうかの判定処理である。等しければステップＳ９０９に進み、等しくなければステップＳ９０３に戻る。
ステップＳ９０９は、変数ｃｏｏｒｄの横方向の値ｃｏｏｒｄ．ｘを０に初期化し、変数ｃｏｏｒｄの縦方向の値ｃｏｏｒｄ．ｙを１加算する処理である。

ステップＳ９１０は変数ｃｏｏｒｄの縦方向の値ｃｏｏｒｄ．ｙがビットマップデータの縦方向の大きさｂｍｐ．ｈと等しくなったかどうかの判定処理である。等しければステップＳ９１１に進み、等しくなければステップＳ９０３に戻る。
ステップＳ９１１は終了である。本定義済み処理の戻り値はないが、引数ｂｍｐで渡したビットマップデータｂｍｐ．ｄａｔａ［］が更新される。

［アルファブレンド］
次に、図１２〜図１３を参照して、アルファブレンドの動作について説明する。
図１２は、検証結果ＤＢ３１２の構成を示す図である。

１００１は検証結果ＤＢ３１２の各レコードを構成する列を示す。
１００２は各列に格納されるデータを示す。
１００３、１００４の各列はアルファブレンドの対象となる色をＲＧＢＡ表記で格納する。

１００５、１００６、１００７の各列はそれぞれレンダラー３１０がＣＭＭ３１１を利用する際の入力プロファイル３０５、レンダリングプロファイル３０６、プリンタプロファイル３０７、レンダリングインテント３０８を識別するＩＤを格納する。
１００８の列はアルファブレンドの結果の色をＲＧＢＡ表記で格納する。
１００９の列はレンダリング前カラーマッチングを行なったかレンダリング後カラーマッチングを行なったかをｐｒｅまたはｐｏｓｔの値で格納する。

図１３は，アルファブレンドを行なう定義済み処理の動作を示すフローチャートである。
本定義済み処理は図１１に示すフローチャートのステップＳ９０６から呼び出される。本定義済み処理ではＣＭＭ３１１のカラーマッチング機能として、ＣＭＭ．ｇｍ、ＣＭＭ．ｃｃ、ＣＭＭ．ｌａｂの３つの機能を利用する。

ＣＭＭ．ｇｍは色域圧縮（ｇａｍｕｔ ｍａｐｐｉｎｇ）を行なう。引数（ｃｏｌｏｒ、ｐｒｏｆ１、ｐｒｏｆ２、ｉｎｔｅｎｔ）は色指定ｃｏｌｏｒ、プロファイルｐｒｏｆ１、プロファイルｐｒｏｆ２、レンダリングインテントｉｎｔｅｎｔである。機能はｐｒｏｆ１が表現する色域の色ｃｏｌｏｒをｐｒｏｆ２が表現する色域の色にｉｎｔｅｎｔにしたがって圧縮し、ｐｒｏｆ１が表現する色域の色として返す。

ＣＭＭ．ｃｃは色域変換（ｃｏｌｏｒ ｃｏｎｖｅｒｓｉｏｎ）を行なう。引数（ｃｏｌｏｒ、ｐｒｏｆ１、ｐｒｏｆ２）は色指定ｃｏｌｏｒ、プロファイルｐｒｏｆ１、プロファイルｐｒｏｆ２である。機能はｐｒｏｆ１が表現する色域の色ｃｏｌｏｒをｐｒｏｆ２が表現する色域の色に圧縮せずに変換し、ｐｒｏｆ２が表現する色域の色として返す。ｃｏｌｏｒで指定する色はｐｒｏｆ２が表現する色域に収まっていることが前提である。

ＣＭＭ．ｌａｂはＬ＊ａ＊ｂ＊値への変換を行なう。Ｌ＊ａ＊ｂ＊色空間はＣＩＥ（Ｃｏｍｍｉｓｓｉｏｎ Ｉｎｔｅｒｎａｔｉｏｎａｌｅ Ｉ’Ｅｅｌａｉｒａｇｅｌ；国際照明委員会）が１９７６年に定めた均等色空間であり、明度指数Ｌ＊とクロマティクネス指数ａ＊およびｂ＊で表わす。引数（ｃｏｌｏｒ、ｐｒｏｆ）は色指定ｃｏｌｏｒとプロファイルｐｒｏｆである。機能はｐｒｏｆが表現する色域の色ｃｏｌｏｒをＬ＊ａ＊ｂ＊値に変換して返す。

ステップＳ１１０１はアルファブレンドの開始である。ｃｏｌｏｒ１、ｃｏｌｏｒ２は本定義済み処理呼び出し時の引数である。引数ｃｏｌｏｒ１は、図９〜図１０のステップ８０５で初期化し、図１１のステップＳ９０５、ステップＳ９０６その他で更新したビットマップデータｂｍｐ．ｄａｔａ［］ の任意の座標における色の値である。引数ｃｏｌｏｒ２は、図９〜図１０のステップＳ８０２で初期化し、ステップＳ８１０で更新した変数ｆｉｌｌの色の値である。

ステップＳ１１０２は変数の初期化処理である。ｒｅｔｕｒｎは戻り値を保持する変数で、要素（ｒ、ｇ、ｂ、ａ）はＲＧＢＡ表記の色の各要素を表わす。要素ｐｒｅ＿ｏｒ＿ｐｏｓｔはレンダリング前カラーマッチングを行なったか、レンダリング後カラーマッチングを行なったかを保持する変数で、値としてｐｒｅまたはｐｏｓｔを保持する。ｉｎｐｕｔＰｒｏｆは入力プロファイル３０５の内容を保持する変数である。ｐｒｉｎｔｅｒＰｒｏｆはプリンタプロファイル３０７の内容を保持する変数である。ｉｎｔｅｎｔはレンダリングインテント３０８の内容を保持する変数である。

ステップＳ１１０３は検証結果ＤＢ３１２に検証結果が登録されているかどうかを検索する処理である。図１２に構成を示した検証結果ＤＢに対して、変数ｃｏｌｏｒ１、変数ｃｏｌｏｒ２、変数ｉｎｐｕｔＰｒｏｆ、変数ｐｒｉｎｔｅｒＰｒｏｆ、変数ｉｎｔｅｎｔを引数として登録レコードを検索する。ｃｏｌｏｒ１が列１００３、ｃｏｌｏｒ２が列１００４、ｉｎｐｕｔＰｒｏｆが列１００５、ｐｒｉｎｔｅｒＰｒｏｆが列１００６、ｉｎｔｅｎｔが列１００７にそれぞれ一致するレコードが見つかると、見つかったレコードの列１００８の値と列１００９の値をそれぞれ変数ｒｅｔｕｒｎの（ｒ、ｇ、ｂ、ａ）と（ｐｒｅ＿ｏｒ＿ｐｏｓｔ）に格納する。ステップＳ１１０３ではレコードが見つかったかどうかを判定し、見つかった場合はそのままステップＳ１１１２に進んで処理を終了する。見つからなかった場合はステップＳ１１０４に進む。

ステップＳ１１０４はレンダリング前カラーマッチングを行なった場合のＬ＊ａ＊ｂ＊値を求める処理である。まず、ＣＭＭ３１１のＣＭＭ．ｇｍ機能を利用して、引数ｃｏｌｏｒ１の値と引数ｃｏｌｏｒ２の値を入力色域（ｉｎｐｕｔＰｒｏｆが表現）からプリンタ３１３の色域（ｐｒｉｎｔｅｒＰｒｏｆが表現）にレンダリングインテントｉｎｔｅｎｔで圧縮し、結果をそれぞれ変数ｐｒｅＩｎｐｕｔ１とｐｒｅＩｎｐｕｔ２に格納する。次に、変数ｐｒｅＩｎｐｕｔ１の値と変数ｐｒｅＩｎｐｕｔ２の値とでブレンド処理を行ない、結果を変数ｐｒｅＲｅｎｄｅｒに格納する。ブレンド処理は、ｐｒｅＩｎｐｕｔ１の値（ｒ、ｇ、ｂ、ａ）とｐｒｅＩｎｐｕｔ２の値（ｒ、ｇ、ｂ、ａ）とから、以下の式により計算される。

preRender.r＝preInput1.r×preInput1.a＋preInput2.r×preInput2.a×（1−preInput1.a）
preRender.g＝preInput1.g×preInput1.a＋preInput2.g×preInput2.a×（1−preInput1.a）
preRender.b＝preInput1.b×preInput1.a＋preInput2.b×preInput2.a×（1−preInput1.a）
preRender.a＝preInput1.a＋preInput2.a×（1−preInput1.a）

最後に、ＣＭＭ３１１のＣＭＭ．ｃｃ機能を利用して、ブレンド結果ｐｒｅＲｅｎｄｅｒの値を入力色域（ｉｎｐｕｔＰｒｏｆが表現）からプリンタ３１３の色域（ｐｒｉｎｔｅｒＰｒｏｆが表現）に変換して変数ｐｒｅＰｒｉｎｔｅｒに格納し、ＣＭＭ ３１１のＣＭＭ．ｌａｂ機能を利用して、ｐｒｅＰｒｉｎｔｅｒの値をＬ＊ａ＊ｂ＊値に変換して変数ｐｒｅＬａｂに格納する。

ステップＳ１０５はレンダリング後カラーマッチングを行なった場合のＬ＊ａ＊ｂ＊値を求める処理である。まず、引数ｃｏｌｏｒ１の値と引数ｃｏｌｏｒ２の値とでブレンド処理を行ない、結果を変数ｐｏｓｔＲｅｎｄｅｒに格納する。ブレンド処理は、ステップＳ１１０４と同様に、ｃｏｌｏｒ１の値（ｒ、ｇ、ｂ、ａ）とｃｏｌｏｒ２の値（ｒ、ｇ、ｂ、ａ）とから、以下の式により計算される。

preRender.r＝color1.r×color1.a＋color2.r×color2.a×（1−color1.a）
preRender.g＝color1.g×color1.a＋color2.g×color2.a×（1−color1.a）
preRender.b＝color1.b×color1.a＋color2.b×color2.a×（1−color1.a）
preRender.a＝color1.a＋color2.a×（1−color1.a）

次に、ＣＭＭ３１１のＣＭＭ．ｇｍ機能を利用して、ブレンド結果ｐｒｅＲｅｎｄｅｒの値を入力色域（ｉｎｐｕｔＰｒｏｆが表現）からプリンタ３１３の色域（ｐｒｉｎｔｅｒＰｒｏｆが表現）に、レンダリングインテントｉｎｔｅｎｔで圧縮し、結果を変数ｐｏｓｔＩｎｐｕｔに格納する。最後に、ＣＭＭ３１１のＣＭＭ．ｃｃ機能を利用して、ブレンド結果ｐｏｓｔＩｎｐｕｔの値を入力色域（ｉｎｐｕｔＰｒｏｆが表現）からプリンタ３１３の色域（ｐｒｉｎｔｅｒＰｒｏｆが表現）に変換して変数ｐｏｓｔＰｒｉｎｔｅｒに格納し、ＣＭＭ３１１のＣＭＭ．ｌａｂ機能を利用して、ｐｏｓｔＰｒｉｎｔｅｒの値をＬ＊ａ＊ｂ＊値に変換して変数ｐｏｓｔＬａｂに格納する。

ステップＳ１１０６は入力色域（ｉｎｐｕｔＰｒｏｆが表現）における理論的なＬ＊ａ＊ｂ＊値を求める処理である。まず、引数ｃｏｌｏｒ１の値と引数ｃｏｌｏｒ２の値とでブレンド処理を行ない、結果を変数ｔＲｅｎｄｅｒに格納する。ブレンド処理はステップＳ１１０５と同じである。次に、ＣＭＭ３１１のＣＭＭ．ｌａｂ機能を利用して、ブレンド結果ｔＲｅｎｄｅｒの値をＬ＊ａ＊ｂ＊値に変換して変数ｔＬａｂに格納する。

ステップＳ１１０７はＬ＊ａ＊ｂ＊値ｐｒｅＬａｂとｔＬａｂ、ｐｏｓｔＬａｂとｔＬａｂのＣＩＥ Ｌ＊ａ＊ｂ＊色差（ＣＩＥ １９７６）を求める処理である。ｐｒｅＬａｂとｔＬａｂの色差ΔＥ_preおよびｐｏｓｔＬａｂとｔＬａｂの色差ΔＥ_postは、ｐｒｅＬａｂの値（Ｌ＊、ａ＊、ｂ＊）、ｐｏｓｔＬａｂの値（Ｌ＊、ａ＊、ｂ＊）、ｔＬａｂの値（Ｌ＊、ａ＊、ｂ＊）から、以下の式により計算される。

ΔE_pre ²＝（preLab.L*−tLab.L*）²＋（preLab.L*−tLab.L*）²＋（preLab.L*−tLab.L*）²
ΔE_post ²＝（postLab.L*−tLab.L*）²＋（postLab.L*−tLab.L*）²＋（postLab.L*−tLab.L*）²

計算結果をそれぞれ変数ｄｅｌｔａＥ＿ｐｒｅとｄｅｌｔａＥ＿ｐｏｓｔに格納する。
ステップＳ１１０８は色差ｄｅｌｔａＥ＿ｐｒｅとｄｅｌｔａＥ＿ｐｏｓｔを比較する処理である。変数ｄｅｌｔａＥ＿ｐｒｅの値の方が小さければステップＳ１１０９に進み、それ以外の場合はステップＳ１１１０に進む。

ステップＳ１１０９はレンダリング前カラーマッチングを行なった方が理論値に近かった場合（すなわち、ステップＳ１１０８における比較によりｄｅｌｔａＥ＿ｐｒｅ＜ｄｅｌｔａＥ＿ｐｏｓｔの場合）の処理である。変数ｒｅｔｕｒｎの（ｒ、ｇ、ｂ、ａ）に入力色域（ｉｎｐｕｔＰｒｏｆが表現）におけるレンダリング結果を保持するｐｒｅＲｅｎｄｅｒの値を格納し、変数ｒｅｔｕｒｎの（ｐｒｅ＿ｏｒ＿ｐｏｓｔ）には値ｐｒｅを格納する。

ステップＳ１１１０はレンダリング後カラーマッチングを行なった方が理論値に近かった場合（すなわち、ステップＳ１１０８における比較によりｄｅｌｔａＥ＿ｐｒｅ≧ｄｅｌｔａＥ＿ｐｏｓｔの場合）の処理である。変数ｒｅｔｕｒｎの（ｒ、ｇ、ｂ、ａ）に入力色域（ｉｎｐｕｔＰｒｏｆが表現）におけるレンダリング結果を保持するｐｏｓｔＲｅｎｄｅｒの値を格納し、変数ｒｅｔｕｒｎの（ｐｒｅ＿ｏｒ＿ｐｏｓｔ）には値ｐｏｓｔを格納する。

ステップＳ１１１１は検証結果ＤＢ３１２に検証結果を登録する処理である。図１２に構成を示した検証結果ＤＢに対して、変数ｃｏｌｏｒ１、変数ｃｏｌｏｒ２、変数ｉｎｐｕｔＰｒｏｆ、変数ｐｒｉｎｔｅｒＰｒｏｆ、変数ｉｎｔｅｎｔ、変数ｒｅｔｕｒｎを引数としてレコードを登録する。ｃｏｌｏｒ１が列１００３、ｃｏｌｏｒ２が列１００４、ｉｎｐｕｔＰｒｏｆが列１００５、ｐｒｉｎｔｅｒＰｒｏｆが列１００６、ｉｎｔｅｎｔが列１００７、ｒｅｔｕｒｎ（ｒ、ｇ、ｂ、ａ）が列１００８、ｒｅｔｕｒｎ（ｐｒｅ＿ｏｒ＿ｐｏｓｔ）が列１００９に、それぞれ登録される。

ステップＳ１１１２は終了である。変数ｒｅｔｕｒｎの値を戻り値として返す。

［プリンタ出力］
次に、図１４を参照して、プリンタ出力の動作について説明する。
図１４は、プリンタ出力を行なう定義済み処理の動作を示すフローチャートである。本定義済み処理は図９に示すフローチャートのステップＳ８０７から呼び出される。

ステップＳ１２０１は本定義済み処理の開始である。引数ｂｍｐは図９〜図１０において、ステップＳ８０５で初期化し、ステップＳ８２０、Ｓ８２４、Ｓ８２６でレンダリングされた変数ｂｍｐと同じ値を有する。

ステップＳ１２０２は変数の初期化処理である。ｃｏｏｒｄはビットマップデータｂｍｐ．ｄａｔａを左上から右下に向かってスキャンする際の座標値を保持する変数で、（ｘ、ｙ）はピクセル単位の座標値を表わす。図１４に示したフローチャートは主に変数ｃｏｏｒｄをループ変数とするループ処理で構成される。ｉｎｐｕｔＰｒｏｆは入力プロファイル３０５の内容を保持する変数である。ｐｒｉｎｔｅｒＰｒｏｆはプリンタプロファイル３０７の内容を保持する変数である。ｉｎｔｅｎｔはレンダリングインテント３０８の内容を保持する変数である。ｏｕｔｐｕｔｂｍｐ［］はプリンタ出力用のビットマップデータを保持する配列で、大きさはｂｍｐ．ｄａｔａ［］と同じである。

ステップＳ１２０３は変数ｃｏｏｒｄが指す座標値のビットマップデータとｐｒｅまたはｐｏｓｔの値をｂｍｐ．ｄａｔａ［］とｂｍｐ．ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］から取得する処理である。取得した値をそれぞれ変数ｄａｔａとｐｒｅ＿ｏｒ＿ｐｏｓｔに格納する。

ステップＳ１２０４は変数ｐｒｅ＿ｏｒ＿ｐｏｓｔが値ｐｒｅかどうかの判定処理である。変数ｂｍｐ．ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］は、ステップＳ８０５で値ｐｏｓｔに初期化された後、該ピクセルにアルファブレンドレンダリングが行なわれた場合はステップＳ９０６で値ｐｒｅまたはｐｏｓｔが格納され、それ以外のレンダリングの場合は何も値が格納されない。このため、ここで判定が真になるのは、該ピクセルにレンダリング前カラーマッチングでアルファブレンドレンダリングが行なわれた場合に限られる。その場合はステップＳ１２０６に進む。それ以外の場合はステップＳ１２０５に進む。

ステップＳ１２０５はＣＭＭ３１１のＣＭＭ．ｇｍ機能を利用して、ピクセルデータを入力色域（ｉｎｐｕｔＰｒｏｆが表現）からプリンタ３１３の色域（ｐｒｉｎｔｅｒＰｒｏｆが表現）にレンダリングインテントｉｎｔｅｎｔで圧縮する処理である。結果は変数ｄａｔａに上書きする。

ステップＳ１２０６では、変数ｄａｔａの色値はすでにプリンタ３１３の色域（ｐｒｉｎｔｅｒＰｒｏｆが表現）に圧縮されているので、ＣＭＭ３１１のＣＭＭ．ｃｃ機能を利用して、入力色域（ｉｎｐｕｔＰｒｏｆが表現）からプリンタ３１３の色域（ｐｒｉｎｔｅｒＰｒｏｆが表現）に変換する処理である。結果はプリンタ出力用ビットマップデータｏｕｔｐｕｔｂｍｐ［］の変数ｃｏｏｒｄが指す座標位置に格納する。

ステップＳ１２０７〜Ｓ１２１０はループ処理である。
ステップＳ１２０７は変数ｃｏｏｒｄの横方向の値ｃｏｏｒｄ．ｘを１加算する処理である。
ステップＳ１２０８は変数ｃｏｏｒｄの横方向の値ｃｏｏｒｄ．ｘがビットマップデータの横方向の大きさｂｍｐ．ｗと等しくなったかどうかの判定処理である。等しければステップＳ１２０９に進み、等しくなければステップＳ１２０３に戻る。

ステップＳ１２０９は変数ｃｏｏｒｄの縦方向の値ｃｏｏｒｄ．ｙを１加算する処理である。
ステップＳ１２１０は変数ｃｏｏｒｄの縦方向の値ｃｏｏｒｄ．ｙがビットマップデータの縦方向の大きさｂｍｐ．ｈと等しくなったかどうかの判定処理である。等しければステップＳ１２１１に進み、等しくなければステップＳ１２０３に戻る。

ステップＳ１２１１はプリンタ出力用ビットマップデータｏｕｔｐｕｔｂｍｐ［］を作成し終わったので、プリンタ３１３のコントローラ３１４に送信する処理である。プリンタ３１３は受信したビットマップデータをＲＡＭ２０９にビットマップデータ３１５として格納し、プリンタエンジン２１２をビットマップデータ３１５にしたがって制御して出力を行なう。
ステップＳ１２１２は終了である。戻り値はない。

［レンダラーの動作例］
最後に、図１５〜図１６を参照して、レンダラー３１０の動作の一例について、図８に示した中間コードデータを使用して説明する。
図１５〜図１６は、レンダラー３１０が図８に示した中間コードデータを図９〜図１０、図１１、図１３に示したフローチャートにしたがってレンダリングする様子を示した図である。

中間コードデータはステップＳ８０２で変数ｄｌｃに読み込まれる。変数ｆｉｌｌはｆｉｌｌ（ｒ、ｇ、ｂ、ａ）＝（１．０、１．０、１．０、１．０）で初期化される。変数ｓｔｒｏｋｅはｓｔｒｏｋｅ（ｒ、ｇ、ｂ、ｗ）＝（０．０、０．０、０．０、１）で初期化される。

ｄｌｃの１つ目のオペコード（ＰａｇｅＳｔａｒｔ）では、ステップＳ８０４〜Ｓ８０５で変数ｂｍｐが初期化される。ここではプリンタの解像度を３００ＤＰＩ（Ｄｏｔｓ Ｐｅｒ Ｉｎｃｈ）とすると、１インチ＝２５．４ｍｍとして、１１．８１１ ＰＰＭとなるので、ｂｍｐ．ｗ＝２１０．０×１１．８１１＝２４８０．３１≒２４８０（小数点以下切り捨て）、ｂｍｐ．ｈ＝２９７．０×１１．８１１＝３５０７．８６７≒３５０７（小数点以下切り捨て）、ｂｍｐ．ｒｅｓ＝１１．８１１（ＰＰＭ）となる。また、ｂｍｐ．ｄａｔａ［］とｂｍｐ．ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］の両配列の大きさは２４８０×３５０７＝８４４４８５６となる。ｂｍｐ．ｄａｔａ［］はステップＳ８０２で初期化されたｆｉｌｌ（ｒ、ｇ、ｂ、ａ）＝（１．０、１．０、１．０、１．０）で初期化される。ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］ はｐｏｓｔで初期化される。

ｄｌｃの２つ目のオペコード（Ｆｉｌｌ）では、ステップＳ８０９〜Ｓ８１０で変数ｆｉｌｌが更新される。ここではｆｌｌｌ（ｒ、ｇ、ｂ、ａ）＝（１．０、１．０、０．０、０．７）となる。

ｄｌｃの３つ目のオペコード（Ｓｔｒｏｋｅ）では、ステップＳ８１１〜Ｓ８１２で変数ｓｔｒｏｋｅが更新される。ここで、線幅にはオペランドの２．０に解像度ｂｍｐ.ｒｅｓを乗算するので、２．０×１１．８１１＝２３．６２２≒２３（小数点以下切り捨て）となり、ｓｔｒｏｋｅ（ｒ、ｇ、ｂ、ｗ）＝（０．０、０．０、１．０、２３）となる。

ｄｌｃの４つ目のオペコード（ＰａｔｈＳｔａｒｔ）では、ステップＳ８１３〜Ｓ８１４で変数ｐａｔｈ［］とｃｕｒｓｏｒが初期化される。ここではオペランドに依存した処理は行なわれないので、ｃｕｒｓｏｒ（ｘ、ｙ）＝（０、０）である。

ｄｌｃの５つ目のオペコード（ＰａｔｈＭｏｖｅＴｏ）では、ステップＳ８２１〜Ｓ８２２で変数ｃｕｒｓｏｒが更新される。座標値には解像度ｂｍｐ．ｒｅｓを乗算するので、ｃｕｒｓｏｒ．ｘ＝８０．０×１１．８１１＝９４４．８８≒９４４（小数点以下切り捨て）、ｃｕｒｓｏｒ．ｙ＝３０．０×１１．８１１＝３５４．３３≒３５４（小数点以下切り捨て）となる。

ｄｌｃの６つ目のオペコード（ＰａｔｈＡｒｃ）では、円弧１３０１がレンダリングされる。開始点１３０２は変数ｃｕｒｓｏｒの現在の値である（９４４、３５４）である。中心点１３０３はオペランドの（８０．０、８０．０）に解像度ｂｍｐ．ｒｅｓを乗算するので、８０．０×１１．８１１＝９４４．８８≒９４４（小数点以下切り捨て）より（９４４、 ９４４）となり、角度はオペランドにより３６０°となる。外形線は変数ｓｔｒｏｋｅの現在の値である青色、線幅２３ピクセルである。開始点１３０２から時計回りに１３０１に沿って開始点１３０２に戻る外形線の各座標が変数ｐａｔｈ［］に追加される。

ｄｌｃの７つ目のオペコード（ＰａｔｈＥｎｄ）では、オペランドが１ではないことからステップＳ８１８の処理は行なわれないが、ｐａｔｈ［］に保持されている開始点と終了点がともに１３０２に示す（９４４、３５４）であることからステップＳ８１９で閉パスと判定され、ステップＳ８２０でパス塗りつぶし定義済み処理（図１１）が呼び出される。

このパス塗りつぶし処理ではビットマップデータの各ピクセル座標がｐａｔｈ［］ 内部かどうかを判定し、ｐａｔｈ［］ 内部ならばｆｉｌｌで塗りつぶす処理が行なわれる。すなわち、外形線１３０１の内部の点について、変数ｆｉｌｌの現在の値である（ｒ、ｇ、ｂ、ａ）＝（１．０、１．０、０．０、０．７）で塗りつぶされる。アルファ値が１．０ではないのでステップＳ９０６でアルファブレンド定義済み処理（図１３）が呼び出される。

ステップＳ１１０３で検証結果ＤＢにレコードが見つからなかったとすると、ステップＳ１１０４〜Ｓ１１１１のアルファブレンド処理が行なわれる。ここではｂｍｐ．ｄａｔａ［］ の初期化値（１．０、１．０、１．０、１．０）とｆｉｌｌ（１．０、１．０、０．０、０．７）でブレンド処理が行なわれる。ブレンド前カラーマッチングかブレンド後カラーマッチングのどちらが選択されるかは入力プロファイル３０５、プリンタプロファイル３０７、レンダリングインテント３０８の内容に依存するが、ここではレンダリング前カラーマッチングが選択されたとする。また、ブレンド結果については、外形線１３０１の内部の点について、ビットマップデータｂｍｐ．ｄａｔａ［］の値が（０．９、０．２、０．２、１．０）、ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］の値がｐｒｅになったとする。この時点での様子を図１５に示す。

ｄｌｃの８つ目のオペコード（Ｆｉｌｌ）では、ステップＳ８０９〜Ｓ８１０で変数ｆｉｌｌが更新される。ここではｆｌｌｌ（ｒ、ｇ、ｂ、ａ）＝（１．０、０．０、０．０、０５）となる。

ｄｌｃの９つ目のオペコード（ＰａｔｈＳｔａｒｔ）では、ステップＳ８１３〜Ｓ８１４で変数ｐａｔｈ［］とｃｕｒｓｏｒが初期化される。ここではオペランドに依存した処理は行なわれないので、ｃｕｒｓｏｒ（ｘ、ｙ）＝（０、０）である。

ｄｌｃの１０個めのオペコード（ＰａｔｈＭｏｖｅＴｏ）では、ステップＳ８２１〜Ｓ８２２で変数ｃｕｒｓｏｒが更新される。座標値には解像度ｂｍｐ．ｒｅｓを乗算するので、ｃｕｒｓｏｒ．ｘ＝１４０．０×１１．８１１＝１６５３．５４≒１６５３（小数点以下切り捨て）、ｃｕｒｓｏｒ．ｙ＝３０．０×１１．８１１＝３５４．３３≒３５４（小数点以下切り捨て）となる。

ｄｌｃの１１個めのオペコード（ＰａｔｈＡｒｃ）では、円弧１３０４がレンダリングされる。開始点１３０５は変数ｃｕｒｓｏｒの現在の値である（１６５３、３５４）である。中心点１３０６はオペランドの（１４．０、 ８０．０）に解像度ｂｍｐ．ｒｅｓを乗算するので、１４０．０×１１．８１１＝１６５３．５４≒１６５３（小数点以下切り捨て）、８０．０×１１．８１１＝９４４．８８≒９４４（小数点以下切り捨て）より（１６５３、 ９４４）となり、角度はオペランドにより３６０°となる。外形線は変数ｓｔｒｏｋｅの現在の値である青色、線幅２３ピクセルである。開始点１３０５から時計回りに１３０４に沿って開始点１３０５に戻る外形線の各座標が変数ｐａｔｈ［］に追加される。

ｄｌｃの１２個目のオペコード（ＰａｔｈＥｎｄ）では、オペランドが１ではないことからステップＳ８１８の処理は行なわれないが、ｐａｔｈ［］に保持されている開始点と終了点がともに１３０５に示す（１６５３、３５４）であることからステップＳ８１９で閉パスと判定され、ステップＳ８２０でパス塗りつぶし定義済み処理（図１１）が呼び出される。

このパス塗りつぶし処理ではビットマップデータの各ピクセル座標がｐａｔｈ［］内部かどうかを判定し、ｐａｔｈ［］内部ならばｆｉｌｌで塗りつぶす処理が行なわれる。すなわち、外形線１３０４の内部の点について、変数ｆｉｌｌの現在の値である（ｒ、ｇ、ｂ、ａ）＝（１．０、０．０、０．０、０５）で塗りつぶされる。アルファ値が１．０ではないのでステップＳ９０６でアルファブレンド定義済み処理（図１３）が呼び出される。

ここでもステップＳ１１０３で検証結果ＤＢにレコードが見つからなかったとすると、Ｓ１１０４〜Ｓ１１１１のアルファブレンド処理が行なわれる。円弧１３０１の外形線と重なっている領域１３０８についてはｂｍｐ．ｄａｔａ［］の値（０．０、０．０、１．０、１．０）とｆｉｌｌ（１．０、０．０、０．０、０．５）でブレンド処理が行なわれる。円弧１３０１の内部と重なっている領域１３０７についてはｂｍｐ．ｄａｔａ［］の値（０．９、０．２、０．２、１．０）とｆｉｌｌ（１．０、０．０、０．０、０．５）でブレンド処理が行なわれる。

それ以外の領域１３０６についてはｂｍｐ．ｄａｔａ［］の初期化値（１．０、１．０、１．０、１．０）とｆｉｌｌ（１．０、０．０、０．０、０．７）でブレンド処理が行なわれる。ブレンド前カラーマッチングかブレンド後カラーマッチングのどちらが選択されるかは入力プロファイル３０５、プリンタプロファイル３０７、レンダリングインテント３０８の内容に依存するが、ここではすべてレンダリング後カラーマッチングが選択されたとする。

ブレンド結果については、円弧１３０１の外形線と重なっている領域１３０８についてビットマップデータｂｍｐ．ｄａｔａ［］の値が（０．５、０．０、０．５、１．０）、円弧１３０１の内部と重なっている領域１３０７についてビットマップデータｂｍｐ．ｄａｔａ［］の値が（０．９５、０．１、０．１、１．０）、それ以外の領域についてはｂｍｐ．ｄａｔａ［］の値が（１．０、０．５、０．５、 １．０）となる。ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］の値はすべてｐｏｓｔである。この時点での様子を図１６に示す。
以降、ｄｌｃの１３個目〜１７個めのオペコードについても同様の処理が行なわれる。

１８個めのオペコード（ＰａｇｅＥｎｄ）では、ステップＳ８０７でプリンタ出力定義済み処理（図１４）が呼び出される。

この時点でｂｍｐ．ｐｒｅ＿ｏｒ＿ｐｏｓｔ［］の値がｐｒｅであるピクセル、たとえば円弧１３０１内部で他の円弧と重なっていない領域については、ステップＳ１２０５でプリンタの色域に圧縮が行なわれる。次に、すべてのピクセルについてステップＳ１２０６でプリンタの色域に変換が行なわれる。こうして用意されたプリンタ出力用ビットマップがステップＳ１２１１でプリンタ３１３のコントローラ３１４に送信され、最終的な出力を得る。

[その他の実施形態]
上記実施形態では中間コードデータをクライアント１０１でレンダリングしたが、クライアント１０１からプリンタ１０３に中間コードデータを送信することで、レンダリングはプリンタ１０３で行なうようにしてもよい。

また上記実施形態では入力プロファイル３０５が表現する入力色域（カラースペース）でレンダリングを行なったが、レンダリングプロファイル３０６が表現するレンダリング色域（カラースペース）でレンダリングしてもよいし、プリンタプロファイル３０７が表現するプリンタ色域（カラースペース）でレンダリングするようにしてもよい。

また上記実施形態ではＰＤＬとしてＳＶＧ １．１を使用したが、もちろんこれに限るものではなく、ＳＶＧのその他のバージョン、あるいは前述の中間コードに変換可能なものであれば任意のＰＤＬを使用することが可能である。

また上記実施形態では１ページの表示・印刷を行なう例を示したが、ＰＤＬが複数ページに対応するものであれば、中間コード、ビューワプログラム、コントローラをそれに対応させてもよい。

また上記実施形態ではＳＶＧ文書につき一つの入力プロファイルとレンダリングインテントを使用したが、ＳＶＧ文書内に存在するオブジェクトの種類ごと、たとえばイメージ、グラフィックス、テキストオブジェクトごとに入力プロファイルとレンダリングインテントを指定できるようにしてもよい。さらに、個々のオブジェクトごとに入力プロファイルとレンダリングインテントを指定できるようにするシステムも考えられる。

また図１においてＰＣとプリンタはネットワーク接続されるとしたが、これ以外の接続形態であってもよく、たとえばＰＣとプリンタが直接接続されていても、あるいはメモリカードやＣＤなどのメディアを通じてデータを受け渡しするような形態であっても、本発明の実施を妨げるものではない。

また図２においてプログラムはＲＡＭ ２０２に格納されるとしたが、これに限るものではなく、他の実施形態においてはプログラムを外部記憶装置２０４から読み込んで実行するようにしてもよいし、ネットワークインタフェース２０３を介して受信して実行するようにしてもよい。また、図２には示していないが、ＲＯＭ等の読み出し専用の内部記憶部から読み込んで実行するようにしてもよい。また、キーボード２０６やポインティングデバイス２０７の代わりに、あるいはそれらに加えて、音声入力等の他の入力装置を備えることもできる。また、ディスプレイ２０５、キーボード２０６、ポインティングデバイス２０７を他のコンピュータ装置と共有する場合も考えられる。

また図４において中間コードデータ３０３、ビットマップデータ３０４、３１５をＲＡＭに保持したが、これ以外に、ファイルやデータベースその他の永続記憶に保存してもよい。また、同じＰＤＬ文書に対する中間コードデータはキャッシュしておいて、次回以降の処理に利用する形態も考えられる。

また図７において中間コードの仕様を示したが、使用可能な中間コードはこの仕様に限定されるものではない。たとえば単位系はｍｍ以外の任意の単位系またはその組み合わせであってもよい。パスにはベジエ曲線、楕円弧、その他の数学的に表現可能な任意のパスを記述できるようにしてもよい。Ｆｉｌｌは単色ではなくブラシ、イメージ、グラデーション等の複雑な塗りを行なえるようにしてもよい。色はＲＧＢ、ＲＧＢＡ以外にカラープロファイルによる指定、デバイスカラーによる指定、特色の指定なども行なえるようにしてもよい。また、オペコードとして１バイト整数、オペランドとして２バイト浮動小数点数を使うことも単なる一例であって、他のエンコード方法を使用しても構わない。あるいは、中間コードをプリンタ１０３に送信する形態においては、プリンタ１０３が解釈可能なＰＤＬを用いても構わない。

また図１１において汎用的アルゴリズムを使用してビットマップ全体をスキャンし、各座標が引数ｐａｔｈが表現するパスに含まれるかどうかを判定したが、これ以外に、引数ｐａｔｈが表現するパスに含まれる座標をあらかじめ抽出し、それらの座標に対してレンダリングを行なう方法も考えられる。

また図１３において色差としてＣＩＥ Ｌ＊ａ＊ｂ＊色差（ＣＩＥ １９７６）を使用したが、それ以外の色差、たとえばＣＩＥ ΔＥ₉₄（ＣＩＥ １９９４）やＣＩＥ ΔＥ₂₀₀₀（ＣＩＥ ２０００）等を用いてもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータがその供給されたプログラムコードを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。

従って、本発明の機能処理をコンピュータで実現するために、そのコンピュータにインストールされるプログラムコード自体およびそのプログラムを格納した記憶媒体も本発明を構成することになる。つまり、本発明の特許請求の範囲には、本発明の機能処理を実現するためのコンピュータプログラム自体、およびそのプログラムを格納した記憶媒体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、そのホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷｅｂサーバも、本発明の請求の範囲に含まれるものである。

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

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

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

本発明に係る一実施形態の概略構成を示す図である。 同実施形態におけるコンピュータ装置の構成を示す図である。 同実施形態におけるプリンタ装置の構成を示す図である。 同実施形態の全体構成を示すブロック図である。 同実施形態で使用するＳＶＧ文書ファイルの内容を示す図である。 同実施形態で使用するＳＶＧ文書ファイルのレンダリング例である。 同実施形態で使用する中間コード仕様を示す図である。 同実施形態で使用するＳＶＧ文書ファイルを変換した中間コードのダンプ表示例である。 同実施形態におけるレンダラーの動作を示すフローチャート（１）である。 同実施形態におけるレンダラーの動作を示すフローチャート（２）である。 同実施形態におけるパス塗りつぶし動作（定義済み処理）を示すフローチャートである。 同実施形態における検証結果ＤＢの構成例を示す図である。 同実施形態におけるアルファブレンド動作（定義済み処理）を示すフローチャートである。 同実施形態におけるプリンタ出力準備動作を示すフローチャートである。 同実施形態におけるレンダラーがレンダリングしたビットマップ例（１）である。 同実施形態におけるレンダラーがレンダリングしたビットマップ例（２）である。

符号の説明

１０１…クライアント
１０２…プリンタ
１０３…ネットワーク
２０１…ＣＰＵ
２０２…ＲＡＭ
２０３…ネットワークインタフェース
２０４…外部記憶装置
２０５…ディスプレイ
２０６…キーボード
２０７…ポインティングデバイス
２０８…ＣＰＵ
２０９…ＲＡＭ
２１０…ネットワークインタフェース
２１１…外部記憶装置
２１２…プリンタエンジン

Claims (11)

1. 記述言語文書をレンダリングするレンダリング手段と、
   前記記述言語文書で指定された色情報を、前記記述言語文書を印刷する印刷デバイス用の色情報に変換するカラーマッチング手段と、
   前記記述言語文書でアルファブレンドレンダリングが必要な場合、前記カラーマッチング手段による前記変換を前記レンダリング前に行なうか前記レンダリング後に行なうかを判断し、該判断結果によりいずれかを選択する選択手段と、を備えることを特徴とする印刷装置。
2. 前記選択手段による選択は、前記カラーマッチング手段による前記変換を、前記レンダリング前に行なった場合と前記レンダリング後に行なった場合の結果を検証し、前記選択をすることを特徴とする請求項１に記載の印刷装置。
3. 前記選択手段における選択に使用した条件と選択結果とを保持しておく保持手段と、
   次回以降のアルファブレンドレンダリングの際、前記保持手段で保持した情報を利用する利用手段と、をさらに備えることを特徴とする請求項１または請求項２に記載の印刷装置。
4. 記述言語文書をレンダリングするレンダリングステップと、
   前記記述言語文書で指定された色情報を、前記記述言語文書を印刷する印刷デバイス用の色情報に変換するカラーマッチングステップと、
   前記記述言語文書でアルファブレンドレンダリングが必要な場合、前記カラーマッチングステップによる前記変換を前記レンダリング前に行なうか前記レンダリング後に行なうかを判断し、該判断結果によりいずれかを選択する選択ステップと、を備えることを特徴とする印刷装置の制御方法。
5. 前記選択ステップによる選択は、前記カラーマッチングステップによる前記変換を、前記レンダリング前に行なった場合と前記レンダリング後に行なった場合の結果を検証し、前記選択をすることを特徴とする請求項４に記載の印刷装置の制御方法。
6. 前記選択手段における選択に使用した条件と選択結果を保持しておく保持ステップと、
   次回以降のアルファブレンドレンダリングの際、前記保持手段で保持した情報を利用する利用ステップと、をさらに備えることを特徴とする請求項４または請求項５に記載の印刷装置の制御方法。
7. 記述言語文書をレンダリングするレンダリングステップと、
   前記記述言語文書で指定された色情報を、前記記述言語文書を印刷する印刷デバイス用の色情報に変換するカラーマッチングステップと、
   前記記述言語文書でアルファブレンドレンダリングが必要な場合、前記カラーマッチングステップによる前記変換を前記レンダリング前に行なうか前記レンダリング後に行なうかを判断し、該判断結果によりいずれかを選択する選択ステップと、を備えることを特徴とする印刷装置の制御プログラム。
8. 前記選択ステップによる選択は、前記カラーマッチングステップによる前記変換を、前記レンダリング前に行なった場合と前記レンダリング後に行なった場合の結果を検証し、前記選択をすることを特徴とする請求項７に記載の印刷装置の制御プログラム。
9. 前記選択ステップにおける選択に使用した条件と選択結果を保持しておく保持ステップと、
   次回以降のアルファブレンドレンダリングの際、前記保持手段で保持した情報を利用する利用ステップと、をさらに備えることを特徴とする請求項７または請求項８に記載の印刷装置の制御プログラム。
10. 請求項７から請求項９のいずれかに記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
11. 請求項７から請求項１０のいずれかに記載のプログラムを格納したＷｅｂサーバ。
    

Images