フォント名の文字化け-フォント側に問題がないことを確認

公開日 2026-01-17 更新日 2026-01-18

フォントの名前が文字化け

2つのフォントパッケージをインストールしました。fonts-yozvox-yozfont(YOz) と fonts-kouzan-mouhitsu(衡山毛筆)です。かなり前からOSを更新するたびに入れています。debian12までは問題なしでした。

fonts-yozvox-yozfont は手書き風のフォントです。 new-kana, antique, standard-kana, cute, edu のパッケージがまとめられています。さらに、各パッケージは16〜30程度のttfファイルから構成されていますので、全部で122のフォントが入ります。基本的には漢字が共通でひらがなとカタカナのデザイン、半角英数の幅、などが異なるだけでしたが、JIS X 0213:2000 の漢字と JIS X 0213:2004 の漢字を分けるようになり、Bold, Italic, 等幅, プロポーショナルもそれぞれ別々のフォントとしているなど、otfの仕組みでもう少しなんとかならないものかと思っていました。

フォント名とフォントファイル名が微妙に異なっていて、整理しようにもなかなか面倒です。こんなYOzフォントでしたが、今回フォント名が文字化けするようになりました。

GIMPのフォント選択の文字化け

盛大に化けている部分を紹介しましたが、約半分は YOzAF Regular などと全く化けないか、YOzAF90bi 䉯汤などと最後の部分だけ化けます。

LibreOfficeでも化けます。

The GNOME Projectで作成されている「フォント」というソフトウェアでも化けます。これは日本語フォントの確認には向きませんが、GNOME の仕組みを一番準拠していると考えて確認しました。これでフォントの中身は見ることができますので、フォント名の文字コードの問題だろうと推測できます。

utf-16であることが判明

この項は試行錯誤の1番目。後から考えれば無駄の多い作業だったが、簡単に記述しておく。

ここでいうUTF-16は正確にはutf-16のうち、BMPだけを使用するもの。

整然と化けていることから元がShift_JISではないだろうと当たりをつけて、漢字をいろいろな文字コードで表してみる。日本語にない文字は難しいが「奏」は日本語にある。文字コード表から探すと、

文字	区点	JIS	EUC	SJIS	UTF-16
奏	33区48点	4150	C1D0	916F	594f

yozfontのフォント名はすべてYOで始まるはずですから、YOをASCII(またはShift_JIS)で 59 4f となっていたものを UTF-16 と解釈して「奏」としたものだという推測がたちます。

奏穓㤰扩䉯汤など、ほとんどの文字は日本語にありません。unicode.org で公開されている、Unihan Radical-Stroke Index で画数からutf-16コードを調べていくと、

文字	奏	穓	㤰	扩	䉯	汤
UTF-16 code	594f	7a53	3930	6269	426f	6c64
ASCII で解釈	YO	zS	90	bi	Bo	ld

fc-list で簡単に

このように、文字化けの文字列と本来のフォント名の対応をとっていったが、後でもっと簡単にできたこともわかった。

フォント名の選択欄から奏穓㤰扩をコピーできれば、次のようにしてttfファイル名と別のフォント名(YOzS90bi)がわかります。

adachi@banach:~$ fc-list 奏穓㤰扩
/usr/share/fonts/truetype/yozvox-yozfont/YOzBS_90i.ttf: 奏穓㤰扩,YOzS90bi:style=䉯汤,Bold

正確には奏穓㤰扩とYOzS90biは日本語名と英語名ですが、もともと同じにしてあったものが、utf-16で読んだ結果奏穓㤰扩になったということです。

英語名から奏穓㤰扩を調べることもできます。

adachi@banach:~$ fc-list YOzS90bi
/usr/share/fonts/truetype/yozvox-yozfont/YOzBS_90i.ttf: 奏穓㤰扩,YOzS90bi:style=䉯汤,Bold

ファイル名がわかっているときには、次のようにすればフォント名がわかります。

