/
67.txt
101 lines (79 loc) · 4.63 KB
/
67.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
* OpenType と shaping
[14]
[[OpenType Layout]] では [[shaping]] によって[[フォント]]から探索する[[文字]]や適用するべき[[機能][フォント機能]]を決定するという想定になっています。
[SRC[>>13]]
[15]
[[OpenType]] で扱うのは[RUBYB[低水準][low-level]]の[[機能][フォント機能]]だけで、
[[shaping]] の詳細は[[仕様書]]の[[適用範囲外]]とされています。
[SRC[>>13]]
[16]
[[OpenType]] [[フォント]]ファイルに格納されるのは [[shaping]] された結果から[[グリフ]]への対応関係なので、
外部から与えられた[[Unicode文字列]]から [[shaping]] された結果への変換方法
(つまり [[shaping]] の方法) が決められないことには[[フォント]]の[[相互運用性]]は保証されないと言わざるを得ません。
つまり [[OpenType]] 仕様は[[相互運用性]]を半ば放棄しているようです。
[17]
[[Windows]] は [[Uniscribe]] で [[shaping]] を実装しています。
[[Uniscribe]] は[[独占ソフトウェア]]ですが、その処理の概要は公式サイトに載っていますし、
おおむね [CITE[The Unicode Standard]] に従っているようなことが書かれています。
その情報と実在の[[フォント]]ファイル、それに [[Windows]]
その他の実装から挙動を推測するしかありません。
[REFS[
- [13]
[CITE@ja-jp[OpenType specification overview (OpenType 1.9) - Typography | [[Microsoft]] Docs]], [[PeterCon]], [TIME[2022-08-27T13:06:23.000Z]] <https://docs.microsoft.com/ja-jp/typography/opentype/spec/overview>
]REFS]
* Uniscribe の処理モデル
[2]
[[Uniscribe]] は[[用字系]]ごとに [DFN[shaping engine]]
を持っています。
[SRC[>>1, >>3]]
[6] また, 特別に対応していない[[用字系]]用の
[[OpenType Layout]] [[shaping engine]] も持っています。
[SRC[>>1]]
[4]
[[Uniscribe]] は入力の[[文字列]]を[[項目]]群, [[連なり]]群, [[クラスター]]群の3階層に分割します。
[SEE[ [[連なり]] ]]
[5]
[[クラスター]]は[[用字系]]によって決まる、[[文字]]群の基本的な要素です。
[SRC[>>3]]
[[Unicode]] でいう[[書記素クラスター]]に相当する単位と思われますが、
同じかどうかは不明。
[7]
[[Uniscribe]] は[RUBYB[文字の前処理][character preprocessing]]も行います。
入力 ([[Unicode]] の[[文字列]]) は[[論理順]]になっていますが、
前処理で[[グリフ]]処理に都合の良い順序に並べ替えます。
具体的には [[Unicode]] の規定によります。
[SRC[>>3]]
[EG[
[8]
例えば[[基底文字]]の左右に[[結合文字]]が表示されるような場合でも
[[Unicode]] では必ず[[基底文字]]が先になりますが、
ここで左、[[基底文字]]、右の順序に並べ替えたりすることがあります。
]EG]
[11]
[CODE[GSUB]] を駆使すれば文字前処理の並べ替えをしなくても[[フォント]]側で[[グリフ]]決定をすべて行うこともできるのでしょうが、
それでは[[フォント]]開発が大変になるようです。
文字前処理があるので[[フォント]]開発で複雑な条件をたくさん記述しなくてもよいのです
[SRC[>>3]]。
;; [12] そのかわり [[Uniscribe]] 相当の [[shaping]] をしていなかった古い実装で
[[shaping]] 前提の[[フォント]]を使っても正しく表示されないのです。
[9]
結果得られた[[Unicode文字]]の列が [[OTLS]] に渡されます。
適宜[[機能][フォント機能]]を適用します。
[SRC[>>3]]
[EG[
[10]
例えば[[アラビア文字]]の場合は[[単語]]の単位を検出して、
[[語頭形]]、[[語中形]]などを表す[[機能][フォント機能]]を各[[クラスター]]に適宜指定することになります。
]EG]
[REFS[
-
[1] [CITE@ja-jp[OpenType development (LEGACY INFORMATION) - Typography | Microsoft Docs]], [[nihar]], [TIME[2022-08-27T06:22:28.000Z]] <https://docs.microsoft.com/ja-jp/typography/develop/otdevinfo>
-
[3] [CITE@ja-jp[OpenType glyph processing (part 1) - Typography | [[Microsoft]] Docs]], [[alib-ms]], [TIME[2022-08-27T07:59:48.000Z]] <https://docs.microsoft.com/ja-jp/typography/develop/processing-part1#uniscribe>
]REFS]
* 歴史
[58] [[タグ文字]]による指定を
[[character shaping]]
に影響する指定に使える可能性があるとされていました。
* メモ
[18] [CITE[HarfBuzz Manual: HarfBuzz Manual]], [TIME[2022-07-31T13:57:21.000Z]], [TIME[2022-08-28T13:56:02.521Z]] <https://harfbuzz.github.io/>