返信

> 情報ありがとうございます。 > > 若干、脳が溶けてしまいそうなお話なので頭の整理のため引用を多用させていただきますがご了承ください。 > > > 互換性分解 <compat> は 0E4D 0E32 です。 > > U+0E4D は Mn で結合文字です。 > > ユニコードの資料をみて <compat> という項目は気になっていたものの、何のことか良くわからずスルーしていましたが、なるほどそういうことだったのですね！ > > タイ語で実験してみたところ確かに… > > で同じ文字が出来上がりました。 > > > 結合文字と違ってもともとが２文字なので、そのうちの前の文字 > > が文字幅ゼロであっても、次の文字には文字幅があります。 > > 互換性分解のほうですと U+0E4D は文字幅ゼロですが、U+0E32 は文字幅があるということですね。 > > > でも同時に The Grapheme Cluster Break は SpacingMark であり、 > > 結合文字と同様に、直前の文字とは分離できないのです。 > > ふむふむ、Grapheme Cluster Break、ググってきました。基本的に分離できない文字なのですね。 > > 個人的なメモで恐縮ですが、今後も使うことがあるかもしれないのでメモとして GraphemeBreakProperty.txt へのリンクを貼っておきます。 > http://www.unicode.org/Public/UCD/latest/ucd/auxiliary/GraphemeBreakProperty.txt > > > 互換性分解 <compat> の例には ゛ U+309B ゜ U+309C があって、空白と U+3099 や空白と U+309A を「結合したのと同じ」通常文字になります。 > > 参考になります。 > > 試しに… > > ↑ を入力してみると Mery だと「が」のほうは表示がおかしくなってしまいました。(DirectWrite 有効時) > > > 2 文字だけ Lo (Letter other) があります。 > > U+0E33 と U+0EB3 です。 > > これは重要！U+0EB3、ラオス文字？も同様の対応が必要になりそうですね。 > > > 文字幅がゼロになることはないので、結合文字の処理と全く同じ > > にはならないはずですが、「２文字の前の部分が結合文字」と > > いうことが特殊なのです。 > > > > 前の文字によっては結合しない、という文字ではありません。 > > 検証のため Mery のプログラムで単純に U+0E33 を結合文字として識別するようにしてみたところ GDI のほうはそれだけで行けそうです。 > > …が、DirectWrite のほうは上記の「ぱ」と「が」の例がダメだったのと同じで問題がありまして、結合文字のロジックを根本的に見直す必要がありそうです。 > > > 参考に… > > https://github.com/orling/grapheme-splitter/issues/9 > > 情報ありがとうございます。まさか U+0E33 がこんなに大変な文字だったとは…。 > > …ユニコードにきちんと対応するのは無理かもしれません。(弱音) > > この問題に対応するためには大幅な変更が必要となり、それに伴い従来より品質が低下してしまうバグが発生する可能性があります。 > > そのため、修正版としては公式ブログではなくこちらのフォーラムのほうに投稿させていただくかもしれません。 > > その場合は、私はタイ語に詳しくないもので、タイ語向けの修正を必要とされているかたやユニコードに詳しい方、Mery に興味のある方は検証にご協力いただけると大変助かりますので、よろしくお願いいたします。

マークダウンを有効にする