Chrome 21：Arial Unicode MSの問題

Chromeでのトランプのマーク（U+2660～U+2667）の表示をあらためて見てみます。

黒塗り（2660・2663・2665・2666）はArialにありますので、Chromeで表示されているのはそれだと思われます。仮にLucida Sans Unicodeが代替に使われるとしても、Lucidaにもトランプのマークは黒塗りしかありません。
それなら白抜きはArial Unicode MSじゃないかということでフォントを削除してみると、図の通り白抜きの表示が変わります。U+2661がMicrosoft Sans Serifだというのは前にも書きました。他はMSゴシックや明朝に見えます。U+2662はもともと両者の字形がそっくりなのでなんとも言えませんが。

実はU+2XXX辺りの特殊文字だけ見ても同様のケースがたくさんあります。
これはけっこう面倒な問題です。Arial Unicode MSというのはOffice添付のフォントで、必ずしもインストールされているとは限らないからです。インストールされていてもシステムフォントではないので、ユーザーがかんたんに削除できてしまいます。

＜参考＞
Windows 7 によってインストールされるフォント - Adobe
Arial Unicode MS - Microsoft typography

IEと完全にコメント幅を合わせるためにこういうケースを避けてしまったら、使える文字がかなり限定されます。完全に合わせる場合と、多少ズレても破綻しない程度で済む場合とを、組み合わせて使うのが現実的なのかなぁと思います。

ただし極端に表示が異なるケースもあったので、一応紹介しておきます。Windows 8です。

図の通り、Arial Unicode MSを削除すると白抜きは消えてしまいました。
何が起きたのかと思ったらゼロ幅になっていました。下図はU+2661を単独で入力したところです。

トランプのマークだけでなく、他のArial Unicode MSと思われる文字でも同じことが起こりました。
しかし豆腐になるならともかく、ゼロ幅になるのは仕様としておかしいのでは？そのうち直されるんじゃないかと思いました。それともなんか意味があるんでしょうか。

12/3追記：
今はゼロ幅にならないことに気づきました。→この日記

Chrome 21：全角幅の空白文字（1）

Chromeのコメント表示で全角の空白文字が無いなーと思ってたら、そうでもなさそうです。
下図はU+3164という文字を試しているところです。一番下のコメント（U+2587×3文字）はコメント幅の比較のために置いてあります。

「ハングル互換字母」というブロックにある文字で、日本語や中国語のフォントにはありません。
Chromeの表示はGulimでしょうか。Arial Unicode MSにはこの文字がありましたが、削除しても表示は変わりませんでした。下図は2つの画像を重ねたところです。

フォント変化文字はIEもChromeも同じ幅で表示されるものを使っています。コメント幅は全てのパターンで合っているように見えます。XPでも同様のようです。

MingLiU化はそもそもXPでは表示できないので例外です。

ただし、Windows 8（試したのは90日評価版）では同じようにはいきませんでした。

SimSun化とMingLiU化は縮んでしまいました。

実はU+3164はそれ自体がGulim化文字なので、IEの場合少なくともSimSun化・MingLiU化以外はGulimが表示されていると考えられます。一方SimSun化・MingLiU化（PMingLiU）は、7だとフォントリンクによりBatangだと思われます。
8でもフォントリンクに従えば同じ挙動のはずです。これに優先して他のものが表示されたのであれば、Segoe UI Symbolの件と同じような現象が起きているのかもしれません。

と言うわけで、Windows 8を考慮しなければどのフォント状態でも使えそうです。でも今後のことを考えるならSimSun化・MingLiU化ではやめた方がいいでしょう。8は10月には発売されます。

上の図は8・7・XPの画像を重ねてみたところです。それにしてもChromeの表示はブレません。こっちの方が動作としては正しいんじゃないの、と思うんですけど。

なお、U+3164はMacだと何か記号が表示されてしまうという話を見たことがあります。 最新のMacではどうかわかりませんが、グリフが無いことを示す文字ではないかと思います。
ちなみにAndroidではWindowsと同様に空白で表示されました。

U+3164自体がフォント変化文字であるということが弊害になるケースもあるかもしれません。
別の文字で、「ハングル字母」というブロックにあるU+115A～U+1160も全角の空白が表示されました。こちらはフォント変化文字ではありません。しかしU+3164ほど実用的ではなさそうです。

8だと何か表示されちゃってます。調べたらMalgun Gothicというフォントでした。U+3164が縮んだのもこれかもしれません。U+115F・U+1160だと空白になりますが、幅が縮んでいずれにしろダメでした。Gulim化でしか使えないみたいです。まぁ探せば他にもあるかもしれません。

