スケーラブルフォントのバックエンド(Type 1, Speedo, TrueType)
は、フォントを自動的に再エンコードして、
`fonts.dir
' に書いた XLFD が指定するエンコードにできるように
なりました。例えば Type 1 の Courier フォントは
`fonts.dir
' ファイルに
cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
cour.pfa -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-2
のように書け、これによってそれぞれのフォントは
ISO 8859-1 と ISO 8859-2 に再エンコードされます。
スケーラブルフォントの 3 つのバックエンド (Type 1, Speedo, および TrueType のバックエンドである `freetype') は共通の `fontenc' 層をフォントの再エンコーディングに使います。 これにより、これらのバックエンドでエンコーディングデータを共有でき、 新しいロケールの設定をフォントの種類に関係なく簡単にできるようになりま す。
注意: X-TrueType (X-TT) バックエンドは `fontenc' 層を使わず、 独自の方法を使ってフォントの再エンコーディングを行っています。 X-TT にしか興味がない読者は、 シンボルフォントの使用 の節まで進んでください。というのも、それまでの内容は X-TT には 当てはまらないからです。X-TT そのものについての詳しい説明は X-TrueType の節にあります。
`fontenc' 層では、エンコーディングは名前(例えば `iso8859-1
')、
最終的には多数のエイリアス(別名)、マッピングの順序付き集合によって定義
されます。マッピングは、`fontenc' が知っている「ターゲット」エンコーディング
のいずれかにエンコーディングをマッピングできるような方法を定義します。
現在は対象エンコーディングは Unicode, Adobe グリフ名、TrueType の任意
の `cmap' からなります。
たくさんのエンコーディングが `fontenc' に組み込まれており、これらは常 に使えます。組み込みのエンコーディングは簡単には再定義できません。 組み込みエンコーディングを以下に示します:
iso10646-1
': Unicode;iso8859-1
': ISO Latin-1 (西ヨーロッパ);iso8859-2
': ISO Latin-2 (東ヨーロッパ);iso8859-3
': ISO Latin-3 (南ヨーロッパ);iso8859-4
': ISO Latin-4 (北ヨーロッパ);iso8859-5
': ISO Cyrillic;iso8859-6
': ISO Arabic;iso8859-7
': ISO Greek;iso8859-8
': ISO Hebrew;iso8859-9
': ISO Latin-5 (Turkish);iso8859-10
': ISO Latin-6 (北欧);iso8859-15
': ISO Latin-9 または Latin-0 (
東ヨーロッパエンコーディングを改訂したもの);koi8-r
': KOI8 Russian;koi8-u
': KOI8 Ukrainian (RFC 2319 参照);koi8-ru
': KOI8 Russian/Ukrainiankoi8-uni
': KOI8 ``統合エンコーディング'' (Russian, Ukrainian, Byelorussian);koi8-e
': KOI8 `European', ISO-IR-111 または ECMA-Cyrillic;microsoft-symbol
' および `apple-roman
': これらが役に
立つのは TrueType の記号フォントを使う場合だけでしょう。新しいエンコーディングはエンコーディングファイルの定義によって
追加できます。`fontenc' 層が知らない新しいエンコーディングが要求される
と、バックエンドはフォントファイルが置かれているディレクトリ(`fonts.dir
'
が置かれているディレクトリではありません!)をチェックし、`encodings.dir
'
というファイルを探します。このファイルが見つかると、この中から未知の
エンコーディングを探し、要求されたエンコーディング定義を読み込みます。
mkfontdir(1) ユーティリティを呼び出すときに `-e
' オプションと
エンコーディングファイルがあるディレクトリ名を指定すると、
`encodings.dir
' ファイルを自動的に作れます。詳しくは mkfontdir
(1)
のマニュアルページを見てください。
配布物には予め定義されたたくさんのエンコーディングファイルが入っていま す。新しいエンコーディングファイルを記述するための情報は エンコーディングディレクトリファイルのフォーマット と エンコーディングファイルのフォーマット にあります。
Type 1 のバックエンドはまず PostScript をターゲットとして マッピングを検索します。マッピングが見つかれば、それを使用します。 マッピングが見つからなければ、バックエンドは Unicode をターゲットとし てマッピングを探します。これはコードをグリフ名にマッピングする組み込み の表を使って組み立てられます。 この表は、 Unicode のコードポイントのうち、Adobe が名前を割り当ててい る一部のものしか網羅していない点に注意してください。
PostScript のマッピングも Unicode のマッピングも見つからなかった場合は、 バックエンドはデフォルト値として ISO 8859-1 を使います。
エンコーディングの値に `adobe-fontspecific
' を指定すると、
エンコーディングの機構は無効になります。これは記号や
エンコーディングが間違っているフォントを扱う際に便利です(後述)。
Type 1 バックエンドは現在、全ての 8 ビットコードの エンコーディングしか扱えません。
この TrueType バックエンドはマッピングを順に走査します。 PostScript をターゲットに持つマッピングは無視されます。 TrueType または Unicode をターゲットに持つマッピングは、ファイル中の 全ての cmap に対してチェックされます。利用可能な最初のマッピングが 使われます。
この TrueType バックエンドに使われるエンコーディングファイルを書く場合 には必ず、使いたい度合の高い順にマッピングを記述すべきである。
フォントのバックエンドが知らないエンコーディングのフォントを使うた
めは、使用するフォントファイルと同じディレクトリに `encodings.dir
'
ファイルを置く必要があります。`encodings.dir
' のフォーマットは
`fonts.dir
' と同じです。最初の行にはエンコーディングの個数を指定
します。残りの全ての行にはエンコーディングの名前と
エンコーディングファイルの名前の 2 つずつの項目を指定します。
ファイルは相対ディレクトリ指定でも絶対ディレクトリ指定でも構いません。
全てのエンコーディング名は、エンコーディングファイル内で定義された
エンコーディング名と一致しなければなりません。
例を以下に示します:
3
mulearabic-0 encodings/mulearabic-0.enc
mulearabic-1 encodings/mulearabic-1.enc
mulearabic-2 encodings/mulearabic-2.enc
エンコーディング名はエンコーディングファイルの
STARTENCODING 行か ALIAS 行で指定しなければなりません。
`encodings.dir
' エントリを作るだけでは不十分です。
お使いのプラットフォームが対応していれば(たぶん対応しています)、 エンコーディングファイルを compress や gzip で圧縮しても構いません。
`encoding.dir
' ファイルは mkfontdir
(1) ユーティリティで
きっちりメンテナンスできます。詳しくは mkfontdir
(1) の
マニュアルページを見てください。
エンコーディングファイルは「自由書式」です。つまり、空白文字を
組み合わせた任意の文字列は一つの空白と同じです。キーワードは
大文字と小文字を区別せずに解析されます。つまり `size
',
`SIZE
', `SiZE
' は全て同じキーワードとして処理されます。ただ
し、グリフ名については大文字と小文字は区別されます。
数字は 10 進数は `256
' のように、16 進数は `0x100
' のように、
8 進数は `0400
' のように書かれます。
コメントは `#
' 記号で始まります。`#
' が行のどこかに現われる
と、`#
' 以降の行末までの文字は全て無視されます。
エンコーディングファイルはエンコーディング名の定義で始まり、それから 別名(エイリアス)が続きます:
STARTENCODING mulearabic-0
ALIAS arabic-0
ALIAS something-else
エンコーディング名は XLFD フォント名として使える名前であるべきです。
したがって、ちょうど一つの `-
' を含みます。
エンコーディングファイルは、この後にオプションとして エンコーディングのサイズを宣言できます。線形エンコーディング (Mule のアラビア文字や ISO 8859-1 等)の場合は、SIZE 行には (最大のコード + 1) を指定します。
SIZE 0x2B
行列形式のエンコーディングの場合は、2 つの数を指定しなければなりません。
前の数字は (列の最大値 + 1) であり、後の数字は (行の最大値 + 1)です。
例えば、`jisx0208.1990-0
'
(JIS X 0208(1990), 2 バイトエンコーディング、再上位ビットは
立っていません)の場合は以下のようになるはずです:
SIZE 0x75 0x80
サイズ行によって定義された領域の外側のコードは未定義とみなされます。
デフォルトのエンコーディングは、サイズが 256(0x100)の
線形エンコーディングです。つまり、16 ビットエンコーディングの場合は必
ずサイズを宣言しなければなりません。
その後にはマッピングセクションが 1 つまたはそれ以上続きます。
マッピングセクションは `STARTMAPPING
' 行で始まり、
そのマッピングのターゲットを示します。
ターゲットとしては以下のいずれかを指定できます:
STARTMAPPING unicode
cmap
':
STARTMAPPING cmap 3 1
STARTMAPPING postscript
0x21 0x0660
0x22 0x0661
...
省略形として、連続した範囲のコードのマッピングを一つの行で行えます。
整数値を 3 つ含む行
start end target
は、
start target
start+1 target+1
...
end target+end-start
という一連の行を省略した形です。
例えば、
0x2121 0x215F 0x8140
は
0x2121 0x8140
0x2122 0x8141
...
0x215F 0x817E
の省略形です。
列挙されていない行は恒等変換でマッピングされます(つまり数値が
変わりません)。このデフォルトのマッピングを上書きするために、
`UNDEFINE
' 行を使って、ある範囲のコードを未定義として指定できます。
UNDEFINE 0x00 0x2A
あるいは一つのコードを
UNDEFINE 0x1234
のように指定できます。
これがうまく動作するのは、後から指定した値が前の値を上書きするためです。
PostScript のマッピングは異なります。PostScript のマッピングの全ての行 はコードをグリフ名にマップします。
0x41 A
0x42 B
...
また、明示的に列挙されなかったコードは未定義となります。
マッピングセクションは ENDMAPPING
行で終わります。
ENDMAPPING
全てのマッピングを定義した後、ファイルは ENDENCODING
行で終わりま
す。
ENDENCODING
UNASSIGNED 0x00 0x1F
または
UNASSIGNED 0x1234
という形式の行はサーバには無視されますが、補助ユーティリティが使うかも
しれません。
将来的にフォーマットを拡張できるように、未知のキーワードで始まる行は 無視されます。未知のターゲットについてのマッピングセクションも同様です。
Type 1 の記号フォントは `adobe-fontspecific
'
エンコーディングを使ってインストールされているはずです。
理想的な世界では、全ての TrueType の記号フォントは
`microsoft-symbol
' エンコーディングと `apple-roman
' エンコーディング
のどれかを使ってインストールされるはずです。しかし、多くの記号フォント
はそのようになっていません。こういったフォントは
`microsoft-cp1252
' や、古いフォントの場合には
`microsoft-win3.1
' を使ってインストールされているはずです。
必ず矛盾のない結果を得られるようにするため(特に同じフォントの
Type 1 版と TrueType 版の間で)、あるフォントに対して
特別なエンコーディングを定義することができます。これは既に
`ZapfDingbats
' フォントで行われています。
`encodings/adobe-dingbats.enc
' ファイルを見てください。
テキストフォントの多くのエンコードは間違っています。間違った エンコーディングは、設計の時に外国のスクリプト用のフォントをを普通の Western テキストフォントのように見せようとして起こることがあります。 これは多くの場合フォント設計者の怠慢や無能のために起こります。特に、 多くの人は Adobe のグリフリストに従わずに、妙なグリフ名を発明する方が 楽だと思うようです。
このようなフォントを扱う方法は二通りあります。一つはそのフォントの設計 に従ったエンコーディングを用いることで、もう一つはアドホックな エンコーディングファイルを作ることです。
もちろん、ほとんどの場合は適切な修正がフォントデザイナの頭を PLRM で ぶん殴るべきだったのです(できれば初版で。というのも初版はハードカバー で出版されたから)。
Type 1 フォントの場合は、フォントデザイナはデフォルトの
エンコーディングを指定できます。このエンコーディングは XLFD 名で
`adobe-fontspecific
' エンコーディングを使うことによって要求されま
す。フォントデザイナ適切なデフォルトエンコーディングの指定を省略するこ
ともあります。このような場合には、
`adobe-standard
', `iso8859-1
', `microsoft-cp1252
',
`microsoft-win3.1
' を試してください(Type 1 フォントの場合に
は `microsoft-symbol
' は無意味です)。
TrueType フォントはデフォルトのエンコーディングを持っていないので、
Microsoft Symbol エンコーディングを使うと(X11 でない)いくつかの
プラットフォームではおかしな結果になります。しかし、ほとんどの
TrueType フォントは Microsoft か Apple のプラットフォームを想定して
設計されているので、`microsoft-cp1252
', `microsoft-win3.1
',
`apple-roman
' のいずれかでちゃんとした結果が得られるはずです。
フォント中のグリフを好きな順序にするようなエンコーディングファイル
を定義することはいつでも可能です。繰り返しになりますが、これを行う方法
については `encodings
adobe-dingbats.enc/' ファイルを見てください。
前述の指示に従うと、おかしな名前のフォントがたくさんできるでしょう――
エンコーディングが `adobe-fontspecific
', `microsoft-win3.1
'
のように指定されているものです。こういったフォントを一般的な
アプリケーションで使うためには、フォントを別の適切な名前に再マップする
とよいでしょう。
これは `fonts.alias
' ファイルを書くことで行います。このファイルの
フォーマットは `fonts.dir
' ファイルのフォーマットに似ており、異な
るのは XLFD 名を XLFD 名にマップすることだけです。`fonts.alias
'
ファイルは以下のようになります:
1
"-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-iso8859-2" \
"-ogonki-alamakota-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific"
(両方の XLFD 名を一つの行に書きます。) `fonts.alias
' ファイルの
文法はマニュアルページの mkfontdir(1) で説明されています。