7。文字エンコーディングのLaTexのモデル

この記事では、Latexエンコーディングについて詳しく説明しています。ラテックスシステム内のキャラクターデータフローの議論から始まります。次に、LaTex内の文字データの内部表現モデルを詳しく調べ、その後、入力エンコーディングを介してその内部表現に入力するデータをマッピングするために使用されるメカニズムの議論が続きます。最後に、出力エンコーディングを介して内部表現が版形設定に必要なフォームにどのように翻訳されるかを説明します。

7.1。ラテックス内の文字データフロー

LaTexでドキュメントを処理することは、1つ以上のソースファイルに存在するデータを解釈することから始まります。ドキュメントコンテンツを表すこのデータは、文字を表すオクテットのシーケンスとしてソースファイルに保存されます。これらのオクテットを正しく解釈するには、ファイルを処理するために使用されるプログラム(ラテックスを含む)は、抽象文字とそれらを表すオクテットの間のマッピングを知る必要があります。言い換えれば、ファイルが記述されたときに使用されたエンコードを知る必要があります。

マッピングが誤っている場合、ファイルに正しいエンコーディングと誤ったエンコーディングの両方で共通のサブセットの文字のみが含まれていない限り、すべてのさらなる処理は多かれ少なかれ誤りになります。ラテックスはこの時点で基本的な仮定を行います。ほとんどすべての目に見えるASCII文字(10進32-126)は、ASCIIコードテーブルにある数で表されます。

$目に見えるASCII文字$

この仮定の理由の1つは、今日使用されているほとんどの8ビットエンコーディングが共通の7ビット平面を共有していることです。もう1つの理由は、TEXを効果的に使用するには、ASCIIの可視部分の大部分をカテゴリ *文字 *の文字として処理する必要があることです。このカテゴリの文字のみがTexまたはカテゴリ *のマルチキャラクターコマンド名で使用できるからです。

キャラクター(または、より正確には、8ビット番号)がTexのカテゴリ *文字 *または *その他 *であると宣言されると、この8ビット番号はTexを透過的に渡されます。つまり、Texは、その数で扱われている位置にあるフォントにあるシンボルがすべて入力されます。

前述の仮定の結果として、一般的なテキストに使用することを目的としたフォントでは、目に見えるASCII文字のほとんどがフォントに存在し、ASCIIエンコードに従ってエンコードされる必要があります。

入力ファイルに存在する可能性のある他のすべての8ビット番号(外側のASCIIの外側)には、 *Active *のカテゴリコードが割り当てられているため、Tex内のコマンドのように動作します。したがって、ラテックスは、入力エンコーディングを介してそれらをフォームに変換できます。これは、 *LaTex内部文字表現(LICR) *と呼ばれます。

UnicodeのUTF8エンコーディングについては、同様に処理されます。 ASCII文字はそれ自体を表し、マルチバイト表現の開始オクテットは、残りのオクテットの入力をスキャンするアクティブな文字として機能します。結果は、Mappedの場合、LICRのオブジェクトに変換されます。または、指定されたUnicode文字がマッピングされていない場合、LaTexがエラーをスローします。

LICRのオブジェクトの最も重要なことは、7ビットASCII文字の表現が、すべての入力エンコーディングが目に見えるASCIIに関して透明であると想定されるため、エンコードの変更に不変であることです。その後、出力(またはフォント)エンコーディングが機能し、内部文字表現を、植チングに使用される現在のフォントのGlyph位置にマッピングします。たとえば、いくつかのシンボル(現在のフォントの別の位置)にアクセント(現在のフォントの1つの位置に存在する)を配置して、内部文字エンコーディングのコマンドで表される抽象文字の印刷画像を取得できます。

LICRは、LaTex内でアドレス指定可能なすべての可能な文字をエンコードします。したがって、単一のTexフォント(最大256のグリフを含むことができる)で表すことができる文字の数よりもはるかに大きいです。場合によっては、内部エンコードの文字は、アクセント付き文字などのグリフを組み合わせることでフォントでレンダリングできます。ただし、内部文字が特別な形状を必要とする場合、そのグリフがフォントに存在しない場合、それを偽造する方法はありません。

