667.txt

[6] 
[DFN[[[文字]]の[[レンダリング]]]]は、
単純に[[文字]]を並べていくだけに思えますが、
実は考えなければならないことがたくさんあって、
非常に複雑で難解な処理なのです。

* 文字とレンダリング

[16] [[文字]]の連続の[[レンダリング]]が個別の[[文字]] ([[グリフ]]) 
の[[レンダリング]]の連続とは異なることがあります。

[FIG(short list)[ [10] [[文字]]と表現の記述
- [[文字]]
- [[文字コード]]
- [[結合文字]]
- [[合成文字]]
- [CODE(charname)@en[GCC]]
- [[重ね打ち式文字合成]]
- [[書記素クラスター]]
- [CODE(charname)@en[ZWJ]]
- [CODE(charname)@en[ZWNJ]]
- [[制御文字]]
- [[空白文字]]
- [[スペース]]
- [[˥˩]], [[˩˥]]
- [[国旗]]
- [[肌の色]]
- [[ハングル字母]]の列による[[ハングル音節]]の表現
- [CODE[transcoding hint: group next [VAR[n]] characters]]
- [[IDS]]
]FIG]

[FIG(list middle)[ [8] [[文字のレンダリング]]
- [[連なり]]
- [[subtending mark]]
- [[語頭形]]、[[語末形]]など
-- [[アラビア文字]]、[[σ]]などの[[文字]]
-- [CODE[1st]] の[[上付き]] [CODE[st]] などの[[フォント]]ごとの文脈依存[[グリフ]]
- [[cursive]] な場合
-- [[アラビア文字]]など、それが一般的な[[書字体系]]
-- [[筆記体]]の[[ラテン文字]]や[[草書体]]の[[漢字]]・[[仮名]]など、そうも表現される[[書字体系]]
-- [CODE(charname)@en[ZWJ]]
- [[合字]]
- [[カーニング]]
- [[shaping]]
- [[グリフの選択]]
- [[鏡文字]]
- [[回転][回転 (書字方向)]]
- [[上下反転]]
- [CODE(charname)@en[SGR]]
- [[フォント]]
- [[機能][フォント機能]]
- [[斜体]]
- [[イタリック]]
]FIG]

[FIG(short list)[ [12] [[文字]]の周辺
- [[語境界]]
- [[改行]]
- [[ハイフン付け]]
- [[改段落]]
- [[改行記号]]
- [[言語情報]]
- [[書字方向]]
- [[bidi]]
- [[ルビ]]
- [[interlinear annotation]]
-
[[行内構造]]
-[[アキ]]
-[[字間]]
- [[行揃え]]
-[[語間]]
-[[行間]]
-[[改行]]
-[[改段落]]
-[[禁則処理]]
- [[カーソル]]
- [[hit testing]]
- [[置換要素]]
]FIG]

* フォント依存

[1] 
[FIG(short list)[
- [CODE(char)[U+005C]]
- [CODE[~]]
- [[フォント機能]]
- [[包摂規準]]
- [[ビルマ文字]]
- [[PUA]]
- [[EUDC]]
- [[DRCS]]
- [[機種依存文字]]
- [[外字]]
]FIG]

* OpenType の処理モデル


[32] 
[[Windows]]
は[[サロゲートペア]], [[bidi]], 
[[用字系]]依存の [[shaping]] (文字前処理を含む。)
を 
[[Uniscribe]]
で実装し、
[[OpenType Layout]]
による[[グリフ]]の置換と位置決定を
[[OTLS]]
で実装する、
という2段階構造になっているようです。


[30] 
[[Uniscribe]]
は[[アラビア文字]],
[[ヘブライ文字]],
[[タイ文字]]については、
古い [[OS]]
が対応していた
[[OpenType Layout]]
以前の[[フォント]]にも対応しています。
[SRC[>>31]]

[34] 
[[鏡像化]]は [CODE[cmap]] を参照する時点でも処理が必要です。
[SEE[ [[書字方向依存グリフ]] ]]

[33] 
[CODE[vert]] を使った[[レンダリング]]や[[縦書き]]対応していない[[フォント]]の[[レンダリング]]には、
取得した[[グリフ]]データの[[回転][回転 (書字方向)]]が必要となります。
[SEE[ [[縦書きグリフ]] ]]


[REFS[
-
[31] [CITE@ja-jp[OpenType glyph processing (part 2) - Typography | [[Microsoft]] Docs]], [[alib-ms]], [TIME[2022-08-27T13:16:47.000Z]] <https://docs.microsoft.com/ja-jp/typography/develop/processing-part2#uniscribe-in-detail>
]REFS]


** OpenType Layout の処理モデル

[14] 
[[OpenType Layout]] [[フォント]]を使って[[文字]]を表示する[RUBYB[文章処理クライアント][text-processing client]]は、
次のようにして[[文字列]]から[[グリフ]]列を得るとされています。
[SRC[>>13]]

