BTRONフォント形式

[1] BTRONフォント形式は、 BTRON で使われるフォント形式です。

仕様書

呼称

[2] 正式名称は不明です。

[3] BTRON の仕様書では固有名詞なくフォントとだけ呼ばれているようです。 >>6

[4] 関連プロジェクトでBTRONフォント形式と呼ばれています >>5。

[34] BTRON標準形式のフォントデータ実身と呼んだ事例もあります。 >>33

[5] Tフォントプロジェクト, 2021-10-13T05:53:03.000Z, 2026-01-13T13:53:19.359Z https://charcenter.tron.org/tfont/download.html

概要

[8] BTRON ではファイルはレコードの集合体として表されます。各レコードはレコードタイプを持ちます。

[9] フォントファイルは、レコードタイプが 11 であるフォントデータレコードを1つ以上持ちます。 >>6

[10] フォントファイルは仕様上かなり自由度が高いようですが、そのうちの一部は定義されているだけで実際には利用されていないような記述が仕様書にもあります。超漢字Vに標準付属するフォントファイルをみると、実際に利用されている機能は更に限られます。それ以外の機能がどこまで実装されているのかは不明です。

[12] 実用されているフォントは2種類に大別できます。

[13] 標準ドット形式のうち固定イメージサイズ形式のものは、固定幅 (すべての文字が同じ幅) のビットマップフォントです。 >>6
[14] TrueType形式のものは、 TrueType フォントです。 >>6

[15] 固定イメージサイズ形式のフォントファイルは、 1つ以上のフォントデータレコードで、それぞれが独立したフォントとして機能し得るものが1つにまとめられます。

[16] TrueType形式のフォントファイルは、 1つ以上のフォントデータレコードと 1つ以上のその他のレコードです。その他のレコードの方はレコードタイプが [ 15, 31 ] とされますが >>6、超漢字Vの標準フォントで確認できたものはすべて 31 です。

[17] TrueType形式のフォントファイルの場合、フォントデータレコードのそれぞれが独立したフォントとして機能し得るものですが、フォントデータレコード自体に入っているのはメタデータと索引データであり、字形データは同じフォントファイルの他のどれか1つの 31 レコードの TrueType データを参照する形になっています。 31 レコードの中身は TrueType フォントデータそのものです。 >>6

[18] 複数のフォントデータレコードが同じTrueType レコードを参照することもできますし、いくつも TrueType レコードを含めることもできます。

[57] TrueType フォントデータは、 TTC のこともあります。

[22] なお、超漢字ではデータ構造に出現する多バイト数値はすべて小エンディアンです。

超漢字検索用フォント

[41] Windows や Linux 用に提供されている超漢字検索にもこの形式のフォントが同梱されています。

[42] BTRON と違って Unix 系ファイルシステムのファイル (= ただのバイト列) になっています。

[43] FONT ディレクトリーにすべてのフォントデータレコードと TrueType フォントが各1つのファイルとして収容されています。 fonts.cfg にフォントデータレコードと TrueType のファイル名の対応関係が単純なテキストファイルで記述されています。

[44] TrueType フォントファイルは、 TrueType データの前にメタデータが付加されています。

TRON コードと字形の関連付け

[20] 各フォントデータレコードには、 TRONコードの「文字セット(スクリプト)指定」を記述する script, 最初の符号を記述する topcode, 最後の符号を記述する lastcode があります。 >>6

[23] ただし、TRONコードの符号平面は Aゾーンから Dゾーンまでに分かれています。範囲の整列は数値の順序ですが、上位バイト、下位バイトそれぞれの上下限が決まります。すなわち、

[48] 上位バイト [ floor ( $\frac{topcode}{0x100}$ ), floor ( $\frac{lastcode}{0x100}$ ) ]
[49] 下位バイト [ topcode mod 0x100, lastcode mod 0x100 ]

... が範囲となります。

[56] 従って 0x3100 のようなものは必ず除外されますが、 0x317F は含まれることがあります。

[21] script は TRONコードの面を指定する値であり、 topcode と lastcode はその面の中の符号の範囲を表しています。 >>6

[26] 従って1つのフォントデータレコードに含められるのは、特定の面の連続した範囲の符号群だけです。異なる範囲に対応したいときは複数のフォントデータレコードを使うことになります。

[24] script, topcode, lastcode がいずれも 0 のフォントデータレコードがあります。空を表しているようです。

[19] 固定イメージサイズ形式のビットマップフォントでは、 offimage で参照されるビットマップデータに最初の符号から最後の符号まで順に字形が並びます。

[25] TrueType形式のフォントでは、 offwidth で参照される FT_INDEXWDATA (文字幅/インデックスデータ) から参照されるインデックスデータに最初の符号から最後の符号まで順に文字インデックスが並びます。文字インデックスは、 0xFFFF が未定義を表します。 >>6

[28] 文字インデックスと TrueType の関係は仕様書に明言がありませんが、 [ 0, 0xFFFE ] のとき TrueType のグリフID を指していると思われます。

[29] TrueType の cmap やグリフ名は使われていないようです。 cmap の中身が空のものもあります。 cmap で参照できるグリフが一部だけで、多くはグリフIDかグリフ名でしか参照できないものもあります。そうでないものは、シフトJIS環境での利用を想定したと思しき Unicode cmap になっていることが多いように見えます。おそらくフォント事業者で一般的な日本語フォントの開発環境を使いつつ、本来の JIS の漢字等のかわりに独自の配列で字形を配置して制作したものなのでしょう。

[30] グリフIDは TRONコード側の順序と揃っていることもありますが、そうでない場合もかなり多いです。インデックスデータを見なければTRONコードと字形の対応を知ることは不可能です。

[32] たまに索引データの末尾の部分 (おそらく意味のある字形が割り当てられた最後よりも後の部分) が不適切 (lastcode までのデータが揃っていない) なのではないかと思われるものもありますが、当該データが間違ったまま使われているのか、こちらの仕様の理解の不足による誤解なのか、よくわかりません。

[58] 索引は TrueType 専用というわけではないらしく、超漢字Vに付属する (しかし標準ではない) 基本-ナガ10 はビットマップフォントでありながら索引を使って、 JIS X 0201 フォントを TRONコードの JIS X 0208 の領域に対応付けています。

[27] なお、データ構造定義上存在し得る文字幅データは使われていないようです。