「ご使用のOS環境では、通常の動画プレーヤーを表示できないため～」

Waterfoxのフォーラムを見たら、先日公開されていた"24 Preview 1"に続いて試作版がアップされていました。試しにインストールした際、ちょっとおかしなことがありました。

ニコニコの視聴ページを開いてみると、Qwatchではなく懐かしい原宿の画面になってしまいました。よく見ると、ページの下に「ご使用のOS環境では、通常の動画プレーヤーを表示できないため、一部機能が制限された動画プレーヤーをご利用いただいています。」と表示されていました。

ググるとこういうエラーが起きることはあるらしいのですが、自分は初めて見ました。どういうわけかOS（Windows 8）を正しく認識してくれていないようです。
トラブルシューティングを開いたところ：

一方、Firefox（25 Beta）で同じくトラブルシューティングを開いたところ：

Waterfoxの方のユーザエージェント文字列では、OSのバージョンが「Windows NT」としか表示されていません。調べたら、この値はabout:configのgeneral.useragent.overrideで変更できることがわかりました。
「Windows NT」の部分を「Windows NT 6.2」と修正しました。

これでふつうにQwatchが表示されるようになりました。なぜ「6.2」が入らなかったのかはわかりませんが、勉強になりました。

なお、このWaterfoxはFirefoxのプロファイルを読み込まないという問題もありました。C:\Users\＜ユーザー名＞\AppData\Roaming以下のパスの設定が、現在のFirefoxと違っているためでした。とりあえずSyncで同期させて使っています。軽くて快適だったので安定版の公開が待たれます。

Chrome 29：半角カナの表示とフォント変化

Chromeでの半角カナの表示において、記号類だけがなぜかゴシックになりません。Arial Unicode MSが使われているようです。

Officeが入っていない環境であれば下の図のような表示になるのではないでしょうか。
半角カタカナと混ぜて並べてみると、Arial Unicode MSが適用されている方はなんかバランスが悪いです。

意味の分からない仕様です。何か他の目的のアルゴリズムの副作用なんでしょうか。

さて下図は、ひらがなの「あ」・半角半濁点・罫線のU+2501を並べたコメントです。上の段はU+2501にU+0323を合成させて「Lucida化」の形にしています。
上の段と下の段はコメントの幅が異なっています。

上下で幅が違う文字は真ん中のU+FF9Fです。このケースにおいて、Arial Unicode MSが無ければChromeの表示はIEと同様になります。

つまり上の段のU+FF9Fは、「Lucida化」によりArial Unicode MSからゴシックへ変化しているようです。
この挙動には後ろのU+2501とU+0323だけでなく、先頭の「あ」（というかゴシック）も必要です。「あ」が無いと「ただのLucida化」になります。

LucidaにU+FF9Fは無いので豆腐です。
なお冒頭の半角記号がすべてこのやり方でゴシックになるわけではありません。半角読点だと「ただのLucida化」でした。

濁点と読点を何で区別しているのかは謎です。

顔文字の豆腐化を見て

どこかからコピペしたようなコメントが豆腐になっているのを見かけることがあります。先日下図のような顔文字を見て、もしやとChromeで表示させてみると豆腐になりませんでした。ちょっと気になって調べてみました。

この顔文字を構成する文字は下図の通りでした。

これらの文字のWindowsコードページにおける定義の有無と、Arial・Lucida Sans Unicode・ＭＳ Ｐゴシックの各CMapにおける定義の有無を以下に示します。CMapはWindows 7のもので見ています。

Unicode	ブロック名	Windowsコードページ	Arial	LSU	MS Pゴ
0020	基本ラテン文字 （ASCII互換）	CJK各コードページおよび1250～1258	3	3	16076
0028	基本ラテン文字 （ASCII互換）	CJK各コードページおよび1250～1258	11	11	16084
0029	基本ラテン文字 （ASCII互換）	CJK各コードページおよび1250～1258	12	12	16085
03C9	ギリシア文字及びコプト文字	CJK各コードページおよび1253	550	752	16616
1555	統合カナダ先住民音節	-	-	-	-
1557	統合カナダ先住民音節	-	-	-	-
207E	上付き・下付き	-	-	1041	16951
208D	上付き・下付き	-	-	1056	16966
25D3	幾何学模様	-	-	1691	17799
25D4	幾何学模様	-	-	1692	17800

