agl specification
Version 2.9
©1997–2019 Adobe。
このドキュメンテーションファイルのコピーを取得して、ドキュメントのコピーを使用、コピー、公開、配布、サブライセンス、および/または販売し、他の人が同じことを許可するように、許可は無料で許可されます。
このドキュメントの変更、編集、またはその他の変更は許可されていません。そして
上記の著作権通知とこの許可通知は、ドキュメントのすべてのコピーに含まれるものとします。
このドキュメントファイルのコピーを入手し、このドキュメントのコンテンツから独自のデリバティブ作業を作成して、デリバティブ作業を使用、コピー、公開、公開、配布、サブライセンス、および/またはデリバティブワークを販売することを許可し、派生作業がこのドキュメントのコピーまたはバージョンとして表現されていない場合、他の人を許可するために、許可が無料で許可され、無料で許可されます。
Adobeは、不法行為（過失または厳格責任を含む）、契約またはその他の法的または公平な理由に基づいていても、収入または利益の損失、または間接的、偶発的、特別な、結果、またはその他の同様の損害について、いかなる当事者にも責任を負わないものとします。アドビの材料は、「現状のまま」で提供されます。 Adobeは、Adobe資料に関する商品性または適合性に関するものを含むがこれらに限定されないAdobe資料に関連するすべての明示的、法定、または黙示的な保証を具体的に放棄します。
Adobeは、この仕様の主題に関する特許を取得していません。
ドキュメントバージョン2.9。最終更新2019年8月21日
Adobe Glyphリストの仕様の目的は、一連のグリフ名からのユニコード文字列の計算を記述することです。これは、グリフ名からユニコード文字文字列へのマッピングを指定することで実現されます。
マッピングは、基礎となるセマンティクスを保存しながら、一連のグリフ名をプレーンテキストに変換することを目的としています。たとえば、「A」のグリフ名、「Small Capital A」のGlyph名、および「A」のスワッシュバリアントのGlyph名はすべて同じUV（ Unicode値）にマッピングされます。これは、一部の環境でテキストをコピーするのに役立ち、「A」に対応する元の文字列のすべてのGlyph名と一致するテキスト検索を実行するのにも役立ちます。
合法的なグリフ名のセットを決定するのは、この仕様の範囲外です。グリフ名は多くの異なるコンテキストで発生し、それぞれが法的名を構成するものの独自の定義を持っています。この仕様は、グリフ名がユニコード文字の任意の有限シーケンスに対応することのみを想定しています。
仕様は、AGL（ Adobe Glyphリスト）で構成されており、Glyph名の分解と解釈のルールとともに、特定のGlyph名をUnicode値にマッピングします。この仕様は多くのソフトウェアに実装され、使用する可能性が低いすべての実装を修正することが予想されるため、この仕様は安定することを目的としているため、実質的な方法で修正されることはありません。特に、AGLにマッピングが追加されないことを意図しています。また、AGLは、新しいフォントのGlyph名を選択するためのガイドとして機能することを意図したものではありません。その目的のために、AGLFN（新しいフォントのAdobe Glyphリスト）が存在します（セクション6を参照）。
この仕様は、Unicodeスカラー値の全範囲、U+0000からU+10ffffをサポートしています。特定のUnicodeバージョンの文字レパートリーに依存しません。したがって、Unicode標準の過去、現在、および将来のバージョンに適用できます。
フォント生産者は、グリフをフォントに命名する際に、この仕様を尊重することを強くお勧めします。フォント消費者は、グリフ名からコンテンツを導き出そうとするときに、この仕様に従うことをお勧めします。
グリフ名を文字列にマッピングするには、以下の3つのステップに従ってください。
Glyph名からすべての文字をドロップします。
残りの文字列を、デリミッターとしてアンダースコア（U+005Fローライン）を使用して、コンポーネントのシーケンスに分割します。
以下の手順に従って各コンポーネントを文字文字列にマップし、それらの文字列を連結します。その結果、Glyph名がマッピングされている文字文字列があります。
フォントがzapf dingbats（postscript fontname： zapfdingbats ）の場合、コンポーネントがITC zapf dingbats glyphリストにある場合、そのリストの対応する文字にマッピングします。
それ以外の場合、コンポーネントがAGLにある場合は、そのリストの対応する文字にマップします。
それ以外の場合、コンポーネントが「uni」（u+0075、u+006e、およびu+0069）の形式である場合、次に大文字とa – fのシーケンス（0–9およびa – f（u+0030からu+0039およびu+0041 seu u+0046を意味します）、それぞれのグループの場合、それぞれのグループの場合は、4つの額を表しています。範囲0000からD7FFまたはE000からFFFFで、それぞれをUnicodeスカラー値として解釈し、コンポーネントをそれらのスカラー値で作成した文字列にマッピングします。範囲と数字の長さの制限は、「Uni」Glyph名のプレフィックスは、基本的な多言語平面（BMP）のUVSでのみ使用できることを意味することに注意してください。
それ以外の場合は、コンポーネントが「u」（u+0075）の形式である場合、次に4〜6匹の大文字の桁数（0–9およびa – f、u+0030からu+0039およびu+0041からu+0046を意味する）のシーケンスがあり、それらの桁はd7ffを超えてd7ffを介してd7ffを介した値を表しています。スカラー値とコンポーネントをこのスカラー値で作成した文字列にマッピングします。
それ以外の場合は、コンポーネントを空の文字列にマップします。
「lcommaaccent」という名前には、AGLによって文字列u+013bにマッピングされた単一のコンポーネントがあります。
「uni20ac0308」という名前には、文字列u+20ac u+0308にマッピングされた単一のコンポーネントがあります。
「U1040C」という名前には、文字列u+1040cにマッピングされた単一のコンポーネントがあります。
「unid801dc0c」という名前には、空の文字列にマッピングされた単一のコンポーネントがあります。 D801もDC0Cも適切なセットにありません。このフォームを使用して、UTF-16でD801 DC0C、特にU+1040Cとして表される文字にマッピングすることはできません。この文字は、Glyph名「U1040C」を使用して正しくマッピングできます。
「uni20ac」という名前には、空の文字列にマッピングされた単一のコンポーネントがあります（小文字「A」と「c '）。
名前 'lcommaaccent_uni20308_u1040c.alternate'には、「lcommaaccent」、「uni20ac0308」、および「u1040c」という3つのコンポーネントがあります。文字列u+013b u+20ac u+0308 u+1040cにマッピングされます。
通常、複数の名前を同じ文字列にマッピングできます。たとえば、コンポーネント「lcommaaccent」、「uni013b」、および 'u013b'はすべて、文字列u+013bにマップします。
「foo」は空の文字列にマッピングされます。「foo」はAGLではなく、「u」で始まっていないためです。
名前 '.notdef'は最初のステップで空の文字列に縮小され、3番目のステップの最後の句によって空の文字列にマッピングされます。
この仕様は、PUA値を含む文字列へのグリフ名のマッピングをサポートしています。たとえば、「ogoneksmall」と「unif6fb」という名前は、両方ともu+f6fbに対応する文字列にマップします。
この仕様には、特定のPUAの使用法は含まれていません。復元された文字文字列にPUAコードポイントが含まれるように、グリフの命名を許可するだけです。 PUAの使用に関する合意を確立するのは、Glyph名の生産者と消費者次第です。
フォント設計者は、汎用フォントのユーザーと本契約を確立することは難しい場合があることに注意する必要があります。 Glyph名から構築された文字文字列を操作するすべてのツールがPUAの使用量を正しく実装するわけではなく、これが誤った機能または予期しない機能につながる可能性があります。したがって、汎用フォントの場合、すべてのGlyph名がPUAコードポイントを含まない文字列に変換することをお勧めします。
この仕様は時間とともに進化してきました。変更については、セクション7（ドキュメント変更）を参照してください。
Unicode標準の文字に対応するグリフの場合、セクション2の規則に従って、基本的な多言語平面（BMP）の文字に「UNI」プレフィックスと16の補足平面の文字の短い「U」プレフィックスを使用して名前を指定することをお勧めします。
これは、グリフ名に「UNI」および「U」プレフィックスを使用せずに作成された場合、フォントが無効であることを意味するものではありません。例外の1つのグループを除いて、AGLのすべてのGlyph名は現在、すべての既知の環境で機能し、「Uni」プレフィックスを使用した名前を付けています。例外は、PUAコードポイントに関連付けられているAGLグリフ名です。これらには、すべての上司と小さなキャップ名が含まれます。これらの名前の使用は、テキストを検索する目的で、現在の実装を導き、「asmall」などの名前を「a」の場合ではなく、AGLで指定されたPUA値にマッピングします。このセクションで指定されたルールに従って、これらのグリフを命名することをお勧めします。 PUAに関連付けられた名前を除外するAGLのサブセットは、AGLFN（新しいフォントのAdobe Glyphリスト）によって提供されます。
フォント内の複数のグリフが、「A」や「A.swash」などのUnicode標準の同じ文字を表している場合、異なる接尾辞を持つ同じベース名を使用することで区別できます。サフィックス（最初の期間に続くグリフ名の部分）は、文字シーケンスの計算に関与しません。フォントデザイナーは、グリフの特別な特性を示すために使用できます。接尾辞には、期間またはその他の許可された文字が含まれる場合があります。たとえば、小さなキャップ「A」には「uni0041.sc」または「a.sc」という名前が付けられます。
同じベースグリフの複数のバリアントがある場合、バリアントの接尾辞には、グリフ名がソートされた場合、意図された順序を保存できるように、ゼロパッド固定長桁を含める必要があります。たとえば、「Ampersand」Glyphに23の代替形式がある場合、それらは「Ampersand.alt」ではなく、「Ampersand.alt23」を介して「ampersand.alt01」と呼ばれます。このルールは、フォントの開発とテストのためのわずかな利便性のみを提供します。上記のように、これらのグリフ名の接尾辞は、文字シーケンスの計算に関与しません。
この仕様では、接尾辞のいずれも標準化されません。任意の接尾辞は、テキスト検索の目的で機能します。開発とテスト中に便利なため、Adobeは最も適切なOpenTypeレイアウト機能名を接尾辞として使用します。たとえば、小さなキャップ「A」には、「a.smcp」、初期フォーム「a.init」、最終フォーム「a.fina」、およびスワッシュフォーム「a.swsh」と名付けられました。追加のスワッシュフォームがある場合、「A.swsh1」、「A.swsh2」などと呼ばれる可能性があります。以下は、Adobeのフォントで使用されている接尾辞の例です。
Unicode標準のキャラクターに対応しないグリフの場合、名前には技術的な有用性がありません。名前がこのドキュメントのルールに従ってセマンティック値を持っていると解釈されない限り、すべての名前を割り当てることができます。 Adobeのタイプ開発チームの実践は、グリフに有用な説明タグがある場合、「マウス」、「Signforsale」、「Christmastreeball12」など、それに応じて名前を付けます。それ以外の場合は、「orn001」、「orn123」など、「orn」（飾りの略）のバリアントとして名前を付けます。
標準的なユニコード文字の結晶を表すグリフの場合、次のようにグリフ名に2つの推奨形式があります。
記述分解は、標準のユニコード文字のGlyph名を結合して、アンダースコア（U+005F低線）を使用して表現されます。文字のグリフ名は、「uni」または「u」のプレフィックスを指定し、上記のように上記の16進数桁を使用するか、AGLの名前を使用する必要があります。たとえば、「Off I」の結紮は「O_F_F_I」と名付けられるべきです。
'uni'プレフィックス付きUVグリフ名は、プレフィックス「uni」として表され、その後に4つの大文字の16進数桁の2つ以上のシーケンスが続きます。 4つの大文字の16進数の各シーケンスは、BMP内のユニコードスカラー値を順番に指定します。たとえば、ラテン語のキャピタルレターezhはu+01b7であるため、circodeと墓のないキャラクターラテンキャピタルレターEzhは、uniCodeにないcircirflexと墓を描いている必要があります。 「T.swash」と「H」という名前のグリフの結晶は、「T_H.Swash」と名付けられます。 「T.swash_h」は、「t」のグリフバリアントとして解釈されるため、間違っています。すべてのグリフ名は63文字の長さ制限の対象であり、次のセットの文字で完全に構成される必要があります：a – z、a – z、0–9、 '。' （期間; u+002eフルストップ）、および '_'（アンダースコア; u+005fローライン）。いくつかの古い実装では、31文字の長さ制限が課される場合があります。
過去の実装の問題とGlyph名の結果的な制限の簡単なレビューは、ドキュメントGlyph名と現在の実装（2003-01-31のバージョン1.1に基づく）に記載されています。
はじめにこの記事には、現在の実装に関するコメントが含まれているため、この記事は強く日付です。 2002年10月以降に読んでいる場合は、これを念頭に置いてください。
（ロンガーなしで利用できない）記事UnicodeおよびGlyph名の命名規則に従って、Glyph名が使用される場所と理由は、現在、PDF（ポータブルドキュメント形式）ドキュメントでテキストをコピーしてテキストを検索して、これらの慣習に従わない名前や名前を持たない名前を持たない場合よりも、より広範な状況でテキストを検索することができます。多くのドキュメントが役立つために検索可能でなければならないインターネットの時代では、これは非常に重要です。
多くのPDFファイルは、ドキュメントで参照されている元のフォントが使用できず、埋め込まれたフォントデータを使用する必要がある場合、PostScriptプリンターファイルから作成されています。この場合、OpentypeフォントのUnicode 'cmap'テーブルは使用できません。PDFプロデューサーがGlyphのセマンティクスについて持っている可能性のある唯一の手がかりは、その名前です。
元のフォントファイルが利用可能であっても、Unicodeの文字に直接対応しないグリフは、その名前を介してUnicode文字に有用に接続される場合があります。たとえば、「T」の装飾的なバリアントを「T.ALT」と名付けて、PDFプロデューサーが「T.ALT」が検索やその他の目的のために「T」と同じセマンティクスを運ぶことができることに注意することができます。
将来的には、Adobe自身の製品よりも多くの製品がグリフのユニコードベースのテキスト文字列検索をサポートすることが期待されています。つまり、これらのルールの有用性の範囲ははるかに広くなります。
Glyph名を完全に欠落している可能性のあるTrueTypeフォントの場合、「CMAP」テーブルにグリフのユニコード値が存在すると、ほとんどの場合、グリフがユニコード文字に正しく関連付けられます。ただし、Unicodeコードポイントからマップしないグリフの場合、以前のコメントが適用されます。
UnicodeのBMPでエンコードされているグリフには、プレフィックス「U」がまだ推奨されていないのはなぜですか？接頭辞「U」は、Acrobatバージョン4および5でサポートされていません。Acrobatバージョン6以降でサポートされるようになりました。これは、BMP（基本多言語平面）外のユニコード文字のサポートが導入された場合でもあります。 '。'。 「_」解析ルールは、Acrobatバージョン4および5ですでにサポートされています。
西部のOpentype/CFFおよびTrueTypeフォントの名前のグリフの長さと文字セットの制限は、多くのワークフローで名前キーのフォントデータとして参照する必要があります。その結果、Glyph名は、タイプ1の仕様とPostScriptインタープリターの実装によって課される長さと文字セットの制限の対象となります。これらはどちらも、グリフ名の長さが31文字以下ではないことを指定していますが、実際には現代の環境では、グリフ名は63文字から63文字である可能性がありますが、数字や期間から始めてはなりません。
これらの要件の唯一の例外は、特別な「.notdef」グリフです。
たとえば、「Twocents」、「A1」、および「_」は有効なGlyph名ですが、「2cents」と「.twocents」はそうではありません。
多くのアプリケーションのATMとカーニングのペアフィルタリング、OpenTypeフォントでのKerningのサポートは、ATMのWindowsおよびMacintoshバージョン（ Adobe Type Manager ）によって限定的に提供されました。この制限は、Opentype-Awareではないほとんどのアプリケーションが、フォント内のすべてのKerningペアが合理的にフィットすることが1つのテーブルであり、数千のKerningペアが存在することを想定しているためです。これよりも多くのカーニングペアを提供すると、そのようなアプリケーションがクラッシュしました。 OpentypeレイアウトでクラスベースのKerningがサポートされているため、220のグリフのみを備えたフォントでさえ、通常、この制限を超えています。多くの現在のアプリケーションをクラッシュせずにこのようなオペティエフォントを使用できるようにするために、ATMは、クラスベースのカーニングを単一のGlyph-Nameペアのリストに完全に拡張し、ハードコーディングされたGlyph名のリストを介してこのリストをフィルタリングすることにより、レガシーOSベースのAPIを介してKerningをサポートしました。 Kerningペアの両側にあるグリフ名がフィルターリストに存在しなかった場合、カーニングペア全体が省略されました。 Windows 95およびMac OS 9のKerningペアフィルタリングリストとWindows NTおよびWindows 2000のフィルタリングリストは、使用できなくなりました。
バージョン2.9（2019年8月21日）編集上の更新。
バージョン2.8（2018年8月9日）Glyph名の長さの制限は、現在のプラクティスと実装を反映するために31〜63文字に調整され、いくつかの古い実装が31文字の制限を課す可能性があることに注意してください。
バージョン2.7（2017年8月12日）編集上の変更を伴うGlyph名と現在の実装というタイトルの外部文書は、セクション6に追加されました。
バージョン2.6（2015年3月28日）GitHubに移行することに関連するマイナーな編集改訂。
バージョン2.5（2010年11月10日）オープン仕様にすることに関連するマイナーな編集改訂。
バージョン2.4（2003年9月24日）マイナーな改訂。新しいフォントのAdobe Glyph名の先の尖ったURL。
バージョン2.3（2003年4月17日）マイナーな改訂。 「Uni」プレフィックスをBMP Unicode値でのみ使用できることを明確にするために、短い文を追加しました。
バージョン2.2（2003年1月31日）マイナーな改訂。新しいフォントを作成するときに使用するグリフ名のリストへのリンクを追加し、AGLバージョン2.0はこの目的のためのものではなく、フォントでグリフをエンコードすることでもないことを強調しました。
バージョン2.1（2002年11月4日）マイナーリビジョン。新しいフォントでのGlyph名の割り当てに関するセクションを拡張します。
バージョン2.0（2002年9月20日）主要な改訂。グリフ名のユニコードスカラー値への変換に文書を焦点を当て、AGLに多くの名前を追加します。 zapfdingbatsリストのUnicodeバージョン3.2への更新。
バージョン1.1（1998年12月17日）は、一般的に文書全体を改訂しました。ほとんどのテーブルとデータファイルを更新しました。グリフ名の選択に関するセクションを追加しました。拡張されたセマンティクスを抽出するための擬似コードは、非統合の結紮糸とグリフのバリアントを含むように拡張されました。ダブルマッピング用の個別のデザインの提供に関するセクションを追加しました。 WGL4との不一致に関するセクションを削除しました（もはや該当しません。WGL4が更新されました）。
バージョン1.0（1997年11月10日）最初のバージョン。
