JP2000338953A - フォント特徴ファイル処理 - Google Patents

Abstract

(57)【要約】 【課題】 特に、ＯｐｅｎＴｙｐｅフォントであるフォ
ントに対する特徴を特定する特徴ファイルと呼ばれるフ
ロントエンド編集可能テキストファイルを処理する方法
及び装置を提供する。 【解決手段】 本発明によれば、特定された特徴が構文
解析され且つフォントデータとしてフォント内に格納さ
れる。特徴ファイルはハイレベル特徴定義言語で表現さ
れた例えばレイアウト特徴等の種々のタイポグラフィ特
徴の仕様に対する簡単な論理ステートメントを包含して
いる。特徴ファイルはフォントテーブル内のフィールド
に対する上書き値を包含することが可能である。特徴フ
ァイルは既存のフォントファイルと結合して処理され向
上されたフォントファイルを確立する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、デジタルフォント
の変換及び修正技術に関するものである。

【０００２】

【従来の技術】特定のデザインを有する１組のキャラク
タは「タイプフェース」と呼ばれる。例えばカリフォル
ニア州サンノゼのアドビシステムズインコーポレイテッ
ド（以下、単に「アドビ」と呼称する）から入手可能な
ポストスクリプト（ＰｏｓｔＳｃｒｉｐｔ）（商標）フ
ォント等のデジタルフォント（以後、単に、「フォン
ト」と呼ぶ）は、特定のタイプフェースでキャラクタを
レンダリングさせるための命令（通常、プログラム可能
なプロセッサ上で実行されるレンダリングプログラムに
よって読取られ且つ解釈される）を有している。

【０００３】ＯｐｅｎＴｙｐｅ（商標）フォントフォー
マットはワシントン州レドモンドのマイクロソフトコー
ポレイション（以後、単に、「マイクロソフト」と呼
ぶ）とアドビとによって共同開発されたものである。

【０００４】ＯｐｅｎＴｙｐｅフォントは多様なテーブ
ルを有しており、且つ、オプションとして、ＯｐｅｎＴ
ｙｐｅレイアウトテーブルを有しており、それらはフォ
ント作成者がより良い国際的な且つハイエンドの活字フ
ォントを設計することを可能とさせている。ＯｐｅｎＴ
ｙｐｅレイアウトテーブルはグリフ置換、グリフ位置決
め、行端揃え、及びベースライン位置決めに関する情報
を有しており、テキスト処理アプリケーションがテキス
トレイアウトを改善することを可能とさせる。該テーブ
ルは活字特徴を表す二進データを包含しており、それ
は、その形式においてＯｐｅｎＴｙｐｅフォントへ付加
することが可能である。例えば、ＯｐｅｎＴｙｐｅフォ
ントにおけるグリフ置換（ＧＳＵＢ）テーブルはそのフ
ォントで設定されているテキスト中の隣接するｆ及びｉ
のグリフをそのフォントにおけるｆｉ合字グリフで置換
することを特定することが可能な合字（ｌｉｇａ、即ち
リガチャ）特徴を包含することが可能である。従来、こ
のようなテーブルは二進データを発生するための特定の
プログラムを書込むことによるか又は最初に各フォント
テーブルデータ構造内へ入る値を詳細に記述するテキス
ト入力ファイルを用意し、次いで該テキスト表現をＯｐ
ｅｎＴｙｐｅによって必要とされる二進形態へ組立てる
ツールを稼動させることによって作成していた。これら
のアプローチのうちの最初のものは柔軟性を欠如してお
り、一方マイクロソフトによって開発されたＴｒｕｅ
Ｔｙｐｅ Ｏｐｅｎ Ａｓｓｅｍｂｌｅｒ（ＴＴＯＡＳ
Ｍ）によって例示されるように後者は非常に低いレベル
であり且つ基礎となるデータ構造の完全なる知識を必要
とし、従って、コンピュータサイエンスのバックグラウ
ンドではなくグラフィックアーツの経験を有する傾向の
あるフォント編集者にとって妥当なものではない。

【０００５】

【発明が解決しようとする課題】本発明は、以上の点に
鑑みなされたものであって、上述した如き従来技術の欠
点を解消し、例えばＯｐｅｎＴｙｐｅ（商標）フォント
ファイル等の既存のフォントファイルに対する変更を定
義するか又はフォントファイルを作成するためにユーザ
（例えばフォント編集者）が使用することの可能なフロ
ントエンド編集可能テキストファイル（「特徴ファイ
ル」と呼称する）を処理する方法及び装置を提供するこ
とを目的とする。

【０００６】

【課題を解決するための手段】本発明によれば、特徴フ
ァイルと呼ばれるフロントエンド編集可能テキストファ
イルを処理する技術が提供される。特徴ファイルはソー
スフォントを向上させるか又は補充することの可能な例
えばレイアウト特徴等の種々の活字特徴の仕様に対する
簡単な論理ステートメントを包含している。特徴ファイ
ルは、フォントテーブル内のフィールドに対するオーバ
ーライド（上書き）値を包含している。特徴ファイルは
向上させたフォントファイルを確立するために既存のフ
ォントファイルと結合して処理することが可能である。

【０００７】一般的に、１つの側面においては、本発明
はフォントに対して活字特徴を付加する方法を提供して
いる。本方法は、ハイレベル特徴定義言語で表現された
特徴定義を包含する特徴ファイルを用意し、コンピュー
タプログラム内の前記特徴ファイルを読取り且つ構文解
析して前記特徴定義の内部表現を発生し且つ前記内部表
現をコンピュータメモリ内に格納し、前記特徴定義をフ
ォントテーブル又はサブテーブル定義へ変換し、前記テ
ーブル又はサブテーブル定義をフォントファイル内に書
き出す、ことを包含している。

【０００８】一般的に、別の側面によれば、本発明はフ
ォントへ活字特徴を付加すべく動作可能なシステムを提
供している。本システムは、命令プロセッサと、ランダ
ムアクセスメモリと、データファイルメモリとを具備す
るプログラム可能なコンピュータ、ハイレベル特徴定義
言語で表現された特徴定義を包含する特徴ファイルを読
取る手段、前記特徴定義の内部表現を発生するために前
記特徴ファイルを構文解析する手段、前記内部表現を前
記ランダムアクセスメモリ内に格納する手段、前記特徴
定義をフォントテーブル又はサブテーブル定義へ変換す
る手段、前記テーブル又はサブテーブル定義を前記デー
タファイルメモリ内に格納されているフォントファイル
へ書き出す手段、を有している。

【０００９】一般的に、別の側面によれば、本発明は、
フォントへ活字特徴を付加するためのコンピュータプロ
グラムが記録されているコンピュータによって読取可能
な記録媒体が提供される。前記記録媒体は、コンピュー
タをして、ハイレベル特徴定義の言語で表現されている
特徴定義を包含する特徴ファイルを読取らせ、前記特徴
定義内部表現を発生させるために前記特徴ファイルを構
文解析させ、前記内部表現をメモリ内に格納させ、前記
特徴定義をフォントテーブル又はサブテーブル定義へ変
換させ、且つ前記テーブル又はサブテーブル定義をフォ
ントファイル内に書き出させる、上記各命令を有してい
る。

【００１０】種々の実施形態において、本発明は、以下
の有益的な特徴の内の１つ又はそれ以上を包含すること
が可能である。本発明は、インクルード（ｉｎｃｌｕｄ
ｅ）即ち包含メカニズムによって包含されている他のフ
ァイルを包含する特徴ファイルを読取り、且つ特徴ファ
イル内に見つかったエラーを報告する規則を抽出する。
それは、適宜、タイプによって該規則をグループ化し且
つ各グループの規則に対してどのテーブル及びサブテー
ブルフォーマットを使用するかを決定する。置換規則ス
テートメントから推論的に特定のフォントテーブル又は
サブテーブルを識別することが可能である。特徴定義か
らユーザの介入なしで共用データ構造を作成することが
可能であり、且つ特徴定義をフォントファイル内へ書込
む前に冗長性を除去することが可能である。特徴定義言
語は、サブテーブルフォーマット選択を表す構成体なし
で定義することが可能である。

【００１１】本発明の実施化において得られる利点は以
下のうちの１つ又はそれ以上を包含している。ユーザが
定義した特徴を特徴ファイル内において特定することが
可能な柔軟性のある形式は多様なフォント特性を受付け
る。フォント特徴はデータファイル内において英語のよ
うな文法を使用して特定され、該データファイルは任意
のテキストエディタを使用して作成し且つ修正すること
が可能である。このことは著しい柔軟性を与え且つフォ
ントを作成しているか又は修正しているフォント編集者
の作業を著しく容易なものとさせる。フォント編集者は
基礎となるデータ構造の詳細について知ることが必要で
はない。ユーザはフォントデータ構造と１対１の態様で
あることに制限されることのない言語構成体を使用する
ことが可能である。適宜のフォーマットのサブテーブル
が自動的に選択される。フォントに対する修正は効率的
なファイルの格納を簡単化させる態様で行われる。共用
データに関しての最適化が実施され、そのことはフォン
トの寸法を減少させる。他のファイルを包含させるメカ
ニズムは、複数個のフォントに対して標準であるデータ
を共用するために使用することが可能である。パーサ即
ち構文解析器は、特徴ファイル内でエラーに遭遇した場
合に編集者に対してエラーをフィードバックさせる。グ
リフ名エイリアス（別名付与）用メカニズムを使用する
ことが可能である。全代替（ａａｌｔ）特徴のアルゴリ
ズム作成が提供される。

【００１２】

【発明の実施の形態】図１に示したように、本発明に基
づく特徴ファイル処理方法１００は、特徴ファイルと呼
称されるフロントエンド編集可能テキストファイルを処
理する。本方法を実行するコンピュータシステムのユー
ザは、特徴ファイルを使用して、既存のフォントファイ
ル、特に、ＯｐｅｎＴｙｐｅ（商標）フォントファイル
に対する変更を定義するため、又はフォントファイルを
作成することが可能である。特徴ファイルは、ソース即
ち元のフォントを向上させるか又は補充することの可能
な例えばレイアウト特徴等の種々のタイポグラフィ即ち
活字（印刷を含む）特徴の仕様に対する簡単な論理ステ
ートメントを包含している。特徴ファイルはフォントテ
ーブル内のフィールドに対するオーバーライド（上書
き）値を包含することが可能である。特徴ファイルはハ
イレベル特徴定義言語で表現されている特徴定義を包含
しており、該言語の仕様は以下の例Ａに記載しており、
且つその１例を以下の例Ｂに記載してある。該仕様から
理解することが可能であるように、該言語は英語のよう
な文法で表現された宣言論理ステートメントに基づいて
いる。別の実施例においては、特徴定義言語のステート
メントは英語以外の自然言語に対する自然言語のような
文法で表現することが可能である。

