IVSの実装は難しい (LibreOfficeを中心に）

ものかの @monokano

【改訂】 Unicodeの合成除外とHFS+の正規化 第2版 tama-san.com/?p=3336 誤った情報を修正し、あわせて全面的に見直しました。でもやっぱり分かりにくい…

ものかの @monokano

@akane_neko @KAN0U Adobeのアプリはその基礎技術に完全対応できているわけではなくて、とくに結合文字列の実装にずっと問題を抱えていますよね（だからペースト時にとにかくNFCを適用しちゃう）

あかね @akane_neko

@KAN0U @monokano なるほど。お二人の話を総合すると「もともとそういった処理が苦手な上に」「IVSはその状態があってるのかどうか判断が難しい」ので実装がなかなかうまくいってない。ということですか…。

MORIOKA Tomohiko @CHISE_ja

（IVS 実装する場合、２文字として扱うより、１つのグリフオブジェクトとして扱った方が良い気がするけど、後付けだと難しいんだろうなぁ）

狩野宏樹 @KAN0U

@monokano @akane_neko Wordとかでは一旦結合したクラスターは一塊りになって途中にカーソルを入れるたぐいの操作ができなくなるんですが、Adobeアプリの場合、できてしまう場合があるんですね。IVSに 限らず、アイヌ語の仮名でもルビを振ると字間が空いてしまう。

狩野宏樹 @KAN0U

@monokano @akane_neko 証拠写真。CS6／Win8です。テキストはU+30C8,U+309Aの繰り返しと改行。2行目は「ト」だけ選択してルビをつけた例。3行目は半濁点まで含めた2文字にルビをつけていますが同症状。 pic.twitter.com/HM01TQORtw

拡大

あかね @akane_neko

@KAN0U @monokano 今のところIVSの実装が一番うまくできてるのはWordですか？（アイヌ語の例、とかがサクッとでてくるのが、さすが狩野さんだわぁ…）

ものかの @monokano

@KAN0U @akane_neko ぉぉぉこれは知らなかった！ UCSの文字合成は実現困難すぎる理想だとひしひし感じますねー

狩野宏樹 @KAN0U

@akane_neko @monokano Wordもよく知りませんし比較対象のアプリもなおさら知らないので分かりません。（「ト゚」についてはJISX 0213がUnicodeに追加申請して認めてもらえなかった文字を選んでいるだけで、日本語の鼻濁音「か゚」が例でもよかったんですが

小熊善之 @0guma

@akane_neko @KAN0U @monokano Wordも2010 on Windows 7にIVSぶちこむと……。 pic.twitter.com/idABPNIAdj

拡大

小熊善之 @0guma

@akane_neko @KAN0U @monokano Wordpadだと……。 pic.twitter.com/uItbDldMZy

拡大

小熊善之 @0guma

@akane_neko @KAN0U @monokano なぜかNotepadだと、こう。 pic.twitter.com/gnR6Td22GC

拡大

ıɥɔıɐʇ ɐʇɐqɐʍɐʞ @kawabata

Unicodeにおける「１文字」の概念は規格本文の２.11節と、UAX#29 の "extended_grapheme_cluster" を参照。一応、正規表現も定義されている。

ıɥɔıɐʇ ɐʇɐqɐʍɐʞ @kawabata

ずいぶん昔だけど、Emacsでカーソルの移動・挿入・削除の影響範囲としての「１文字」を決める際には、合成文字とかは無関係なコンソール上でも動くこと、IVSやインド系文字のOpenType等の有無を考慮して、中間吸収層として auto-composition-mode を導入した。

ıɥɔıɐʇ ɐʇɐqɐʍɐʞ @kawabata

間違えた。Emacsの auto-composition-mode の導入はOpenTypeの出現より前だった。その後、OpenType対応がこれのお陰でスムーズになったのだった。中核は font-shape-gstring や、composition_reseat_it 関数。

Naruhiko Ogasawara @naru0ga

昨日のIVSの話題で気になったんだけどICU Regular ExpressionsってIVS対応してるのかな（調べろよ自分

四九六々(縦書き用) @496_

ICUの正規表現駄目か。まあ、高速検索と同じチェックが必要ということか。別に問題ないな。

ものかの @monokano

Illustrator CC 2014のIVS対応、確認漏れがあったので今確認。［編集>検索と置換...］で基底文字を検索すると「基底文字だけ選択される」ことが判明。その状態で削除するとVSが取り残され、直前に文字があればそこにVSが付く。

UTF-8はBOMなしでって言ったよね？ @moji_memo

やっほー！ “@monokano: Illustrator CC 2014のIVS対応、確認漏れがあったので今確認。［編集>検索と置換...］で基底文字を検索すると「基底文字だけ選択される」ことが判明。その状態で削除するとVSが取り残され、直前に文字があればそこにVSが付く。”

ものかの @monokano

@moji_memo @JunTajima こういうところにも対応させるのは相当難しいんでしょうねえ。それに本当に完全対応したとしても、やっぱりこわい。

Jun Tajima @JunTajima

@monokano @moji_memo IVSの理屈をちゃんと知ってる人ばかりが使うわけじゃないですからねえ。

UTF-8はBOMなしでって言ったよね？ @moji_memo

@JunTajima @monokano いやいや、IVSの理屈をちゃんと知っている人でも死んでしまうでしょうこれは。

ものかの @monokano

@moji_memo @JunTajima おそらく現時点で最もIVS対応の完成度が高いNSTextViewの場合、「葛 葛󠄀 葛󠄁」（845B 845B+E0100 845B+E0101）を対象に「葛」（845B）を検索すると、検出されるのは1文字目の845Bだけです。（続

ものかの @monokano

@moji_memo @JunTajima IVS対応としてはこれが理想であるものの、一方で「他の同じグリフで表示されている箇所が検出されない」という問題が起こってしまいます。IVS完全対応は問題がなくなることを意味しないんですよね。