ところでChromeではフォント変化が起きないと思ってたのですが、どうもそうとは言い切れないようです。この件を調べているときに、文字の組み合わせによってフォントが変わってしまう現象を見ました。と言っても、既知のフォント変化とは全く異なる現象です。これについてはあらためて調べてみたいと思います。

Chrome 21：IE互換のコメントにできないか

Chromeでのコメント表示の話を読んでくださったōrzさんが検証動画を作られました。画面左が現在のChrome(pepflashplayer)の表示・右がIEやFirefoxと同じ表示です。実にわかりやすいです。

しかし困ったもんです。月も変わったことなので、またStatCounterで日本のブラウザシェアを見てみました。

シェア率の数字は統計によって違うものなので、これだけでどうこうも言えません。
が、気になったのはIEの推移です。少し下がったのがまた盛り返しています。その分、下がっているのはこのグラフだと悲しいことにFirefoxです。そしてChromeはその間も少し伸びています。
世界的にはIEを抜いたと言われた状況とはだいぶ開きがあるものの、この傾向は今後も続くのかなぁと思いました。そのChromeでニコニコが安定して視聴できるとなると、やはりコメント表示の件は無視しづらい話です。

IEとChromeで文字幅を合わせる例はすでにいくつか見たので、この件の当初に挙げたコメントのサンプルを直してみました。とは言ってもChromeでは一つの文字に適用されるフォントが決まってしまっているので、元のコメントと全く同じ見た目にするのはほぼ無理です。とりあえず崩れないようにできないかというのが趣旨です。

まず1つめの例です。

文字列がゴシックになってしまうのはどうしようもないとして、ブロック文字の縮みだけでも直したい。これはU+2588をU+2587で代用できないかという話を書きました。

ちょっとアレですけどｗ
さらにU+2587をMingLiU化すれば継ぎ目が無くなって、よりChromeと似たような見た目にはできるでしょう（そのための細工がまた必要になりますが）。全角幅ということであれば、U+2589などもArialに無いので使えそうです。

2つめの例は、二重リサイズと呼ばれる現象を利用したbig10行というやり方です。

冒頭の動画でもこのケースが非常に目立っていました。
本来は、改行により一度縮小したコメントがある一定の幅になると拡大するという現象です。一定の幅というのがちょうど全角幅で決まった文字数と一致することから、コメントを等幅フォントのSimSunやGulimに変化させて行われます。ChromeではSimSun化させるためのブロック文字だけでなく空白文字（おそらく全角スペース）も縮んでしまってこの一定の幅が保てず、現象が起きなくなっています。

SimSun化させる文字は他でも代用できますが、Chromeで全角になる空白文字というのは今のところわかりません。しかし一定の幅にさえなればいいのであって、必ずしも全角の文字である必要はありません。下図は直してみたものです。

文字列はChromeに合わせてゴシックに変えています。ブロック文字はU+2587に、空白部分はU+0020（半角スペース）とU+3000（全角スペース）に置き換えました。U+3000はそのままだとU+2587の影響でSimSunになってしまうため、Chromeと合うようゴシック状態にする細工をしています。
Arial・ゴシックは文字によって幅が違いますので、何文字でこうなると決まったことは言えません。空白部分も含めた1行全体の長さが、全角文字で作った場合と近くなるようにちょこちょこ調整しました。

これは思いつきですが、文字列部分はIEでSimSun・Chromeでゴシックという表示にもできるかもしれません。下図は文字列の最後へ先日の日記に書いたU+25ACを置いたコメントです。

U+25ACはSimSun化状態だと縮み、Arialでは全角に近くなるという変わった挙動を取ります。下図は2つの画像を重ねてみたところです。

Chromeではひらがながゴシックになって縮む一方、U+25ACは幅が広がっています。結果的にコメント全体ではIEと同じ幅になったように見えます。

まぁ上のような例は元々フォント変化が起きる前提で考えたコメントを直しているので、どうしても限界があります。でもこうやっていろいろいじくり回しているうちに、新たに気づくこともあるかもしれません。

Chrome 21：pepflashplayer.dllの件（つづき）

Chromeがまたアップデートされて21.0.1180.89となりました。
pepflashplayerも更新されていて、バージョンは11.3.31.232となっています。あいにく英語はさっぱりなんですけど、公式ブログを見ると「Several Pepper Flash fixes」とあります。「niconico video」もその対象だったようです。

＜参考＞Stable Channel Update - Chrome Releases

Windows XPではpepflashplayer有効のままだとコメント入力やメニュー操作ができない、という話を先日の日記で書きました。アップデートしてから原宿・ZeroWatch両方とも試してみたところ、これが直ってました。

