CJKフォント変化における前後と隣接

下図はU+2588とU+3042（「あ」）を並べたコメントです。上下とも同じようにU+3042がU+2588によってSimSun化（いわゆる明朝化）しているように見えます。

ところが2文字の間にArialを挟むと結果が変わります。

下段のU+3042はゴシックに戻っています。

CJKフォント変化には3種類あるように思います。

• 前後の並びによるフォント変化
• 隣接によるフォント変化
• 「フォントの連れ回し」

3つ目の具体的な発生条件はわかりません。

上の図においてArialを挟むと上下の結果が異なるのは、この種類の違いなのではないでしょうか。上段のU+2588の効果は前後の並びによるものであるのに対して、下段は隣接によるものではないかということです。
下段のパターンで後ろにもU+3042を置いてみます。

後ろのU+3042は、中段のU+2588に隣接しない状態ではゴシックに戻っています。これは先頭のU+3042の効果であることを下段のコメントが示しています。先頭のU+3042のゴシックが前後の並びで優先されたように見えます。

隣接によるフォント変化の発生は、Windowsコードページの定義の有無に左右されているように思います。
U+2588・U+3042ともにコードページ1250～1258には定義はありません。そしてCJKコードページにはあります。この条件に当てはまる文字で起きるフォント変化を、勝手にCJKフォント変化と呼んでいることは前に書きました。

Unicode	cp932	cp936	cp949	cp950
2588	-	A880	-	A269
3042	82A0	A4A2	AAA2	-

CJKコードページにおける定義の有無について、わかりやすく以下のように考えています。

• 932（日本語）に定義がある＝ゴシック属性
• 936（簡体字中国語）に定義がある＝SimSun属性
• 949（韓国語）に定義がある＝Gulim属性
• 950（繁体字中国語）に定義がある＝MingLiU属性

U+2588との隣接によってU+3042がSimSun化するのは、SimSun属性を持っているからではないか。持っている属性が多いほど隣接によるCJKフォント変化の影響を受けやすい＝フォント変化的に弱いということではないかと思います。
上の例のU+2588をMingLiU化文字U+02CDに替えてみます。

上段のU+3042はMingLiU化しますが下段はゴシックのままです。これはU+3042がMingLiU属性を持たないからではないでしょうか。

Unicode	cp932	cp936	cp949	cp950
02CD	-	-	-	A1C5
3042	82A0	A4A2	AAA2	-

もう一つ別のケースを見てみます。U+2474はU+2588と同じく「SimSun化文字」です。

しかし後ろに「Gulim化文字」U+2661を置くとそれぞれの結果が異なります。

上段は隣接によるGulim化ではないかと思います。U+2588はGulim属性を持っていませんが、U+2474は持っています。

Unicode	cp932	cp936	cp949	cp950
2474	-	A2C5	A9E7	-
2588	-	A880	-	A269
2661	-	-	A2BD	-

間にArialを挟めば、このGulim化は起きなくなります。下図は後ろにU+3042を置いて、Arialを挟む前と後のコメントを比較しているところです。

下段では隣接によるGulim化が無効になり、前後の並びによるSimSun化に変わっています。
「フォント変化文字」 という考え方はちょっと違う、みたいなことを前に書きました。要はこのように、前後・隣接・属性の有無による強弱の組み合わせなのではないかという意味です。

もっとも、これでは説明のつかないことがあります。
「ゴシック化（ゴシック保護）文字」U+30FBはcp932にだけ定義があり、フォント変化的には一番強いはずです。しかし後ろにU+2588やU+2661を置いても、ゴシックの字形には変わりません。
おそらくCJKフォント変化とはデフォルトのゴシックとその他のCJKフォントとの遷移なのであって、ゴシック属性とその他のCJK属性は並列ではないのだろうと思います。それが説明できるケースを今のところ思いつかないのですが。