【００１３】図１に戻って説明すると、特徴ファイルが
読取られ（ステップ１０２）且つ構文解析される（ステ
ップ１０４）。特徴ファイルの構文解析期間中に、各規
則のグリフパターンが最初に図３に示してあり且つ以下
に説明する内部表現へ変換し、それは無制限の複雑性及
び長さのグリフパターンを許容する（ステップ１０
６）。グリフ名又はＣＩＤ番号が最初にグリフＩＤへ変
換される。グリフＩＤへの変換は重要である。何故なら
ば、全てのＯｐｅｎＴｙｐｅレイアウトテーブルはグリ
フＩＤによってグリフを参照し、且つグリフ名又はＣＩ
Ｄ番号によって参照するものではないからである。グリ
フエイリアシング（即ちエイリアス用）データベース
（例えば、オプションのデータベース４５０、図４）が
使用されている場合には、最終のグリフ名を派生するた
めに参照される。グリフエイリアシングデータベース
は、ホワイトスペース即ち空白部分によって離隔されて
いるライン当たりの２つのフィールドを有するテキスト
ファイルとして極めて簡単に実現することが可能であ
り、一方のフィールドはユーザフレンドリィグリフ名で
あり、他方のフィールドはフォントにおいて使用される
最終的なグリフ名である。例えば、最終的なグリフ名
「ｕｎｉ０３９４」はグリフエイリアスデータベースに
おいてより認識可能な名前である「Ｄｅｌｔａ.ｇｒｅ
ｅｋ」へエイリアス即ち別名を付与することが可能であ
り、このことが行われ且つデータベースが使用される場
合には、そのグリフは特徴ファイルにおいて「Ｄｅｌｔ
ａ．ｇｒｅｅｋ」として参照することが可能である。

【００１４】次いで、全ての規則における各グリフに対
して「グリフノード（ｇｌｙｐｈｎｏｄｅ）」（データ
タイプ：ＧＮｏｄｅ）を作成する。ＧＮｏｄｅは、以下
のように、グリフＩＤ、フラグフィールド、次のシーケ
ンス及び他のＧＮｏｄｅへの次のクラスポインタを包含
している。

【００１５】

【数１】

【００１６】例えば、且つ図３を参照すると、グリフク
ラス＠ＯＮＥ及び＠ＴＷＯは以下の如くに定義される。

【００１７】

【数２】

【００１８】以下の特徴ファイル規則

【数３】

【００１９】は、両方ともＧＮｏｄｅに対するポインタ
であるターゲット及び交換によって内部的に表される。
この例は図３に示してあり、その場合に、説明の便宜
上、グリフＩＤではなくグリフ名が示されている。図３
において右側へ向いている矢印はｎｅｘｔＳｅｑフィー
ルドを表しており、下側に向いている矢印はｎｅｘｔＣ
ｌフィールドを表している。

【００２０】全てのタイプの置換規則（ｓｕｂｓｔｉｔ
ｕｔｉｏｎ ｒｕｌｅ）は、１個のターゲットパターン
と１個又はそれ以上の交換（ｒｅｐｌａｃｅｍｅｎｔ）
パターンへ還元させることが可能であり、且つ全てのタ
イプの位置決め規則は関連する位置情報を具備するター
ゲットパターンへ還元することが可能である。

【００２１】図１に戻って説明すると、規則が認識され
（ステップ１０８）、タイプ毎にグループ化され（ステ
ップ１１０）、メモリの動的に割り当てられるアレイ内
に読み込まれる（即ち、格納される）（ステップ１１
２）。例えば、特定のカーニング対のランは、クラスカ
ーニング対のランとは別個にグループ化される。何故な
らば、それらをフォント内に格納するのに必要な態様だ
からである。

【００２２】データの種々の部分を適宜のビン内に蓄積
し且つ重複するものを取除くことによって可能な限り共
用される（ステップ１１４）。各組の規則は内部的にラ
ベルが与えられ、幾つかの組の規則が共用することが必
要であるか又は共用することが可能である場合には、そ
れらに同一の内部的なラベルが割り当てられ、従ってデ
ータ書込時に、それらはフォント内に一度だけ格納され
る。例えば、２つの別個ＧＳＵＢ特徴が同一の組のター
ゲットグリフに関して作用する場合には、この範囲のグ
リフは一度だけ格納され且つ該２つの特徴の各々によっ
てポイントされる。グリフクラス、即ち複数組のグリフ
はグリフのリンクされたリストとして表され、クラスデ
ータが最早必要とされない場合にはメモリが再使用され
る。別の実施例においては、その他のデータ構造を使用
することが可能である。

【００２３】図２に示したように、本発明に基づく方法
２００は特徴ファイルから派生された内部表現を変換し
且つフォント内に格納すべき実際のサブテーブル及びそ
の他のデータを作成する。各テーブルに対して（ステッ
プ２０２及び２０８）、最初に種々のサブテーブルフォ
ーマットオプションの寸法を計算し（ステップ２０４）
且つ次いで最も小さなものを選択（ステップ２０６）す
ることによってサブテーブル（ｓｕｂｔａｂｌｅ）の最
適化が実施される。このことは、幾つかのものが使用可
能である場合に、フォントエディタがどのサブテーブル
フォーマットを使用するかを特定することが必要でない
（実際には、不可能である）ことを意味している。

【００２４】次いで、サブテーブル及びその他の出力デ
ータが作成される（ステップ２１０）。特徴ファイルに
おいて表現されている規則の内部表現が対応するフォン
トデータフォーマットへ変換される。関連するＯｐｅｎ
Ｔｙｐｅフォントテーブル及びサブテーブルのフォーマ
ット及びセマンティクスはアドビ及びマイクロソフトか
ら入手可能なＯｐｅｎＴｙｐｅに関する参考文献に記載
されている。

【００２５】図４に示したように、コンピュータシステ
ム４０２は例えばｇｌｙｐｈＮａｍｅ（グリフ名）対ｇ
ｌｙｐｈＩＤ（グリフＩＤ）マッピング等の情報を供給
する入力フォントファイルとすることも可能なフォント
ファイル４６０内に格納されているフォント等のフォン
トに対する変更を定義するために使用することが可能で
ある。特徴ファイル４４０はシステム４０２又はテキス
トファイルを作成し且つ編集することの可能なその他の
システム上で任意のテキスト編集プログラム４０４を実
行するユーザによって作成することが可能である。特徴
ファイル処理プロセス４１０、即ち特徴プロセッサが動
作して特徴ファイルを読取り且つ図１及び２を参照して
上述した動作を実行する。プロセス４１０は任意の便利
なプログラミング言語を使用して任意の便利な態様でプ
ログラムすることが可能であり、例えば、それは特徴フ
ァイル４４０を読取り（モジュール４１２）且つパース
即ち構文解析を行い（モジュール４１４）、特徴ファイ
ルステートメントの内部表現４３０を作成し（モジュー
ル４１６）、内部表現を最適化し（モジュール４１
８）、且つテーブル及びその他の出力を作成する複数個
のモジュールの形態に編成することが可能である。プロ
セス４１０は前述した如くオプションのグリフエイリア
スデータベース４５０を使用することが可能である。１
実施形態に置いては、特徴ファイルがコンパイルされ且
つ特徴ファイルから抽出された規則がテーブル作成モジ
ュール４１６へ供給される。この実施形態においては、
テーブル作成モジュール４１６へのインターフェース
は、作成プロセスがターゲットと交換ＧＮｏｄｅによっ
て定義されるＧＮｏｄｅ表現の結果として極めて簡単で
ある。

【００２６】図５に示したように、上述した特徴プロセ
ッサ４１０はコンピュータシステム上で稼動させること
の可能なフォント変換プロセス５１０、即ちフォントコ
ンバータの一部とすることが可能である。特徴ファイル
プロセスのように、フォントコンバータは任意の便利な
プログラミング言語を使用して任意の便利な態様でプロ
グラムすることが可能である。１実施形態においては、
特徴プロセッサ４１０はフォントコンバータ５１０に対
するサーバとして動作する。特徴プロセッサは特徴ファ
イル４４０及びオプションのグリフデータベース４５０
を読取り、且つ前述したようにフォントテーブルデータ
を発生する。フォントコンバータ５１０は、又、入力フ
ォント５４０を読取り且つ出力フォント５５０を発生
し、特徴ファイル４４０に従って特徴及び定義を付加又
は変化させる。有益的な実施形態においては、入力及び
出力フォントは異なるフォーマットのものであり、例え
ば、夫々、Ｔｙｐｅ１及びＯｐｅｎＴｙｐｅである。

【００２７】特徴定義言語はフォント生成環境において
容易に使用するために特に設計されている。それは多数
の興味のある特性を有している。

【００２８】第一に、名前空間分離は必要な場合にのみ
発生し、そうでない場合には発生しない。例えば、言語
中において使用される通常最も一般的なエンティティ即
ち実体であるグリフ名は文脈によってキーワードから区
別される生の単語である。グリフ名がキーワードでもあ
る通常の場合（例えば、「ｆｅａｔｕｒｅ」）、それは
最初のバックスラッシュによってグリフ名として表すこ
とが可能である（例えば、「＼ｆｅａｔｕｒｅ」）。グ
ラフシーケンスにおいてしばしば発生する名前付きグリ
フクラスは、通常、グリフ名と同様の名前を有してお
り、従って異なる名前空間を占有し、それらは「＠」キ
ャラクタによって先行されている。特徴、言語及びスク
リプトタグ名、例えば「ｌｉｇａ」は、グリフ名が発生
することが不可能である場合にのみ発生し、従って、そ
れらも生の単語である。これらの言語特徴はフォントエ
ディタが使用することが必要な特別のキャラクタの数を
最小とさせている。

【００２９】第二に、該言語は例えＯｐｅｎＴｙｐｅフ
ォント使用自身によってサポートされていない場合であ
っても、一度に複数個のグリフに関して共通の操作を実
施することを可能としている。例えば、「ＯＮＥ ｈａ
ｌｆ」に対する合字置換は、例えＯｐｅｎＴｙｐｅフォ
ント自身が特定の規則を格納することが可能であるに過
ぎない場合であっても、以下の如くにして簡単に示すこ
とが可能である。

【００３０】

【数４】

【００３１】この例においては、ソフトウエアはシーケ
ンス「＠ＯＮＥ ｓｌａｓｈ ＠ＴＷＯ」のクロスプロ
ダクト (ｃｒｏｓｓ ｐｒｏｄｕｃｔ)をとり且つ該規
則を別個にフォント内に格納する。このことは、１６個
(この例の場合)の別々の規則をタイプアウトせねばな
らないエラーが発生しやすい別法からエディタを解放し
ている。

【００３２】単一の置換は特徴定義言語において及びＯ
ｐｅｎＴｙｐｅフォーマット自身において両方とも複数
個のグリフに関してサポートされている。例えば、以下
の如くである。

【００３３】

【数５】

【００３４】従って、エディタ (フォント編集者)は実
際にフォント内に格納する場合に規則を拡張することが
必要であるか否かを知ることは必要でない。

【００３５】第三に、該言語は規則のタイプの自動検知
を与えるために処理することが可能である。従って、フ
ォントエディタ即ちフォント編集者は２種類の規則、即
ち置換 (ｓｕｂｓｔｉｔｕｔｉｏｎ)及び位置決め (ｐ
ｏｓｔｉｏｎｉｎｇ)について知っていることが必要で
あるに過ぎない。規則はキーワード「ｓｕｂｓｔｉｔｕ
ｔｅ」又は「ｐｏｓｉｔｉｏｎ」 (それらは、夫々、
「ｓｕｂ」又は「ｐｏｓ」として省略することが可能で
ある)によって導入される。該規則の残部のタイプは全
ての共通の場合において自動検知され、単に１つの付加
的なキーワードが例えばＧＰＯＳルックアップタイプ３
−６のような使用頻度の低い位置決め規則を明確化させ
るために必要とされるに過ぎない。例えば、以下の如く
である。