それにもかかわらず、キャラクターエンコーディングのLaTexのモデルは、さまざまなフォントからグリフを取得するための自動メカニズムをサポートしているため、現在のフォントに欠けている文字がタイプセットを取得します。

7.2。ラテックスの内部文字表現(LICR)

テキスト文字は、3つの方法のいずれかでラテックスによって内部的に表されます。

文字としての表現

少数の文字は「文字そのもの」で表現されます。例えば、ラテン文字のAは文字「A」として表現されます。これらの文字は上記の表に示されています。これらは可視ASCII文字のサブセットを形成し、TeX内ではすべて文字またはその他のカテゴリコードが割り当てられています。可視ASCII文字範囲の一部は、TeX構文の一部であるか、すべてのフォントに存在しないため、このように表現されません。例えば、テキストで「<」を使用した場合、現在のフォントエンコーディングによって、印刷出力に<（T1）が表示されるか、あるいは反転した感嘆符（OT1）が表示されるかが決まります。

文字シーケンスとしての表現

TeXの内部合字機構は、入力文字のシーケンスから新しい文字を生成することができます。これは実際にはフォントの特性ですが、一部の合字シーケンスは、ほとんどのキーボードでは入力が難しい文字の入力ショートカットとして明示的に設計されています。このように生成される文字のうち、LaTeXの内部表現に属すると考えられるのはごくわずかです。これには、合字--と---によって生成されるenダッシュとemダッシュ、そして````と`''`によって生成される開始二重引用符と終了二重引用符（後者は通常、単一の`"`でも表すことができます）が含まれます。ほとんどのフォントは、反転した感嘆符と疑問符を生成するために`` !`と`` ? ```も実装していますが、これはすべてのフォントで普遍的に利用できるわけではありません。そのため、**すべての**これらの文字には、コマンド（例：\textendashまたは\textexclamdown`）という代替の内部表現が用意されています。

「フォントエンコード固有の」コマンドとしての表現

キャラクターの大部分をカバーするLaTexで内部的にキャラクターを表す3番目の方法は、ファイルに書き込まれたとき、または移動引数に配置されたときに延長されたままである特別なLaTexコマンド(またはコマンドシーケンス)を使用します。そのような特別なコマンドは、 *フォントエンコード固有のコマンド *と呼びます。なぜなら、その意味は、LaTexがそれらを入力する準備ができているときに現在使用されているフォントエンコードに依存するためです。このようなコマンドは、以下で説明する特別な宣言を使用して宣言されます。通常、各フォントエンコードの個々の定義が必要です。現在のエンコーディングに定義が存在しない場合、デフォルトが使用され(利用可能な場合)、またはユーザーにエラーメッセージが表示されます。ドキュメントのある時点でフォントエンコードが変更されると、エンコード固有のコマンドの定義はすぐには変更されません。代わりに、これらのコマンドは、使用されると、現在の定義がフォントエンコードに適していないかどうかに気付くように実装されます。そのような場合、彼らは実際の作業を行うために現在のフォントエンコードでカウンターパートを呼び出します。

フォントエンコード固有のコマンドのセットは固定されていませんが、個々のフォントエンコーディングに対して定義されたすべてのコマンドの結合として暗黙的に定義されます。したがって、新しいフォントエンコーディングがLATEXに追加されると、新しいフォントエンコード固有のコマンドが必要になる場合があります。

7.3。入力エンコーディング

inputenc パッケージがロードされると、8 ビット入力文字を LICR オブジェクトにマッピングするための 2 つの宣言 \DeclareInputText と \DeclareInputMath が使用可能になります。これらの宣言は、エンコードファイル（下記参照）、パッケージ、または必要に応じてドキュメントのプリアンブル内でのみ使用してください。

これらのコマンドは、最初の引数として 8 ビットの数値を取ります。数値は、10 進数、8 進数、または 16 進数で指定できます。10 進数表記を使用することをお勧めします。これは、言語サポートパッケージでは、文字 ' や " がアクセント記号のショートカットなど特別な意味を持つ場合があり、パッケージが間違った順序でロードされると 8 進数表記や 16 進数表記が無効になる可能性があるためです。

1\DeclareInputText{number}{LICR-object}

\ declareInputTextコマンドは、テキストで使用する文字マッピングを宣言します。その2番目の引数には、エンコード固有のコマンド(またはコマンドシーケンス)が含まれています。これは、文字番号をマッピングするLICRオブジェクトです。例えば、

1\DeclareInputText{239}{\"\i}

数値 239 を、エンコード固有の ‘i-ウムラウト’ 表現である \"\i にマッピングします。このように宣言された入力文字は数式では使用できません。

1\DeclareInputMath{number}{math-object}

数値が数式で使用する文字を表している場合、宣言「\ declareInputmath」を使用する必要があります。たとえば、 cp437de(ドイツのms-dosキーボード)をエンコードする入力で、

1\DeclareInputMath{224}{\alpha}

数値 224 をコマンド \alpha にマッピングします。この宣言により、この数値を生成するキーは数式モードでのみ使用可能になります。\alpha は他のモードでは使用できないためです。

1\DeclareUnicodeCharacter{hex-number}{LICR-object}

この宣言はオプション utf8 が使用されている場合にのみ利用可能です。これはUnicodeの数値をLICRオブジェクト（つまりテキストで使用可能な文字）にマッピングします。例えば、

1\DeclareUnicodeCharacter{00A3}{\textsterling}
2\DeclareUnicodeCharacter{011A}{\v E}
3\DeclareUnicodeCharacter{2031}{\textpertenthousand}

理論上は、2つの空間の間には一意の双方向マッピングが1つだけ存在するはずなので、utf8 オプションが選択されると、そのような宣言はすべて自動的に行われるはずです。しかし実際には、状況はもう少し複雑です。まず、テーブル全体を自動的に提供すると、TeX のメモリが大量に必要になります。さらに、LICR オブジェクトが存在しない Unicode 文字が多数存在し、逆に Unicode に同等のものが存在しない LICR オブジェクトも多数存在します。この問題は、inputenc パッケージで、特定の文書で使用されているエンコーディングに対応する Unicode マッピングのみをロードし (既知の範囲で)、その他の Unicode 文字の要求には適切なエラーメッセージを返すことで解決されています。そのため、ユーザーは適切なマッピング情報を提供するか、必要に応じて追加のフォントエンコーディングをロードする必要があります。

前述の通り、入力エンコーディング宣言はパッケージ内またはドキュメントのプリアンブルで使用できます。この動作を実現するには、まずinputencパッケージをロードし、適切なエンコーディングを選択することが重要です。以降の入力エンコーディング宣言は、現在の入力エンコーディングで定義されているエンコーディングの置き換え（または追加）として機能します。

inputenc パッケージを使用するとき、\@tabacckludge コマンドを目にすることがあるかもしれません。これは「タブアクセントの工夫」を意味します。これは、現在のバージョンの LaTeX が \=, \`,\' コマンドのオーバーロードを継承しているために必要です。これらのコマンドは通常、特定のアクセント（つまり、エンコード固有のコマンド）を表しますが、tabbing 環境内では特別な意味を持ちます。そのため、これらのアクセントを含むマッピングは特別な方法でエンコードする必要があります。例えば、232 を ’e-grave’ 文字（内部表現は \`e）にマッピングしたい場合、次のように記述します。

1\DeclareInputText{232}{\@tabacckludge`e}

