(57)【要約】      （修正有）【課題】マンマシンインターフェースの複数の文字又は文字列のグラフィック表示を改善する。【解決手段】コンピュータで実行される、マンマシンインターフェースのグラフィック表示用の文字列の処理方法が利用可能とされ、文字列の各々の文字はフォントライブラリの中に保存されたグリフによって表される。各々の文字に割り当てられたグリフが当該文字に対して少なくとも一つの輪郭を定める。その方法は、フォントライブラリから、少なくとも文字列の各々の文字の輪郭を検索する工程と、複数の検索された輪郭に基づいて、少なくとも文字列の全ての文字の輪郭を含み、文字列を表す単一のパスオブジェクトを生成する工程と、パスオブジェクトのグラフィック表示の目的のために、パスオブジェクトをグラフィックインターフェースに転送する工程を有する。さらに、その方法を実行するモジュールが詳述される。【選択図】図５
2015228021.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータで実行される、マンマシンインターフェースのグラフィック表示用の文字列の処理方法であって、
前記文字列の各々の文字はフォントライブラリの中に保存されたグリフによって表され、前記各々の文字に割り当てられたグリフが当該文字に対して少なくとも一つの輪郭を定め、前記方法は、
前記フォントライブラリから、少なくとも前記文字列の各々の文字の輪郭を検索する工程と、
複数の前記検索された輪郭に基づいて、少なくとも前記文字列の全ての文字の輪郭を含み、前記文字列を表す単一のパスオブジェクトを生成する工程と、
前記パスオブジェクトのグラフィック表示の目的のために、前記パスオブジェクトをグラフィックインターフェースに転送する工程を有することを特徴とする方法。
【請求項２】
前記各々の文字の輪郭は、少なくとも一つの径路によって定義され、前記少なくとも一つの径路はベクタ形式の命令によって記述されることを特徴とする請求項１に記載の方法。
【請求項３】
前記文字列を表すパスオブジェクトは、グラフィック表示の目的のために、一つの単位として前記グラフィックインターフェースへ転送されることを特徴とする請求項１に記載の方法。
【請求項４】
前記パスオブジェクトを生成する工程は、前記文字列によって予め定められた一連の文字に対応する前記複数の検索された輪郭を、単一のパスオブジェクトに組み立てる工程を有することを特徴とする請求項１記載の方法。
【請求項５】
複数の前記文字の輪郭は、隣接する文字間の水平及び／又は垂直方向の間隔が所望の文字間隔をとるように組み立てられることを特徴とする請求項４に記載の方法。
【請求項６】
前記パスオブジェクトを生成する工程は、さらに、前記文字列内の少なくとも一つの先行する文字に基づいて、前記文字の輪郭に対しての変換を計算する工程を有することを特徴とする請求項１に記載の方法。
【請求項７】
前記文字の輪郭の変換は、各々の前記先行する文字に基づいて連続的に計算されることを特徴とする請求項６に記載の方法。
【請求項８】
前記グリフは、さらに、少なくとも、高さ、幅、オフセット、カーニング、及び前記輪郭の開始点に関する情報についてのデータ項目を定め、前記情報のデータ項目の少なくとも一つが前記輪郭の変換の計算において考慮されることを特徴とする請求項６に記載の方法。
【請求項９】
前記計算された変換は、前記複数の輪郭の１次元又は２次元の変換を表すことを特徴とする請求項６に記載の方法。
【請求項１０】
さらに、前記パスオブジェクトに対して一組の属性を定め、前記属性が前記文字列の全文字のグラフィック表示を定義する工程を有することを特徴とする請求項１に記載の方法。
【請求項１１】
さらに、前記パスオブジェクトに対して、パターン情報又は勾配情報の複数の有効なデータ項目を作成し、該複数のデータ項目が所定のパターンに応じて複数の文字のグラフィック表示を定義する工程を有することを特徴とする請求項１に記載の方法。
【請求項１２】
表示可能な文字として、アルファベット文字、数字、及び／又は特殊文字を含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記文字列は、複数の単語、複数の数字、複数の単語及び／又は複数の数字の集合、又はテキストの一節を有することを特徴とする請求項１に記載の方法。
【請求項１４】
請求項１から請求項１３のいずれか一項に記載の方法を実行するためのプログラムコードを有し、コンピュータ装置で実行されるコンピュータプログラム製品。
【請求項１５】
コンピュータで読み取り可能な記録媒体に格納された請求項１４に記載のコンピュータプログラム製品。
【請求項１６】
マンマシンインターフェースのグラフィック表示用の文字列の処理モジュールであって、
前記文字列の各々の文字はフォントライブラリの中に保存されたグリフによって表され、前記各々の文字に割り当てられたグリフが当該文字に対して少なくとも一つの輪郭を定め、前記モジュールは、
前記フォントライブラリから、少なくとも前記文字列の各々の文字の輪郭を検索し、複数の前記検索された輪郭に基づいて、少なくとも前記文字列の全ての文字の輪郭を含み、前記文字列を表す単一のパスオブジェクトを生成するように構成されたテキストレンダリングユニットと、
前記生成されたパスオブジェクトをグラフィック表示するように構成されたグラフィックインターフェースを有することを特徴とするモジュール。
【請求項１７】
前記グラフィックインターフェースは、前記パスオブジェクトをビデオスクリーン上に表示する目的のために、グラフィックドライバとグラフィックプロセッサを有することを特徴とする請求項１６に記載のモジュール。
【請求項１８】
請求項１６に記載のモジュールを有するマンマシンインターフェース。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マンマシンインターフェースのグラフィック表示用の文字列の処理技術に関する。具体的には、コンピュータで実行される、マンマシンインターフェースのグラフィック表示用の文字列の処理方法について詳細に記載される。
【背景技術】
【０００２】
ベクタ形式（Ｖｅｃｔｏｒ  ｇｒａｐｈｉｃｓ）は、二次元又は三次元の対象物のグラフィック表示において、これまで重要な役割を果たし続けている。ベクタ形式は、ラスタ形式の場合において習慣的な、表示される対象物の各ピクセルに対する明度の詳細な記述の代わりに、表示される複数の対象物の数学的記述に基づいている。複数の対象物のグラフィック表示の様式（例えば、塗りつぶし、線の太さ等）は、ベクタ形式においては複数の対象物に割り当てられることができる複数の属性によって定義される。例えば、「円」によって構成される対象物は、単に円の中心と円の半径を定義することによって独自に記述されることができる。さらに、例えば、外郭線の太さ、外郭線の色、塗りつぶし色等の属性の詳細な記述を通して、対象物がどのようにグラフィック表示されるか（すなわち、「レンダされる」か）が定義されることができる。
【０００３】
ラスタ形式に対するベクタ形式の利点は、グラフィック表示対象物が処理しやすく、容量の観点から扱いやすい一組のデータによって記述されうるという事実にある。その結果として、プロセッサリソースとメモリリソースが節約される。ベクタ形式のオブジェクトは、さらに、段階なく、かつ損失のない方法で拡大縮小されることができ、視覚による出力媒体の解像度に依存しない。その結果、ベクタ形式に基づくオブジェクトは、より迅速に、より高い品質で表示されることができる。
【０００４】
ベクタ形式は、二、三の例を挙げるならば、魅力的なユーザーインターフェース（マンマシンインターフェース）を実現する目的のために、モバイルエンターテイメントアプリケーションの実現の目的のために、ナビゲーションアプリケーションのために、又はｗｅｂブラウザの分野において使用される。しかし、二次元のベクタ形式はまた、文字、文字列、又はテキストのグラフィック表示にも利用される（テキストレンダリングとも呼ばれる）。テキストレンダリングにおいて、最近のアプリケーションはいわゆるオンラインフォントに頼っている。オンラインフォントは、複雑な複数の位置ベクトルの集合としてグリフの輪郭（ｏｕｔｌｉｎｅ）（外郭（ｃｏｎｔｏｕｒ）とも呼ばれる）を表し、その位置ベクトルの集合は、複数の直線と弧を示すのに加え、複数のベジエ曲線とスプラインも示すことができる。この関連において、文字の具体的な外観（見かけ）が「グリフ」によって定められる。そのようなオンラインフォントの例としては、Ｔｒｕｅ  Ｔｙｐｅフォント、すなわち略してＴＴＦ、ｄｉｖｅｒｓｅ  ＰｏｓｔＳｃｒｉｐｔフォント、又はＯｐｅｎＴｙｐｅフォントがある。
【０００５】
複数の文字及びテキストのグラフィック表示が最近のマンマシンインターフェースの能力に大きな影響を与えうることが注意されるべきである。この関連において、文字表示の品質と速度は採用される表示処理に大きく依存する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、マンマシンインターフェースの複数の文字又は文字列のグラフィック表示をさらに改善する方法を明らかにすることである。
【課題を解決するための手段】
【０００７】
本発明の第一の態様によれば、コンピュータで実行される、マンマシンインターフェースのグラフィック表示用の文字列の処理方法が利用可能とされ、文字列の各々の文字はフォントライブラリの中に保存されたグリフによって表され、各々の文字に割り当てられたグリフが当該文字に対して少なくとも一つの輪郭を定め、その方法は、フォントライブラリから、少なくとも文字列の各々の文字の輪郭を検索する工程と、複数の検索された輪郭に基づいて、少なくとも文字列の全ての文字の輪郭を含み、文字列を表す単一のパスオブジェクトを生成する工程と、パスオブジェクトのグラフィック表示の目的のために、パスオブジェクトをグラフィックインターフェースに転送する工程を有している。
【０００８】
各々の文字は、グリフとしてフォントライブラリの中に保存されてもよい。フォントライブラリを通して、ＦｒｅｅＴｙｐｅが（又はｉＴｙｐｅも）使用されてもよい。グリフは文字の具体的な外観を表してもよい。具体的には、グリフは文字がどのようにグラフィック表示されるか（レンダされるか）を表してもよい。
【０００９】
グラフィック表示に対して、ベクトルフォントが使用されてもよい。具体的には、グリフが少なくともその輪郭の指定によって記述される輪郭フォントが使用されてもよい。輪郭は、文字に割り当てられたグリフの外郭を表していてもよい。輪郭はベクトルデータによって数学的に記述されることができる。この場合、輪郭は少なくとも一つの閉じた（及び／又は、開いた）径路によって記述されることができる。径路はベクトルに基づく（閉じた、及び／又は、開いた）線又は形を表してもよい。各々の径路は、お互いに区分により結合されることができる一連の点を通して定義されてもよい。それらの複数の点は、二次元の座標系において（点の座標を定義することによって）定義されてもよい。上記の区分は、複数の直線、弧、ベジエ曲線、及び／又はスプラインを表してもよい。
【００１０】
生成されたパスオブジェクトは、表示される文字列の全ての文字の輪郭を記述する全ての径路を有してよい。換言すれば、生成されたパスオブジェクトは、文字列の文字に割り当てることができるグリフの全ての輪郭を有してよい。その結果、表示される文字列は単一のパスオブジェクトによって表されることができる。その結果、グラフィック表示用の分かれたパスオブジェクトが、文字列の各々のグリフについてそれぞれ生成されることはない。
【００１１】
さらに、パスオブジェクトは視覚による外観をさらに定義する属性の情報（例えば、塗りつぶし色、塗りつぶしパターン、外郭線、外郭の色等のような）を含んでよい。パスオブジェクトは、その結果、表示対象物の視覚による外観を定めるために必要な全てのベクトルデータを有してよい。
【００１２】
単一のパスオブジェクトのみが、表示される文字列に対して生成されるので、この一つのパスオブジェクトのみがグラフィック表示の目的のために、グラフィックインターフェースへ転送されることができる。表示される文字列は、その結果として、単一のオブジェクトとしてグラフィックインターフェースへ転送され、さらに処理されることができる。グラフィックインターフェースは次に、視覚による出力部で表示されることができる像データを、対象物のベクトルに基づくグラフィックデータから生成するために、公知の方法で、転送されたパスオブジェクトを処理することができる。
【００１３】
パスオブジェクトを生成する工程は、さらに、文字列によって予め定められた一連の文字に対応する複数の検索された輪郭を、単一のパスオブジェクトに組み立てる工程を有していてもよい。文字列によって予め定められた順序の組み立てに続いて、複数の文字を表す複数の輪郭は、隣接する輪郭の間の水平、及び／又は垂直方向の間隔が、適応可能な、及び／又は所望の文字間隔をとるように組み立てられることができる。
【００１４】
パスオブジェクトを生成する工程は、文字列の先行する文字に対する、輪郭の所定の又は計算された位置に関して、文字を表す輪郭の変換（位置の移動）を計算する工程を有してよい。具体的には、どのくらい、及びどの方向に、一つの文字に対する各々の輪郭の一区分（径路の一区分）が先行する文字の輪郭に関連して変位されるかを示す変換ベクトルが計算される。輪郭の位置（又は輪郭を記述する径路の位置）は、所定の相対的、又は絶対的な座標系に関して定義されることができる。パスオブジェクトを生成する工程はその結果、複数の文字を表す複数の輪郭の位置の再計算を含んでよい。前記生成する工程は、さらに、単一のパスオブジェクトを形成するために、再計算された複数の輪郭の結合を含んでよい。そして、生成されたパスオブジェクトは、文字列の、全ての再計算された輪郭（径路の複数の区分）を有してよい。
【００１５】
変換又は各々の文字の輪郭に対する変換ベクトルの計算は、個々の先行する文字（先行する文字の輪郭）に基づいて連続的に計算されることができる。
【００１６】
グリフは、さらに、一つの輪郭に対して、少なくとも、高さ、幅、オフセット、カーニング、及び／又は輪郭の座標点（例えば、開始点）に関する情報についてのデータ項目を定めてもよい。カーニングの情報を通して、他の文字との間隔がそれらのグラフィック表示に依存して定義されることができる。この情報は、例えば、二つの連続する文字の間で異常に大きな間隔があくことや、又は合字になることを避けるために利用されることができる。これらの情報のデータ項目の少なくとも一つが、文字の輪郭の変換の計算において考慮されることができる。例えば、先行する文字の輪郭の幅は、先行する文字に関連して、それに続く文字の水平方向の変換を計算するために考慮されることができる。同様に、文字の高さは、先行する文字に垂直方向に続く文字の垂直方向の変換の計算に取り入れられてよい。その代わりに、高さと幅は、先行する文字に関連して、文字の水平及び垂直方向の対応する変位を生成するために、変換の計算に一緒に取り入れられてよい。
【００１７】
個々のグリフの輪郭の、高さ、幅、オフセット、カーニング、及び座標点に基づいて計算された変換は、１次元又は２次元でよい。１次元の変換は、先行するグリフの輪郭に関連して、グリフの輪郭が一方向のみ（水平又は垂直のどちらか）に変位されることを意味してよい。２次元の変換は、先行するグリフの輪郭に関連して、グリフの輪郭が水平方向と垂直方向の両方に変位されることを意味してよい。
【００１８】
本発明の処理はさらに、パスオブジェクトに対して、統合された一組の属性を定める工程を含んでよい。その結果、有効になる一組の属性は、文字列の全ての文字の視覚的表示を統一的な方法（すなわち、集中方式）で詳細に定義することができる。これの代わりに、文字列の個々の文字の視覚的表示を別々に定義するために、パスオブジェクトに対して、数組の属性を定めてもよい。
【００１９】
これに加えて、又はその代わりに、その処理はさらに、パスオブジェクトに対して、パターン情報又は勾配情報の複数のデータ項目を定める工程を有してよい。パターン情報を通して、文字が表示される際の塗りつぶしのパターンが定義されることができる。勾配情報を通して、定義されたパターン、及び／又は、文字の塗りつぶしが文字列の方向にどのように変更されるかが定義されることができる。
【００２０】
表示される文字列の文字は、任意のアルファベット文字、数字、音節文字、特殊文字、及び／又はそれらの文字の部分を含んでよい。表示される文字列は、単に一文字又は数文字を含むだけでもよい。特に、文字列は、任意の長さ、テキストの一節、幾つかの単語の組み又は集合である前述の複数の文字から組み立てられるテキストを含んでよい。本発明の方法により、テキスト全体、テキストの一節、幾つかの単語の組み又は集合が結果として、単一のパスオブジェクトを形成するためにまとめられ、表示のためにグラフィックインターフェースへそれ自体が転送されることができる。
【００２１】
さらに、上記の方法を実行するためのプログラムコードを有し、コンピュータ装置で実行されるコンピュータプログラム製品が提供される。この関連において、コンピュータプログラム製品は、コンピュータで読み取り可能な記録媒体に格納されてもよい。
【００２２】
さらなる態様によれば、マンマシンインターフェースのグラフィック表示用の文字列の処理モジュールが提供され、文字列の各々の文字はフォントライブラリの中に保存されたグリフによって表される。この場合、各々の文字に割り当てられたグリフは、少なくとも文字の輪郭に関する情報についてのデータ項目を定める。そのモジュールは、フォントライブラリから、少なくとも文字列の各々の文字の輪郭を検索し、複数の検索された輪郭に基づいて、少なくとも文字列の全ての文字の輪郭を含み、文字列を表す単一のパスオブジェクトを生成するように構成されたテキストレンダリングユニットと、生成されたパスオブジェクトをグラフィック表示するように構成されたグラフィックインターフェースを有する。
【００２３】
グラフィックインターフェースは、ハードウエアモジュールとして、ソフトウエアモジュールとして、又はハードウエアとソフトウエアが結合されたモジュールとして設計されてよい。グラフィックインターフェースは、少なくとも一つのグラフィックドライバとグラフィックプロセッサユニット（ＧＰＵ）を含んでよい。グラフィックドライバは、ベクタ形式のデータ処理（例えば、ＯｐｅｎＶＧ  ＡＰＩ）に対するプログラミングインターフェース（ＡＰＩ）として実行されてもよい。ＧＰＵは、視覚による出力部に転送されたパスオブジェクトを、グラフィック表示するためのグラフィック機能を実行することができる。さらに、グラフィックインターフェースは、複数のパスオブジェクトの保存又は一時保存するためのグラフィックメモリを有していてよい。
【００２４】
さらに他の態様によれば、上述のモジュールを有するマンマシンインターフェースが提供される。マンマシンインターフェースは、利用者の命令と入力を受けとり、及び／又は操縦面又はマシンの操作パラメータを詳述するように構成されてもよい。マンマシンインターフェースは、インフォテインメントシステム又はナビゲーションシステムの一部分であってよい。
【図面の簡単な説明】
【００２５】
本発明のさらなる態様、利点、及び詳細が図面を参照して、以下の実施態様の記述から示される。
【００２６】
【図１】マンマシンインターフェースのグラフィック表示用の文字列の処理モジュールのブロック図である。
【図２】表示される文字列と、ベクトルデータとしての記述を示す図である。
【図３】文字列のグラフィック表示方法を示す図である。
【図４】文字列のグラフィック表示の別の方法を示す図である。
【図５】実施態様による文字列のグラフィック表示方法を示す図である。
【図６】本発明による方法を示すフロー図である。
【図７】図２（ａ）に示された文字列によって構成される例に基くパスオブジェクトの生成を示す図である。
【発明を実施するための形態】
【００２７】
本発明は、概要ブロック図及びフロー図を参照して明らかにされるであろう。これらの図の基礎となる技術的な教示は、ハードウエアとソフトウエアの両方で、又はハードウエアとソフトウエアの組み合わせにおいて実行されることができる。そのような実行にはまた、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、及び他のスイッチ又はコンピュータ部品を含む。
【００２８】
以下にマンマシンインターフェースのグラフィック表示用の文字列の処理方法を、ＯｐｅｎＶＧスタンダードに関連して詳細に記述する。ＯｐｅｎＶＧ（オープンベクタ形式）は、ハードウエアアクセラレーションによる２次元ベクタ形式に対して、Ｋｈｒｏｎｏｓコンソーシアムによって開発された、ベクトルに基づくグラフィックプログラミングインターフェース（アプリケーションプログラミングインターフェース、すなわち略してＡＰＩ）である。ＯｐｅｎＶＧの場合には、抽象化レイヤーとして、アプリケーションプログラムとグラフィックプロセッサユニット（以下では、ＧＰＵ）の間に置かれ、アプリケーションプログラムのＧＰＵへのリンクを支援する、プラットホームから独立し、プログラミング言語から独立したソフトウエアグラフィックインターフェースが重要である。特に、ＯｐｅｎＶＧの術語を以下の記載で使用する。文字列のグラフィック表示用にここに記載される方法は、ＯｐｅｎＶＧ  ＡＰＩ（以下では、ＯｐｅｎＶＧドライバ）の詳細に依存することなく、むしろ他のベクトルに基づく（自家製の）ＡＰＩとの関連においても実行されることができることは言うまでもない。
【００２９】
文字列のグラフィック表示に関して、さらに、例えば、ＴｒｕｅＴｙｐｅフォント、すなわち、略してＴＴＦのようなベクトルフォントが使用される。ＴＴＦにおいては、任意の文字がそのグリフの輪郭を通して記述される。輪郭はグリフの外郭を表す。それは、ベクタ形式の命令によって数学的に記述される少なくとも一つの閉じた（及び／又は開いた）、プロットされた線によって表される。ＯｐｅｎＶＧスタンダードに関連した、文字の輪郭のベクトルによる記述を、再び、図２（ａ）−（ｃ）を参照してさらに以下に詳細に説明する。
【００３０】
図１を参照して、最初に、ここに記述された方法を実行するのに適したモジュールの実施態様を説明する。そのモジュールは、テキストレンダラ１０２４とグラフィックインターフェース１０１０を含む。グラフィックインターフェース１０１０は、ＯｐｅｎＶＧドライバ１０１２とＧＰＵ１０１４を含む。グラフィックインターフェース１０１０は、任意でグラフィックメモリ１０１６を含んでもよい。グラフィックインターフェース１０１０は、視覚による出力部１０３０と連携する（図１の矢印によって示される）。そのモジュールは、例えば、インフォテインメントシステム、ナビゲーションシステム、又はスマートフォンのようなシステムの中に実装されてもよい。この関連において、ここに記載されるモジュールはシステムの様々なレベル（階層）に置かれてよいことは言うまでもない。例えば、テキストレンダラ１０２４はアプリケーションレベルで、ＯｐｅｎＶＧドライバ１０１２はオペレーティングシステムレベルで、ＧＰＵ１０１４はハードウエアレベルで組み込まれてもよい。
【００３１】
テキストレンダラ１０２４は、フォントライブラリ１０２２と共にアプリケーションレベルで配置されている。アプリケーションレベルにおいて、例えば、表示される文字列を定めるグラフィックユーザーインターフェース（マンマシンインターフェース）のような、一つ以上のアプリケーション１０２０が、作動されてもよい。この場合には、文字列は、アルファベット文字、特殊文字、数字、又は音節文字の形式の一つ以上の文字から構成される、文字の任意の集合を有する。特に、ここで使用される「文字列」という術語は、表示される複数のテキスト、テキストの複数の一節、複数の文（センテンス）、又は単語の集合もまた包含する。
【００３２】
フォントライブラリ１０２２には、様々なベクトルに基づく、及び／又はピクセルに基づくフォントが保存されてよい。本処理については、ＴｒｕｅＴｙｐｅフォント（ＴＴＦ）が使用される。ＴＴＦにおいては、文字のグリフは、ベクトルデータ（径路データ）の形式でその輪郭（外郭）によって記述される。さらに、大きさ（高さ、幅）に関する情報のデータ項目、オフセット情報（左側オフセット、上側オフセット）のデータ項目、及び各々のグリフのカーニングがＴＴＦにおいて定められる。フォントライブラリ１０２２を通して、エイリアスの中に、ＴＴＦフォーマットをサポートするＦｒｅｅＴｙｐｅ（又は、ｉＴｙｐｅも）の使用がなされてもよい。
【００３３】
テキストレンダラ１０２４は、各々の文字の輪郭を（フォントライブラリ１０２２から）検索し、検索された輪郭に基づいて、少なくとも一つのパスオブジェクトを生成するように構成される。少なくとも一つのパスオブジェクトが、さらなる処理のために、グラフィックインターフェース１０１０に転送される。少なくとも一つのパスオブジェクトの具体的な生成が、図３から図５に関連してより詳細に明らかにされるであろう。さらに、図３と図４に関連してより詳細に明らかにされるように、本発明の文字を表示する方法においては、パスオブジェクトが、表示される文字列の各々の文字に対して生成される。ＯｐｅｎＶＧにおいては、各々のベクタ形式がパスオブジェクトである。「パスオブジェクト」によって、オブジェクトは、ベクトルデータによって記述される視覚的外観の意味を持たされる。このことは、表示される文字に対して生成されるパスオブジェクトが、文字の輪郭を記述する複数の径路（ベクトルデータの形式において）はもちろん、具体的には、文字がどのように視覚的に表示されるかを定義する属性のデータをも含むことを意味する。属性のデータは、例えば、外郭の具体的な表示（幅、破線で示された外郭、色）、（閉じた）外郭によって定義される表面の具体的な塗りつぶし等を含んでよい。
【００３４】
グラフィックインターフェース１０１０は、さらに、その中で実行されるレンダリングパイプラインに応じて定められる複数の径路と属性に基づいてパスオブジェクトを処理するように構成される。レンダリングパイプラインは、ＧＰＵ１０２４の中で実行されるグラフィック処理の工程がパスオブジェクトをレンダするために、すなわち、視覚による出力部１０３０での表示用の対応する像データを生成するために適用される順序を定義する。ＧＰＵ１０１４の適合と駆動が、この場合は、ＯｐｅｎＶＧドライバ１０１２を通して行われ、ＯｐｅｎＶＧドライバはアプリケーション１０２０とＧＰＵ１０１４の間のインターフェースとして作用する。特に、ＯｐｅｎＶＧドライバ１０１２は、グラフィック対象物の表示を加速する、複数のグラフィック機能を実行する。
【００３５】
そして、ＧＰＵ１０１４において生成された像データは、視覚表示のために、視覚による表示部１０３０へ出力される。出力部１０３０は、（接触感応の）ビデオスクリーン又はプロジェクタとして実現されてもよい。
【００３６】
グラフィックメモリ１０１６は、さらにＧＰＵ１０１４によって処理されるグラフィックデータ（パスオブジェクトデータ）を一時的に保存するように構成される。
【００３７】
図２（ａ）−（ｃ）を参照して、文字のベクトルによる記述を、ＯｐｅｎＶＧスタンダードの枠組みの中でより詳細に説明する。図２（ａ）は、四つの文字、「Ｔ」、「Ｅ」、「Ｘ」、及び「Ｔ」から構成され、黒の塗りつぶし（ｆｉｌｌｉｎｇ）で表される、表示対象の文字列「ＴＥＸＴ」を示している。塗りつぶしは、一つの属性によって容易に定義されることができ、これに応じてグラフィックインターフェース１０１０によって描画されることができる。その結果、単に、個々の文字の輪郭がフォントライブラリ１０２２から検索されねばならないだけである。個々の文字「Ｔ」、「Ｅ」、「Ｘ」、及び「Ｔ」の輪郭が図２（ｂ）に示されている。
【００３８】
そして、テキストレンダラ１０２４とＯｐｅｎＶＧドライバ１０１２を用いて、文字列「ＴＥＸＴ」の各々の文字に対して、文字の視覚による外観を記述する、少なくとも一つのパスオブジェクトが、検索された輪郭と定義された属性に基づいて生成される。ＯｐｅｎＶＧは、対象物の視覚による外観を定義するために、複数の属性を定める。そのような様式の属性は、例えば、対象物の塗りつぶし（塗りつぶしの色、塗りつぶしの勾配、塗りつぶしのパターン）、複数の径路の表示（径路上の点の数、区分の連結の様式、径路の幅、区分終結の型）等に関連付けられる。
【００３９】
図２（ｃ）は、ベクトルに基づく文字の記述がＯｐｅｎＶＧのもとでどのように行われるかを、文字「Ｔ」に対しての典型的な方法で示すものである。上述のように、グリフの輪郭は少なくとも一つの閉じた径路（プロットされた線）によって記述される。径路は、複数の点（２次元の座標点）とそれらの点を結んだ径路の区分によって記述される。径路の区分は、対応するベクタ形式の命令によって、ＯｐｅｎＶＧにおいて記述される。具体的には、文字「Ｔ」は、ＯｐｅｎＶＧの複数の命令である下記の配列によって記述されることができる。
【００４０】
（１）ｍｏｖｅ ｔｏ（１０，１０），
（２）ｌｉｎｅ ｔｏ（１０，２０）
（３）ｌｉｎｅ ｔｏ（３０，２０）
（４）ｌｉｎｅ ｔｏ（３０，８０）
（５）ｌｉｎｅ ｔｏ（４０，８０）
（６）ｌｉｎｅ ｔｏ（４０，２０）
（７）ｌｉｎｅ ｔｏ（６０，２０）
（８）ｌｉｎｅ ｔｏ（６０，１０）
（９）ｌｉｎｅ ｔｏ（１０，１０）．
【００４１】
この関連において、「ｍｏｖｅ ｔｏ（ｘ，ｙ）」という命令は、２次元の座標系における開始点（及びその結果としての輪郭全体）の初期の変位を定義し（図２（ｃ）の矢印１を参照）、それによって、変換された座標値（ｘ，ｙ）が両方の次元（座標）における変位の程度を定義する。そして、輪郭の具体的な形状が、命令の列（２）−（９）を通して決定される。「ｌｉｎｅ ｔｏ（１０，２０）」という命令が、例えば、座標点（１０，１０）と（１０，２０）の間の輪郭の径路区分を直線として定義する。同様に、それに続く複数の「ｌｉｎｅ ｔｏ（ｘ，ｙ）」という命令が、二つの連続する座標点の間の、文字「Ｔ」の輪郭の直線の区分を、各々の場合において記述する。複数の区分が、図２（ｃ）において、対応する矢印によって表されており、上述の番号を付けた配列が複数の矢印に割り当てられている。この関連において、各々の場合で、先行する径路区分の終点又は輪郭の開始点（「ｍｏｖｅ−ｔｏ」命令）が径路区分の開始点として定義されたので、終点の座標が単に「ｌｉｎｅ ｔｏ（ｘ，ｙ）」という命令に変換されるだけである。上述の複数の命令の配列によって、文字「Ｔ」の輪郭を定義する閉じた径路が連続的に生成されることができる。ＯｐｅｎＶＧでは、直線の区分の表示に加えて、２次又は３次の曲線の区分の表示も可能である。これらは、「ｑｕａｄ ｔｏ」又は「ｃｕｂｉｃ ｔｏ」という命令によって記述される。結局、ＯｐｅｎＶＧにおいては、任意の文字の輪郭を記述するための径路が、径路命令（パスインストラクション）の配列によって記述されることが強調されてもよい。そして、（１）−（９）の命令列に定義された径路情報は、文字「Ｔ」をグラフィック表示するために、（属性情報のさらに他のデータ項目と共に）使用される。残りの文字「Ｅ」、「Ｘ」、及び「Ｔ」も同様にして記述されることができる。
【００４２】
ここで、図３から図５を参照して、ＯｐｅｎＶＧドライバ１０１２を用いて文字列を処理する方法を説明する。ＯｐｅｎＶＧは、ビットマップデータとベクトルデータを処理することができる。例えば、図２（ａ）に示された文字列「ＴＥＸＴ」のような文字列のグラフィック表示の目的のために、二つの公知の文字表示方法があり、それらは図３及び図４において、簡潔に明らかにされるであろう。
【００４３】
最初に図３を参照する。テキストレンダラ１０２４、フォントライブラリ１０２２、ＯｐｅｎＶＧドライバ１０１２、及びＧＰＵ１０１４の一般的な機能は、既に図１との関係において説明された。この文脈において、図１についての記載が参照される。図３は、テキストレンダラ１０２４、フォントライブラリ１０２２、ＯｐｅｎＶＧドライバ１０１２、及びＧＰＵ１０１４が、アプリケーション階層、オペレーティングシステム（ＯＳ）階層１０００、及びハードウエア階層１００５での分担に対応する方法において表される点で主に図１と異なっている。
【００４４】
図３に示される方法は、ベクトルに基づいて文字列を表示する方法であり、その方法においては、表示される文字列の各々のグリフの輪郭（すなわち、径路データ）がフォントライブラリから検索され、そして、各々の文字のパスオブジェクトがグラフィック表示の目的のために生成される。
【００４５】
具体的には、テキストレンダラ１０２４は、文字列「ＴＥＸＴ」の各々の文字に対して、フォントライブラリ１０２２から対応するグリフの輪郭を呼び出す。次に、表示される各々の文字に対して、テキストレンダラ１０２４は、呼び出された輪郭に基づいてパスオブジェクトを生成し、グラフィック表示の目的のためにそのパスオブジェクトをグラフィックインターフェース１０１０へ転送する。グラフィックオブジェクトの生成と転送は、ＯｐｅｎＶＧドライバ１０１２への数回の呼び出しによって行われる。最初の呼び出しは、パスオブジェクトを生成する（ｖｇＣｒｅａｔｅＰａｔｈ）ために行われ、さらなる呼び出しがパスオブジェクトを径路データで満たす（ｖｇＡｐｐｅｎｄＰａｔｈＤａｔａ）ために行われ、そして、パスオブジェクトを描画するための呼び出し（ｖｇＤｒａｗＰａｔｈ）が行われる。そして、ＧＰＵ１０１４は、パスオブジェクトデータ（これらは、図２（ａ）−（ｃ）との関連において上述された、輪郭と属性情報のデータ項目を有する）に基づいて、後に視覚による出力部１０３０へ提供される、対応する像データを生成する。この手順は、文字列の各々の文字に対して繰り返される。換言すると、文字列「ＴＥＸＴ」の各々の文字に対して、分けられたパスオブジェクトが生成され、ＯｐｅｎＶＧドライバ１０１２のレンダリングパイプラインへ転送される。このことは、図３において、ＯｐｅｎＶＧドライバ１０１２とテキストレンダラ１０２４、及びＯｐｅｎＶＧドライバ１０１２とＧＰＵ１０１４の間の４本の矢印によって図式的に示されており、４本の矢印の各々が文字列「ＴＥＸＴ」の文字をそれぞれ表している。さらに、図３においては、簡単のために、上述の３回の呼び出しは、アプリケーション１０２０とＯｐｅｎＶＧドライバ１０１２の間の各々の文字に対して、１本の矢印によってのみ表されていることに注意が必要である。
【００４６】
図４に示された文字列を表す方法は、ビットマップに基づく方法である。それは、個々の文字に割り当てられたグリフが、輪郭の代わりにビットマップで表される点において、図３に示される方法と本質的に異なっている。テキストレンダラ１０２４は、各々のグリフに対して、フォントライブラリ１０２２から対応するビットマップを呼び出す。そして、検索されたビットマップのグリフに基づいて、ＯｐｅｎＶＧドライバ１０１２を用いて、テキストレンダラ１０２４はイメージオブジェクトを生成し、グラフィック表示の目的のために、そのイメージオブジェクトをグラフィックインターフェース１０１０に転送する。各々のイメージオブジェクトの生成と描画は、ＯｐｅｎＶＧドライバ１０１２への数回の呼び出しによって再び行われ、最初の呼び出しはイメージオブジェクトを生成するために行われ、さらなら呼び出しがイメージオブジェクトをビットマップデータで満たすために行われ、さらに他の呼び出しがオブジェクトを描画する目的で行われる。この処理でもまた、文字列の各々の文字に対して、分かれたイメージオブジェクトが生成され、グラフィックインターフェース１０１０へ転送される。
【００４７】
ここで、図５及び図６を参照して、本発明による、グラフィック表示用の文字列の処理方法を説明する。図５は表示に関係するハードウエアとソフトウエアの相互作用を再度示すものである。ＯｐｅｎＶＧドライバ１０１２、ＧＰＵ１０１４、及びフォントライブラリ１０２２の機能に関して、再度、図１の記載が参照される。テキストレンダラ１０２４ａの動作様式が、以下の処理に関連して記述されるであろう。図６は、その処理に対応するフロー図を示すものである。
【００４８】
第一の工程Ｓ１０において、少なくとも、図式的に表示される文字列の各々の文字に対するグリフの輪郭が、フォントライブラリ１０２２から検索される。テキストレンダラ１０２４ａは表示される文字列を認識し、その文字列の全ての輪郭が得られるまで、フォントライブラリ１０２２に対して繰り返し呼び出しを行う。輪郭に加えて、各々のグリフに対してフォントライブラリ１０２２の中に保存され、文字列のグラフィック表示のために必要とされてもよい、文字についての情報のさらに他のデータ項目も検索されることができる。そのような情報のデータ項目は、例えば、上述したように、各々のグリフの大きさ、オフセット、カーニングに関連している。
【００４９】
そして、第二の工程（Ｓ２０）において、表示される文字列に対するパスオブジェクトが生成される。このために、テキストレンダラ１０２４ａは、文字の各々の輪郭の変換を決定し、その変換によって輪郭の各々の径路区分を再計算することによって、得られた文字列の全ての輪郭を単一の径路に結合する。複数の輪郭の単一径路への合成（結合）は、文字列「ＴＥＸＴ」に基づいて、図７に例示的な方法で記述される。重要なことは、本発明による処理に従って、テキストレンダラ１０２４ａが一つの径路を形成するため文字列の全ての輪郭を組み立て、文字列全体に対して単一のパスオブジェクトを生成することである。
【００５０】
そして、単一のパスオブジェクトの生成は、空のパスオブジェクトを生成するためのｖｇＣｒｅａｔｅＰａｔｈ呼び出しと、そのパスオブジェクトを結合された径路データで満たすためのｖｇＡｐｐｅｎｄＰａｔｈＤａｔａによって行われる。
【００５１】
第三の工程Ｓ３０において、文字列に対して生成されたパスオブジェクトは、グラフィックインターフェース１０１０に転送される。テキストレンダラ１０２４ａは、ｖｇＤｒａｗＰａｔｈ呼び出しによってインターフェースへパスオブジェクトを転送する。そして、公知の方法において、ＧＰＵ１０１４は得られたデータに基づいて、表示される像の情報を生成する。
【００５２】
本発明の方法によれば、単に一つのパスオブジェクトが表示される文字列の全体に対して生成され、グラフィックインターフェース１０１０へ転送されるだけである。このことは、図５において、テキストレンダラ１０２４ａとＯｐｅｎＶＧドライバ１０１２の間と、ＯｐｅｎＶＧドライバ１０１２とＧＰＵ１０１４の間の単一の矢印で表される。換言すれば、文字列の全体が単一のパスオブジェクトとして表される。その結果、例えば、図３及び図４に関連して記述された方法の場合のように、分かれたパスオブジェクトが各々の文字に対して生成され、表示目的のためにグラフィックインターフェース１０１０へ転送されることはない。このように、ＯｐｅｎＶＧドライバ１０１２とアプリケーション（すなわち、テキストレンダラ１０２４）の間の呼び出しの回数は大幅に削減されることができる。本発明の方法によれば、図３及び図４に関連して議論された方法よりも（ｎ−１）回少ない「描画呼び出し（ｄｒａｗ  ｃａｌｌ）」が、ｎ文字の文字列を表すために必要とされる。パスオブジェクトの生成と描画に対する各々の呼び出しは、リソース（メモリリソース及びプロセッサリソース）を必要とし、それにより、表示能力に影響を与える。ここに記述された方法によって、呼び出しの回数は大幅に削減され、その結果として、グラフィック文字表示の速度は明確に最適化される。
【００５３】
図７において、文字列を表す単一のパスオブジェクトの生成を、文字列「ＴＥＸＴ」に基づいて、再びより詳細に説明する。テキストレンダラ１０２４ａは、フォントライブラリ１０２２から検索された全ての輪郭を単一の径路に結合するように構成される。この目的のために、複数の文字の輪郭が、文字の並びと、各々の連続する文字の間の、所望の、又は所定の間隔に応じて再計算される。具体的には、輪郭の複数の点がパスオブジェクトの中でどのような座標を取るかを定める、文字を表す各々の輪郭（各々の径路区分）に対する１次元又は２次元の変換が再計算される。輪郭を変換する計算は、先行する輪郭の計算された位置情報に基づいて、一つずつ行われることができる。
【００５４】
水平方向に配置された文字列「ＴＥＸＴ」の例においては、最初に、第一の文字「Ｔ」の輪郭が計算される。「Ｔ」は表示される最初の文字であるので、輪郭又は複数の径路区間の計算は、他の文字には依存しない。従って、最初の文字「Ｔ」の複数の径路区間は、任意のベクトル（「ｍｏｖｅ−ｔｏ」命令による初期変位）によって変位されることができる。最初の文字「Ｔ」の輪郭は、例えば、図２（ｃ）との関連において上述した径路区間（２）から（９）の配列によって記述されることができる。そして、第一の文字「Ｔ」の輪郭は、それに続く複数の文字の輪郭と結合される。
【００５５】
二つの連続する文字「Ｔ」と「Ｅ」の輪郭の結合のために、第一の文字「Ｔ」の輪郭に関係して第二の文字「Ｅ」の輪郭が、変換ベクトル（図７、矢印１０を参照）によって変位される。この場合、水平方向の文字の連結が問題であるから、第二の文字「Ｅ」は単に水平方向に変位され、文字「Ｅ」の水平方向の開始点は以下の変換規則、
「Ｓｔａｒｔｉｎｇ＿Ｐｏｉｎｔ＿ｏｆ＿Ｔ＋Ａｄｖａｎｃｅ＿ｏｆ＿Ｔ＋ｋｅｒｎｉｎｇ  ｏｆ＿Ｔ＿ｔｏ＿Ｅ＋Ｓｔａｒｔｉｎｇ＿Ｐｏｉｎｔ＿ｏｆ＿Ｅ」
に応じて計算される。
【００５６】
その結果、所定の変換規則に従い、文字「Ｅ」の開始点は、文字「Ｔ」の開始点の値によって、文字「Ｔ」の先行する値によって、文字「Ｔ」のカーニングの値（この値は負になることもある）によって、及び、文字「Ｅ」の所定の開始点の値によって変位される。換言すれば、文字「Ｅ」の各々の径路区分（すなわち、図７における１１−２２の径路区分）、及び、結果としての文字「Ｅ」の輪郭全体が、上記の変換規則によって定義される変換によって変位される。もし、例えば、最初の文字「Ｔ」が、Ｓｔａｒｔｉｎｇ＿Ｐｏｉｎｔ、Ａｄｖａｎｃｅ、及びｋｅｒｎｉｎｇに対して、それぞれ１０、８０、及び（−５）の値を取り、第二の文字「Ｅ」に対して開始値０が規定であるならば、その時は輪郭「Ｅ」に対する再計算された開始値は、以下の式、
ｓｔａｒｔ＿ｏｆ＿Ｅ＝（１０）＋（８０）＋（−５）＋（０）＝（８５）
に応じて変位される。
【００５７】
文字「Ｅ」に対する輪郭の全ての径路区分１１−２２は、この値だけ変位される。
【００５８】
第二の文字「Ｅ」に続く、第三の文字「Ｘ」の輪郭の変位は、図７の矢印２３によって表されるように、第二の文字「Ｅ」の輪郭に対して再計算された座標に依存して、同様に計算される。同様に、文字「Ｘ」の輪郭の再計算された位置に続いて、第四の文字「Ｔ」の水平方向の変位が、図７における矢印３６によって示されるように、計算される。
【００５９】
そして、上記計算アルゴリズムを用いて再計算された複数の輪郭は、単一の径路に結合される。それに対応して、文字列全体に対して、以下の複数の命令の配列からなる単一のパスオブジェクトが生成される。
【００６０】
（１）ｍｏｖｅ ｔｏ（１０，１０），
（２）ｌｉｎｅ ｔｏ（１０，２０）
（３）ｌｉｎｅ ｔｏ（３０，２０）
（４）ｌｉｎｅ ｔｏ（３０，８０）
（５）ｌｉｎｅ ｔｏ（４０，８０）
（６）ｌｉｎｅ ｔｏ（４０，２０）
（７）ｌｉｎｅ ｔｏ（６０，２０）
（８）ｌｉｎｅ ｔｏ（６０，１０）
（９）ｌｉｎｅ ｔｏ（１０，１０）
（１０）ｍｏｖｅ ｔｏ（８５，１０）
（１１）ｌｉｎｅ ｔｏ（８５，８０）
（１２）ｌｉｎｅ ｔｏ（１３５，８０）
（１３）．．．（２１）
（２２）ｌｉｎｅ ｔｏ（８５，１０）
（２３）ｍｏｖｅ ｔｏ（１６０，１０）
（２４）．．．（４３）
（４４）ｌｉｎｅ ｔｏ（２３５，１０）．
【００６１】
配列の行（１０）の「ｍｏｖｅ ｔｏ（８５，１０）」という命令は、最初の文字「Ｔ」がどこで終わり、第二の文字「Ｅ」がどこで始まるかを指定する。同様に、配列の行（２３）の「ｍｏｖｅ ｔｏ（１６０，１０）」という命令は、第二の文字「Ｅ」がどこで終わり、第三の文字「Ｘ」がどこで始まるかを指定する。配列の行（４４）の「ｌｉｎｅ ｔｏ（２３５，１０）」という命令は、第四の文字「Ｔ」が、そして、結果として文字列がどこで終わるかを最終的に指定する。その結果、複数のグリフの全ての径路が、グラフィック表示の目的のために、単一のオブジェクトに組み立てられる。
【００６２】
文字列の水平方向の連結（変位）でここに示される例は、単に例示的な文字を有しているだけであるのは言うまでもない。水平方向の変換の代わりに、同様の変換が垂直方向に実行されてもよい。これに加えて、又はこれに代えて、対応する変換が両方向（すなわち、水平方向と垂直方向）に実行されることが考えられる。さらに、一つの文字列を単一のパスオブジェクトとして表すことは、四文字の表示に限定されない。それどころか、ＯｐｅｎＶＧはパスオブジェクトのサイズに関する制限を規定していないので、任意の長さの文字列又はテキストが、個々の径路として様式化され、単一のパスオブジェクトがその文字列又はテキストに対して生成されることができる。
【００６３】
複数の文字を単一のパスオブジェクトで表されるようにまとめることは、上述のように、呼び出しの回数を削減する。しかし、一つのパスオブジェクトを形成するためにここに記述したまとめる工程は、また、データ削減とオーバーヘッドデータの回避の関連においても多大な利点を有する。例えば、グラフィック文字の視覚による表示の詳細を定義する属性データは、文字列の全体に対してのみ、一度、定義されなければならない。他方、グリフ様式の描画においては、例えば、図３に示される処理の場合のように、各々のグリフに対して、新しいパスオブジェクトを生成する際には、属性データが再び全てにわたって定められねばならない。
【図１】
2015228021.tif 000003
【図２】
2015228021.tif 000004
【図３】
2015228021.tif 000005
【図４】
2015228021.tif 000006
【図５】
2015228021.tif 000007
【図６】
2015228021.tif 000008
【図７】
2015228021.tif 000009
【外国語明細書】
2015228021000001.pdf