文字のレンダリング

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

文字とレンダリング

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

[10] 文字と表現の記述

文字
文字コード
結合文字
合成文字
GCC
重ね打ち式文字合成
書記素クラスター
ZWJ
ZWNJ
制御文字
空白文字
スペース
˥˩, ˩˥
国旗
肌の色
ハングル字母の列によるハングル音節の表現
transcoding hint: group next n characters
IDS

[8] 文字のレンダリング

連なり
subtending mark
語頭形、語末形など
- アラビア文字、σなどの文字
- 1st の上付き st などのフォントごとの文脈依存グリフ
cursive な場合
- アラビア文字など、それが一般的な書字体系
- 筆記体のラテン文字や草書体の漢字・仮名など、そうも表現される書字体系
- ZWJ
合字
カーニング
shaping
グリフの選択
- 言語情報によるグリフ選択
鏡文字
回転
上下反転
SGR
フォント
機能
斜体
イタリック
文字列座標
ラスター化
アンチエイリアシング

[12] 文字の周辺

フォント依存文字

[1] フォント依存文字

OpenType の処理モデル

[35] cmap を参照する時点では、文字列の転送・保管等に使う符号化方式 (いわゆる外部コード) ではなくフォント符号化を知っている必要があります。 Unicode の場合、 UTF-8 バイト列や UTF-16 サロゲートペア等ではなく、 Unicode符号点の列です。

[36] cmap は文字コード(列)からグリフIDへの写像です。ほとんどの場合は1つの文字 (符号点) が入力ですが、異体列は1つの異体列が入力となります。従って cmap を引くには、入力の文字列を (異体列とそれ以外の文字) の列に分解する必要があります。

[37] また、異体列から cmap を引いた出力は「基底文字と同じグリフ」という回答かもしれませんから、基底文字の符号点で cmap をもう一度引かなければなりません。 (普通は同じフォントの cmap で基底文字を引けば適切なグリフIDが返ってくるはずですが、データ構造的に保証はされていませんから、エラー処理が必要となります。)

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

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

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

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

[38] グリフ位置決定

[42] 機能については、 justification のために適当な行長を実現すべく、グリフの置き換えや位置調整を適用し直すことがあります。 JSTF

[44] MERG の指定に従いグリフ列を併合します。
[45] アンチエイリアシングの処理を適用します。

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

OpenType Layout の処理モデル

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

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

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

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

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

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

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

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

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

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

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

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

[40] OpenType GPOS lookupType 5 (Mark-to-Ligature Attachment Positioning, MarkLigPos) は合字グリフ上の anchor point をいくつか指定できます。マークグリフの配置に当たっては、そのいずれかの anchor point を選ばなければなりません。グリフ位置決定

[41] shaping engine による文字前処理や GSUB によるグリフの置き換えがあると、合字グリフとマークグリフの元になった基底文字と結合文字の関係 (など) はグリフ列から読み取れなくなってしまうかもしれません。しかし実装はその関係性を追跡しておかなければなりません (must) >>39。基底文字が合字グリフのどの部分に変化したかに応じて、結合文字に由来するマークグリフをどの anchor point を使って配置するかを決定します。