の代わりに

1\DeclareInputText{232}{\`e}

テキストおよび/または数学へのマッピング

技術的および概念的な理由により、Texはテキストと数学で使用できるキャラクターを非常に強い区別しています。目に見えるASCII文字を除いて、文字を生成するコマンドは通常、テキストモードまたは数学モードのいずれかで使用できますが、両方のモードでは使用できません。

8ビットエンコーディングのファイルを入力します

入力エンコーディングは、拡張子 .def を持つファイルに保存されます。ベース名は入力エンコーディング名です（例：latin1.def）。このようなファイルには、このセクションで説明するコマンドのみを含める必要があります。ファイルは、ファイルの性質を説明する \ProvidesFile コマンドを含む識別行で始まります。例えば、次のようになります。

1\ProvidesFile{latin1.def}[2000/07/01 v0.996 Input encoding file]

追加のパッケージがロードされない限り利用できない可能性のあるエンコード固有のコマンドにマッピングがある場合、「\ provideTextCommandDefault」を使用してデフォルトを宣言できます。例えば：

1\ProvideTextCommandDefault{\textonehalf}{\ensurement{\frac12}}
2\ProvideTextCommandDefault{\textcent}{\TextSymbolUnavailable\textcent}

811 / 5,000 コマンド \TextSymbolUnavailable は、現在使用されているフォントでは特定の文字が利用できないことを示す警告を発します。これは、特殊なフォントがロードされている場合にのみ利用可能な文字があり、既存の文字でその文字を偽装する適切な方法がない場合（\textonehalf のデフォルト設定では可能だったように）に、デフォルト設定として役立ちます。

ファイルの残りの部分には、入力エンコーディング宣言 \DeclareInputText と \DeclareInputMath のみを含める必要があります。前述のように、後者のコマンドの使用は推奨されませんが、許可されています。入力エンコーディングファイル内では、他のコマンド、特にファイルの複数回の読み込みを妨げるコマンド（例：\newcommand）を使用しないでください。これは、エンコーディングファイルが単一のドキュメント内で複数回ロードされることが多いためです。

UTF8の入力マッピングファイル

前述のように、UnicodeからLICRオブジェクトへのマッピングは、LaTeXが現在の文書で使用されているフォントエンコーディングに関連するマッピングのみを読み込むように構成されています。これは、各エンコーディング<name>について、そのエンコーディングで提供されるUnicode文字のマッピング情報を含むファイル<name>enc.dfuの読み込みを試行することで実現されます。このファイルが存在する場合、これらのファイルには、複数の\DeclareUnicodeCharacter宣言に加えて、\ProvidesFile行のみを含める必要があります。

さまざまなフォントエンコードが多かれ少なかれ同じ文字を提供することが多いため、同じUnicode文字が異なる .dfuファイルに表示されるのは非常に一般的です。したがって、さまざまなファイルのこれらの宣言が同一であることが非常に重要です。それ以外の場合、最後にロードされた宣言は生き残ります。これは、ドキュメントごとに異なる場合があります。

そのため、これまでサポートされていなかったエンコーディング用の新しい .dfu ファイルを提供したい方は、関連するエンコーディングの .dfu ファイル内の既存の定義を注意深く確認する必要があります。inputenc に付属する標準ファイルは、統一された定義を持つことが保証されています。実際、それらはすべて、適切に分割された単一のリストから生成されます。現在存在するマッピングの完全なリストは、ファイル utf8enc.dfu に記載されています。

7.4。出力エンコーディング

出力エンコーディングは、LICRから組版に使用されるフォントで利用可能なグリフ（またはグリフから構成される構造）へのマッピングを定義することを既に述べました。これらのマッピングは、LaTeX内では2文字または3文字の名前（例：OT1、T3）で参照されます。特定のフォントが特定のエンコーディングに属しているとは、そのマッピングがフォント内のグリフの位置と一致することを意味します。では、このようなマッピングの具体的な構成要素を見ていきましょう。

ASCII文字によって内部的に表される文字は、単にフォントに渡されます。言い換えれば、TexはASCIIコードを使用して現在のフォントからグリフを選択します。たとえば、ASCIIコード65を使用した文字「A」は、現在のフォントの位置65でグリフを化場させます。これが、この基本的なTEXメカニズムと対話する方法がないため、ASCIIコード位置にすべてのASCII文字を含むためにテキストにフォントを必要とする理由です。したがって、目に見えるASCIIの場合、すべての出力エンコーディングに1対1のマッピングが暗黙的に存在します。

内部的にASCII文字のシーケンスとして表現される文字（例："--"）は、次のように処理されます。現在のフォントが最初に読み込まれると、TeXはフォントにいわゆる合字プログラムが含まれていることを通知されます。これらのプログラムは、直接タイプセットするのではなく、フォント内の他のグリフに置き換えるべき特定の文字シーケンスを定義します。例えば、TeXが入力で"--"（つまり、ASCIIコード45を2回）に遭遇した場合、合字プログラムは代わりに位置123のグリフ（つまり、エンダッシュグリフ）に指示することがあります。繰り返しますが、このメカニズムを操作する方法はありません。

それにもかかわらず、内部文字表現の最大の部分は、以下で説明する宣言を使用してマッピングされるフォントエンコード固有のコマンドで構成されています。すべての宣言は、最初の2つの引数で同じ構造を持っています。フォントエンコード固有のコマンド(またはコマンドシーケンスの場合の最初のコンポーネント)、エンコードの名前が続きます。残りの引数は、宣言の種類によって異なります。

したがって、エンコード「XYZ」は、宣言の束によって定義され、すべて「XYZ」という名前を2番目の引数として持っています。その後、もちろん、そのエンコードでいくつかのフォントをエンコードする必要があります。実際、フォントエンコーディングの開発は通常、逆に行われます - 誰かが既存のフォントから始めて、それを使用するための適切な宣言を提供します。この宣言のコレクションには、「OT1」などの適切な名前が与えられます。以下に、フォント「ECRM1000」(Glyphチャートを参照)を使用します。フォントエンコードはラテックスで「T1」と呼ばれ、この方法でエンコードされたフォントからグリフにアクセスするための適切な宣言を作成します。グリフチャートの青い文字は、ラテックスを透過的に通過するため、すべてのテキストエンコードに同じ位置に存在する必要があるものです。

$ECRM1000フォントのグリフチャート$

ファイルの出力エンコード

出力エンコーディングファイルは、入力エンコーディングファイルと同じ .def 拡張子で識別されます。ただし、ファイルの基本名はやや構造化されており、小文字で表記されたエンコーディング名に enc が続きます（例: T1 エンコーディングの場合は t1enc.def）。

これらのファイルには、このセクションで説明されている宣言のみを含める必要があります。出力エンコーディングファイルは LaTeX によって複数回読み込まれる可能性があるため、このルールに従うことが重要です。また、例えば、このようなファイルの複数回読み込みを防ぐ \newcommand などの使用は避けてください。

繰り返しますが、出力エンコードファイルは、ファイルの性質を説明する識別行から始まります。例えば：

1\ProvidesFile{t1enc.def}[2001/06/05 v1.94 Standard LaTeX file]

特定のエンコードのエンコーディング固有のコマンドを宣言する前に、まずこのエンコードをLaTexに知らせる必要があります。これは、 \ declareFontencodingコマンドを介して行われます。この時点で、エンコードのデフォルトの代替ルールを宣言することも役立ちます。コマンド「\ DeclareFontSubstitution」を使用して、そうすることができます。両方の宣言については、新しいフォントをセットアップする方法で詳細に説明します。

1\DeclareFontEncoding{T1}{}{}
2\DeclareFontSubstitution{T1}{cmr}{m}{n}

この方法でラテックスに「T1」を導入したので、そのエンコードでフォントエンコード固有のコマンドがどのように動作するかを宣言することができます。

1\DeclareTextSymbol{LICR-Object}{encoding}{slot}

テキストシンボルの宣言は最も単純なようです。ここでは、内部表現をターゲットフォントの単一のグリフに直接マッピングできます。これは、「\ declaretextsymbol」宣言を使用することによって達成されます。その3番目の議論 - グリフの位置 - は、小数、octal、または16進数として与えることができます。例えば、

1\DeclareTextSymbol{\ss}{T1}{255}
2\DeclareTextSymbol{\AE}{T1}{'306} %font position as octal number
3\DeclareTextSymbol{\ae}{T1}{"E6} %...as hexadecimal number

フォントエンコード固有のコマンドは、 \ ss、 \ ae、および \ aeを、それぞれ t1エンコードフォントでフォント(小数)位置255、198、および230にマッピングする必要があることを宣言します。上で述べたように、このような宣言で小数表記を使用することは最も安全です。とにかく、前の例のように表記を混ぜることは確かに悪いスタイルです。

1\DeclareTextAccent{LICR-accent}{encoding}{slot}

フォントには、アクセント記号を独立したグリフとして含むことが多く、他のグリフと組み合わせることでアクセント付き文字を作成できます。このようなアクセント（他のグリフの上に配置される場合）は、\DeclareTextAccent コマンドを使用して宣言されます。3番目の引数 slot は、フォント内でのアクセント記号の位置です。例えば、

1\DeclareTextAccent{\"}{T1}{4}

743 / 5,000 ウムラウトアクセントを定義します。この定義以降、\"a のような内部表現は、T1 エンコーディングにおいて以下の意味を持ちます。つまり、位置 4 のアクセントを位置 97 のグリフ（文字 a の ASCII コード）の上に置くことで、「ウムラウト付き a」とタイプセットするということです。実際、このような宣言は、暗黙的に非常に幅広い内部文字表現を定義します。つまり、\" 型のあらゆる文字です。ここで、は \DeclareTextSymbol で定義されたもの、または ‘a’ などの LICR に属する任意の ASCII 文字です。

\"\P（つまり、ウムラウト付きピルクロウ記号）のようにあまり意味をなさない組み合わせであっても、概念的にはこのようにしてフォントエンコーディング固有のコマンド群のメンバーになります。

1\DeclareTextComposite
2     {LICR-accent}{encoding}{simple-LICR-object}{slot}

上記のグリフ表には、多数のアクセント付き文字が個別のグリフとして含まれています。例えば、8進数で'240の位置にある「ウムラウト付きa」などです。したがって、T1では、エンコーディング固有のコマンド\"aは文字’a’の上にアクセントを配置するのではなく、フォントのその位置にあるグリフに直接アクセスする必要があります。これは、以下の宣言によって実現されます。

1\DeclareTextComposite{\"}{T1}{a}{228}

これは、エンコーディング固有のコマンド \"a によりグリフ 228 がタイプセットされ、上記のアクセント宣言が無効になることを示しています。\" で始まるその他のエンコーディング固有のコマンドでは、アクセント宣言はそのまま残ります。例えば、\"b はベースグリフ ‘b’ の上にアクセントを配置することで、‘ウムラウト付き b’ を生成します。

3番目の引数 simple-LICR-object は、‘a’ などの単一の文字、または \j や \oe などの単一のコマンドである必要があります。

1\DeclareTextCompositeCommand
2     {LICR-object}{encoding}{simple-LICR-object}{code}

T1 エンコーディングでは使用されませんが、\DeclareTextComposite のより汎用的なバージョンもあり、スロット位置の代わりに任意のコードを記述できます。例えば、OT1 エンコーディングでは、TeX の \accent プリミティブでタイプセットした場合と比較して、‘A’ のリングアクセントの位置を低くするためにこの宣言が使用されます。‘i’ の上のアクセントも、この形式の宣言を使用して実装されています。

1\DeclareTextCompositeCommand{\'}{OT1}{i}{\@tabacckludge'\i}
2\DeclareTextCompositeCommand{\^}{OT1}{i}{\^\i}

多数の異なるマークが他のキャラクターの上に置かれるのではなく、その下に配置されています。アクセントの実際のポジショニングには低レベルのTEXコードが含まれるため、このようなマークに特別な宣言フォームはありません。代わりに、一般的な \ declaretextCommandをこの目的に使用できます。

1\DeclareTextCommand{LICR-object}{encoding}[num][default]{code}

たとえば、「T1」エンコードの「underbar」アクセント「\ b」は、次のコードで定義されます。

1\DeclareTextCommand{\b}{T1}[1]
2     {\hmode$bgroup\o$lign{\relax#1\crcr\hidewidth\sh$ft{29}%
3           \vbox to.2ex{\hbox{\char9}\vss}\hidewidth}\egroup}

この議論では、コードが正確に何を意味するのかはそれほど重要ではありませんが、「\ declaretextCommand」はある意味で「newCommand」に似ていることがわかります。引数の数(ここに1つ)、2番目のオプションの *デフォルト *引数(ここには存在しない)を示すオプションの * num *引数があり、 ＃1、＃2などを使用して引数を参照できるコードを含む最終的な必須引数があります。

\DeclareTextCommand は、単一の制御シーケンスからなるフォントエンコーディング固有のコマンドを作成するためにも使用できます。この場合、オプション引数を指定せずに使用するため、引数なしのコマンドが定義されます。例えば、T1 には「千分の一」記号のグリフがありませんが、'30 の位置に小さな「o」があり、これを「%」の直後に配置すると適切なグリフになります。したがって、次のような宣言が可能です。

1\DeclareTextCommand{\textperthousand} {T1}{\%\char 24}
2\DeclareTextCommand{\textpertenthousand}{T1}{\%\char 24\char 24 }

これで、新しいエンコードのためにフォントエンコード固有のコマンドを宣言するために必要なすべてのコマンドをカバーしました。すでに述べたように、これらのコマンドのみが定義ファイルのエンコードに存在する必要があります。

出力エンコードデフォルト

現在、現在のフォントエンコードに宣言がないエンコーディング固有のコマンドが使用されている場合、何が起こるかを見てみましょう。その場合、2つのことのいずれかが発生する可能性があります。ラテックスにはLICRオブジェクトのデフォルトの定義があります。この場合、このデフォルトが使用されるか、要求されたLICRオブジェクトが現在のエンコードでは利用できないことを示すエラーメッセージが発行されます。 LICRオブジェクトのデフォルトをセットアップする方法はいくつかあります。

1\DeclareTextCommandDefault{LICR-object}[num][default]{code}

\ declearetextCommandDefaultコマンドは、現在のエンコードにオブジェクトの特定の設定がない場合はいつでも、 licr-objectのデフォルトの定義を提供します。このような定義は、たとえば、特定のキャラクターを偽造できます。たとえば、 \ textregisteredには、このような他の2つのキャラクターからキャラクターが構築されるデフォルトの定義があります。

1\DeclareTextCommandDefault{\textregistered}{\textcircled{\scshape r}}

技術的には、デフォルトの定義は、名前 ？のエンコードとして保存されます。この事実に頼るべきではありませんが、実装は将来変化する可能性があるため、この名前でエンコードを宣言できないことを意味します。

1\DeclareTextSymbolDefault{LICR-object}{encoding}

ほとんどの場合、デフォルトの定義ではコーディングは必要ありませんが、LaTexに存在することが知られているエンコードからキャラクターを取得するように指示するだけです。たとえば、「TextComp」パッケージには、すべてが「TS1」エンコードを指している多数のデフォルト宣言が含まれています。例えば：

1\DeclareTextSymbolDefault{\texteuro}{TS1}

「\ decleartextsymboldefault」コマンドを使用して、他のエンコーディングで「\ declaretextsymbol」コマンドで宣言されたものだけでなく、引数のない任意のLICRオブジェクトのデフォルトを定義することができます。

1\DeclareTextAccentDefault{LICR-accent}{encoding}

アクセントなど、1つの引数を実行するLICRオブジェクトには同様の宣言があります。繰り返しますが、このフォームは、1つの引数を持つ任意のLICRオブジェクトに使用可能です。たとえば、ラテックスカーネルには、タイプの多くの宣言が含まれています。

1\DeclareTextAccentDefault{\"}{OT1}
2\DeclareTextAccentDefault{\t}{OML}

これは、「\ “」が現在のエンコードで定義されていない場合、「ot1」エンコードフォントからのものを使用することを意味します。同様に、ネクタイのアクセントを取得するには、より良いものがない場合は「oml」から拾い上げます。

1\ProvideTextCommandDefault{LICR-object}[num][default]{code}

「\ provideTextCommandDefault」宣言により、別の種類のデフォルトを「提供」することができます。デフォルトが以前に定義されていない場合にのみデフォルトが提供されることを除いて、「\ declaretextCommandDefault」宣言と同じジョブを実行します。これは、主に入力エンコードファイルで使用され、異常なLICRオブジェクトに何らかの些細なデフォルトを提供します。例えば：

1\ProvideTextCommandDefault{\textonequarter}{\ensuremath{\frac14}}
2\ProvideTextCommandDefault{\textcent}{\TextSymbolUnavailable\textcent}

「TextComp」のようなパッケージは、そのような定義を実際のグリフを指す宣言に置き換えることができます。 \ subment ...を使用してください。

1\UndeclareTextCommand{LICR-object}{encoding}

場合によっては、代わりにデフォルトの宣言が使用されることを確認するために、既存の宣言を削除する必要があります。これは、 \ undeclaretextCommandを使用して実行できます。たとえば、「TextComp」パッケージは、すべての「OT1」エンコードされたフォントが実際にこれらのシンボルを持っているわけではないため、「OT1」エンコードから「\ textDollar」と「\ textString」の定義を削除します。

1\UndeclareTextCommand{\textsterling}{OT1}
2\UndeclareTextCommand{\textdollar} {OT1}

この削除がなければ、「TS1」からシンボルをピックアップする新しいデフォルトの宣言は、「OT1」でエンコードされたフォントには使用されません。

1\UseTextSymbol{encoding}{LICR-object}
2\UseTextAccent{encoding}{LICR-object}{simple-LICR-object}

宣言「\ decleartextsymboldefault」および \ decleRetextAccentDefaultの背後に隠されたアクションも直接使用できます。たとえば、現在のエンコードは「u」であると仮定しましょう。その場合、

1\UseTextSymbol{OT1}{\ss}
2\UseTextAccent{OT1}{\'}{a}

以下のコードを入力するのと同じ効果があります。特に、「a」は「u」をエンコードする際にタイプセットであることに注意してください - アクセントのみが他のエンコードから取得されます。

1{\fontencoding{OT1}\selectfont\ss}
2{\fontencoding{OT1}\selectfont\'{\fontendcoding{U}\selectfont a}}

標準のLICRオブジェクトのリスト

このサブセクションの表は、ラテン語系言語の3つの主要なエンコーディング（OT1（オリジナルのTeXエンコーディング）、T1（LaTeX標準エンコーディング）、およびLY1（Y&Yが提案した代替8ビットエンコーディング））で利用可能なLaTeX内部表現の概要を示しています。さらに、textcompパッケージをロードすることで提供されるTS1（LaTeX標準テキストシンボルエンコーディング）で宣言されているすべてのLICRオブジェクトも表示しています。

テーブルの最初の列は、Alphabetical順序でLICRオブジェクト名を示し、どのLICRオブジェクトがアクセントのように作用するかを示します。 2番目の列は、オブジェクトのグリフ表現を示しています。

3番目の列は、オブジェクトにデフォルトの宣言があるかどうかを説明します。エンコーディングがリストされている場合、デフォルトでは、そのエンコードの適切なフォントからグリフがフェッチされていることを意味します。 constr.は、デフォルトが低レベルのTexコードから生成されることを意味します。列が空の場合、このLICRオブジェクトのデフォルトが定義されていないことを意味します。最後のケースでは、明示的な定義がないエンコードでそれを使用すると、「シンボルは利用できない」エラーが返されます。オブジェクトが他のLICRオブジェクトのエイリアスである場合、代替名はこの列にリストされています。

列4〜7列は、指定されたエンコードでオブジェクトが利用可能であるかどうかを示します。ここで、「x」とは、オブジェクトがエンコードを使用してフォントでネイティブに(グリフとして)利用可能であることを意味します。「O」は、すべてのエンコーディングのデフォルトで使用可能であることを意味します。「TS1」からデフォルトがフェッチされている場合、 textcompパッケージが読み込まれている場合にのみ、licrオブジェクトが利用可能です。