[1] OpenType glyph processing (part 1) - Typography | Microsoft Docs, alib-ms, 2022-08-27T04:06:55.000Z https://docs.microsoft.com/ja-jp/typography/develop/processing-part1

A run is normally a maximum of one line in length and consists of a text string formatted in a single font at a particular size, in a single direction, in a particular script and a particular language system.

[2] OTLS の処理モデルでは

• フォント変更
• 用字系変更
• 言語系変更
• 書字方向変更
• 行末

... が連なり境界になります。 >>1

[3] OpenType development (LEGACY INFORMATION) - Typography | Microsoft Docs, nihar, 2022-08-27T07:16:20.000Z https://docs.microsoft.com/ja-jp/typography/develop/otdevinfo#unicode-script-processor

[4] Uniscribe の処理モデルでは、 Uniscribe shaping engine によって文字列を

• 項目群items - 用字系と書字方向属性が同じ文字列
• 連なり群runs - 項目群のうち continuous formatting attribute を持つ部分
• クラスター群clusters - 用字系定義の分割できないindivisible文字を群化groupingしたもの

に分割します。>>3

[5] そして Uniscribe のクライアント (ライブラリーを呼び出す応用) は自身の持つ formatting attribute と、 Uniscribe から取得した項目の境界に基づき、 連なりを構築します。 >>2

[6] この説明では Uniscribe 側と応用側の連なりが必ずしも同じではないとなっていて、 Uniscribe が連なりと認識していても応用がそう見なすとは限らないということになりますね。

[9] クラスターについては shaping engine 参照。

[7] >>1 には

Obviously, in many documents, the majority of consecutive runs of text will simply equate to individual lines. In multilingual documents, however, a client may need to be able to identify and tag a number of runs within a single line of text.

と書いてあって、著者は専門家だろうに用字系の混在がありふれてる日本語の例を考えていないことがわかります。混在しないのが「many documents」でそれ以外が 「multilingual documents」なのですから。 この直後で bidi の実例を示してますけど、アラビア文字と数字を混在させるだけで runs になってしまう、というアラビア語のごく普通の文書の例も漏れてる。

詳しくない一般欧米人の認識ならともかく、専門家が詳しくない人に解説するチュートリアルにこんなこと書いてるのはよくない。

[8] これを読んだ欧米人開発者が、ああそうなんだ多言語文書なんて滅多にないし、 a run = a line になるケースに最適化して他はパフォーマンスが落ちても仕方ないよね、 みたいな認識で設計したらどうするんか。

[10] フォント境界の絡みについては結合文字も参照。

[11] 文字列座標

[12] Unicode では符号点にUnicode用字系特性値が割り当てられていて、 連なりの検出に利用できます。 Unicode用字系特性値

[159] shaping において連なりに分割してから処理されるために、 用字系が違うと GSUB が適用されないことがあるようです。

• [13] 23073-irgn2581-fdbk.pdf, 2023-03-23T16:06:03.000Z, 2023-07-13T08:24:27.947Z https://www.unicode.org/L2/L2023/23073-irgn2581-fdbk.pdf#page=2

[14] >>13 IDS を GSUB ccmp で漢字としてレンダリングするフォントがあります (実例は IDS 参照)。しかし IDS が Common のため、 後続の Hani と別用字系とみなされてうまくいかないことがあると言っています。

[15] >>13 は

the feature under the DFLT script in the font will NOT be applied to the sequences according to the specification. Of course you can rewrite a Shaping Engine to support the features cross the different script properties, but that actually violates the rule, and lack of standardization.

と書いてますけど、それがどの仕様書のどこに書いてある規則だとは教えてくれない...

[17] IDC は前置演算子で必ず後続の符号点とまとめられるというのは Unicode の仕様なのだから、それを無視して用字系だけを根拠に連なり境界位置を決める shaping の仕様(というものがどこかにあるとして)の方が間違っているような。

[19] Common で前置演算子的に機能するものって IDC 以外にもあるのだろうか?

[16] HTML / DOM + CSS のようなマーク付け言語やデータモデルの構造やスタイル言語の処理モデルと連なりの決め方の相互作用にも注意が必要です。

[18] Uniscribe モデル的には formtting attribute でこれを実現するのでしょうか。

[20] 連なりの前景色 SVG