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

文字とレンダリング

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

[10] 文字と表現の記述
[8] 文字のレンダリング
[12] 文字の周辺
[58] 文字のレンダリングの処理モデル

フォント依存文字

[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

[57] Windows の Chrome で試してみると、 基底文字に続く結合文字は正準再順序付けされているようで、 そうでない順序の GSUB lookup の規則を用意しておいても無視され、 正準化された状態の GSUB lookup の規則があればそれが適用されます。

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

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

[38] グリフ位置決定

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

[51] SVG による SVG 字形データがあれば、それへの置き換えを行います。 これはグリフIDの列が決定した後で、 advance width や advance height は変化しないはずとされています。 SVG 具体的にどのタイミングかまでは明らかではありませんが、 アンチエイリアス関係の処理よりは前でしょうか。 あるいは SVGグリフにはアンチエイリアス処理が適用できないとか、 通常グリフと同時処理はできないとか制約があったりするのでしょうか。

[56] 色フォント/絵文字グリフ選択と SVG の関係
  1. [53] variable font の処理
    • SVGグリフには適用されない。
  2. [54] hinting
    • SVGグリフには適用されない。
  3. [44] MERG の指定に従いグリフ列を併合します。
  4. [45] アンチエイリアシングの処理を適用します。

[52] SVGグリフへの置き換えやアニメーションによって bounding box が変化する可能性があります。 これが行配置に影響するときは、再配置が必要になります。 SVG

[55] SVGグリフはアニメーションすることがあります。 印刷時などのため、アニメーション有効、無効の2状態の入力が必要です。

OpenType Layout の処理モデル

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

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

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

  • [13] Advanced typographic tables - OpenType Layout (OpenType 1.9) - Typography | Microsoft Docs, PeterCon, 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 を使って配置するかを決定します。

動的なフォント変更

font-display, CSSアニメーション

セキュリティー

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

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

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

[7] AppleのOSをクラッシュさせる文字列がまた見つかる | スラド IT () https://it.srad.jp/story/20/04/25/2016238/

[49] Mac OS XとiOSで特定のアラビア語文字列を表示させるとクラッシュする問題が見つかる | スラド アップル, https://apple.srad.jp/story/13/09/03/0824238/

テスト

[2] unicode-org/text-rendering-tests: Test suite for text rendering () https://github.com/unicode-org/text-rendering-tests

関連

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

メモ

[11] Text Rendering Hates You, , https://gankra.github.io/blah/text-hates-you/

[43] ケケモコソカメニハさんはTwitterを使っています: 「Qtさんフォールバックフォントを選ぶときに隣接する文字を考慮するらしく、こういうことが起きます。 スクリーンショットの状況はUbuntu Monoが◆を持っていないため。左の◆はDejaVu Sans Mono、aはUbuntu Mono、「あ」と右の◆はNoto Sans Mono CJK JP。 https://t.co/AKD9HfhYiJ」 / Twitter, , https://twitter.com/ytomino/status/1590051393716768768

[46] クメール文字が書けない - Helpfeel社のScrapboxを一部公開, https://scrapbox.io/nota-private-sample/%E3%82%AF%E3%83%A1%E3%83%BC%E3%83%AB%E6%96%87%E5%AD%97%E3%81%8C%E6%9B%B8%E3%81%91%E3%81%AA%E3%81%84

[47] 文字 (の情報システム上での表現) の知識がない技術者が設計すると >>46 のようなことが起きる。 欧米の技術者がシステムを設計するとアジア人が使えないものができるのと同じ原理。

[48] 書記素クラスターにうまく分割できればいいみたいな話になってるけど、それで語頭形とかの表示ちゃんとできてるんだろうか?

[50] Unicode はサービス拒否攻撃のリスク有り (#2767675) | iOSベータ版に「肌の色を指定できる」絵文字が登場 | スラド, https://srad.jp/comment/2767675

[61] WebKit Features for Safari 26.2 | WebKit, https://webkit.org/blog/17640/webkit-features-for-safari-26-2/#text-shaping-across-inline-boxes