[120] OpenType ではいろいろな文字コードが使われます。
[39] OpenType における文字コードには2つの側面があります。
name 表のフォント名が関係します。cmap 表が文字コードとグリフIDの対照表となっています。[42]
name 表と
cmap 表は、
利用する文字コードを記述し、その文字コードによって文字を記述または参照しています。
[43] その他のいくつかの文字データは符号化方式が決め打ちです。
metaのテキストデータは UTF-8 です。name の言語タグは UTF-16BE です。[119]
GSUB や GPOS ではグリフIDが使われます。
文字コードとグリフ符号の違いに注意。
OpenType のグリフIDは個々のフォントが独自に決定できるフォント内部の記述用のもので、
情報交換には適しません。
(ただしグリフ名とCIDも参照。)
[49]
cmap 表には異なる文字符号化の部分表を含められます。
文字符号化は、
(platformID, encodingID, language)
の3つの値の組で識別されます。
>>1
[68] Unicode部分表とその他の何種類かの部分表は、 Unicode の符号位置(列)からグリフIDへの対応関係を表します。 その他の部分表は、 非Unicodeの文字符号化からグリフIDへの対応関係を表します。
platformID[50]
platformID
は、
次のいずれかです。
platformID[55]
platformID は encodingID の名前空間を区別する役割がありますが、
それ以外の意味も処理方法も規定がありません。例えば Linux
の実装が Windows platformID を使ってはいけないということはありません。
プラットフォームごとに文字コードの体系がまったく違っていた旧時代の遺物と考えるべきなのでしょう。
[53] すべての値に対応しなければならないとする規定はありません。 未対応のものは無視して構わないと思われます。
[52] 未知の値に遭遇したときどう処理するべきか不明確です。 それが含まれるものは無視するのが妥当でしょう。
[54]
利用者定義の値について、使い方に何の規定もありません。
encodingID は好きに使って良いのでしょう。
未知の値は無視して構わないと考えるのが妥当でしょう。
[74]
platformID 1 (Macintosh)
の
cmap 部分表はかつての Macintosh では必須でしたが、
現在の Apple のプラットフォームでは非推奨です。
>>1
encodingID[70]
encodingID
の意味は
platformID に依存します。
encodingID
には次のものがあります。
platformIDencodingIDcmap:
部分表 format 4, 6 で使うべき >>1,
name >>121cmap :
部分表 format 10, 12 で使うべき >>1,
name >>121cmap : OTF Windows NT compatibility mappingcmap format 0, 6 でなければ。
新たに使うべきではない。[67]
OpenType 仕様書では
cmap
表の
Unicode部分表という語が使われています。
platformID 0
と
platformID 3
encodingID 1, 10
を表すとされています。
>>1
[75]
また Windows 用のフォントを作成するときは
Unicode cmap 部分表を常に使うべきともされています。
この Unicode cmap 部分表は
platformID 3
encodingID 1, 10
を意味するとされています。
>>1
[123]
Windows 用フォント
の
name
については、
platformID 3
で
encodingID 1 (Unicode フォント)
または
encodingID 0 (Symbol font)
とするべきです。
>>121
[122]
name
における
platformID 3 (Windows)
においては、
encodingID
は、
cmap の
platformID 3 (Windows)
の
encodingID
と一致しているべきです。
>>121
[78]
Unicode の BMP のみと全体とは format が違えば区別可能なはずです。
にも関わらず encodingID と format
の両方に違う値を指定させて区別しています。
format 13 専用の encodingID もそうです。
format だけでの区別では実装上の問題があったのでしょうか。
[124]
name
の文字列は、
encodingID が 3 (Windows)
の場合、
UTF-16BE
で符号化しなければなりません。
>>121
[125]
これはつまり、 cmap の encodingID と同じ値を指定する (>>122)
だけで、その値自体にはそれほど意味がなく、
値に関わらず UTF-16BE を使わなければならないということのようです。
[126]
古い CJK フォントはこの規定に反していることがあります。
例えば MingLi
は、
ラテン文字名を UTF-16BE で符号化しながらも中文名は
encodingID 4 (Big5) で文字列を CP950
で符号化していました。
>>121
[127]
これは platformID 1 (Macintosh)
が実際に指定された通りの符号化となるのと違う点です。
[128]
さて、 OpenType の仕様はこの状況をどう処理するべきなのか何も語っていません。
現在となっては platformID 3 (Windows)
のデータを含むフォントは希少となっているようですが、
古いフォントを扱う必要がある (可能性がある) ソフトウェアは、
何らかの方針を立てて対処しなければなりません。
[129] CJK のコードページならコードページ通りの符号化、 それ以外なら UTF-16BE、としてしまっていいのでしょうか。 それなら楽なのですが、 CJK のコードページで UTF-16BE のフォントも出回っているなら、文字コード自動判定が必要となります。
[146] なお、
OS/2 表にはカバーしているコードページを記述できます。
[145] OS/2 - OS/2 and Windows metrics table (OpenType 1.9) - Typography | Microsoft Learn, PeterCon, https://learn.microsoft.com/ja-jp/typography/opentype/spec/os2#cpr
platformID 4[79]
platformID 4 (Custom)
は、
encodingID [ 0, 255 ] が
OTF Windows NT compatibility mapping
として使われます。
>>1
[81]
platformID 4
は、
Type 1
フォント由来の OpenType フォントを通じて古い応用との互換性を維持するための遺物です。
cmap platformID 4
を使って、
非Unicode 応用に対してフォントを
Windows ANSI符号化されているように見せかけられます。
>>1
[82]
Windows ANSI符号化でない Type 1 フォント、
例えばキリル文字や中欧フォントは、
過去 Adobe が出荷した際に
.PFM ファイルの CharSet 欄を
0 (Windows ANSI)
としていました。
ATM for Windows 9x
は
CharSet
を無視していました。
>>1
[83]
Adobe は
Encoding が StandardEncoding でない Type1 フォントから変換された
OpenType フォントにおいて
cmap platformID 4
を使います。
>>1
[84]
platformID 4
の
encodingID
は、
元の Type 1 フォントの .PFM
ファイルの
Windows charset 値 [ 0, 255 ]
に設定しなければなりません。
>>1
[85]
platformID 4 encodingID [ 0, 255 ]
が
CFF アウトラインの OpenType フォントで使われた場合、
Windows NT の OTF フォントドライバーは、
次のように動作します。
>>1
CharSet 0) をフォントが対応する
CharSet の一覧に追加します。encodingID を Windows CharSet 値とみなし、
フォントが対応する CharSet の一覧に追加します。[90]
cmap の符号化は、
CFF の符号化と同一でなければなりません。
>>1
[80]
platformID 4
は、現在広くは用いられていません。
新しいフォントでは使うべきではありません。
>>1
[24]
互換性のためか
platformID = 0 (Macintosh),
encodingID = 0 (MacRoman)
で、
0x100, 0x101
だけの
cmap
部分表が含まれるフォントがままあります。
[32]
Nishiki-teki
は
platformID = 0 (Unicode),
encodingID = 10
という
cmap subtable
を持っています。
でも
platformID 0 encodingID 10
は
Microsoft の仕様書にも Apple の仕様書にも載っていません。
[33]
中身は Unicode のようです。
platformID = 3 (Windows)
だと
encodingID = 10 が Unicode
なので、
それの誤りなのでしょうか。
[34]
Makoto Comic
にも
platformID = 0 (Unicode),
encodingID = 10
があります。
[130]
name では3種類の言語符号の体系が使われています。
cmap ではそのうち1種類 (の変種) が使われています。
なお OpenType の他の場所では他の体系も使われています。
[131]
name の項目を表す
NameRecord
の
languageID
は言語を表します。
[132]
languageID の値の意味は当該
name
表の
version
と
NameRecord
の
platformID
に依存して決まります。
>>121
[141]
name
で
platformID が 0 (Unicode)
の場合、
languageID 0 を使うことができます。
この値は特定の言語を表しません。
>>121
[143]
name
で
platformID が 1 (Macintosh)
の場合、
languageID
には
Macintosh language ID
を指定できます。
>>121
[144]
name
で
platformID が 3 (Windows)
の場合、
languageID
には
Windows language ID
を指定できます。
>>121
[133]
name
の
version
には
0 と 1
がありますが、
1 のとき、
IETF言語タグを任意個設定できます。
各 NameRecord
はこの言語タグを参照することによって言語を記述できます。
>>121
[134]
version 1 では、
languageID
は
0x8000
以上のとき、 言語タグを表すと解釈され、
それ未満のとき、
platformID
依存の言語符号と解釈されます。
>>121
[140]
version 0 では、
languageID
は原則として
0x8000
未満の値を使わなければなりません。
>>121
[142]
version 0 の
languageID
でも、
例外的に、
platformID
が
[ 240, 255 ]
のときは
0x8000
以上の値を使うことが禁止されていません。
>>121
[137]
IETF言語タグを設定したときは、
languageID
ではそれを 0x8000, 0x8001, ... といった値で参照できます。
数値は言語タグが記述された順序で割り振られていきます。
>>121
[138] 指定された値に対応する言語タグが存在していないときは、 言語は未知となります。そのような値は使うべきではありません。 >>121
[93]
cmap
部分表の
language
は文字符号化の言語を表します。
[92]
platformID 1 (Macintosh)
以外の
cmap 部分表の
language
は、
0
でなければなりません。
>>1
[94]
platformID 1 (Macintosh)
の
cmap 部分表の
language
は、
とします。 >>1
[95]
Mac OS Roman
cmap
では、
言語依存の符号化ではありませんから、
0
としなければなりません。
>>1
[96]
Mac OS Turkish
cmap
では、
Turkish の Macintosh language ID が 17
なので、
language
は
18
とします。
>>1
[105]
language
は
format
依存の部分表に属しています。
ということは古い
Macintosh
でしか使われていないこの欄をいつまでも残しておく必要も無さそうなものですが、
新しそうな
format
でもそのまま引き継がれています。
[106]
ただし
format 14
には
language
欄がありません。この format だけ
Unicode
に完全に依存している
(= language があってもまったく使いようがない)
関係なのでしょうかね。
(他は、少なくても理屈の上では、
Unicode に限定されていないので使い道がないとはいえない。)
cmap 表[111]
cmap は一部例外を除き、1つの文字 (を表す符号位置、ビット組合せ)
に対して1つのグリフを与える写像です。
cmap だけでは実現できず、 GSUB
(または shaping engine による文字前処理)
との組み合わせが必要となります。[56]
cmap 表の encodingRecords
に含められる EncodingRecord
は、
その
platformID,
encodingID,
部分表の language
の優先順で整列しなければなりません。
>>1
ここでの順序は数値の小さい順と思われます。
[57]
cmap 表にあっては
EncodingRecord
の
platformID,
encodingID,
部分表の language
の組み合わせは、
高々1回しか出現できません。
>>1
[58] 順序が不適切な場合や重複を含む場合にどう処理するべきなのかは定かではありません。 順序を無視する実装もあり得ますし、 求めるものより大きな値が出現したら探索を止める実装もあり得ます。 最初の一致を採る実装も、無作為に選ぶ実装もあり得ます。 エラーにする実装もあり得ます。 主要な実装はどうしているのでしょうか?
[59]
各部分表は、
format が 14 の場合を除き、
排他的であります。
つまり応用は、そのうちの1つだけを選び、他を無視するべきです。
>>1
[60]
Unicode部分表が含まれる場合で、
16ビットの
format
のものと
32ビットの
format
のものが両方含まれるなら、32ビットの部分表に含まれる文字は、
16ビットの部分表に含まれる文字の超集合であるべきです。
応用は、
32ビットの部分表を使うべきです。
>>1
[63]
platformID が違い
format
が同じ
Unicode部分表が含まれる場合、
応用はそのいずれを選んでも構いませんが、
そのフォントの利用時にどの部分表が選ばれるかは一貫しているべきです。
>>1
[97] 明示的には定められていませんが、その趣旨からして、 未対応の組み合わせが出現しても、 実装は黙って無視するべきと思われます。
[98] 指定されたすべての組み合わせが未対応の場合にどうするかは定められていません。 エラーとしてまったく受理しない実装もあるかもしれませんし、 黙って他のフォントにフォールバックするような実装戦略もあるかもしれません。
format 14 を除けば)
もはやプラットフォームの違いによる互換性の問題はおおむね解消しており、
必要だからというより今までそうしてきたからというところが大きそうです。format[47]
cmap
表の
format
は文字コードからグリフIDへの写像の記述方法を表します。
>>1
[48] 多くの方法が定義されていますが、新しいフォントはそのうちの 4, 12、 用途により 13, 14 が適切です。 それ以外は新しいフォントには推奨されません。 >>1
[104]
いくつかの
format
はデータ構造上、
矛盾した値を記述することができます。
例えば開始よりも終了が小さな値の範囲を記述できたり、
小さい順に整列と規定されている (が構文上は無視できる)
ことがあります。
それらの一部は仕様書上で明確に禁止されています。
しかし禁止されている場合や当然に異常とみなされる場合に、
どう処理するべきかは明確ではありません。
(これは cmap に限らず OpenType 全般でそうです。)
format 0 (1バイト符号)[4]
format = 0 :
[ 0x00, 0xFF ]
のビット組合せに対応するグリフIDが順番に格納されています。
>>1, >>2
[100] 古い Macintosh ではこれが標準でした。 >>1
[5] 新しい Apple のプラットフォームでは必須ではありません。 >>1 今はあまり使われていません。 対応していない実装もあります。
format 2 (1バイトと2バイトの多バイト符号)[6]
format = 2 :
1バイト (8ビット) または2バイト (16ビット)
の多バイト符号に対応するグリフIDが順番に格納されています。
>>1, >>2
[99] 記述のないバイトはグリフID 0 に対応するものと解釈されます。 >>1
[101]
CJK の非Unicodeの多バイト符号に適していました。
[7] 古い時代に用いられていたもので、今はあまり使われていません。 対応していない実装もあります。
format 4, 6, 12, 10, 13 (16ビット符号と32ビット符号)format = 4 :
16ビット符号用。
>>1, >>2format = 6 :
16ビット符号用。
>>1, >>2format = 12 :
32ビット符号用。
>>1, >>2format = 10 :
32ビット符号用。
>>1, >>2[11] 4, 6 は Unicode BMP 用, 12, 10 は Unicode 全体に使われています。
[10] 4, 12 は連続した符号位置にグリフIDが割り当てられた密なもの、 6, 10 は疎なものに適したデータ構造になっています。
[28] 6 に対応していない実装もあります。
[16] 10 はあまり使われておらず、 Windows は対応していません。 >>1, >2
[20]
当初 4 が使われ後に 12 が使われるようになった経緯のため、
古い実装は 12 に対応していません。
多くのフォントは 4 と 12 の両方の cmap 部分表を含めているようです。
(そうできると明記されていますが、必須ではありません。 >>1)
古い実装は 4 の方を見るので、 BMP の文字だけは使えます。
[64]
format が 4 と 6
の
Unicode部分表を同時に含めるべきではありません。
format が 10 と 12
の
Unicode部分表を同時に含めるべきではありません。
これらの場合、 4 や 12 を使うべきです。
>>1
[76]
Windows (platformID 3)
で
Unicode BMP
のみ対応するフォントは、
encodingID 1
format 4
部分表を使わなければなりません。
>>1
[77]
Windows (platformID 3)
で
Unicode 非 BMP
に対応するフォントは、
encodingID 10
format 12
部分表を使わなければなりません。
>>1
[15]
format = 13 は format = 12 の変種。
複数の連続した符号位置の範囲を1つのグリフIDに割り当てる。
>>1, >>2
[18] last-resort font (適当なグリフを用意できないときに代替グリフを提供するためのフォント) 用とされています。 その性質上ほとんど使われておらず、 対応していない実装もあります。
[73]
format 13
部分表は、
platformID 0
encodingID 6
でのみ使うべきです。
>>1
[149]
format 4
のとき最後に startCode 0xFFFF,
endCode 0xFFFF
の segment が必須です。
>>1
[150]
妥当な写像でもそうでもなくても構わない >>1 とされます。
つまり U+FFFF 用のグリフ情報を含めることも、
含めないこともできますが、
どちらの場合も機械的にこの segment が必要となります。
[154]
Chrome も Firefox も、指定された符号が仕様通り昇順になっていないとき、
構文解析エラーとしてフォントを無視します。
Chrome は開発者ツールに cmap のエラーである旨のみを表示しますが、
それくらいしか情報がありません。
Firefox は開発者ツールに符号の値を表示してくれます。
[164]
format 12 と format 13
の両方があるとき、
Chrome も Firefox も format 13 の方は無視します。
cmap 中の順序は関係ありません。
(format だけによって決まるのか encodingID などでも決まるのかはよく分かりません。)
[114]
format 4
の部分表のサイズ上限を超えるようなフォントを作ろうとすると、
AFDKO の makeotf
は最初の2つの segment だけ残して後は捨ててしまいます。 >>113
[115]
Windows
のメモ帳や Microsoft Excel
は
format 4
が存在すること、という
heuristics
を実装しています。
それへの対処として、
format 12
を使うときでも
format 4
部分表を含めなければなりません。
>>113
(その場合でも format 12 が使われるので、
format 4 は不完全でも存在していればOKらしいです。)
原ノ味フォント 20200516 から、KR のみ format 4 と format 12 に対し、 Unicode コードポイントで一つだけ抜けている (両隣は存在するが該当箇所は存在しない)ものに .notdef を割り当てる加工をしています。 これは、何もしないと format 4 のサイズが 64 KB を超えてしまい、 ttx でのフォント生成が例外で落ちてしまったためです。 format 12 はサイズの問題がないし format 4 の情報もすべて含んだ上位互換なので、 format 4 がなくてもいいだろうと削除してみたら落ちなくなりましたが、 Windows がフォントとして認識してくれません。 仕方なく format 4 の仕様書とにらめっこしてサイズを低減する方法を模索し、 上記の処理を入れました。 なお format 12 も BMP の範囲は format 4 と同じである必要があるため、 BMP 範囲内のみ同じ処理を入れてあります。
原ノ味フォント 20200612 から、 KR で入れていた Unicode コードポイントで一つだけ抜けているものに .notdef を割り当てる加工 をやめ、代わりに Adobe-KR のドキュメントに記載されている format 4 から CJK Unified Ideographs (U+4E00..U+9FFF) と CJK Compatibility Ideographs (U+F900..U+FAFF) のブロックを削除する方法に変更しました。 これは .notdef を割り当てる加工をしていて、 かつ(関係ないはずの) GPOS テーブルが存在すると、 なぜか Windows がフォントを認識してくれないことが分かったためです。 OpenType 仕様的には(というか Windows 向けとしては) format 4 と format 12 の BMP 部分は一致するようにするのが推奨されていますが、 サイズ的に収まらないので仕方がなく Adobe お勧めの対処法に従った処理を行ったものです。
format 8 (16ビットと32ビットの混合符号)[12]
format = 8 :
16ビットまたは32ビットの符号用。
>>1, >>2
[103] 上位が 0x0000 となる32ビット符号に グリフを割り当てることも禁止はされていません。 しかし 0x0000 と上位 0x0000 の32ビット符号の両方にグリフを割り当てることは禁止されています。 >>1 そのような場合にどうするべきなのかは不明。
[13]
U+10FFFF まで使う Unicode を想定したものでした。
[102]
この
format
はあまり使われていません。
対応していない実装もあります。
非推奨とされています >>1。
format 14 (Unicode 異体列)[21]
format = 14 :
UVS
用。
>>1, >>2
[22]
他の format と違って入力が1つの文字 (符号位置)
ではなく2つの文字 (符号位置)。
Unicode の異体列の専用の仕組みになっています。
(2, 8 の入力は多バイトであっても1文字。 4, 6, 10, 12, 13 も同じ。
4, 6, 8, 10, 12, 13 は Unicode 想定であっても、専用ではない。)
[23]
同じく複数の Unicode文字で1つのものを表現する結合列や合字は
GSUB
でグリフレベルの操作を使っていますが、 VS
だけなぜか専用の仕組みが cmap に文字レベルで追加されました。
[25]
異体列に対し「異体選択子なしと同じ」を指定するものと、
グリフIDを指定するものの2種類の指定方法があります。
前者が得られた場合には他の
cmap 部分表を使って再探索することになります。
[26] 実際のフォントは前者の方法を使わずすべて後者の方法によるものと、 前者の方法を適宜使うものがあります。 前者を使った方がデータ量はいくらか少なくなるのでしょうが、 グリフ取得が少し遅くなります。 といっても現在の計算機の性能からみればどちらの差分もほとんど誤差みたいなものでしょう。
[29] VS は日本語や蒙古文字の表示には必須の機能ですが、 欧米では必要とされないことや、 比較的歴史の浅い機能であることから、 14 に対応していない実装もあります。
[30] 日本語用フォントで多くの文字を含んだものにはよく使われています。
[65]
Unicode部分表が使われる場合、
platformID 0
encodingID 5
format 14
の部分表で UVS に対応することができます。
format 14
部分表は、
platformID 0
encodingID 5
でのみ使うべきです。
>>1
format 14
は使えないということでしょうか。
(実用上それ以外で format 14 を使いたいことはなさそうですが。)[71]
UVS は、cmap 表で format 14 部分表で指定するべきです。
>>1
[117] 利用者:emk - GlyphWiki, https://glyphwiki.org/wiki/User:emk#i0
Windows 7でIVSを認識させるには、以下の条件をすべて満たす必要があるようです。
[165]
Chrome も Firefox も、
異体選択子が0個だとエラーとしてフォントを無視します。
従って1つも VS を含まないフォントでは
format 14 部分表全体を省かなければなりません。
[155]
仕様書上は特に制限されているようには読めませんが、
Chrome も Firefox も異体選択子以外の符号位置が書かれていると、
cmap の構文解析エラーとしてフォントを無視します。
[156] Chrome でも Firefox でも漢字 + 通常 SVS, 漢字 + IVS はうまく動作しますが、 漢字 + 蒙古文字自由異体選択子は動作しません。
format の実利用例[3] GitHub - nixeneko/nxTokiACF, https://github.com/nixeneko/nxTokiACF
format = 0, 4
[19] Release Version 14.000 Release · unicode-org/last-resort-font · GitHub, https://github.com/unicode-org/last-resort-font/releases/tag/14.000
LastResort-Regular.ttf
は
7.89MB
のフォント。
format = 12 と format = 4 (空)。
LastResortHE-Regular.ttf
は
506KB
のフォント。
format = 13 (platformID 3, encodingID 10),
format = 4 (platformID 3, encodingID 1) (空)。
(ファイルサイズの違いは format の違いに起因するものではない。)
[46]
cmap では、
フォント中に対応するグリフを持たない文字コードはグリフID
0
に写像するべきです。
>>1
[151]
この規定と関係するのかどうか、実装によっては cmap でグリフID 0
に対応付けるように設定しても、無視される (ように見える) ことがあります。
それが仕様通りの動作なのかどうかはよくわかりません。
[152] グリフID 0 のとき未実装とみなして他のフォントにフォールバックしているのかもしれません。
[153]
Chrome で format 13 のフォントで全符号位置をグリフID
0 にしても、エラーにはなりませんが、そのグリフは使われずに他のフォントで表示されます。
フォント内のグリフが 0
1個だけではだめなのかと他のグリフを入れてみても変わりません。
グリフID 0 以外に設定すればちゃんと使われるので、
グリフID 0 を使ったことに起因するのは間違いありません。
[107]
cmap
は文字のレンダリングのためにフォントのグリフを取得する過程の1つとして参照されます。
[108]
cmap の写像を引く入力となる文字コードは、
必ずしも情報交換に使う
Unicode文字列を構成するUnicode符号位置の列そのものではないことに注意が必要です。
[109]
bidi に関係して鏡像化のための符号位置の書き換えが事前に発生していることがあります。
[110]
その他 shaping に属する前処理で符号位置の変更が事前に発生していることがあります。
[3]
TrueType の cmap と
CIDFont の CMap
は、
似たような用途ですが、
技術的にはまったくの別物です。
正式な表記は大文字と小文字で区別できますが、
俗に
cmap, CMAP, CMap
と混用されているので、文脈で注意して区別するしかありません。
[35] OpenType glyph processing (part 2) - Typography | Microsoft Docs, alib-ms, https://docs.microsoft.com/ja-jp/typography/develop/processing-part2#cmap-table
[36] >>35 公式ドキュメントですが、ここでは CMAP になっています。
cmap にしないと正常動作しないと思いますが、どうなんでしょう。
[37] Character-level mirroring では cmap で得られる値が 0 か検査します。
[161] 開発者ツールで見られるエラーは Chrome より Firefox の方が親切です。
[162] gecko-dev/gfx/ots/src/cmap.cc at master · mozilla/gecko-dev · GitHub, https://github.com/mozilla/gecko-dev/blob/master/gfx/ots/src/cmap.cc
[163] そしてエラーのより詳しい意味は >>162 のソースを見るとわかります。
[166] How to decode namerecord? · Issue #956 · MicrosoftDocs/typography-issues · GitHub, https://github.com/MicrosoftDocs/typography-issues/issues/956
[167] Fonts without Microsoft-platform cmaps use Mac NameRecord · Issue #679 · libass/libass · GitHub, https://github.com/libass/libass/issues/679
cmapを引いています。以前 (平成時代初期頃まで) は非Unicode の実装もありました。 現在では非Unicodeのcmap部分表を含まないフォントも多いです。 MacRoman のcmap部分表を含むフォントも多いですが、 互換性のためというよりは、互換性が必要だった時代の名残りの慣習と思われます。 現在使われているフォントの MacRomancmapは使い物にならないおかしなデータのことも多いです。