連なり

連なり

[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.

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

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

[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 参照。

[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 が適用されないことがあるようです。

[14] >>13 IDSGSUB ccmp漢字としてレンダリングするフォントがあります (実例は IDS 参照)。しかし IDSCommon のため、 後続の 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 でこれを実現するのでしょうか。