Chrome 29：三角（U+25E2～U+25E5）の縮みを補完するテスト（2）

Chromeでの三角のブロック文字の縮みを補完する話の続きです。
以前の書式制御文字を使ったやり方だと文字数も増えるしややこしいので、もっと簡単な方法がないか考えてました。アラビア文字にIEでは合成が起き、Chromeでは起きないケースがあったので試してみました。

下図の下段のコメントは三角と四角の間にアラビア文字U+06E5を挟んでいます。IEでは合成が起きてこの文字はゼロ幅となり、Chromeでは合成が起きません。

ちなみにIEでちょっと表示されているU+06E5はSimSunのフォントリンクによりMicrosoft Sans Serif、ChromeはArialではないかと思います。Chromeでは合成が起きない分コメント幅が広がり、結果的にIEと同じになっているように見えます。

同じ幅になったのは偶然です。U+06E6も同様の挙動でしたが、こちらは文字幅がU+06E5より広くうまくいきませんでした。
Windows 8での表示は7と変わりません。

ただしXPはIEでも合成が起きませんでした。

7・8への移行が進んでいるとは言え、まだXPは一定のシェアを持っているようです。無視するには早いのかなと思います。

＜参考＞OS・ブラウザー国内シェア調査 - サムライファクトリー

見た目が美しくないのもネックです。もっと目立たない字形で同様の挙動を取るものがあればいいんですが。
なお、（1）の書式制御文字を使ったやり方はXPでも使えます。

Windows 8：U+FEFFによる「Lucida化」について

U+FEFFはZERO WIDTH NO-BREAK SPACEという名前の通り、ゼロ幅文字です。
ArialにはなくてLucida Sans UnicodeにはあることからChromeでの「Lucida化」に使えそうですが、Windows 8でIEの表示がダメだったという話を以前書きました。

U+FEFFは、7・8ともゴシック・SimSun・Gulim・PMingLiUのいずれにもありません。Microsoft Sans Serifにはあるのでフォントリンクでそっちに飛ぶと思われ、7でのIEの表示はちゃんとゼロ幅です。

8での挙動は何かと思ったら、なぜかフォントリンク先に飛ばず「未定義」にされてしまうようです。Gulimの場合は豆腐です。

BabelMap

MingLiU化で豆腐にならない理由はわかりません。
前回書いた「Segoe化」と同じように、Arialを挟んでみたらSimSunやGulimでもゼロ幅になりました。

Arialをゼロ幅文字（下図ではU+200C）にすれば8でも使えそうです。

ただし「Lucida化」させる文字が連続していればいいのですが、途中にArialやゴシックが入ると効果がそこで無効にされてしまいます。

この例の場合は左側にも同じ仕掛けが必要になります。

なお、Windows XPでもIEの表示は7と変わりません。しかしChromeでは「Lucida化」が起きません。XPのLucida Sans UnicodeにもU+FEFFはあるのですが、7とは扱いが異なるようです。
また、上の「萌」を挟んだケースでLucidaの文字がU+2501やU+2587であれば左側にU+0323は要りません。U+FEFFはちょっと特殊なんだと思われます。

「Lucida化」の話のついでに、Chrome上で別のフォント変化を見つけたので書いておきます。下図はU+2030をU+2587とアラビア語の合成文字U+0610で変化させているところです。

U+061Xの他の文字でも同様でした。Tahomaかなと思うんですが。

U+2587が豆腐になっちゃってますし、今のところメリットを思いつかないのでこれ以上は調べてません。

Windows 8：「Segoe化」の回避

Windows 8でCJKフォント変化が発生したとき、特殊文字がSegoe UI Symbolで表示される話の続きです。

パターンが2種類ありました。単にCJKフォント変化が起きた場合と、CJKフォント変化＋後ろに特定の文字がついた場合です。
いずれも代替表示が行われる時に発生します。下図はSimSun化でのU+263Aの挙動を示しています。U+263AはSimSunにありませんので代替表示になります。

Segoeへの変化はArialの文字を使うことで回避できました。前者のパターンであればフォント変化文字との間、後者であれば後ろの文字との間にArialを挟みます。

「a」をゼロ幅文字に変えれば、この操作を隠してWindows 7と同じ表示にすることができます。下図の下段はゼロ幅文字にU+200Cを使っています。

ただし、このパターンだとU+263AがArialに変わってしまいます。下図はU+263AをU+2639に変えたところですが、これはArialに無いため豆腐化しています。

後者のパターンではフォント変化文字との隣接が変わらないため、フォントリンクによる代替表示に戻ります。U+263AはSimSunのフォントリンクによりＭＳ Ｐ明朝（字形はＭＳ Ｐゴシックと同じ）で表示されます。

表示がどうなるかは文字の組み合わせによるので、この方法をパターン化するのは難しいと思います。「Segoe化」を避ける最も簡単な方法は、ゴシックを保護してCJKフォント変化を起こさないことでしょう。

「Segoe化」とは別に、特殊文字がはじめから縮んで表示されるケースもあります。

これはゴシックにすればWindows 7と同じ表示にできます。CJKフォント変化が起きると初期の縮んだ状態に戻ってしまいます（U+2740もSimSunにはありませんので代替表示です）。

「Segoe化」と同じ方法でこの縮みを回避することはできません。

Chromeの件にしても、やはりCJKフォント変化自体を避けることが表示の互換につながるんじゃないかと思います。もちろん大丈夫なケースもありますから、結局は組み合わせの問題なんですが。