928.txt

* 仕様書

[REFS[
-
[1] [CITE@en-us[cmap - Character To Glyph Index Mapping Table ([[OpenType]] 1.9) - Typography | Microsoft Docs]]
([[PeterCon]], [TIME[2022-08-16T01:57:58.000Z]])
<https://docs.microsoft.com/en-us/typography/opentype/spec/cmap>
-
[2] [CITE@en[Character to Glyph Mapping Table - [[TrueType]] Reference Manual - Apple Developer]]
([[Apple Inc.]], [TIME[2022-07-12T17:06:26.000Z]], [TIME[2022-08-16T01:58:07.176Z]])
<https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6cmap.html>
]REFS]

* 概要

[39] 
[[OpenType]] における[[文字コード]]には2つの側面があります。

- [40] 1つは、[[フォント]]に関係する[[文字列]]データの記述に使われるものです。
例えば [CODE[name][name (OpenType)]] [[表][OpenType表]]の[[フォント名]]が関係します。
- [41] 1つは、[[フォント]]に格納された[[グリフ]]データの参照 (利用)
方法としての[[文字]]の記述に使われるものです。
具体的には [CODE[cmap]] [[表][OpenType表]]が[[文字コード]]と[[グリフID]]の対照表となっています。


[38] [[UTF-16BE]] が使われることがあります。

* [CODE[platformID]], [CODE[encodingID]]

[24] 
互換性のためか 
[CODE[platformID]] = 0 (Macintosh),
[CODE[encodingID]] = 0 ([[MacRoman]])
で、
[N[0x100]], [N[0x101]]
だけの 
[CODE[cmap]]
部分表が含まれる[[フォント]]がままあります。

[32] 
[CITE[[[Nishiki-teki]]]]
は
[CODE[platformID]] = 0 ([[Unicode]]),
[CODE[encodingID]] = 10
という 
[CODE[cmap]] subtable
を持っています。
でも
[CODE[platformID]] 0 [CODE[encodingID]] 10
は
[[Microsoft]] の仕様書にも [[Apple]] の仕様書にも載っていません。

[33] 
中身は [[Unicode]] のようです。
[CODE[platformID]] = 3 ([[Windows]])
だと
[CODE[encodingID]] = 10 が [[Unicode]] 
なので、
それの誤りなのでしょうか。


[34] 
[CITE[Makoto Comic]]
にも
[CODE[platformID]] = 0 ([[Unicode]]),
[CODE[encodingID]] = 10
があります。

* [CODE[cmap]] 表

** [CODE[format]]

[4] 
[CODE[format]] = 0 : 
[ [N[0x00]], [N[0xFF]] ]
の[[ビット組合せ]]に対応する[[グリフID]]が順番に格納されています。
[SRC[>>1, >>2]]

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

-*-*-

[6] 
[CODE[format]] = 2 : 
1バイトまたは2バイトの[[多バイト符号]]に対応する[[グリフID]]が順番に格納されています。
[SRC[>>1, >>2]]

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

-*-*-

-
[8] 
[CODE[format]] = 4 :
16ビット符号用。
[SRC[>>1, >>2]]
-
[9] 
[CODE[format]] = 6 :
16ビット符号用。
[SRC[>>1, >>2]]
-
[17] 
[CODE[format]] = 12 :
32ビット符号用。
[SRC[>>1, >>2]]
-
[14] 
[CODE[format]] = 10 :
32ビット符号用。
[SRC[>>1, >>2]]

[11] 
4, 6 は [[Unicode BMP]] 用,
12, 10 は [[Unicode]] 全体に使われています。

[10] 
4, 12 は連続した[[符号位置]]に[[グリフID]]が割り当てられた密なもの、
6, 10 は疎なものに適した[[データ構造]]になっています。

[28] 
6
に対応していない実装もあります。

[16] 
10 はあまり使われておらず、 
[[Windows]] は対応していません。
[SRC[>>1, >2]]

[20] 
当初 4 が使われ後に 12 が使われるようになった経緯のため、
古い実装は 12 に対応していません。
多くの[[フォント]]は 4 と 12 の両方の [CODE[cmap]] 部分表を含めているようです。
古い実装は 4 の方を見るので、 [[BMP]] の[[文字]]だけは使えます。


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

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