adachi@banach:~$ fc-list |grep YOzBS_90i.ttf
/usr/share/fonts/truetype/yozvox-yozfont/YOzBS_90i.ttf: 奏穓㤰扩,YOzS90bi:style=䉯汤,Bold

奏穓㤰扩が日本語名でYOzS90biが英語名というのは-vオプションでわかります。-bは--briefで-vのうちの一部省略です。ここにはさらに省略して冒頭部だけ示しています。familylangやstylelangで言語がわかります。

adachi@banach:~$ fc-list -vb 奏穓㤰扩
Pattern has 26 elts (size 32)
	family: "奏穓㤰扩"(s) "YOzS90bi"(s)
	familylang: "ja"(s) "en"(s)
	style: "䉯汤"(s) "Bold"(s)
	stylelang: "ja"(s) "en"(s)
	fullname: "奏穓㤰扩"(s) "YOzS90bi"(s)
	fullnamelang: "ja"(s) "en"(s)
	slant: 0(i)(s)
	...以下略

文字化けせずうまくいっているものもあります。日本語名と英語名が異なり、うまく使い分けられています。

adachi@banach:~$ fc-list -vb 衡山毛筆フォント草書
Pattern has 26 elts (size 32)
	family: "衡山毛筆フォント草書"(s) "KouzanBrushFontSousyo"(s)
	familylang: "ja"(s) "en"(s)
	style: "Regular"(s)
	stylelang: "en"(s)
	fullname: "衡山毛筆フォント草書"(s) "KouzanBrushFontSousyo"(s)
	fullnamelang: "ja"(s) "en"(s)
	slant: 0(i)(s)
	...以下略

衡山毛筆フォントには草書だけでなく行書もあります。こちらは3つ目の名前がでてきて、盛大に化けています。

adachi@banach:~$ fc-list -vb 衡山毛筆フォント行書
Pattern has 26 elts (size 32)
	family: "衡山毛筆フォント行書"(s) "KouzanBrushFontGyousyo"(s) "䭯畺慮䉲畳框潮瑇祯畳祯"(s)
	familylang: "ja"(s) "en"(s)
	style: "Regular"(s)
	stylelang: "en"(s)
	fullname: "衡山毛筆フォント行書"(s) "KouzanBrushFontGyousyo"(s) "䭯畺慮䉲畳框潮瑇祯畳祯"(s)
	fullnamelang: "ja"(s) "en"(s)
	slant: 0(i)(s)
	...以下略

3つ目の名前にはfamilylangがありません。

この文字化けもASCIIの範囲で書かれたものをUTF-16として読んだためにうまれたものです。

䭯	畺	慮	䉲	畳	框	潮	瑇	祯	畳	祯
4b6f	757a	616e	4272	7573	6846	6f6e	7447	796f	7573	796f
Ko	uz	an	Br	us	hF	on	tG	yo	us	yo

ttfファイル中の記述を調べる

まず、拡張子.ttfのttfファイルのときには単一フォントです。先頭にある「オフセットテーブル」を読みます。

ttcファイルの場合は先頭に「TTCヘッダテーブル」があって「オフセットテーブル」の位置(多分複数)を読み取り、それぞれの「オフセットテーブル」を読んでいくことになります。今回の調査の過程でttcファイルに出会わなかったので、ここは確認できていません。

OpenTypeの場合は拡張子が.otf, .otcですが、TrueTypeの拡張仕様になっているので、以降の解説に変更はありません。今回の調査の参考資料は OpenType のものでした。

オフセットテーブル

奏穓㤰扩,YOzS90biフォントのファイルである、YOzBS_90i.ttfを例に見ていきます。