【００３６】

【数６】

【００３７】第四に、該言語は複数個のマスタ及びキャ
ラクタ識別子 (ＣＩＤ)フォントの継ぎ目のない統合を
与える。全てのマスタに対して同一である場合には、マ
ルチマスタメトリクスを、単一のマスタフォントの場合
のように、生の数字で示すことが可能である。例えば、

【数７】

【００３８】は、６マスタフォントに対する以下のもの
と同一である。

【００３９】

【数８】

【００４０】これは便利であり且つエラーの可能性を減
少させる。勿論、複数個のマスタに対して値が異なるも
のである場合には、それらは以下の如くに特定されねば
ならない。

【００４１】

【数９】

【００４２】ＣＩＤフォントの取扱いにおける差異も小
さいものである。ＣＩＤフォントの場合には、グリフ名
の代わりに、グリフのＣＩＤ番号 (数値と区別するため
にバックスラッシュによって先行されている)を特定す
ることが必要である。

【００４３】本発明は、デジタル電子回路、又はコンピ
ュータハードウエア、ファームウエア、ソフトウエア又
はそれらの組合せで実現することが可能である。本発明
装置は、プログラム可能なプロセサによって実行する本
発明方法のコンピュータプログラムを記録させたコンピ
ュータによって読取可能な記録媒体として実現すること
が可能であり、且つ本発明の方法ステップは、入力デー
タについて操作を行い且つ出力を発生することによって
本発明の手順を実行する命令からなるプログラムを実行
するプログラム可能なプロセッサによって実施すること
が可能である。本発明はデータ記憶システムからデータ
及び命令を受取り且つデータ記録システムへデータ及び
命令を送信するために結合されている少なくとも１個の
プログラム可能なプロセッサ、少なくとも１個の入力装
置、少なくとも１個の出力装置を有するプログラム可能
なシステム上で実行することの可能な１つ又はそれ以上
のコンピュータプログラムを格納する記録媒体として実
現することが可能である。各コンピュータプログラムは
ハイレベル手順又はオブジェクト指向型プログラミング
言語で、又は、所望により、アッセンブリ又はマシン言
語で実現することが可能であり、且つ、いずれの場合に
おいても、該言語はコンパイル型又はインタプリタ型の
言語とすることが可能である。適宜のプロセッサとして
は、１例として、汎用及び特定目的用のマイクロプロセ
ッサ等がある。一般的に、プロセッサはリードオンリメ
モリ及び／又はランダムアクセスメモリから命令とデー
タとを受取る。通常、コンピュータはデータファイルを
格納するための１つ又はそれ以上の大量記憶装置を有し
ており、このような装置としては、内部ハードディスク
及び着脱自在なディスク等の磁気ディスク、ＭＯディス
ク、光学的ディスク等がある。コンピュータプログラム
命令及びデータを格納するのに適した記憶媒体として
は、例えばＥＰＲＯＭ、ＥＥＰＲＯＭ等の半導体記憶装
置を包含する全ての形態の非揮発性メモリ、及びフラッ
シュメモリ装置、内部ハードディスク及び着脱自在なデ
ィスク等の磁気ディスク、及びＭＯディスク、ＣＤ−Ｒ
ＯＭディスク等がある。前述したもののいずれもＡＳＩ
Ｃ (応用特定集積回路)によって補充されるか又はその
中に組込むことが可能である。

【００４４】ユーザとの対話を与えるために、本発明は
例えばユーザに対して情報を表示するためのモニタ又は
ＬＣＤスクリーン等のディスプレイ装置、キーボード、
ユーザがコンピュータシステムへ入力を与えることの可
能なマウス又はトラックボール等のポインティング装置
等を具備するコンピュータシステム上で実現することが
可能である。コンピュータシステムはそれによってコン
ピュータプログラムがユーザと対話を行うグラフィカル
ユーザインターフェースを与えるようにプログラムする
ことが可能である。

【００４５】例Ａ−特徴ファイル仕様 １．緒論 ＯｐｅｎＴｙｐｅ特徴ファイルは読むのが簡単なフォー
マットでのＯｐｅｎＴｙｐｅフォントに対する特徴仕様
を包含しているテキストファイルである。それは、又、
フォントテーブル内のあるフィールドに対するオーバー
ライド値即ち上書き値を包含することが可能である。以
下のものは完全な特徴ファイルの１例である。

【００４６】

【数１０】

【００４７】この例のファイルはｆｉ及びｆｌ合字 (ｌ
ｉｇａｔｕｒｅ)の形成を特定している。

【００４８】２．シンタックス ２.ａ.コメント 「＃」キャラクタはコメントの開始を表し、そのコメン
トはそのラインの終りまで続く。

【００４９】２．ｂ．ホワイトスペース ホワイトスペース即ち空白部分は区切り用のトークンを
除いて有意性があるものではない。

【００５０】２．ｃ．キーワード 以下のものは特徴ファイルの特徴定義言語のキーワード
である。

【００５１】 anonymous(又はanon) by cursive device enumerate(又はenum) except excludeDFLT feature include includeDFLT language lookup lookupflag mark nameid position(又はpos) required script substitute(又はsub) subtable table サポートされるテーブルフィールド名は以下のものを包
含している。

【００５２】 HorizAxis.BaseTagList #BASEテーブル HorizAxis.BaseScriptList HorizAxis． MinMax VertAxis． BaseTagList VertAxis． BaseScriptList VertAxis． MinMax GlyphClassDef #GDEFテーブル Attach LightureCaret ContourPoint FontRevision #headテーブル CaretOffset #hheaテーブル Panose #OS/2テーブル TypoAscender TypoDescender TypoLineGap Xheight CapHeight VertTypoAscender #vheaテーブル VertTypoDescender VertTypoLineGap 以下のものはタグが予測される場合のみのキーワードで
ある。

【００５３】 DFLT ２．ｄ．特別キャラクタ 特別キャラクタは以下のテーブルにリストされている。

【００５４】 ＃ シャープ コメントの開始を示す ； セミコロン ステートメント終了 ， カンマ 例外文節においてグリフシーケンスを分離 ‘ 引用符 文脈置換のためのグリフ又はグリフクラスの印付け ＠ アットマーク グリフクラス名を識別 ＼ バックスラッシュ ＣＩＤを識別し、グリフ名を同一のキーワードから 区別する − ハイフン グリフクラス内のグリフ範囲を示す ＝ 等記号 グリフクラス割り当てを示す ｛｝ ブレース 特徴、ルックアップテーブル又は匿名ブロックを取 囲む ＜＞ 山括弧 マルチマスタメトリクスに対するマスタ値を取囲む ［］ 角ブラケット グリフクラスのコンポーネントを取囲む （） 括弧 インクルードされるべきファイル名を取囲む ２．ｅ．数字 ＜ｎｕｍｂｅｒ＞は符号付き十進数の整数（先行するゼロなし）である。例え ば、 -150 1000 であり、それはグリフの位置決め及び種々のテーブルフ
ィールドの値を表すために使用される。

【００５５】＜ｆｉｘｅｄ ｐｏｉｎｔ ｎｕｍｂｅｒ
＞はｈｅａｄテーブル内のＦｏｎｔＲｅｖｉｓｉｏｎ値
に対して必要とされる。整数部及び小数部は十進数表示
で特定すべきである。例えば、 FontRevision 1.10 #フォント内において0ｘ0001
A000として格納される ２．ｆ．グリフ グリフはグリフ名又はＣＩＤ番号のうちの1つによって
表される。グリフ名は以下のセットからのキャラクタで
構成される。

【００５６】 A−Z a−z 0−9 ． （ピリオド） ＿ （下線） それは数字又はピリオドで開始することはない。唯一の
例外は特別キャラクタ「.ｎｏｔｄｅｆ」である。例え
ば、「ｔｗｏｃｅｎｔｓ」、「ａｌ」、「＿」は有効な
グリフ名であり、且つ「２ｃｅｎｔｓ」及び「.ｔｗｏ
ｃｅｎｔｓ」は有効なグリフ名ではない。

【００５７】最初のバックスラッシュはグリフ名を同一
のキーワードから区別する機能を有している。例えば、 ＼substitute #グリフ名 であり、グリフ名エイリアスデータベースが使用される
場合には、エイリアス（即ち、別名）を特徴ファイルに
おいて使用することが可能である。ＣＩＤはバックスラ
ッシュによって先行される十進数で表され、例えば、 ＼101 ＼0 である。

【００５８】２．ｇ．グリフクラス グリフクラスはシーケンス内の単一のグリフ位置を表し
且つ角ブラケットで取囲んだグリフからなるリストによ
って示される。例えば、 [endash emdash figuredash] であり、グリフクラスを包含するシーケンスの1例は、 space[endash emdash figuredash]space であり、複数個のグリフからなる範囲はハイフンによっ
て示され、即ち、 [＜firstGlyph＞−＜lastGlyph＞] であり、例えば、 [＼0−＼31] [A−Z] であり、ＣＩＤフォントの場合には、その順番付けはＣ
ＩＤの順番付けである。非ＣＩＤフォントの場合には、
順番付けはフォント内のグリフの順番付けとは独立して
いる。＜firstGlyph＞及び＜lastGlyph＞は同一の長さ
でなければならず、且つ、 １．大文字又は小文字のＡ−Ｚからの単一の文字、例え
ば、 ［Aswash−Zswash］ ［a−z］ この範囲は、グリフ名の残部を同一に維持しながら、異
なる文字をインクリメントさせることによって拡張され
る。

【００５９】２．連続するランにおいて最大で３個まで
の十進数字、例えば、 [ampersand.01−ampersand.58] この範囲はグリフ名の残部を同一に維持しながら数値を
インクリメントすることにより拡張される。

【００６０】の点で異なることが可能である。

【００６１】以下のものはグリフ名の長さが異なるので
有効なグリフクラスではない。

【００６２】 ［ampersand.1−ampersand.58］ #無効 注意すべきであるが、 ［zero−nine］ は有効なグリフ範囲ではない。それは以下のように明示
的に列挙されるものでなければならない。

