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の多バイト符号に適していました。 シフトJIS型符号

[7] 古い時代に用いられていたもので、今はあまり使われていません。 対応していない実装もあります。

format 4, 6, 12, 10, 13 (16ビット符号と32ビット符号)

• [8] format = 4 : 16ビット符号用。 >>1, >>2
• [9] format = 6 : 16ビット符号用。 >>1, >>2
• [17] format = 12 : 32ビット符号用。 >>1, >>2
• [14] format = 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部分表を同時に含めるべきではありませんshould。 format が 10 と 12 の Unicode部分表を同時に含めるべきではありませんshould。 これらの場合、 4 や 12 を使うべきですshould。 >>1

[76] Windows (platformID 3) で Unicode BMP のみ対応するフォントは、 encodingID 1 format 4 部分表を使わなければなりませんmust。 >>1

[77] Windows (platformID 3) で Unicode 非 BMP に対応するフォントは、 encodingID 10 format 12 部分表を使わなければなりませんmust。 >>1

[15] format = 13 は format = 12 の変種。 複数の連続した符号位置の範囲を1つのグリフIDに割り当てる。 >>1, >>2

[18] last-resort font (適当なグリフを用意できないときに代替グリフを提供するためのフォント) 用とされています。 その性質上ほとんど使われておらず、 対応していない実装もあります。

[73] format 13 部分表は、 platformID 0 encodingID 6 でのみ使うべきですshould。 >>1

• [147] The Typekit Blog | Introducing Adobe Blank, 2020-07-28T21:33:01.000Z, 2023-05-02T08:40:10.206Z https://blog.typekit.com/2013/03/28/introducing-adobe-blank/
• [148] 1,111,998 to 1 → Adobe Blank 2, 2020-11-19T06:22:25.000Z, 2023-05-02T08:41:20.984Z https://ccjktype.fonts.adobe.com/2015/04/adobe-blank-2.html

[149] format 4 のとき最後に startCode 0xFFFF, endCode 0xFFFF の segment が必須です。 >>1

[150] 妥当な写像でもそうでもなくても構わない >>1 とされます。 つまり U+FFFF 用のグリフ情報を含めることも、 含めないこともできますが、 どちらの場合も機械的にこの segment が必要となります。

[154] Chrome も Firefox も、指定された符号が仕様通り昇順になっていないとき、 構文解析エラーとしてフォントを無視します。 Chrome は開発者ツールに cmap のエラーである旨のみを表示しますが、 それくらいしか情報がありません。 Firefox は開発者ツールに符号の値を表示してくれます。 2023-08-27T02:54:40.600Z

[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らしいです。)

• [116] GitHub - trueroad/HaranoAjiFonts-generator: 原ノ味フォント生成プログラム / Harano Aji Fonts generator, 2022-09-29T15:48:27.000Z https://github.com/trueroad/HaranoAjiFonts-generator#cmap

原ノ味フォント 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ビット符号の両方にグリフを割り当てることは禁止may notされています。 >>1 そのような場合にどうするべきなのかは不明。

[13] U+10FFFF まで使う Unicode を想定したものでした。

[102] この format はあまり使われていません。 対応していない実装もあります。 非推奨discouragedとされています >>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 でのみ使うべきですshould。 >>1

[71] UVS は、cmap 表で format 14 部分表で指定するべきshouldです。 >>1

[117] 利用者:emk - GlyphWiki, 2022-10-14T10:19:13.000Z https://glyphwiki.org/wiki/User:emk#i0

Windows 7でIVSを認識させるには、以下の条件をすべて満たす必要があるようです。

[165] Chrome も Firefox も、 異体選択子が0個だとエラーとしてフォントを無視します。 従って1つも VS を含まないフォントでは format 14 部分表全体を省かなければなりません。 2023-11-04T03:01:28.900Z

[155] 仕様書上は特に制限されているようには読めませんが、 Chrome も Firefox も異体選択子以外の符号位置が書かれていると、 cmap の構文解析エラーとしてフォントを無視します。 2023-08-27T03:44:41.300Z

[156] Chrome でも Firefox でも漢字 + 通常 SVS, 漢字 + IVS はうまく動作しますが、 漢字 + 蒙古文字自由異体選択子は動作しません。

• [157] FVS1, FVS2, FVS3 があってもエラーにはなりませんが、グリフは使われず、 基底文字だけが表示されます。
• [158] FVS4 は cmap にあるだけで構文解析エラーになって、 フォントが無視されます。
  • [160] Firefox の開発者ツールによると、 UVS cmap の最大数が259 (FVS4 以外のVSの総数) になっているようです。 それを超えないとしても不正なVS扱いでエラーにはなります。
• [159] FVS4 があるときFirefoxでは基底文字だけが表示されますが、 Chromeでは基底文字とFVS4が同じ位置に重なった状態で、選択に対しては1文字扱いで、表示されます。

[79] Chrome は以前よりも制限が厳しくなったようです。 いつ変わったのか、どれが新しい制限かはわかりませんが、 次のような挙動を確認できます。 2026-01-25T12:10:52.00Z

• [84] Webフォントの検査のエラーメッセージ全般が以前より詳しく親切になっています。
• [80] あるIVSについて、その基底文字が cmap にあって IVS が cmap にない場合、以前の Chrome と現在の Firefox はその基底文字のグリフを使っていましたが、現在の Chrome では次のフォントを調べます。
  • [81] 従って format 13 ですべての符号位置にグリフを割り合てているとしても、 IVS があるとそのフォントは使われず次の候補のIVS のグリフが使われることがあります。
  • [82] URO + IVS ではこの挙動になりますが、 URO + SVS では少し挙動が違うようにも見え、更なる検証が望まれます。
• [83] numVarSelectorRecords の最大が 256 (SVS + IVS の最大値か) で、それを超えると開発者コンソールにエラーが表示され、 そのフォントは使われません。
• [85] numUnicodeValueRanges が 236 を超えるとエラーメッセージなしでそのフォントは無視されます。 numUnicodeValueRanges に上限があるのか、 それとも他の長さ超過などが主因なのかは不明です。
  • [86] 同じフォントが Firefox では正常動作するので、 OpenType フォントとして壊れてはいないはず。
  • [90] >>83 >>85 の制限があるため、 60416 個の符号位置しか default UVS を設定できません。
• [89] UnicodeRange の startUnicodeValue が 0 だとエラーメッセージが表示され、そのフォントは無視されます。 1 以上にする必要があります。 これは Chrome でも Firefox でも同じ挙動です。
• [87] cmap format 14 の length は、 仕様書では「Byte length of this subtable (including this header)」 と説明されていて、 subtable がどこまでを指すのか不明瞭ですが、 VariationSelector で Offset32 で参照されている表の末尾までが入っていなければなりません。
  • [88] 長すぎてそれより先に余分にバイト列を置いて含めていても、 長さ不一致でエラーになります。

[367] TTF / OTF の異体列用 cmap format 14 に対応していないソフトウェアが意外とあります。

[368] opentype.js では API がなく存在自体が無視されます。

[369] ttfdump や Typr は存在することだけ知らせて中身は dump してくれません。

[370] Font::TTF は普通に対応しています。

format の実利用例

[3] GitHub - nixeneko/nxTokiACF, 2022-08-16T01:59:19.000Z https://github.com/nixeneko/nxTokiACF

format = 0, 4

[19] Release Version 14.000 Release · unicode-org/last-resort-font · GitHub, 2022-08-16T02:36:51.000Z 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 の違いに起因するものではない。)