/
928.txt
233 lines (179 loc) · 7.22 KB
/
928.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
* 仕様書
[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]
* [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[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]] にしないと正常動作しないと思いますが、どうなんでしょう。