[FIG(steps)[

= 
[15] 
[[フォント]]の [CODE[cmap]] [[表][OpenType表]]に基づき、
[[文字符号]]列を[[[RUBYB[グリフ索引][glyph index]]][グリフID]]列に変換します。
=
[17] 
[[フォント]]の [CODE[GSUB]] [[表][OpenType表]]に基づき、
[[グリフ]]列を編集します。
=
[18] 
[[フォント]]の [CODE[GPOS]] [[表][OpenType表]]と
[CODE[BASE]] [[表][OpenType表]]に基づき、
[[グリフ]]の[RUBYB[位置][position]]を決定します。
= [19] 
[RUBYB[[[設計座標]]][design coordinates]] (高解像度で装置非依存)
で装置非依存[RUBYB[[[改行]]][line break]]を決定します。
= [20] 
[[利用者]]の指定がある場合、
[[フォント]]の [CODE[JSTF]] [[表][OpenType表]]に基づき、
[RUBYB[[[行揃え]]][justifies the lines]]をします。
= [21] 
[[グリフ]]の[[行]]を[[ラスター化]]し、
[RUBYB[[[装置座標]]][device coordinates]] (出力装置の[[解像度]]に対応するもの)
に[[グリフ]]群を[[レンダリング]]します。

]FIG]

[22] 
[[OpenType]] [[仕様書]]ではこのうち最後の出力だけを [[OS]]
の処理とし、他を文章処理クライアントの処理としています。
[SRC[>>13]]
[[装置]]依存の処理かどうかで区分しているのでしょうか。
[[Windows]] の場合他の処理も [[OTLS]] を使って実装でき、
広い意味では全体が [[OS]] の範疇であります。
逆に出力が[[ハードウェア]]でなく[[画像ファイル]]等なら全体が[[応用]]レベルで実装されていることもありそうです。



[REFS[
- [13] [CITE@ja-jp[Advanced typographic tables - OpenType Layout (OpenType 1.9) - Typography | [[Microsoft]] Docs]], [[PeterCon]], [TIME[2022-08-28T02:47:24.000Z]] <https://docs.microsoft.com/ja-jp/typography/opentype/spec/ttochap1#text-processing-with-opentype-layout-fonts>
]REFS]

* レンダリング処理と文字性の維持

[23] 
[[文字列]]を[[グリフ]]列に変換し[[レンダリング]]する一連の処理により、
異なる[[文字]]が同じ[[グリフ]]で表現されたり、
複数の[[文字]]が[[合字]][[グリフ]]に置き換えられたり、
[[表示順]]が[[論理順]]の[[文字列]]の位置関係から入れ替わっていたりしますが、
多くの場合に元の[[文字]]との対応関係を保持し続ける必要があります。

[EG[
[24] 例えば[[文字列の選択]]からの[[コピー]]を実現するためには、
選択した[[グリフ]]列から元の[[文字列]]が復元できる必要があります。
]EG]

;; [25] 
異なる[[文字列]]が同じ[[グリフ]]になったり、
[[文字コード]]があっても表示には直接反映されなかったりもするので、
[[グリフ]]の列だけを使って[[文字列]]を生成するのは困難で、
入力の[[文字]]と出力の[[グリフ]]の対応関係を保持するのが一般的みたいです。


;; [29] 
[[PDF]] が作り方により、
または表示ソフトウェアの品質により、
[[コピペ]]でおかしな[[文字列]]が生成されることがある、
というのはよく知られた問題です。


[27] 
[[bidi]] や [[shaping]] の処理では[[文字]]の順序が入れ替わって表示の順序が作られます。
関係性は相当複雑になるものの、元の[[文字]]との対応付けはできます。

[26] 
[[OpenType Layout]] では文章処理クライアントが[[文字]]と[[グリフ]]の関係を追跡し続けることになっています。
[SRC[>>13]]
[[合字]][[グリフ]]に置き換えられて複数[[文字]]が1[[グリフ]]にまとめられたりすることはあるものの、
対応付けを維持したままの [CODE[GSUB]] による置換は容易に実現できます。


[28] 
[[OpenType]] [[フォント]]は[[合字]]における[[キャレット]]位置の情報を持つことが出来ます。
複数の[[文字]]が1つの[[グリフ]]にまとめられていても、
[[文字]]単位で[[選択範囲][文字列の選択]]を指定することができます。
[SEE[ [[キャレット]] ]]
ただしそのような情報が欠けていることもありますし、
[[グリフ]]が図形的に[[文字]]単位に分割できない場合もあります。
そのときは不自然な挙動になってしまいます。



* セキュリティー

[4] [[文字のセキュリティー]]参照。

[3] [CITE@ja[あるUNICODE文字がAppleデバイス上でアプリを破壊する――iOS、Mac、Watchの主要ソフトすべてに影響 | TechCrunch Japan]]
([[Taylor Hatmaker]]著, [TIME[2018-02-19 16:13:56 +09:00]])
<http://jp.techcrunch.com/2018/02/16/2018-02-15-iphone-text-bomb-ios-mac-crash-apple/>


* 関連

[9] [[レタリング]]とは違います。

* メモ

[2] [CITE@en[unicode-org/text-rendering-tests: Test suite for text rendering]]
([TIME[2017-05-16 13:12:37 +09:00]])
<https://github.com/unicode-org/text-rendering-tests>


[5] [CITE@ja[#PS4 特定の文字列のメッセージを受け取るとクラッシュする事案が多数発生しているらしい…対処法はあるようなのでやってみて - Togetter]]
([TIME[2018-10-15 21:56:42 +09:00]])
<https://togetter.com/li/1276875>

[7] [CITE@ja[AppleのOSをクラッシュさせる文字列がまた見つかる | スラド IT]]
([TIME[2020-04-26 11:17:35 +09:00]])
<https://it.srad.jp/story/20/04/25/2016238/>

[11] [CITE@en[Text Rendering Hates You]], [TIME[2021-07-07T04:15:13.000Z]], [TIME[2021-11-15T08:57:15.274Z]] <https://gankra.github.io/blah/text-hates-you/>