XPは2台のPCで試しました（ここだけの話1台は職場）。家の非力なXPだとなぜか原宿が異様に重く、ZeroWatchはとりあえず大丈夫でした。ちなみに7は更新前から一応ふつうに使えましたが、更新後はZeroWatchでプレーヤー下の動画再生リストがやけにぬるぬる動くように感じました。

結局何が問題だったのかはわからないし、環境によってはまだ不具合があるのかもしれません。ただ改善されていることは確かなようなので、Chromeユーザーの方はよかったんじゃないでしょうか。
Firefox派の自分にはコメント表示の問題がよけいに気になるだけですがｗ

Chrome 21：縮む文字・縮まない文字

ブロック文字の話のつづきです。以下はすべてWindows 7で見ています。

もう一度繰り返すと、U+2581～U+2588をChrome（pepflashplayer有効）で見たところ、ArialにグリフのあるU+2584とU+2588はArialの縦長の字形で表示されました。U+2582・2583・2585～2587は全角、U+2581だけなぜかArial Unicode MSの縦長の字形で表示されました。

この範囲がChromeではArialで表示されることになっているとして、Arialに無い文字は全角の何か→Arial Unicode MSの順でフォールバックしたんじゃないかということです。

「全角の何か」はMingLiUを始めとする中国語フォントやメイリオなどにはあるのですが、Arial Unicode MSに優先してCJKフォントが出てくるのは唐突な気がしました。あらためて調べてみると、欧文系のフォントでもSegoe UI SymbolとLucida Sans Unicodeにはありました。しかしSegoe UI SymbolはXPに入ってません。ということは、これはLucida Sans Unicodeではないだろうか。これならXPにも入っています。

下図はU+2587をまたBabelMapで出力してみたものです。空白部分が黄枠とは一致してないですが、これは他のケースで見ても必ずしも関係なさそうなのでとりあえず気にしません。

CMapを見てみると、Lucida Sans UnicodeにはなぜかU+2581が欠けています。U+2581だけArial Unicode MSだったのはこのせいじゃないかと思いました。下図はArial・Lucida Sans Unicode・Arial Unicode MSのCMapを比較しています。

まぁ断定はできませんけど。ただ、こうしてフォント名が推測できるとCMapから縮まなそうな文字を探しやすくなります。例えば下図は罫線記号U+2500～U+2503を試しています。

なぜこの4つを拾ったのかと言うと、Arialには2501と2503は無かったからです。

この2501・2503もChromeではLucida Sans Unicodeなのかもしれません。文字幅はIEと一致するようです。

IEの方はLucida Sans Unicodeというわけではありません。たぶんＭＳ Ｐゴシックです。

と言うのは、これらの文字はコードページの話で言うと1250～1258に定義がなくCJKコードページにある文字だからです。IEではCJKフォントのいずれかで表示されると予想されます。CP932（日本語）に定義があるのでゴシックかなと。

本題とそれますが、上の図の定義を見ると2501と2503はCP950（繁体字中国語） にだけありません。つまりMingLiU化解除文字だろうと考えられます。
下図はそれを試しているところです。欧文系のフォントならこんな現象は起きないでしょう。

最後に上のブロック文字や罫線記号とは違うケースも見てみます。下図はU+25ACという文字の挙動です。

IEでは単独の状態がGulimとよく似ています。ゴシックだともっと細くて短い字形です。SimSun・PMingLiUはこの文字が無いので代替表示です。フォントリンクでＭＳ Ｐ明朝だろうと思われます。
Chromeでもこの単独のが表示されています。フォント変化は起こらないので全部同じです。単独のフォントは何かと思ったらArial自体にありました。

もっとも、字形が全角幅に見えても複数並べるとGulimより少し短いようです。本当にArialだとすれば描画上の問題かなと思いますが、その辺の仕組みはわかりません。

ただ少なくとも挙動は既知のArialのものです。下図はIEとChromeの表示を同じにしてみる例です。
漢字やひらがなに接すると、U+25ACは上で見た通りゴシックになって縮んでしまいます。前にも書いたゼロ幅文字をはさむやり方で、これを回避できました。

このケースではU+200CでArialがゴシックに変わるのを防いでいます。字形的にけっこう使えそうです。

Chrome 21：pepflashplayer.dllの件

先週またChromeのアップデートがありました。
Windows 7ではニコニコの原宿もZeroWatchも一応ふつうに使えるのですが、XPでは相変わらず問題があるようです。自分が試している環境だと原宿で再生はできるものの、コメント入力やメニュー操作ができません。
下図はWindows XP・Chrome 21で、プラグインの設定はいじらずに見ているところです。