-*-*-

[12] 
[CODE[format]] = 8 :
16ビットまたは32ビットの符号用。
[SRC[>>1, >>2]]

[13] 
[CODE[U+10FFFF]] まで使う [[Unicode]] を想定したものでしたが、
あまり使われていません。
対応していない実装もあります。

-*-*-

[21] 
[CODE[format]] = 14 :
[[UVS]]
用。
[SRC[>>1, >>2]]

[22] 
他の [CODE[format]] と違って入力が1つの[[文字]] ([[符号位置]])
ではなく2つの[[文字]] ([[符号位置]])。
[[Unicode]] の[[異体列]]の専用の仕組みになっています。
(2, 8 の入力は多バイトであっても1文字。 4, 6, 10, 12, 13 も同じ。
4, 6, 8, 10, 12, 13 は [[Unicode]] 想定であっても、専用ではない。)

[23] 
同じく複数の [[Unicode文字]]で1つのものを表現する[[結合列]]や[[合字]]は
[CODE[GSUB]] 
で[[グリフ]]レベルの操作を使っていますが、 [[VS]] 
だけなぜか専用の仕組みが [CODE[cmap]] に[[文字]]レベルで追加されました。


[25] 
[[異体列]]に対し「[[異体選択子]]なしと同じ」を指定するものと、
[[グリフID]]を指定するものの2種類の指定方法があります。
前者が得られた場合には他の
[CODE[cmap]] 部分表を使って再探索することになります。

[26] 
実際の[[フォント]]は前者の方法を使わずすべて後者の方法によるものと、
前者の方法を適宜使うものがあります。
前者を使った方がデータ量はいくらか少なくなるのでしょうが、
[[グリフ]]取得が少し遅くなります。
といっても現在の[[計算機]]の性能からみればどちらの差分もほとんど誤差みたいなものでしょう。

;; [27] その誤差みたいな節約のために前者の方法を導入してるのが無駄に思えるのですが、
[[OpenType]] の複雑性の中ではそれも誤差みたいな複雑性かもしれませんw

[29] 
[[VS]] は[[日本語]]や[[蒙古文字]]の表示には必須の機能ですが、
[[欧米]]では必要とされないことや、
比較的歴史の浅い機能であることから、
14 に対応していない実装もあります。

[30] 
[[日本語]]用[[フォント]]で多くの文字を含んだものにはよく使われています。

;; [31] 14 を使わなくても [CODE[GSUB]] でも対応できますが
(そちらの方が対応してる実装は多いかも知れませんが)、
そのような[[フォント]]があるのかは不明。


-*-*-


[3] 
[CITE@en[[[GitHub]] - nixeneko/nxTokiACF]], [TIME[2022-08-16T01:59:19.000Z]] <https://github.com/nixeneko/nxTokiACF>

[CODE[format]] = 0, 4

[19] [CITE@en[Release Version 14.000 Release · unicode-org/last-resort-font · GitHub]], [TIME[2022-08-16T02:36:51.000Z]] <https://github.com/unicode-org/last-resort-font/releases/tag/14.000>

[CODE[LastResort-Regular.ttf]]
は
7.89MB 
の[[フォント]]。
[CODE[format]] = 12 と [CODE[format]] = 4 (空)。

[CODE[LastResortHE-Regular.ttf]]
は
506KB
の[[フォント]]。
[CODE[format]] = 13 と [CODE[format]] = 4 (空)。

(ファイルサイズの違いは [CODE[format]] の違いに起因するものではない。)


* メモ

[35] [CITE@ja-jp[OpenType glyph processing (part 2) - Typography | Microsoft Docs]], [[alib-ms]], [TIME[2022-08-27T08:46:01.000Z]] <https://docs.microsoft.com/ja-jp/typography/develop/processing-part2#cmap-table>


[36] >>35 公式ドキュメントですが、ここでは [CODE[CMAP]] になっています。
[CODE[cmap]] にしないと正常動作しないと思いますが、どうなんでしょう。




[37] [[Character-level mirroring]] では [CODE[cmap]] で得られる値が [N[0]] か検査します。