[1] OpenType glyph processing (part 1) - Typography | Microsoft Docs, alib-ms, 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.
[3] OpenType development (LEGACY INFORMATION) - Typography | Microsoft Docs, nihar, https://docs.microsoft.com/ja-jp/typography/develop/otdevinfo#unicode-script-processor
[4] Uniscribe の処理モデルでは、 Uniscribe shaping engine によって文字列を
に分割します。>>3
[5] そして Uniscribe のクライアント (ライブラリーを呼び出す応用) は自身の持つ formatting attribute と、 Uniscribe から取得した項目の境界に基づき、 連なりを構築します。 >>2
[6] この説明では Uniscribe 側と応用側の連なりが必ずしも同じではないとなっていて、 Uniscribe が連なりと認識していても応用がそう見なすとは限らないということになりますね。
[9] クラスターについては shaping engine 参照。
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 になるケースに最適化して他はパフォーマンスが落ちても仕方ないよね、 みたいな認識で設計したらどうするんか。
[12]
Unicode
では符号点にUnicode用字系特性値が割り当てられていて、
連なりの検出に利用できます。
[159]
shaping において連なりに分割してから処理されるために、
用字系が違うと
GSUB
が適用されないことがあるようです。
[14]
>>13 IDS を GSUB ccmp で漢字としてレンダリングするフォントがあります
(実例は IDS 参照)。しかし
IDS が Common のため、
後続の Hani
と別用字系とみなされてうまくいかないことがあると言っています。
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 のようなマーク付け言語やデータモデルの構造やスタイル言語の処理モデルと連なりの決め方の相互作用にも注意が必要です。