ZeroWatchではいつまで経っても再生が始まりませんでした。

この件の最初の時に、pepflashplayer.dllに問題があるようで無効化したら直ったという話を紹介しました。ググるとこの解決法はけっこう知られているようです。しかし、こちらの記事を見てやっぱりセキュリティ的によくないのかなと思いました。

「Google Chrome」安定版v21.0.1180.83が公開、TLS 1.1が利用できない問題などを修正 - 窓の杜

このアップデートでは、組込みのFlash Playerも脆弱性の問題で更新されています。
ただし記事にあるように「更新されたのはPPAPI版（pepflashplayer）のみで、NPAPI版Flashプラグインは脆弱性の影響を受けるv11.3.300.271のまま」です。つまりpepflashplayer.dllを無効にするだけだと、更新されていないNPAPI版が使われてしまうのではないかと。

NPAPI版（gcswf32）も無効にすればシステムのプラグインが使われるはずです。システムのプラグインが更新されていれば、それで問題ないかもしれません。ただpluginsの設定はサイレントアップデートでリセットされてしまうようなので、いずれにしても実用的ではない気がします。
そこまでやるならIE Tabというアドオンがあったなと今さら思いました。オプションでニコニコのURLを指定しておけば常に実質IEで見ることになるので、その方が手軽で安全なんじゃないでしょうか。

さて、Chrome 22のベータ版が公開されました。

「Google Chrome 22」のベータ版が公開、“Pointer Lock API”を実装 - （同上）

XPにインストールしてみたところ、pepflashplayer.dllのバージョンがさらに上がり11.3.31.318となっていました。そして、このpepflashplayer有効のまま原宿もZeroWatchもとりあえずは動作しました。
家で一番非力なPCで特にZeroWatchはかなり重かったものの、何か改善はされているようです。今後のアップデートでこの問題は解決していくのかもと思いました。

pepflashplayerでも安定してニコニコが見られるようになると、先日来書いているコメントのフォントの問題では面倒な状況となるわけですが。ここのところ試しにずっとChromeでニコニコを見ているので、実際フォントの違いで崩れたコメントを見かけることがあります。まぁ現状どうしようもないですね。

※追記
Chrome 22正式版ではNPAPI版が無くなりました。PPAPI版とシステムのプラグインの2つだけになっています。

VBA：ChrW関数でU+10000以降の文字を取得

先日Windows 7（のSegoe UI Symbol）にケータイ絵文字が追加されたという話を書きました。その補足的なことです。

BMP領域（U+FFFFまで）・拡張領域（U+10000以降）を問わず、一つのUnicodeの文字コードから文字自体を得るのはかんたんです。ワードパッドやMS Wordで文字コードを入力、その後ろでAlt+Xを入力すれば変換されます。下図はU+1F4F6（ケータイのアンテナマーク）をワードパッド上で変換したところです。

フォントはSegoe UI Symbolにしています。もう一度Alt+Xを入力すると文字コードに戻ります。

さてVBAでこのような変換をする場合、 ChrW関数だとBMP領域しか対応できません。
というか、拡張領域の文字はBMP領域の文字2つを連結して表す仕組みになっています（サロゲートペア） 。

＜参考＞Unicode文字のマッピング・代用符号位置 - Wikipedia

上のリンク先には、U+10000以降の文字コードは2つの文字（上位サロゲート・下位サロゲート）を使って下記の数式で求められるとあります。

&H10000 + (上位サロゲート - &HD800) × &H400 + (下位サロゲート - &HDC00)

この数式から逆に2つの文字を求めてChrW関数で変換、連結すれば目的の文字が得られるでしょう。以下のようにユーザー定義関数を作りました。

Public Function ChrW_SP(ByVal CharCode As Long) As String
Dim HS As Long '上位サロゲート
Dim LS As Long '下位サロゲート

    If CharCode < &H10000 Then Exit Function
    CharCode = CharCode - &H10000 '元のコードから&H10000を引く
    HS = (CharCode \ &H400) + &HD800 '上位：&H400で割った商に&HD800を足す
    LS = (CharCode Mod &H400) + &HDC00 '下位：&H400で割ったあまりに&HDC00を足す
    ChrW_SP = ChrW(HS) & ChrW(LS) '連結

End Function

下図はExcelのシート上でこの関数を使ってみたところです。HEX2DEC関数で10進に変換してから渡しています。「字形」の列はフォントをSegoe UI Symbolにしています。

こういう表が作りたかったので調べてみました。