【００６３】＠digits＝ [zero one two three four fi
ve six seven eight nine] グリフクラスはそれに対してグリフ名を割り当てること
によって命名することが可能であり、それは「＠」キャ
ラクタで開始するものであり、後にそのグリフクラス名
で参照することが可能である。例えば、 ＠dash＝［endash emdash figuredash］： #割り当て space ＠dash space #使用 「＠」の後のグリフクラス名の部分はグリフ名に適用さ
れる同一の名前制限が適用される。グリフクラス割り当
ては特徴ファイル内のどこにおいても表れることが可能
である。グリフクラス名はそれを定義した後においての
み特徴ファイル内において使用することが可能である。
グリフクラス名が角ブラケット内において発生する場合
には、その要素が単に定義中のグリフクラス内の他の要
素へ付加される。例えば、 ＠Vowels.lc=[a e i o u]; ＠Vowels.uc=[A E I O U]; ＠Vowels.=[＠Vowels.lc＠Vowels.uc y Y］; である場合に、最後のステートメントは、 ＠Vowels=[a e i o u A E I O U y Y］; と等価である。グリフクラス名が別の単一のグリフクラ
ス名へ割り当てられる場合には角ブラケットは必要では
ない。例えば、以下の通りである。

【００６４】 ＠Figures_lining_tabular=＠FIGSDDEFAULT; 範囲、グリフ及びグリフクラス名は1個のグリフクラス
に結合させることが可能である。例えば、以下の通りで
ある。

【００６５】[zerooldstyle-nineoldstyle ampersandol
dstyle＠smallCaps] 注意すべきことであるが、特徴ファイルのグリフクラス
はＯｐｅｎＴｙｐｅレイアウトのグリフクラスと混乱し
てはならない。

【００６６】２.ｈ.タグ タグは、最終的なスペースなしでタグ名によって示さ
れ、且つ文脈によりグリフ名から区別される。例えば、 ＤＵＥ であり、この例における最後の空間は暗示的である．特
別のタグ「ＤＦＬＴ」でありデフォルト言語を示す。

【００６７】２．ｉ．ルックアップブロックテーブル グリフ名で適用される制限はルックアップブロックラベ
ルにも適用される。

【００６８】３．ファイルのインクルード ファイルのインクルード (ｉｎｃｌｕｄｅ)は以下のよ
うに表される。

【００６９】Include（＜filename＞） 有限のインクルードループ (互いにインクルードするフ
ァイル)を確保するために、例えば５等の最大のインク
ルード深さを実現することが可能である。

【００７０】４．特徴の特定 ４．ａ．特徴 各特長は以下の形態を有する特徴ブロックで特定され
る。

【００７１】

【数１１】

【００７２】特徴の開始における言語及びスクリプト
は、夫々、「ｌａｔｎ」及び「ＤＦＬＴ」へデフォルト
される。ルックアップフラグ属性は０へデフォルトされ
る。

【００７３】４．ｂ．言語 言語属性は、明示的に変化されるまで、スクリプトが変
化されるまで、又はその特徴の終りまで同一の状態を維
持する。以下の形態のステートメントは言語属性をセッ
トするために使用することが可能である。

【００７４】Language＜language tag＞; 例えば、 language DEU; であり、スクリプト及びルックアップフラグ属性は前と
同じく同一のままである。

【００７５】特定の特徴に対する言語特定ルックアップ
はデフォルトによってＤＥＬＴルックアップを受け継
ぐ。このことが望ましくない場合には、「ｅｘｃｌｕｄ
ｅＤＥＬＴ」キーワードが言語タグに追従せねばならな
い。例えば、 language DEU excludeDFLT; であり、キーワード「ｉｎｃｌｕｄｅＤＦＬＴ」は、デ
フォルトのＤＦＬＴルックアップ受け継ぎ動作を明示的
に表すために使用することが可能である。たとえば、 DEU includeDFLT;#言語DEUと同じ； キーワード「ｒｅｑｕｉｒｅｄ (必須)」が存在する場
合には、特定した言語システムに対する必要とされてい
る特徴として現在の特徴を特定する (スクリプト/言語
組合せ)。

【００７６】４．ｃ．スクリプト スクリプト属性は、明示的に変化されるまで、又は該特
徴の終りまで同一の状態に留まる。以下の形態のステー
トメントをスクリプトを変化させるために使用すること
が可能である。

【００７７】Script＜script tag＞; 例えば、 script kana; 言語は暗示的にＤＦＬＴへ設定され且つルックアップフ
ラグ属性は暗示的にゼロへセットされる。

【００７８】４．ｄ．ルックアップフラグ ＯｐｅｎＴｙｐｅフォントファイル仕様はルックアップ
テーブルにおけるルックアップフラグフィールドを記述
する。ルックアップフラグ属性は明示的に変化されるま
で、スクリプトが変化されるまで、又はフィーチャの終
りまで同一に留まる。以下の形態のステートメントをル
ックアップフラグ属性を変化させるために使用すること
が可能である。

【００７９】Lookupflag＜number＞; 例えば、 lookupflag 2; #二進数における「10」;IgnoreBaseGly
phsフラグをセット ４．ｅ．ルックアップ フォントテーブルの異なる部分をして同一のルックアッ
プを参照させるために一連の規則にラベル付けをし且つ
後に明示的に参照することが可能である。ラベルを使用
することは、ユーザが重複する組の規則を維持すること
から解放することに加えてフォントの寸法を減少させ
る。以下の形態のステートメントをルックアップを定義
し且つラベルを付けるために使用することが可能であ
る。

【００８０】

【数１２】

【００８１】後にそれを参照するためには、以下の如く
記述する。

【００８２】Lookup＜label＞; 例えば、以下の通りである。

【００８３】

【数１３】

【００８４】ラベル付けをしたブロックは文字通りフォ
ント内の単一のルックアップを定義するので、そのルッ
クアップブロック内の規則は同一のルックアップタイプ
のものでなければならず且つ同一のルックアップフラグ
属性を有するものでなければならない。ルックアップブ
ロックは別の種類のブロックを包含することは不可能で
ある。

【００８５】４．ｆ．サブテーブル サブテーブル (ｓｕｂｔａｂｌｅ)ブレークは、必要と
される場合に、特定のルックアップに対する規則の間に
挿入される。「ｓｕｂｔａｂｌｅ」キーワードは以下の
ようにして使用することが可能である。

【００８６】Subtable; これは、前の規則の後にサブテーブルブレークを強制的
に挿入する。

【００８７】４．ｇ．例 以下の例は言語特定規則を有する特徴ブロックを示して
いる。デフォルト属性はコメント中に表してある。

【００８８】

【数１４】

【００８９】上の例においては、ｃｈ及びｃｋ合字置換
は、言語がドイツ語である場合にのみ適用される。ｆ
ｆ、ｆｉ、ｆｌ合字置換はラテンスクリプトにおける全
ての言語(ドイツ語を含む)に対して適用される。

【００９０】次の例はラベル付けしたルックアップブロ
ック及びｅｘｃｌｕｄｅＤＦＬＴキーワードの使用を例
示している。

【００９１】

【数１５】

【００９２】ｆｆｉ及びｆｉ合字置換は、言語がトルコ
語である場合には適用されない。注意すべきであるが、
ｌｏｏｋｕｐ［ｘ］はｌｏｏｋｕｐ［ｙ］の前に配置さ
れねばならない。何故ならば、ｆｉｉ置換はｆｆ置換に
先行せねばならないからである。 (特徴ファイルにおけ
るルックアップ及び規則の順番付けの以下の説明を参照
すると良い)。特定のルックアップ内の合字規則の順番
は問題ではない。例えば、ｌｏｏｋｕｐ［ｘ］におい
て、ｆｉ置換はｆｆｉ置換の前に配置させることが可能
である (合字置換の以下の説明を参照)。

【００９３】５．グリフ置換 (ＧＳＵＢ)規則 ５．ａ．［LookupType１］単一置換 以下の形態のステートメントは単一の置換を定義する。

【００９４】 substitute <glyph> by <glyph>; substitute＠glyph class by <glyph class>; キーワード「ｓｕｂｓｔｉｔｕｔｅ」 (置換)は「ｓｕ
ｂ」として省略することが可能であり、例えば、以下の
通りである。

【００９５】 Sub a by Asmall; Substitute [a-z] by [Asmall-Zsmall]; Subsitute＠Capitals by＠CapSwashes グリフクラスを包含する規則は、そのクラスに特定され
た順番でテーブルが作成される場合に列挙される。従っ
て、ターゲット及び交換グリフクラス内の要素の数は同
一でなければならない。上の例の２番目のラインは以下
のようにフォント内において同一の表示を発生する。

【００９６】 substitute a by Asmall; substitute b by Bsmall; substitute c by Csmall; #... substitute z by Zsmall; ５．ｂ． [ＬｏｏｋｕｐＴｙｐｅ２］マルチ置換 以下の形態のステートメントはマルチ置換を定義するた
めに使用することが可能である。

【００９７】 Substitute <glyph> by <glyph sequence>； ＜ｇｌｙｐｈｓｅｑｕｅｎｃｅ＞はグリフクラスを包含
することは不可能であり、包含していた場合には、どの
ターゲットシーケンスが必要とされるかに関しての規則
が不明確である。例えば、 substitute ffi by f f i; #合字分解 ５．ｃ．［ＬｏｏｋｕｐＴｙｐｅ３］代替置換 以下の形態のステートメントは代替置換を行うために使
用することが可能である。

【００９８】Substitute <glyph> from <glyph class>; 例えば、 substitute ampersand from [ampersand.1 ampersand.2
ampersand.3]; ５．ｄ．［ＬｏｏｋｕｐＴｙｐｅ４］合字置換 以下の形態のステートメントは合字置換を定義するため
に使用することが可能である。

【００９９】Substitute <glyph sequence> by <glyph
>； ＜ｇｌｙｐｈｓｅｑｕｅｎｃｅ＞はグリフクラスを包含
することが可能であり、例えば、 substitute [one oneoldstyle][slash fraction][two t
wooldstyle] by onehalf; である。ＯｐｅｎＴｙｐｅ仕様はグリフクラスを包含す
るターゲットシーケンスに関し合字置換を特定すること
を許容するものではないので、＜ｇｌｙｐｈｓｅｑｕｅ
ｎｃｅ＞においてグリフクラスが検知される場合には全
ての特定のグリフシーケンスが自動的に列挙される。従
って、上の例は以下の如く、あたかも全てのシーケンス
が手作業によって列挙されたかのようにそのフォントに
おいて同一の表現を発生する。

【０１００】

【数１６】

【０１０１】連続する組の合字規則は任意の特定の態様
で順番付けされることを必要とするものではなく、特徴
ファイルが処理される場合に適宜のソーティングが行わ
れる。従って、 sub f f by ff; sub f i by fi; sub f f i by ffi; sub o f f i by offi; は、次のようにそのフォントにおいて同一の表現を発生
する。

【０１０２】sub o f fi by offi; sub f f i by ffi; sub f f by ff; sub f i by fi; ５．ｅ．［ＬｏｏｋｕｐＴｙｐｅ５］文脈置換 このＬｏｏｋｕｐＴｙｐｅは文脈置換をチェーン化する
ＧＳＵＢＬｏｏｋｕｐＴｙｐｅ６の機能的サブセットで
ある。従って、このＬｏｏｋｕｐＴｙｐｅの全ての所望
の規則はチェーン化文脈置換規則によって表すことが可
能である。

【０１０３】５．ｆ．［ＬｏｏｋｕｐＴｙｐｅ６］チェ
ーン化文脈置換 グリフ文脈内の1つの単一又は１つの合字置換に対する
チェーン化文脈置換は、オプションの例外と共に、以下
の如くに表される。

【０１０４】[except <glyph sequence list>] #この
規則に対する例外 (オプション) substitute <marked glyph sequnce> #マーク付けした
サブランを有するターゲット文脈 by <replacement glyph or glyph class>; #サブラン
交換シーケンス ＜ｇｌｙｐｈｓｅｑｕｅｎｃｅ＞は1個又はそれ以上の
グリフ又はグリフクラスを有している。＜ｇｌｙｐｈｓ
ｅｑｕｅｎｃｅｌｉｓｔ＞は＜ｇｌｙｐｈｓｅｑｕｅｎ
ｃｅ＞のカンマで分離したリストである。

【０１０５】＜ｍａｒｋｅｄｇｌｙｐｈｓｅｑｕｎｃｅ
＞は、グリフ又はグリフクラスの1つ又はそれ以上のサ
ブランが識別されている即ちマーク付けされている＜ｇ
ｌｙｐｈ ｓｅｑｕｅｎｃｅ＞である。サブラン (ｓｕ
ｂ−ｒｕｎ)は、そのメンバー要素の各々の後に単一の
引用符 ( ‘)を挿入することによってマーク付けされ
る。然しながら、２つ又はそれ以上のサブランが連続し
ている場合には、それらは1つのサブランの要素を単一
の引用符でマーク付けし且つ隣接するサブランの要素を
二重引用符 (”)でマーク付けすることによって区別す
ることが可能である。

【０１０６】これらのサブランはこの規則によって呼び
出されるルックアップのターゲット文脈を表す。マーク
付けしたグリフの各このようなサブランは、順番が、交
換＜ｇｌｙｐｈｓｅｑｕｅｎｃｅｌｉｓｔ＞における交
換グリフシーケンスに対応せねばならない。

【０１０７】例外 (除外)文節が存在しており且つ＜ｍ
ａｒｋｅｄｇｌｙｐｈｓｅｑｕｅｎｃｅ＞におけるどの
グリフもマーク付けされていない場合には、＜ｍａｒｋ
ｅｄｇｌｙｐｈ ｓｅｑｕｅｎｃｅ＞内の全てのグリフ
がマーク付けすべくとられる。例えば、 substitute [a e n] d′by d.alt; の規則は、「ａｄ」又は「ｅｄ」又は「ｎｄ」のシーケ
ンスにおいて、「ｄ」を「ｄａｌｔ」で置換することを
意味している。

【０１０８】オプションの「ｅｘｃｅｐｔ」文節は例外
（除外）をリストし且つ置換ステートメントに先行し、
これがフォント内に格納される態様を鏡映する。例え
ば、上の例に例外文節が付加された以下の場合について
検討する。

【０１０９】 except f [a e] d, a d d substitute [a e n]ｄ′by d.alt; 例外文節は「ｆa d」、「ｆe d」、又は「a d d」のシ
ーケンスに対して置換が発生すべきでないことを特定す
る。

【０１１０】以下の例は単語の境界においてどのように
して合字を置換することが可能であるかを示している。

【０１１１】

【数１７】

【０１１２】例えば「ｉｎｉｔ」特徴及び「ｆｉｎａ」
特徴等のある特徴が1つの単語の始め又は終りにおける
グリフをターゲットするに過ぎない場合には、その特徴
を有するフォントを使用するアプリケーションプログラ
ムはその単語の境界を検知するものとさせることが可能
であり、その特徴自身は単語の境界に拘わらずに適切な
置換として単純に定義される。このようなアプリケーシ
ョンの役務は特徴タグレジストリィ内に記述すべきであ
る。

【０１１３】６．グリフ位置決め（ＧＰＯＳ）規則 ６．ａ．共通データタイプ グリフ位置決めはメトリクス、装置テーブル、値記録及
びアンカーによって特定される。

【０１１４】６．ａ．ｉメトリクス 単一マスターフォントに対する＜ｍｅｔｒｉｃ＞値は単
に＜ｎｕｍｂｅｒ＞である。マルチマスターフォントに
対するメトリクス値は山括弧で取囲まれた＜ｎｕｍｂｅ
ｒ＞からなるアレイによって示される。各＜ｎｕｍｂｅ
ｒ＞はマスターに対するメトリクス値を表しており、そ
の順番はオリジナルのフォントにおけるマスターの順番
と同一である。該アレイ内の＜ｎｕｍｂｅｒ＞の数はそ
のフォント内のマスターの数と等しくなければならな
い。例えば、 <-140 -160> は、最初のマスター（２つのマスターを有するフォント
において）に対するメトリクスが-１４０であり且つ２
番目のマスターに対するメトリクスが-１６０であるこ
とを意味する。その値が全てのマスターに対して一定で
ある場合には、山括弧なしで単一の＜ｎｕｍｂｅｒ＞を
使用することが可能である。例えば、以下の通りであ
る。

【０１１５】 1000 #4マスターフォントに対する<1000 1000 100
0 1000>と等価 ６．ａ． ii． 装置テーブル ＜ｄｅｖｉｃｅ＞は単一の装置テーブルを表し、以下の
フォーマットを有している。

【０１１６】device(<ppem size><number>)+ 例えば、 device 11 -1 12 -1 #11ppem及び12ppemにおいて-
1だけ調節 ＜ｄｅｖｉｃｅ＞のリスト内において必要とされる場合
に、ヌル即ちｎｕｌｌの＜ｄｅｖｉｃｅ＞は以下のよう
に表される。

【０１１７】device 0 ６．ａ． iii．値記録 ＜ｖａｌｕｅｒｅｃｏｒｄ＞は幾つかのフォーマットの
うちの何れかをとることが可能である。

【０１１８】

【数１８】

【０１１９】＜ｖａｌｕｅｒｅｃｏｒｄ＞フォーマット
Ａ内の＜ｍｅｔｒｉｃ＞は、Ｙ前進調節を表す場合であ
る「ｖｋｒｎ」特徴において定義されている場合を除い
て、Ｘ前進調節を表す。これは最も簡単な＜ｖａｌｕｅ
ｒｅｃｏｒｄ＞フォーマットである。それはカーニング
に対して最も一般的に使用される調節を表す。＜ｖａｌ
ｕｅｒｅｃｏｒｄ＞フォーマットＢにおける＜ｍｅｔｒ
ｉｃ＞はＸ配置、Ｙ配置、Ｘ前進、Ｙ前進に対する調節
をその順番で表す。＜ｖａｌｕｅｒｅｃｏｒｄ＞フォー
マットＣにおける＜ｍｅｔｒｉｃ＞はフォーマットＢに
おけるものと同一の調節を表し、＜ｄｅｖｉｃｅ＞はＸ
配置、Ｙ配置、Ｘ前進、Ｙ前進に対する装置テーブルを
その順番で表す。このフォーマットはユーザがＯｐｅｎ
Ｔｙｐｅ値記録の完全なる機能性を表現することを可能
とさせる。

【０１２０】これらの調節はそのフォント内に設けられ
ている配置及び前進の値に対して加算すべき（正の値）
又は減算すべき（負の値）の値（設計単位において）を
表す。＜ｖａｌｕｅｒｅｃｏｒｄ＞の幾つかの例は以下
のとおりである。

【０１２１】

【数１９】

【０１２２】３番目の例は、Ｘ配置及びＸ前進に対する
１１及び１２ｐｐｅｍ寸法における装置調節のみならず
Ｘ配置及びＸ前進に対する調節を特定する。

【０１２３】６．ａ． iv．アンカー ＜ａｎｃｈｏｒ＞は４つのフォーマットのうちの何れか
におけるアンカー点を特定する。

【０１２４】 # <anchor> format A, the null anchor: 0 #X座標、Y座標 # <anchor> format B: <number> <number> #X座標、Y座標 # <anchor> format C: <number> <number> <number> #X座標、Y座標、 #輪郭点インデックス #<anchor> format D: <number> <number> <device> <device> #X座標、Y座標、 #X座標装置テーブル、 #Y座標装置テーブル 例えば、 0 #フォーマットA 120 -20 #フォーマットB 120 -20 5 #フォーマットC；輪郭点インデッ クスは５ 120 -20 device 11 1 device 0 #フォーマットD ６．ｂ．［ＬｏｏｋｕｐＴｙｐｅ1］単一調節位置決め 以下の形式のステートメントは単一調節位置決めを行う
ために使用することが可能である。

【０１２５】position <glyph * glyphclass> <value r
ecord> キーワード「ｐｏｓｉｔｉｏｎ」は「ｐｏｓ」として省
略することが可能である。例えば、グリフの左側及び右
側のサイドベアリングの各々を８０設計単位だけ減少さ
せるためには以下のようにする。

【０１２６】position one -80 0 -160 0; ６．ｃ．［ＬｏｏｋｕｐＴｙｐｅ２］対調節位置決め このＬｏｏｋｕｐＴｙｐｅに対する規則はカーニングの
ために使用され、且つ２つのフォーマットの内の何れか
とすることが可能である。

【０１２７】 # PairPos format A: positon <glyph * glyphclass> <glyph * glyphclass> <valuerecord>; # PairPos format B: [現在サポートされていない] position <glyph * glyphclass> <glyph * glyphclass> <valuerecord>,<valuerecord>; フォーマットＢにおいては、＜ｖａｌｕｅｒｅｃｏｒｄ
＞は最初の＜ｇｌｙｐｈ＊ｇｌｙｐｈｃｌａｓｓ＞に対
応しており、２番目の＜ｖａｌｕｅｒｅｃｏｒｄ＞は２
番目のものに対応している。フォーマットＡにおいては
＜ｖａｌｕｅｒｅｃｏｒｄ＞は＜ｇｌｙｐｈ*ｇｌｙｐ
ｈｃｌａｓｓ＞に対応している。従って、それは、 position <glyph * glyphclass> <glyph * glyphclass>
<valuerecord>,0; を表すより短い態様である。

【０１２８】従って、カーニングはＰａｉｒＰｏｓフォ
ーマットＡ及び＜ｖａｌｕｅｒｅｃｏｒｄ＞フォーマッ
トＡで最も容易に表現することが可能である。これは最
初のグリフのＹ前進を調節する場合である「ｖｒｋｎ」
特徴における場合を除いて、最初のグリフのＸ前進を調
節することとなる。幾つかの単一マスター例としては以
下のようなものがある。

【０１２９】 pos Y space -100; #特定対 pos＼101＼201 -200; #特定対 pos T [a e u] -100; #クラス対（第一グリフをクラスへ変換） pos＠T＠xheight -80; #クラス対 幾つかのマルチマスター例としては以下のようなものが
ある。

【０１３０】 pos Y space <-90 -100 -95 -105>; #特定対；４マスターフォント pos＠T [a e u] <-60 -70>; #クラス対；２マスターフォント 特定のグラフ対は特徴ファイル内におけるグリフクラス
対に先行すべきであり、それらがフォント内に格納され
る態様を鏡映する（特徴ファイル内のルックアップ及び
規則の順番付けに関しては以下の説明を参照）。

【０１３１】以下の形式のステートメントをカーニング
を定義するために使用することが可能である。

【０１３２】

【数２０】

【０１３３】以下の例においては、フォントに対する全
てのカーニングデータは「ｌａｔｎ」、「ｃｙｒｌ」、
「ｇｒｅｋ」のスクリプトの下で共用される。

【０１３４】

【数２１】

【０１３５】幾つかの特定のペア（ｐａｉｒ）即ち対を
クラス対としてより便利に表すが、ユーザがその対をク
ラスカーニングサブテーブル内に存在することを所望し
ない場合には、そのクラス対はキーワード「ｅｎｕｍｅ
ｒａｔｅ」（それは、「ｅｎｕｍ」として省略すること
が可能）によって先行されるべきである。このような対
は特定対として列挙される。従って、これらの対はクラ
ス対に対する「クラス例外」として考えることが可能で
ある。例えば、 ＠Y_LC=[y yacute ydieresis]; ＠SMALL_PUNC=[comma semicolon period]; enum pos＠Y_LC semicolon -80; #特定対 pos f quoteright 30; #特定対 pos＠Y_LC＠SMALL＿PUNC -100; #クラス対 上のｅｎｕｍ規則はフォント内の表現を変化させること
なしに以下のものと交換することが可能である。

【０１３６】 pos y semicolon -80; pos yacute semicolon -80; pos ydieresis semiclon -80; 特徴ファイルがコンパイルされる場合には、クラスオー
バーラップに起因して単一のサブテーブルを作成するこ
とができない場合には、クラス対規則のラン内にサブテ
ーブルブレークを挿入する。警告を発生すべきである。
例えば、 pos [Ygrave][colon semicolon] -55; #[line 99]第一サブテーブル内 pos [Y Yacute] period -50; #[line 100]第一サブテーブル内 pos [Y Yacute Ygrave] period -60; #[line 101]第二サブテーブル内 は、新たなサブテーブルがライン１０１において開始し
たこと、及びこのサブテーブル内の幾つかのカーニング
対は決してアクセスされる場合がないことの警告を発生
すべきである。上の例が全体的なルックアップを構成し
ている場合には対（Ｙｇｒａｖｅ，ｐｅｒｉｏｄ）は０
の値を有している。何故ならば、Ｙｇｒａｖｅは第一サ
ブテーブルの範囲内（即ち、第一グリフの結合）にある
からである。

【０１３７】時折、クラスカーニングサブテーブルは大
きくなり過ぎる場合がある。ユーザは、 subtable; を２つのクラスのカーニング規則の間において特定する
ことによって適宜の点に強制的にサブテーブルブレーク
を入れることが可能である。新たに形成されたサブテー
ブルは未だに同一のルックアップ内にあり、従ってユー
ザはそのようにして作成されたサブテーブルの範囲がオ
ーバーラップしないことを確保せねばならない。例え
ば、以下の通りである。

【０１３８】 pos [Y Yacute] period -50; #第一サブテーブル内 subtable; #サブテーブルブレークをここに強制挿入 pos [A Aacute Agrave] quoteright -30 #第二サブテーブル内 サブテーブルのステートメントが存在しない場合には、
両方の規則が同一のサブテーブル内で表される。

【０１３９】６．ｄ．［ＬｏｏｋｕｐＴｙｐｅ３］カー
シブ（ｃｕｒｓｉｖｅ）取付位置決めこのＬｏｏｋｕｐ
Ｔｙｐｅは以下のように表現される。

【０１４０】position cursive <glyph * glyphclass>
<anchor>, <anchor>; ＜ａｎｃｈｏｒ＞は＜ｇｌｙｐｈ*ｇｌｙｐｈｃｌａｓ
ｓ＞に対するエントリアンカー点を表しており、２番目
のものは出口アンカー点を示している。例えば、グリフ
ｍｅｅｍ．ｍｅｄｉａｌのエントリ点がｘ=５００，ｙ=
２０にあり且つ出口点がｘ=０、ｙ=-２０にあるように
定義するためには、 position cursive meem.medial 500 20, 0 -20; である。グリフは定義したエントリ点、出口点、又は両
方を有することが可能である。＜ａｎｃｈｏｒ＞フォー
マットＡは＜ａｎｃｈｏｒ＞が定義されていないことを
表すために使用される。

【０１４１】６．ｅ．［ＬｏｏｋｕｐＴｙｐｅ４］マー
ク対ベース取付位置決め この位置決め規則は、 position <base glyph * glyphclass> mark <mark glyp
h * glyphclass> <base anchor>; であり、尚＜ｂａｓｅａｎｃｈｏｒ＞は＜ａｎｃｈｏｒ
＞の形態のものである。マーク（ｍａｒｋ）グリフの全
てのアンカー点は「ｍａｒｋ」ステートメントによって
特徴ファイル内において前もって定義されていなければ
ならない。例えば、ａｃｔｅ及びｇｒａｖｅの前に定義
したアンカー点をグリフａ，ｅ，ｉ，ｏ，ｕのアンカー
点ｘ＝２５０，ｙ＝４５０に位置決めさせるためには、 position [a e i o u] mark [acute grave] 250 450; であり、キーワード「ｍａｒｋ」はＬｏｏｋｕｐＴｙｐ
ｅｓ４−６内のマークである＜ｇｌｙｐｈ*ｇｌｙｐｈ
ｃｌａｓｓ＞に常に先行する。

【０１４２】ｍａｒｋグリフに対するアンカー点は、最
初に、以下のマークステートメントによって定義されね
ばならない。

【０１４３】mark <mark glyph * glyphclass> <anchor
>; 例えば、ｃｈｕｔｅ及びｇｒａｖｅのマークグリフのア
ンカーがｘ＝３０，ｙ＝６００にあるように特定するた
めには、 mark [acute grave] 30 600; である。

【０１４４】６．ｆ．［ＬｏｏｋｕｐＴｙｐｅ５］マー
ク対合字取付位置決め このＬｏｏｋｕｐＴｙｐｅは、 position <ligature glyph * glyphclass> mark <mark glyph * glyphclass> <ligature anchors>; として表され、尚＜ｌｉｇａｔｕｒｅａｎｃｈｏｒｓ＞
は少なくとも２つの＜ａｎｃｈｏｒ＞のカンマで分離さ
れたリストである。そこには少なくとも２つ存在せねば
ならない。何故ならば、これがマーク対ベース取付位置
決め規則からこの規則を区別する唯一の態様だからであ
る。合字グリフ内に存在するコンポーネントと同数の＜
ａｎｃｈｏｒ＞が存在せねばならず、各＜ａｎｃｈｏｒ
＞は、順番が、１つの構成要素に対応している。特定の
構成要素がアンカー点を定義するものでない場合には、
その対応する＜ａｎｃｈｏｒ＞が「０」（＜ａｎｃｈｏ
ｒ＞ｆｏｒｍａｔＡ）に設定されねばならない。

【０１４５】ＬｏｏｋｕｐＴｙｐｅ４におけるように、
全てのマークグリフのアンカー点は「ｍａｒｋ」ステー
トメントによって前もって特徴ファイル内において定義
されていなければならない。このＬｏｏｋｕｐＴｙｐｅ
に対するＯｐｅｎＴｙｐｅ仕様における例は以下のよう
に表すことが可能である。

【０１４６】

【数２２】

【０１４７】６．ｇ．［ＬｏｏｋｕｐＴｙｐｅ６］マー
ク対マーク取付位置決め このＬｏｏｋｕｐＴｙｐｅは以下の如くに表される。

【０１４８】 position mark <base mark glyph * glyphclass> mark <mark glyph * glyphclass> <base mark anchor>; この規則は最初の「ｍａｒｋ」キーワードによってマー
ク対ベース取付位置決め規則から区別される。Ｌｏｏｋ
ｕｐＴｙｐｅ４におけるように、全てのマークグリフの
アンカー点は「ｍａｒｋ」ステートメントによって前も
って特徴ファイル内において定義されていなければなら
ない。このＬｏｏｋｕｐＴｙｐｅに対するＯｐｅｎＴｙ
ｐｅ仕様における例は以下のように表すことが可能であ
る。

【０１４９】

【数２３】

【０１５０】６．ｈ．［ＬｏｏｋｕｐＴｙｐｅ７］文脈
位置決め このＬｏｏｋｕｐＴｙｐｅは文脈位置決めをチェーン化
するＧＰＯＳＬｏｏｋｕｐＴｙｐｅ８の機能的サブセッ
トである。従って、このＬｏｏｋｕｐＴｙｐｅの全ての
所望の規則はチェーン化文脈位置決め規則によって表す
ことが可能である。

【０１５１】６．ｉ．［ＬｏｏｋｕｐＴｙｐｅ８］チェ
ーン化文脈位置決め このＬｏｏｋｕｐＴｙｐｅは以下のように表される。

【０１５２】 [except <glyph sequence list>] #この規則に対する例外（オプショ ン） position <marked glyph sequence> #マーク付けしたサブランを有する ターゲット文脈 by <valuerecord * anchor list>; #サブラン位置決め ＜ｖａｌｕｅｒｅｃｏｒｄ*ａｎｃｈｏｒｌｉｓｔ＞は
＜ｖａｌｕｅｒｅｃｏｒｄ＞及び＜ａｎｃｈｏｒ＞のカ
ンマで分離したリストである。

【０１５３】＜ｇｌｙｐｈｓｅｑｕｅｎｃｅｌｉｓｔ＞
及び＜ｍａｒｋｅｄｇｌｙｐｈ ｓｅｑｕｅｎｃｅ＞
は、＜ｍａｒｋｅｄｇｌｙｐｈｓｅｑｕｅｎｃｅ＞にお
けるサブランがＧＰＯＳＬｏｏｋｕｐＴｙｐｅ３−６の
ターゲット文脈において使用されるようにキーワード
「ｃｕｒｓｉｖｅ」及び「ｍａｒｋ」を包含することが
可能であることを除いて、チェーン化文脈置換に関する
セクションにおけるものと同一である。更に、各サブラ
ンと関連する＜ｖａｌｕｅｒｅｃｏｒｄ*ａｎｃｈｏｒ
ｌｉｓｔ＞における＜ｖａｌｕｅｒｅｃｏｒｄ＞又は＜
ａｎｃｈｏｒｓ＞の数はそのサブランをマーク付けする
ために使用される単一引用符又は二重引用符の数によっ
て表される。例えば、 position [Y T]′ [quoteright quotedblright] perio
d′space 20, -10; は、ターゲット文脈がマッチする場合に、Ｙ又はＴのＸ
前進を２０だけ増加し且つｐｅｒｉｏｄのＸ前進を１０
だけ減少させる。

【０１５４】以下の例、即ち、 position lam_meem_jeem''' mark sukun''' space ale
f′625 1800, 0,0, -5; においては、最初のサブランは、 lam_meem_jeem mark sukun # First sub-run である。これは＜ｖａｌｕｅｒｅｃｏｒｄ*ａｎｃｈｏ
ｒｌｉｓｔ＞からの３個の要素（このランをマーク付け
するために使用された３個の単一の引用符によって表さ
れている）を消費するマーク対合字取付ＬｏｏｋｕｐＴ
ｙｐｅ（マークキーワードに起因して）に対するターゲ
ット文脈として識別される。これらの要素は＜ａｎｃｈ
ｏｒ＞として解釈される。注意すべきことであるが、
「ｍａｒｋ」キーワードはグリフではないのでマーク付
けされていない。

【０１５５】上の例における２番目のサブランは以下の
ものである。

【０１５６】Alef これは単一位置決めＬｏｏｋｕｐＴｙｐｅに対するター
ゲット文脈として識別され、且つ＜ｖａｌｕｅｒｅｃｏ
ｒｄ*ａｎｃｈｏｒｌｉｓｔ＞から単一の要素を消費す
る。この要素は＜ｖａｌｕｃｅｒｅｃｏｒｄ＞として解
釈される。

【０１５７】７．特徴ファイルにおけるルックアップ及
び規則の順番付け ７．ａ．ＯｐｅｎＴｙｐｅレイアウト（ＯＴＬ）エンジ
ンのレイアウトアルゴリズム 特徴ファイルを作成するか又は編集するユーザは特徴フ
ァイルにおいて規則を適切に順番付けするためにどのよ
うにしてＯｐｅｎＴｙｐｅレイアウトエンジンが置換及
び位置決めを実施するかを理解すべきである。以下のも
のはそのアルゴリズムの要約である。

【０１５８】最初にＧＳＵＢに対して次いでＧＰＯＳに
対して以下のことを行う：クライエントのグリフランの
スクリプト及び言語に対する全ての特徴（必要とされる
特徴を含む）を集める。

【０１５９】全ての関連するルックアップをＬｏｏｋｕ
ｐＬｉｓｔの順番に集める。

【０１６０】各ルックアップに対して：該グリフラン内
の各グリフに対して：該Ｌｏｏｋｕｐ内の各サブテーブ
ルに対して：ターゲットグリフ又はグリフ文脈が見つか
った場合には：グリフ置換又は位置決めを行う。

【０１６１】該ラン内の次のグリフへ移行（即ち、残り
のサブテーブルをスキップ） ７．ｂ．ルックアップの順番付け ＯｐｅｎＴｙｐｅフォント内のルックアップは同一の特
徴、スクリプト、言語、ルックアップフラグ、及びルッ
クアップタイプ属性を有する規則の各ラン又は各ルック
アップブロックから作成される。ルックアップは１つ又
はそれ以上のサブテーブルを包含することが可能であ
る。サブテーブルブレークはフォーマット制限に起因し
て挿入されている場合があり、又は、それらはユーザに
よって特徴ファイルにおいて明示的に要求されている場
合がある。いずれの場合においても、サブテーブルは特
徴ファイル内の対応するサブテーブルと同一の順番で作
成される。

【０１６２】ルックアップは特徴ファイル内の対応する
ルックアップブロック又は規則のランと同一の順番で作
成される。注意すべきことであるが、ルックアップブロ
ックに対する参照はそのブロックから作成されたルック
アップのルックアップリストインデックスに対応してい
る。

【０１６３】７．ｃ．ルックアップ内の規則の順番付け ルックアップ内の規則の順番付けは文脈置換及び位置決
め規則をチェーン化する場合にのみ重要である。Ｌｏｏ
ｋｕｐＴｙｐｅの全てのその他の場合において（合字置
換を含む）、適宜の順番付けは自動的に導き出すことが
可能である。

【０１６４】８．全代替（ａａｌｔ）特徴 ａａｌｔ特徴が存在する場合には、その他の特徴の前に
特定されるべきである。ａａｌｔ内のグリフのセマンテ
ィクスが等価なグループは以下の如くにしてアルゴリズ
ムにより作成される。

【０１６５】（ａ）ａａｌｔ仕様（以下の例を参照）に
おける、 feature <feature tag>; によって表される特徴のみを考慮し、これらの特徴にお
ける全ての単一及び代替置換（チェーン化文脈規則内に
表れる単一置換を含む）をグループ内に結合させ、その
グループ内の第一グリフはその置換のターゲットグリフ
である。そのグループの後の要素は特徴ファイル内の関
連する規則の順番によって順番付けされる。重複するグ
リフは除去される。

【０１６６】（ｂ）ａａｌｔ仕様内の付加的な単一又は
代替置換をアルゴリズムによって作成されたグループへ
付加させる。このことは、例えば、あるグリフが上の
（ａ）において表された特徴のいずれにおいても参照さ
れなかった場合に、セマンティックグループを微調整す
るために与えられる。

【０１６７】（ｃ）１つのグループ内に２つのグリフが
存在するに過ぎない場合には、ａａｌｔ特徴内に単一置
換を作成する。１つのグループ内に２つを超える数のグ
リフが存在する場合には、ａａｌｔ特徴内に代替置換を
作成し、その第一グリフはターゲットグリフであり且つ
残りのグリフは代替組である。

【０１６８】例えば、

【数２４】

【０１６９】上の例から作成されたａａｌｔは、以下の
ものが特定された場合と同一である。

【０１７０】

【数２５】

【０１７１】９．テーブル値の特定又は上書き テーブル値は以下のように対応するテーブルブロック内
において特定される。

【０１７２】

【数２６】

【０１７３】サポートされる値はＢＡＳＥ、ＧＤＥＦ，
ｈｅａｄ，ｈｈｅａ，ｎａｍｅ，ＯＳ／２，ｖｈｅａで
ある。

【０１７４】９．ａ．ＢＡＳＥテーブル値 ＢＡＳＥテーブルエントリは以下の如くに特定すること
が可能である。

【０１７５】

【数２７】

【０１７６】＜ｓｃｒｉｐｔ ｒｅｃｏｒｄ＞は
以下の形式である。

【０１７７】 <script tag> <default baseline tag> <base coord>+ ＜ｂａｓｅｃｏｏｒｄ＞は幾つかのフォーマットをとる
ことが可能である（現在はフォーマットＡのみがサポー
トされる）。

【０１７８】 <number> #フォーマットＡ <number> <glyph> <number> #フォーマットＢ <number> <device> #フォーマットＣ ＜ｎｕｍｂｅｒ＞は、マルチ即ち複数個のマスターフォ
ントに対する場合であっても単一の数値である。何故な
らば、ベースラインはマスターに依存して変化すべきで
はないからである。例えば、マルチマスターフォントに
対する「欧文」ベースラインに対する＜ｂａｓｅｃｏｏ
ｒｄ＞は０である。

【０１７９】各ＢａｓｅＴａｇＬｉｓｔに対するベース
ラインタグは増加するＡＳＣＩＩ順番に格納されねばな
らない。特定のスクリプトに対するベースライン値の数
は対応するＢａｓｅＴａｇＬｉｓｔにおけるベースライ
ンタグの数と同一とすべきである。

【０１８０】＜ｍｉｎｍａｘ＞は次の形式である。

【０１８１】

【数２８】

【０１８２】９．ｂ．ＧＤＥＦテーブル ＧＤＥＦテーブルエントリは以下の如くにして特定する
ことが可能である。

【０１８３】

【数２９】

【０１８４】ＬｉｇａｔｕｒｅＣａｒｅｔに対して特定
した＜ｃａｒｅｔｖａｌｕｅ＞の数は、（合字構成要素
の数）・１でなければならない。

【０１８５】＜ｃａｒｅｔｖａｌｕｅ＞は３つのフォー
マットをとることが可能である。

【０１８６】

【数３０】

【０１８７】９．ｂ．ｈｅａｄテーブル ｈｅａｄテーブルエントリは以下の如くに特定すること
が可能である。

【０１８８】

【数３１】

【０１８９】９．ｃ．ｈｈｅａテーブル ｈｈｅａテーブルエントリは以下の如くに特定すること
が可能である。

【０１９０】

【数３２】

【０１９１】９．ｄ．名前テーブル 名前（ｎａｍｅ）テーブルエントリは以下の如くに特定
することが可能である。

【０１９２】

【数３３】

【０１９３】名前記録は以下の形式である。

【０１９４】 Nameid <id> [<string attribute>] <string>; ＜ｉｄ＞は名前テーブルへ付加すべき名前ストリングの
ＩＤを特定する番号である。この番号は登録したＩＤ範
囲０，７−２５５内のものでなければならない。注意す
べきことであるが、ＩＤ１-６（ファミリィ、サブファ
ミリィ、ユニーク、フル、バージョン、フォントネイ
ム）は予約されており且つ上書きすることは不可能であ
り、そうすることは警告メッセージを発生し且つ記録は
無視される。

【０１９５】オプションの＜ｓｔｒｉｎｇａｔｔｒｉｂ
ｕｔｅ＞は、名前テーブルの名前記録内に格納されるべ
きプラットフォーム、プラットフォーム特定、言語ＩＤ
を特定する１つ又は３つのスペース区切り付け番号（数
値）である。１つの番号が特定されているに過ぎない場
合には、それはプラットフォームＩＤを表す。プロット
フォームＩＤは、夫々、マッキントッシュ又はマイクロ
ソフトウインドウズプラットフォームに対応して１又は
３の何れかとすることが可能である。他のＩＤ番号は０
−６５５３５の範囲内のものでなければならないが、そ
うでない場合には有効なものとされない。

【０１９６】十進数の数値は０でない数字で開始せねば
ならず、八進数の数値は０の数字で開始せねばならず、
且つ十六進数の数値は数値及び十六進数文字ａ−ｆ又は
Ａ−Ｆに対するプレフィックス０ｘで開始せねばならな
い。

【０１９７】ストリング属性ＩＤ数値の幾つか又は全て
が特定されていない場合には、それらの値は以下の如く
にデフォルトが割り当てられる。

【０１９８】 platform ID 3（ウインドウズ） ウインドウズプラットフォーム選択： platspec ID 1（ユニコード） language ID 0x0409（ウインドウズデフォルト英語） マッキントッシュプラットフォーム選択： platspec ID 0（ローマン） language ID 0（英語） これら全てを一緒にすると以下の有効なｎａｍｅｉｄフ
ォーマット及び割り当てられるＩＤが得られる。

【０１９９】

【数３４】

【０２００】１つのストリング（ｓｔｒｉｎｇ）はＡＳ
ＣＩＩ二重引用符キャラクタ（”）によって取囲まれた
１バイトのＡＳＣＩＩキャラクタから構成されている。
そのストリング内に埋め込まれている新たなラインは格
納されるべきキャラクタシーケンスから除去される。

【０２０１】０の高バイトを付加することによってスト
リングはウインドウズプラットフォーム用のユニコード
へ変換される。ウインドウズプラットフォーム用の２バ
イトユニコード値は、バックスラッシュキャラクタ
（＼）とそれに続く全てがゼロとすることが不可能な正
確に４個の十六進数の数値、例えば＼４ｅ２ｄの特別キ
ャラクタシーケンスを使用して特定することが可能であ
る。ＡＳＣＩＩバックスラッシュキャラクタはシーケン
ス＼００５ｃ又は＼００５Ｃのように表されねばなら
ず、且つＡＳＣＩＩ二重引用符キャラクタはシーケンス
＼００２２として表せねばならない。

【０２０２】マッキントッシュプラットフォーム用のユ
ニコードに対しては対応する変換は存在しないが、１２
８-２５５範囲内のキャラクタコードを、バックスラッ
シュキャラクタ（＼）と両方をゼロとすることが不可能
な正確に２つの十六進数の数値からなる特別キャラクタ
シーケンス、例えば＼８３を使用して特定することが可
能である。ＡＳＣＩＩバックスラッシュキャラクタはシ
ーケンス＼５ｃ又は＼５Ｃとして表せねばならず、且つ
ＡＳＣＩＩ二重引用符キャラクタはシーケンス＼２２と
して表せねばならない。

【０２０３】例えば、マッキントッシュ及びウインドウ
ズプラットフォーム用の非ＡＳＣＩＩキャラクタを包含
するデザイナーの名前を付加するためには、以下の如く
に行う。

【０２０４】

【数３５】

【０２０５】９．ｅ．ＯＳ／２テーブル ＯＳ／２テーブルエントリは以下の如くに特定すること
が可能である。

【０２０６】

【数３６】

【０２０７】尚、＜ｐａｎｏｓｅｎｕｍｂｅｒ＞はホワ
イトスペースによって離隔されている１０（十進数）の
数値である。例えば、以下の如くである。

【０２０８】

【数３７】

【０２０９】マルチマスターフォントの場合には、ここ
で特定したＸＨｅｉｇｈｔ及びＣａｐＨｅｉｇｈｔメト
リクス（寸法）もＭＭＦＸテーブル内のそれらの名前付
きＩＤに格納され、そこにある値を上書きする。

【０２１０】９．ｆ．ｖｈｅａテーブル値 ｖｈｅａテーブルエントリは以下の如くに特定すること
が可能である。

【０２１１】

【数３８】

【０２１２】１０．匿名データブロックの特定 特徴ファイルは特徴ファイル処理プロセスのクライエン
トに対して送り戻されるデータの「匿名（ａｎｏｎｙｍ
ｏｕｓ）」タグ付きブロックを包含することが可能であ
る。このようなデータのブロックは、典型的に、特徴フ
ァイル処理プロセスが直接にサポートするものでないＯ
ｐｅｎＴｙｐｅフォントテーブルを特定するために必要
な情報を包含している。特徴ファイルパーサー即ち構文
解析器はそのデータをパース即ち構文解析することを試
みることはない。このような各ブロックは以下の如くに
特定される。

【０２１３】

【数３９】

【０２１４】閉じブレース、ｔａｇ、セミコロンは構文
解析器に対し匿名ブロックの終りを表すために全て同一
のライン上に存在せねばならない。ホワイトスペースは
このライン上のトークンの間に使用することが可能であ
り、且つセミコロンの後にコメントが続くことが可能で
ある。「ｉｎｃｌｕｄｅ」宣言は、「ａｎｏｎｙｍｏｕ
ｓ」から開始し閉じるラインの終りにおいて終了するそ
のブロック内において認識されることはなく、従ってブ
ロック全体は同一のファイル内に存在せねばならない。

【０２１５】クライエントヘ送り戻されるデータは始め
のブレースの後のラインの初めにおいて開始し且つ閉じ
ブレース前の新たなラインで終了する（且つそれを含
む）。上の例においては、タグ「ｓｂｉｔ」と共に、以
下のデータがクライエントヘ送り戻される。

【０２１６】

【数４０】

【０２１７】例Ｂ-サンプル特徴ファイル サンプルの特徴ファイルを以下の表に示してある。それ
は合字（ｌｉｇａｔｕｒｅ）及び巻ひげ文字（ｓｗａｓ
ｈ）置換特徴を特定する。スワッシュ（ｓｗａｓｈ）即
ち巻ひげ文字特徴は、ある単語の大文字の文字で始まり
その後小文字の文字が続いている場合には、その大文字
の文字をそのスワッシュ（ｓｗａｓｈ）即ち巻ひげ文字
で置換すべきであることを表す。

【０２１８】

【数４１】

【０２１９】本発明を特定の実施例について説明した。
その他の実施例も本発明の技術的範囲内に含まれること
は当然である。例えば、本発明のステップは異なる順番
で実施することが可能であり尚且つ所望の結果を得るこ
とが可能である。本発明は、ＰｏｓｔＳｃｒｉｐｔ Ｔ
ｙｐｅ １フォント、ＯｐｅｎＴｙｐｅフォーマットに
変換された場合にはＣＩＤをキーとしたフォント、及び
ＯｐｅｎＴｙｐｅフォント（ＴｒｕｅＴｙｐｅフォント
を含む）ヘ適用することが可能である。本発明は、アッ
プルアドバンストテクノロジィ（ＡＡＴ）フォントへ適
用することが可能であり、且つそれに対するテーブルを
発生するために使用することが可能である。グラフィカ
ルユーザインターフェース（ＧＵＩ）アプリケーション
が特徴を定義するためのフォントエディター（即ち、ユ
ーザ）に対するＧＵＩインターフェースを与えることが
可能である。例えば、ＧＵＩインターフェースを介し
て、ユーザはフォント内のすべてのグリフを示すパレッ
トからグリフを「合字定義（Ｄｅｆｉｎｅ Ｌｉｇａｔ
ｕｒｅ）」ボタン内へドラッグアンドドロップさせるこ
とが可能である。ＧＵＩアプリケーションは中間的なフ
ォーマットとしてそのデータを特徴ファイルフォーマッ
トで保存することが可能であり、次いで、ユーザが所望
する場合には、ユーザがそれをテキストエディターにお
いて微調整することが可能である。調整を行うか又は行
うことなしに次いで、特徴ファイルを上に説明したよう
にして使用することが可能である。このようなアプリケ
ーションはよりＧＵＩに傾倒したフォントエディターに
とって好ましいものであり且つアプリケーションプログ
ラマがＯｐｅｎＴｙｐｅテーブルのデータ構造を知るこ
とから解放させる。

【０２２０】以上、本発明の具体的実施の態様について
詳細に説明したが、本発明は、これら具体例にのみ制限
されるべきものではなく、本発明の技術的範囲を逸脱す
ることなしに種々の変形が可能であることは勿論であ
る。

【図面の簡単な説明】

【図１】 本発明方法を示したフローチャート。

【図２】 本発明方法を示したフローチャート。

【図３】 本発明を実施する場合に使用されるデータ構
造を示したグラフ図。

【図４】 本発明のコンピュータ実施例を示した概略
図。

【図５】 本発明のコンピュータ実施例を示した概略
図。

【符号の説明】

４０２ コンピュータシステム ４０４ 特徴ファイル ４１０ 特徴ファイル処理プロセス ４１２ 読取モジュール ４１４ 構文解析モジュール ４１６ 内部表現作成モジュール ４１８ 最適化モジュール ４２０ テーブル作成モジュール ４３０ 特徴ファイルデータ ４５０ グリフエイリアスデータベース ４６０ フォントファイル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジェレミー エイ． ホール アメリカ合衆国， カリフォルニア 95120， サン ノゼ， マイクロ プレ イス 1096

Claims (13)

【特許請求の範囲】
1. 【請求項１】 フォントへ活字特徴を付加する方法にお
   いて、 ハイレベル特徴定義言語で表現された特徴定義を包含す
   る特徴ファイルを用意し、 コンピュータプログラムにおける前記特徴ファイルを読
   取り且つ構文解析して前記特徴定義の内部表現を発生し
   且つ前記内部表現をコンピュータメモリ内に格納し、 前記特徴定義をフォントテーブル又はサブテーブル定義
   へ変換し、 前記テーブル又はサブテーブル定義をフォントファイル
   内へ書き出す、ことを特徴とする方法。
2. 【請求項２】 請求項１において、前記特徴定義言語が
   置換規則を定義するステートメント形式と位置決め規則
   を定義するステートメント形式とを有していることを特
   徴とする方法。
3. 【請求項３】 請求項２において、更に、 前記規則をタイプによってグループ化し且つ各グループ
   の規則に対して使用するための定義のテーブルフォーマ
   ットを決定すること、を有しており、前記フォントがＯ
   ｐｅｎＴｙｐｅフォントであり、前記フォントテーブル
   又はサブテーブル定義がＯｐｅｎＴｙｐｅ定義であり、
   且つ前記フォントファイルがＯｐｅｎＴｙｐｅフォント
   ファイルであることを特徴とする方法。
4. 【請求項４】 請求項１において、前記特徴定義言語が
   宣言論理ステートメントに基づいていることを特徴とす
   る方法。
5. 【請求項５】 請求項２において、更に、 ユーザフレンドリィグリフ名から最終的グリフ名を派生
   するためにグリフエイリアス用データベースを参照す
   る、ことを特徴とする方法。
6. 【請求項６】 請求項２において、更に、置換規則ステ
   ートメントから推論的に特定のフォントテーブル又はサ
   ブテーブルを識別し且つ前記置換規則ステートメントを
   前記識別した特定のフォントテーブル又はサブテーブル
   に対する定義へ変換し、 位置決め規則ステートメントから推論的に特定のフォン
   トテーブル又はサブテーブルを識別し且つ前記位置決め
   規則ステートメントを前記識別した特定のフォントテー
   ブル又はサブテーブルに対する定義へ変換する、ことを
   特徴とする方法。
7. 【請求項７】 請求項２において、前記特徴定義言語が
   宣言論理ステートメントに基づいており、且つ前記特徴
   定義言語がサブテーブルフォーマット選択を表現するた
   めの構成体を有するものではなく、本方法が、更に、 前記特徴定義からユーザの介入なしで共用データ構成体
   を作成し且つ前記特徴定義をＯｐｅｎＴｙｐｅフォント
   ファイル内へ書き出す前に冗長性を除去し、且つＯｐｅ
   ｎＴｙｐｅテーブルに対するサーテーブルフォーマット
   オプションの寸法を計算し且つ対応する特徴定義を書き
   出すための最も小さなオプションを選択する、ことを特
   徴とする方法。
8. 【請求項８】 フォントへ活字特徴を付加すべく動作可
   能なシステムにおいて、 命令プロセサと、ランダムアクセスメモリと、データフ
   ァイルメモリとを具備するプログラム可能なコンピュー
   タ、 ハイレベル特徴定義言語で表現されている特徴定義を包
   含している特徴ファイルを読取る手段、 前記特徴定義の内部表現を発生するために前記特徴ファ
   イルを構文解析する手段、 前記内部表現を前記ランダムアクセスメモリ内に格納す
   る手段、 前記特徴定義をフォントテーブル又はサブテーブル定義
   へ変換する手段、 前記テーブル又はサブテーブル定義を前記データファイ
   ルメモリ内に格納されているフォントファイル内へ書き
   出す手段、を有していることを特徴とするシステム。
9. 【請求項９】 フォントへ活字特徴を付加するためのコ
   ンピュータプログラムが格納されているコンピュータに
   よって読取可能な記録媒体において、 前記コンピュータプログラムが、コンピュータをして、 ハイレベル特徴定義言語で表現されている特徴定義を包
   含する特徴ファイルを読取らせ、 前記特徴定義の内部表現を発生するために前記特徴ファ
   イルを構文解析させ、 前記内部表現をメモリ内に格納させ、 前記特徴定義をフォントテーブル又はサブテーブル定義
   へ変換させ、 前記テーブル又はサブテーブル定義をフォントファイル
   内へ書き出させる、上記各命令を有していることを特徴
   とする記録媒体。
10. 【請求項１０】 請求項９において、更に、コンピュー
    タをして、 置換規則を定義するステートメント形式及び位置決め規
    則を定義するステートメント形式を処理させる、命令を
    有していることを特徴とする記録媒体。
11. 【請求項１１】 請求項１０において、更に、コンピュ
    ータをして、 前記規則をタイプによってグループ化させ且つ各グルー
    プの規則に対して使用するための適宜のテーブルフォー
    マットを決定させる、上記命令を有していることを特徴
    とする記録媒体。
12. 【請求項１２】 請求項１０において、前記特徴定義言
    語が宣言論理ステートメントに基づいていることを特長
    とする記録媒体。
13. 【請求項１３】 請求項１０において、更に、コンピュ
    ータをして、 ユーザフレンドリィグリフ名から最終的グリフ名を派生
    させるためにグリフエイリス用データベースを参照させ
    る、上記命令を有していることを特徴とする記録媒体。