表の上4文字はコードページ1250～1258のいずれかに定義があることから、IEではArialで表示されていると思います。ChromeでもArialにあるものはArialで表示されるようなのでIEと同じでしょう。
「統合カナダ先住民音節」の2文字（手の部分）に対応するフォントは、Windows 7に2つしかありませんでした（8でも同様）。

Gadugiは丸の部分の幅が均一な字形のようなので、Euphemiaの方でしょうか。しかしこんなのよく見つけますね。

表の下4文字はいずれもArialにありませんが、LucidaにはあるのでChromeではこれが表示されているのでしょう。問題はIEの表示です。Lucidaやゴシック以外にも対応しているフォントは多数あるのに、3文字がArialの豆腐になっています。
なぜ右端のU+207Eは豆腐にならないのでしょうか。上の推測からすると、これだけがArialではない文字と隣接しています。試しに左の部分からU+0020（半角スペース）を削除してU+208DをU+1555に隣接させると、豆腐にならなくなりました。

ちなみにこうして表示されたU+208Dは、Windows 7と8ではフォントが異なるようです。

Windows 7ではゴシックに隣接した場合と同じ字形に見えますが、8では違っています。Segoeなのかもしれません。

さて、この顔文字を修正してみます。Arialに定義が無いゼロ幅文字を、豆腐化している文字の前へ挟んで隣接させました。
U+FEFFを使った場合：

Windows 7では上手くいきましたが8ではなぜかU+FEFFが豆腐になってしまいました。U+FEFFの使い方はもっと研究が必要なようです。
U+2029を使った場合：

これは大丈夫でした。上でも触れたように、8では豆腐でなくなった文字のフォントが7と違うようですが。
なおU+2029はワードパッド上でコピペすると改行に変換されてしまうという問題があったので、もう一つ試しました。
U+0085を使った場合：

表示はU+2029の時と変わりませんでした。U+0085・2029は制御文字なので、そもそもフォントは関係ないかもしれません。少なくともArialでないことは確かです。Arial以外の文字と隣接することにより、豆腐化せずに他のフォントへフォールバックするという仕組みなんでしょうか。
一方Chromeでは上のどのパターンも表示に影響はありませんでした。

ただしこの顔文字、XPでは豆腐化を避けられません。「統合カナダ先住民音節」に対応するフォントが入っていないからです。

VistaはEuphemiaが入っているようなので7と同じ表示かもしれません。
参考までにAndroidでも見てみました。

XP上のIEで豆腐化した部分が空白になった形です。
ググったら、この顔文字がFacebookなどで使われているケースをいくつか見つけました。こうして見ると、元々あまりおすすめの顔文字とは言えなそうですが。

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

Excel 2010：SP2で図のコピペに変化？

下図のシート上で選択されているのは、その下のセル範囲を「図としてコピー（ピクチャ）」して貼り付けた図です。

Excel 2010 SP1 - Windows 7

Excel 2010でこのシート全体をコピーして他のシートに貼り付けると、上の図が縮んでしまうという現象がありました。Excel 2003ではこのようなことは起こらなかったので困っていました。

Excel 2010 SP1 - Windows 7

一昨日リリースされたOffice 2010 Service Pack 2をインストールしたところ、この挙動に変化が見られました。

Description of Office 2010 SP2 - Microsoft サポート

コピー元が2003形式（.xls）だとコピペしても図が縮まなくなりました。ただし2007形式（.xlsx）ではSP1と変わりませんでした。

Excel 2010 SP2（コピー元が.xls形式の場合） - Windows 7

2007形式では変わらないということは、この現象自体が修正されたのではないでしょう。ただ、なんらかの変更の影響なのかなと思いました。

Office 2010 and SharePoint 2010 Service Pack 2 Availability - TechNet Blogs

上のリンク先にある「changes list」を見るとExcelの変更箇所も解説されています。Copying imagesうんぬんというのもあります。これとはまた別の話のようですが関係あるでしょうか。

ちなみに同様のコピペをExcel 2013でやった場合、コピー元が2007形式であれば問題は起きません。

Excel 2013（コピー元が.xlsx形式の場合） - Windows 7

一方、コピー元が2003形式だと図が伸びるという現象が起きます。

Excel 2013（コピー元が.xls形式の場合） - Windows 7

いちおう解決はしてるけど、2003形式までは面倒見れないということですかね。