adachi@banach:~$ hd /usr/share/fonts/truetype/yozvox-yozfont/YOzBS_90i.ttf|head -19
00000000  00 01 00 00 00 12 01 00  00 04 00 20 47 53 55 42  |........... GSUB|
00000010  39 b5 89 69 00 00 01 2c  00 00 09 a0 4f 53 2f 32  |9..i...,....OS/2|
00000020  7b bb 9c 48 00 00 0a cc  00 00 00 56 63 6d 61 70  |{..H.......Vcmap|
00000030  81 65 89 ac 00 00 0b 24  00 00 85 8c 63 76 74 20  |.e.....$....cvt |
00000040  0f c0 10 00 00 00 90 b0  00 00 02 00 66 70 67 6d  |............fpgm|
00000050  01 52 9c 18 00 00 92 b0  00 00 00 b3 67 61 73 70  |.R..........gasp|
00000060  00 07 00 07 00 00 93 64  00 00 00 0c 67 6c 79 66  |.......d....glyf|
00000070  86 0a 0c 69 00 00 93 70  00 97 79 88 68 65 61 64  |...i...p..y.head|
00000080  0a cf 6d bf 00 98 0c f8  00 00 00 36 68 68 65 61  |..m........6hhea|
00000090  07 73 58 6e 00 98 0d 30  00 00 00 24 68 6d 74 78  |.sXn...0...$hmtx|
000000a0  19 9b 7c b9 00 98 0d 54  00 01 57 2c 6c 6f 63 61  |..|....T..W,loca|
000000b0  88 a4 19 18 00 99 64 80  00 01 57 30 6d 61 78 70  |......d...W0maxp|
000000c0  6e 28 04 4c 00 9a bb b0  00 00 00 20 6d 6f 72 74  |n(.L....... mort|
000000d0  bd c7 3f 9b 00 9a bb d0  00 00 09 a8 6e 61 6d 65  |..?.........name|
000000e0  72 fb d6 d7 00 9a c5 78  00 00 01 fd 70 6f 73 74  |r......x....post|
000000f0  ff a3 00 30 00 9a c7 78  00 00 00 20 70 72 65 70  |...0...x... prep|
00000100  0f 25 3e a5 00 9a c7 98  00 00 02 82 76 68 65 61  |.%>.........vhea|
00000110  05 23 56 98 00 9a ca 1c  00 00 00 24 76 6d 74 78  |.#V........$vmtx|
00000120  2a 33 06 6a 00 9a ca 40  00 01 57 2c 00 01 00 00  |*3.j...@..W,....|

オフセットテーブル
バイト数	名称	ここの値	説明
4	version	00 01 00 00	バージョン。TrueType アウトラインの場合は、0x00010000 のはず。 TTCファイルの場合は 0x74746366 (ttcf) になっているので別の読み方になる PostScript アウトラインを含む場合は、0x4F54544F (OTTO)。
2	numTables	00 12	テーブルの数このファイルは0x12(10進で18)個の部分(テーブル)から構成されている。テーブル識別子は GSUB, OS/2, cmap, ... ,name, ..., vmtx の18個。それぞれのテーブルのファイル内の位置とデータ量がオフセットと長さとして以下に格納されている。
2×3	ここは解説しません
16×18	TableRecord [numTables]	47 53 55 42... 次に詳説	ひとつのTableRecordは16バイト。18あります。

18あるTableRecordのうち、GSUBとnameを抜き出してみます。

テーブル識別子	チェックサム	オフセット	データの長さ
47 53 55 42	39 b5 89 69	00 00 01 2c	00 00 09 a0
6e 61 6d 65	72 fb d6 d7	00 9a c5 78	00 00 01 fd

オフセットはファイル先頭を 0 とした値です。GSUBのオフセットは0x12cですが、これはオフセットテーブルが終わる 0x0000012b の次の00を指しており、辻褄が合っています。

必要なのはファイル名のテーブルです。nameのオフセットが 0x9ac578 ですので、そこから 0x1fd バイトを参照すれば良いとわかります。

fileコマンドで簡単に

実はこのnameテーブルのオフセットは fileコマンドで知ることができます。

adachi@banach:~$ file /usr/share/fonts/truetype/yozvox-yozfont/YOzBS_90i.ttf
/usr/share/fonts/truetype/yozvox-yozfont/YOzBS_90i.ttf: TrueType Font data, 18 tables, 1st "GSUB", name offset 0x9ac578

fileコマンドは寡黙ですが、要点を押さえた出力を出してくれると感心します。でもそれを理解するには、こちらにも知識が必要です。

nameテーブル

nameのデータはオフセットが 00 9a c5 78 長さが 00 00 01 fd なので、009ac570の行の 00 00から、009ac770 の行の 6c 64 までです。

009ac570  53 6d 55 ca ff ff ff ff  00 00 00 21 01 92 00 01  |SmU........!....|
009ac580  00 00 00 00 00 00 00 08  00 4f 00 01 00 00 00 00  |.........O......|
009ac590  00 01 00 08 00 47 00 01  00 00 00 00 00 02 00 04  |.....G..........|
009ac5a0  00 67 00 01 00 00 00 00  00 03 00 08 00 47 00 01  |.g...........G..|
009ac5b0  00 00 00 00 00 04 00 08  00 47 00 01 00 00 00 00  |.........G......|
009ac5c0  00 05 00 0d 00 3a 00 01  00 00 00 00 00 06 00 08  |.....:..........|
009ac5d0  00 47 00 01 00 00 00 00  00 07 00 08 00 47 00 01  |.G...........G..|
009ac5e0  00 01 00 0b 00 00 00 08  00 4f 00 01 00 01 00 0b  |.........O......|
009ac5f0  00 01 00 08 00 47 00 01  00 01 00 0b 00 02 00 04  |.....G..........|
009ac600  00 67 00 01 00 01 00 0b  00 03 00 08 00 47 00 01  |.g...........G..|
009ac610  00 01 00 0b 00 04 00 08  00 47 00 01 00 01 00 0b  |.........G......|
009ac620  00 05 00 0d 00 3a 00 01  00 01 00 0b 00 06 00 08  |.....:..........|
009ac630  00 47 00 01 00 01 00 0b  00 07 00 08 00 47 00 03  |.G...........G..|
009ac640  00 01 04 09 00 00 00 10  00 2a 00 03 00 01 04 09  |.........*......|
009ac650  00 01 00 10 00 1a 00 03  00 01 04 09 00 02 00 08  |................|
009ac660  00 57 00 03 00 01 04 09  00 03 00 10 00 1a 00 03  |.W..............|
009ac670  00 01 04 09 00 04 00 10  00 1a 00 03 00 01 04 09  |................|
009ac680  00 05 00 1a 00 00 00 03  00 01 04 09 00 06 00 10  |................|
009ac690  00 1a 00 03 00 01 04 09  00 07 00 10 00 1a 00 03  |................|
009ac6a0  00 01 04 11 00 00 00 10  00 2a 00 03 00 01 04 11  |.........*......|
009ac6b0  00 01 00 10 00 1a 00 03  00 01 04 11 00 02 00 08  |................|
009ac6c0  00 57 00 03 00 01 04 11  00 03 00 10 00 1a 00 03  |.W..............|
009ac6d0  00 01 04 11 00 04 00 10  00 1a 00 03 00 01 04 11  |................|
009ac6e0  00 05 00 1a 00 00 00 03  00 01 04 11 00 06 00 10  |................|
009ac6f0  00 1a 00 03 00 01 04 11  00 07 00 10 00 1a 00 03  |................|
009ac700  00 01 04 11 00 0d 00 08  00 5f 00 56 00 65 00 72  |........._.V.e.r|
009ac710  00 73 00 69 00 6f 00 6e  00 20 00 31 00 34 00 2e  |.s.i.o.n. .1.4..|
009ac720  00 30 00 34 00 59 00 4f  00 7a 00 53 00 39 00 30  |.0.4.Y.O.z.S.9.0|
009ac730  00 62 00 69 00 59 00 2e  00 4f 00 7a 00 20 00 56  |.b.i.Y...O.z. .V|
009ac740  00 6f 00 78 56 65 72 73  69 6f 6e 20 31 34 2e 30  |.o.xVersion 14.0|
009ac750  34 59 4f 7a 53 39 30 62  69 59 2e 4f 7a 20 56 6f  |4YOzS90biY.Oz Vo|
009ac760  78 00 42 00 6f 00 6c 00  64 00 2d 00 2d 00 2d 00  |x.B.o.l.d.-.-.-.|
009ac770  2d 42 6f 6c 64 00 00 00  00 03 00 00 00 00 00 00  |-Bold...........|
009ac780  ff a0 00 30 00 00 00 00  00 00 00 00 00 00 00 00  |...0............|

NameRecordは33ありますが、最初の2つと最後の2つだけ、開始の6バイトを背景青色にしています。

nameテーブルデータ
バイト数	名称	ここの値	説明
2	format	00 00	フォーマット番号。0 or 1 (1の場合、NameRecordの配列の後に若干の追加があるがここでは触れない)
2	count	00 21	文字列データの数 0x21 なので　33個
2	stringOffset	01 92	文字列が格納されている領域の先頭のオフセット位置。 (name テーブルの先頭を 0 とする)
12×count ここでは 12×33	NameRecord[count]	00 01 00 00 00 00 00 00 00 08 00 4f 00 01 00 00 00 00 00 01 00 08 00 47 ....全部で33行	NameRecord の配列 (各文字列のデータ)。実際にはエンコードの種類、言語、名前の種類、文字列へのオフセットと長さで構成され、文字列そのものは入っていない。
0x1fd-stringOffset ここでは 0x1fd-0x192=0x6b		00 56 00 65 00 72 ....	いろいろな名前の文字列の集合。NameRecord の配列データを使って読み出す。

NameRecord

platformID, encodingID, languageID

NameRecordは2バイトずつ6つの項目からなっています。最初の3項目は、platformID, encodingID, languageIDです。

platformIDは、0:Unicode, 1:Macintosh, 3:Windows のどれかで、続くencodingIDとlanguageIDは、platformIDにより書き方が異なります。

0:Unicode: encodingIDは 0~2:Unicode1.0など古いもので非推奨 3:Unicode2.0以降のBMPのみ、4:Unicode2.0以降のフルレパートリー; languageIDはありませんが、0としてあるようです。
1:Macintosh: encodingIDは 0:Roman, 1:Japanese, 2:Chinese(Traditional), 3:Koreanなどと決められています。昔のMacintoshを知る一にとっては1:Japanese で文字コードとして Shift-JIS を使うということは当然なのかもしれませんが、今となってはJapaneseならShift_JISとはならないでしょう。AdobeのTutorial には書いてありますが、learn.microsoft.com では見つけられませんでした。; languageIDは 0:English, 1:French, 2:German, ...となっていて、11:Japanese です。
3:Windows: encodingIDは 0:symbol, 1:Unicode BMP, 2:ShiftJIS ...となっていますが、symbolはシンボルフォントのことでUTF-16BEを推奨しています。始めてみたときsymbolとはどんなencodingなのかと思いました。なにかとUT-16BEを勧めてきます。1:はBMPに制限され、BMPを超えて使うときには 10:Unicode full repertoire とすべきでしょうが、3:1:でUTF-16BEと強気で書いてあります。; languageIDは言語だけでなく地域も考慮されて 0409:English-US, 0809:English-UK, 0c09:English-Australia, などとなっています。0411:Japanese-Japan です。

組み合わせはたくさんありますが、実際には次の4つしかでてきません。

0001 0000 0000 = Macintosh Roman English, 
0001 0001 000b = Macintosh Japanese Japanese, 
0003 0001 0409 = Windows UnicodeBMP English-US, 
0003 0001 0411 = Windows UnicodeBMP Japanese

nameID

4番めの項目はnameIDです。

もともと各プラットフォームで使われていた約束事を詰め込んでそれぞれ使っていたものが、拡張されたり、新しい仕組みを追加したりしたのではないかと感じられます。Adobeの説明とMicrosoftの説明で強調点が異なったり、詳しい説明がなかったりします。また、ttfファイルの実装をみても全部を取り扱っていないのはもちろん、フラットフォームによっては不要なはずのものをとりあえず設定してあるというのも見かけますので、全部をきちんと理解して使うのは事実上無理なんではないかと思います。

nameID:説明
0	著作権
1	フォントのファミリー名。この「ファミリー」はcssで使われるものとは異なり、regular, italic, bold, bold italic の4つのスタイルをメンバーに持つファミリーです。nameID=2 の名前を付加してフォントを選択するというやり方を想定しています。
2	フォントのサブファミリー名。「サブファミリー」はしっくり来ませんが、"Regular" など、フォントのスタイルを表す名前です。
3	一意のフォント識別子
4	完全なフォント名。nameID=2の名前を付加してフォント名にするのがふさわしくない場合などに使用します。
5	バージョン文字列。
6	フォントの PostScript 名
7	商標
8	製造者
9	デザイナーの名前
10	説明
11	ベンダーの URL
12	デザイナーの URL
13	ライセンス説明
14	ライセンス情報の URL
15	予約
16	タイポグラフィーファミリー名。nameID=1の4つのスタイルという制約を超えてフォントをグループ化したいときに使用する。これが定義されていないときは nameID=1 のものがタイポグラフィーファミリー名とみなされる
17	タイポグラフィファミリーグループ内でサブファミリー名を指定する。
18	(Mac のみ) 互換性のあるフルネーム
19	サンプルテキスト。フォントのサンプル表示時に適した文字列。
20	PostScript CID findfont 名
21	WWS ファミリー名
22	WWS サブファミリー名
23	明るい背景パレット (CPAL テーブル)
24	暗い背景パレット (CPAL テーブル)
25	バリエーションの PostScript 名の接頭語

フォントの名前のしくみとしては、1,2,4,16,17 あたりに注目していればいいでしょう。21,22も気になるところですが、まだ出会っていません。有効に作用している実例がなければなかなか腑に落ちない説明もあります。

length, offset

nameIDに対応した文字列が格納されている場所をoffsetから求め、lengthだけ読み取ってencodeIDで示された方法で解釈することで名前の文字列が得られます。

オフセットは3回目の登場になります。

1つ目はnameテーブルへのオフセットで、例に使っているYOzBS_90i.ttfでは 0x9ac578 でした。

2つ目はnameテーブルの最初にあった stringOffset で、0x192 でした。これはname テーブルの先頭を 0 としています。

3つ目がここに出てきた offset です。これは stringOffset の位置を 0 とします。

つまり、3つのオフセットを加算することで、文字列の位置がわかるということになります。

offsetの値を同じにすれば、異なるnameIDに同じ文字列を与えることができます。エンコードの問題をきちんと考慮すれば、platformIDやLanguageIDが異なっても共通な文字列で済ませることもできます。

NameRecordの実例を読む

ずっと見てきている、YOzBS_90i.ttf のNameRecordです。nameテーブル全体の16進ダンプの図に合わせて、最初の2つと最後の2つだけ、開始の6バイトをを背景青色にしています。

platformID encodingID languageIDについては、対応する値の略記を追記しています。

NameRecord
	platformID	encodingID	languageID	nameID	length	offset
01	00 01 mac	00 00 rom	00 00 en	00 00	00 08	00 4f
02	00 01 mac	00 00 rom	00 00 en	00 01	00 08	00 47
03	00 01 mac	00 00 rom	00 00 en	00 02	00 04	00 67
04	00 01 mac	00 00 rom	00 00 en	00 03	00 08	00 47
05	00 01 mac	00 00 rom	00 00 en	00 04	00 08	00 47
06	00 01 mac	00 00 rom	00 00 en	00 05	00 0d	00 3a
07	00 01 mac	00 00 rom	00 00 en	00 06	00 08	00 47
08	00 01 mac	00 00 rom	00 00 en	00 07	00 08	00 47
09	00 01 mac	00 01 jap	00 0b ja	00 00	00 08	00 4f
0a	00 01 mac	00 01 jap	00 0b ja	00 01	00 08	00 47
0b	00 01 mac	00 01 jap	00 0b ja	00 02	00 04	00 67
0c	00 01 mac	00 01 jap	00 0b ja	00 03	00 08	00 47
0d	00 01 mac	00 01 jap	00 0b ja	00 04	00 08	00 47
0e	00 01 mac	00 01 jap	00 0b ja	00 05	00 0d	00 3a
0f	00 01 mac	00 01 jap	00 0b ja	00 06	00 08	00 47
10	00 01 mac	00 01 jap	00 0b ja	00 07	00 08	00 47
11	00 03 win	00 01 uni	04 09 en	00 00	00 10	00 2a
12	00 03 win	00 01 uni	04 09 en	00 01	00 10	00 1a
13	00 03 win	00 01 uni	04 09 en	00 02	00 08	00 57
14	00 03 win	00 01 uni	04 09 en	00 03	00 10	00 1a
15	00 03 win	00 01 uni	04 09 en	00 04	00 10	00 1a
16	00 03 win	00 01 uni	04 09 en	00 05	00 1a	00 00
17	00 03 win	00 01 uni	04 09 en	00 06	00 10	00 1a
18	00 03 win	00 01 uni	04 09 en	00 07	00 10	00 1a
19	00 03 win	00 01 uni	04 11 ja	00 00	00 10	00 2a
1a	00 03 win	00 01 uni	04 11 ja	00 01	00 10	00 1a
1b	00 03 win	00 01 uni	04 11 ja	00 02	00 08	00 57
1c	00 03 win	00 01 uni	04 11 ja	00 03	00 10	00 1a
1d	00 03 win	00 01 uni	04 11 ja	00 04	00 10	00 1a
1e	00 03 win	00 01 uni	04 11 ja	00 05	00 1a	00 00
1f	00 03 win	00 01 uni	04 11 ja	00 06	00 10	00 1a
20	00 03 win	00 01 uni	04 11 ja	00 07	00 10	00 1a
21	00 03 win	00 01 uni	04 11 ja	00 0d	00 08	00 5f

オフセットの計算をしておきます。こうしておくと16進ダンプから、開始位置を見つけるのが容易になります。

複数のnameIDから参照されているoffsetもありますので、どこから参照されているかわかるようにしてみました。

オフセットの計算
NameTable Offset	stringOffset	offset	開始位置	ここを指定しているnameID
9ac578	+0192	+00	9ac70a	win_en_05version, win_ja_05version
9ac578	+0192	+1a	9ac724	win_en_01fam,03Unique,04full,06ps,07trademark, win_ja_01fam,03Unique,04full,06ps,07trademark
9ac578	+0192	+2a	9ac734	win_en_00©,win_ja_00©
9ac578	+0192	+3a	9ac744	mac_en_05version, mac_ja_05version
9ac578	+0192	+47	9ac751	mac_en_01fam,03Unique,04full,06ps,07trademark, mac_ja_01fam,03Unique,04full,06ps,07trademark
9ac578	+0192	+4f	9ac759	mac_en_00©, mac_ja_00©
9ac578	+0192	+57	9ac761	win_en_02sub, win_ja_02sub
9ac578	+0192	+5f	9ac769	win_ja_0dvender
9ac578	+0192	+67	9ac771	mac_en_02sub, mac_ja_02sub

16進ダンプから次のように開始位置を見つけ出します。

9ac70aの場所

設定されたフォント名を読む

win_enはすでに説明したようにWindows UnicodeBMP English-USの略記です。win_jaはWindows UnicodeBMP Japaneseの略記です。

共に文字エンコードはutf-16BEとして読めば良いので、2バイト区切りで書いてあります。

mac_enはMacintosh Roman Englishの略記です。mac_jaはMacintosh Japanese Japaneseの略記です。

encodeIDで示されたRomanは、多分ASCIIで読むということでしょうから、読めます。JpaneseはShift_JISとして書くことになっていますが、0x20から0x7eの範囲はASCIIと共通ですから、Shift_JISで書いてありますといえば間違いではありません。なので、こちらも同じコードを指定していても大丈夫です。

文字コードと文字列を検証
開始位置	platf_lang	name	文字コード	文字列
9ac70a	win_en,win_ja	ver	0056 0065 0072 0073 0069 006f 006e 0020 0031 0034 002e 0030 0034	Version 14.04
9ac724	win_en,win_ja	fam, etc.	0059 004f 007a 0053 0039 0030 0062 0069	YOzS90bi
9ac734	win_en,win_ja	©	0059 002e 004f 007a 0020 0056 006f 0078	Y.Oz Vox
9ac744	mac_en,mac_ja	ver	56 65 72 73 69 6f 6e 20 31 34 2e 30 34	Version 14.04
9ac751	mac_en,mac_ja	fam, etc.	59 4f 7a 53 39 30 62 69	YOzS90bi
9ac759	mac_en,mac_ja	©	59 2e 4f 7a 20 56 6f 78	Y.Oz Vox
9ac761	win_en,win_ja	sub	0042 006f 006c 0064	Bold
9ac769	win_en,win_ja	vender	002d 002d 002d 002d	----
9ac771	mac_en,mac_ja	sub	42 6f 6c 64	Bold

何の問題もありません。win部分を使っても、mac部分を使っても正しく読むことができます。

fc-listの出力をもう一度見てみましょう。

adachi@banach:~$ fc-list YOzS90bi
/usr/share/fonts/truetype/yozvox-yozfont/YOzBS_90i.ttf: 奏穓㤰扩,YOzS90bi:style=䉯汤,Bold

より詳しい表示では、

adachi@banach:~$ fc-list -vb YOzS90bi
Pattern has 26 elts (size 32)
	family: "奏穓㤰扩"(s) "YOzS90bi"(s)
	familylang: "ja"(s) "en"(s)
	style: "䉯汤"(s) "Bold"(s)
	stylelang: "ja"(s) "en"(s)
	fullname: "奏穓㤰扩"(s) "YOzS90bi"(s)
	fullnamelang: "ja"(s) "en"(s)
	slant: 0(i)(s)
	...以下略

おそらくですが、debian13(trixie)側がMacintosh用のnameデータを読んで、

familyname を Macintosh Roman English familyname から ASCIIとして読んで YOzS90bi
familyname を Macintosh Japanese Japanese subfamilyname から utf-16として読んで 奏穓㤰扩
subfamilyname も同様

ということなのだろうと思います。

Shift_JISとして読もうとして失敗して、utf-16で読んでみたのかもしれませんが、だったら昔通り(たぶんunicodeが普及する前からやっていたのだから)ASCIIとしてよんでみればよいのにと思います。また、utf-16を読めるなら、Windows用のデータを読んでもよかったはずです。

参照した資料

OpenType フォント・フォーマット (opentype全般)
Adobe: OpenType-CID/CFF CJK Fonts: ‘name’ Table Tutorial Adobe Technical Note #5149 (nameテーブル)
Microsoft: name — Naming Table (OpenType 1.8.4) Learn Microsoft Typography (nameテーブル)