CJKフォント変化の無効化

下図は「フォント変化文字」（この言葉にカギカッコをつける理由は前回書きました）をU+30FB＝「ゴシック化」・U+2588＝「SimSun化」・U+2661＝「Gulim化」の順に並べ、最後に漢字を置いたコメントです。

上段のU+6BCDはSimSun化しているのに下段のU+6BCEはゴシックのままです。
U+2661がハートマークでなくなっているのは、SimSunに無いためMicrosoft Sans Serifを代替表示していると考えられます。つまりU+2588より後ろはSimSun化しており、上段の挙動が普通であるように思われます。

不思議なことに、U+2661を削除すると下段のU+6BCEもSimSun化します。

CJKコードページで2つの漢字の定義を見てみます。

Unicode	cp932	cp936	cp949	cp950
6BCD	95EA	C4B8	D9BD	A5C0
6BCE	9688	9AB0	-	-

U+6BCEはGulim属性を持っていません。どうもこれとU+2661の有無とが関係ありそうです。

U+6BCEはCP949に定義がないだけでなく、Gulimに収録もされていません。おそらく韓国では正字のU+6BCFの方を使うのではないでしょうか。
と言うことは、これはGulimのフォントリンクなのかと思って調べてみました。下図はGulimのフォントリンク先からMS UI Gothicを削除する前と後でコメントのフォントを比較しています。

上段のケースは削除後のU+6BCEがPMingLiUに変わり、元はMS UI Gothicを表示していたことがわかります。しかし下段のケースは変化がありません。フォントリンクは関係なかったようです。

下図は先のコメントで、さらに後ろにひらがなを置いてみたところです。下段のケースの「あ」はＭＳ Ｐゴシックで、U+6BCEより右はフォントリンクではなくゴシックに戻っていたことがわかります。

U+2661とGulim属性を持たないU+6BCEの組み合わせが、SimSun化を無効にしていたことになります。下図は上の図からU+2661を削除したところです。

結局、U+2661とU+6BCEによる挙動はArialを挟んだ場合と同じです。

U+2588とU+2661を逆にしたケースも見てみました。下図の下段のコメントで、「あ」 はなぜかGulim化しません。

CJKコードページで「あ」 の直前のU+2469とU+246Aを比較すると、U+246AはSimSun属性を持っていません。

Unicode	cp932	cp936	cp949	cp950
2469	8749	A2E2	A8F0	-
246A	874A	-	A8F1	-

そしてU+2588を削除すると、下段の「あ」もGulim化します。

先のケースと同様の結果です。
「フォント変化文字」 とその属性を持たない文字との組み合わせが、一度ゴシックから他のCJKフォントへ遷移した状態を元に戻す、そういうことなのかなと思いました。