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派の自分にはコメント表示の問題がよけいに気になるだけですがw
2012年8月31日金曜日
2012年8月29日水曜日
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というわけではありません。たぶんMS Pゴシックです。
と言うのは、これらの文字はコードページの話で言うと1250~1258に定義がなくCJKコードページにある文字だからです。IEではCJKフォントのいずれかで表示されると予想されます。CP932(日本語)に定義があるのでゴシックかなと。
本題とそれますが、上の図の定義を見ると2501と2503はCP950(繁体字中国語) にだけありません。つまりMingLiU化解除文字だろうと考えられます。
下図はそれを試しているところです。欧文系のフォントならこんな現象は起きないでしょう。
最後に上のブロック文字や罫線記号とは違うケースも見てみます。下図はU+25ACという文字の挙動です。
IEでは単独の状態がGulimとよく似ています。ゴシックだともっと細くて短い字形です。SimSun・PMingLiUはこの文字が無いので代替表示です。フォントリンクでMS P明朝だろうと思われます。
Chromeでもこの単独のが表示されています。フォント変化は起こらないので全部同じです。単独のフォントは何かと思ったらArial自体にありました。
もっとも、字形が全角幅に見えても複数並べるとGulimより少し短いようです。本当にArialだとすれば描画上の問題かなと思いますが、その辺の仕組みはわかりません。
ただ少なくとも挙動は既知のArialのものです。下図はIEとChromeの表示を同じにしてみる例です。
漢字やひらがなに接すると、U+25ACは上で見た通りゴシックになって縮んでしまいます。前にも書いたゼロ幅文字をはさむやり方で、これを回避できました。
このケースではU+200CでArialがゴシックに変わるのを防いでいます。字形的にけっこう使えそうです。
もう一度繰り返すと、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というわけではありません。たぶんMS Pゴシックです。
と言うのは、これらの文字はコードページの話で言うと1250~1258に定義がなくCJKコードページにある文字だからです。IEではCJKフォントのいずれかで表示されると予想されます。CP932(日本語)に定義があるのでゴシックかなと。
本題とそれますが、上の図の定義を見ると2501と2503はCP950(繁体字中国語) にだけありません。つまりMingLiU化解除文字だろうと考えられます。
下図はそれを試しているところです。欧文系のフォントならこんな現象は起きないでしょう。
最後に上のブロック文字や罫線記号とは違うケースも見てみます。下図はU+25ACという文字の挙動です。
IEでは単独の状態がGulimとよく似ています。ゴシックだともっと細くて短い字形です。SimSun・PMingLiUはこの文字が無いので代替表示です。フォントリンクでMS P明朝だろうと思われます。
Chromeでもこの単独のが表示されています。フォント変化は起こらないので全部同じです。単独のフォントは何かと思ったらArial自体にありました。
もっとも、字形が全角幅に見えても複数並べるとGulimより少し短いようです。本当にArialだとすれば描画上の問題かなと思いますが、その辺の仕組みはわかりません。
ただ少なくとも挙動は既知のArialのものです。下図はIEとChromeの表示を同じにしてみる例です。
漢字やひらがなに接すると、U+25ACは上で見た通りゴシックになって縮んでしまいます。前にも書いたゼロ幅文字をはさむやり方で、これを回避できました。
このケースではU+200CでArialがゴシックに変わるのを防いでいます。字形的にけっこう使えそうです。
2012年8月26日日曜日
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つだけになっています。
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つだけになっています。
2012年8月23日木曜日
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つの文字(上位サロゲート・下位サロゲート)を使って下記の数式で求められるとあります。
この数式から逆に2つの文字を求めてChrW関数で変換、連結すれば目的の文字が得られるでしょう。以下のようにユーザー定義関数を作りました。
下図はExcelのシート上でこの関数を使ってみたところです。HEX2DEC関数で10進に変換してから渡しています。「字形」の列はフォントを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つの文字(上位サロゲート・下位サロゲート)を使って下記の数式で求められるとあります。
この数式から逆に2つの文字を求めてChrW関数で変換、連結すれば目的の文字が得られるでしょう。以下のようにユーザー定義関数を作りました。
下図はExcelのシート上でこの関数を使ってみたところです。HEX2DEC関数で10進に変換してから渡しています。「字形」の列はフォントをSegoe UI Symbolにしています。
こういう表が作りたかったので調べてみました。
ラベル:
VBA
2012年8月19日日曜日
Chrome 21:空白文字の問題
先日の話の続きです。
IE・FirefoxとChromeとの間でコメント表示の互換を図るとしたら、空白文字はどうしたらいいか考えてみます。
まず間違いないのは半角スペース(U+0020)かNBSP(U+00A0)です。
これらは元からArialだと思われ、CJKフォント変化の影響を受けません。Chromeでも同じくArialのようです。下図はU+0020をひらがなとU+2587(SimSun化文字)とで、それぞれはさんだところを比較しています。
U+2587がChromeでも全角幅なのは既に紹介した通りです。
下の図は2つの画像を重ね合わせたところです。
フォント変化は関係ないので両者のコメント幅に差は出ません。幅が短いため、空白部分をたくさん作りたい場合には文字数的に苦しいところです。
次に全角スペースU+3000です。Chromeではゴシックのようです。
IE・Firefoxでもフォント変化が起きなければゴシックですが、下図ではU+2587に隣接するとSimSunの全角幅となりChromeとはコメント幅に差が出ています。
U+2587のようなフォント変化文字と並べて使うなら、U+3000をゴシック状態に保つための仕掛けが必要になります。下図の下段のコメントはその例です。
先頭にU+30FBを置いています(ゴシックを保持する効果)。そしてU+2587と隣接する部分にはArialの文字をはさんでいます(先頭のU+30FBの影響を優先させ、U+3000のSimSun化を回避する効果)。Arialと言っても半角英数字ではコメントの内容が変わってしまうため、ゼロ幅文字を利用しています。
空白部分をたくさん作るのであれば、今のところこれが現実的な方法なのかなと思います。
U+2001も見てみます。ChromeではArialのようです。
IE・Firefoxでは単独またはArialに隣接した場合Arial、ゴシックに隣接した場合はゴシックとなります。
SimSun化・Gulim化・MingLiU化の場合、これらのフォントにU+2001は無いため代替表示となります。フォントリンクによりMincosoft Sans Serifが使われると考えられます。Arialとは文字幅が違うので、U+2587ではさんだケースではChromeと差が出ています。
「あ」ではさんだゴシックのケースは、Arialと同様Chromeとは差が無いように見えます。
これはArialとゴシックでU+2001の文字幅の差が小さいからだと思われます。全く同じではありません。下図はU+2001を10個にして比較してみたところです。
ゴシックだとやはり差が出てしまうのがわかります。
ではArialで使えば大丈夫かと言うと、一つ問題があります。Windows XPではArialにU+2001が無いため豆腐になります。
ちなみにXP上のChromeではArial Unicode MSが使われるらしく、豆腐にはなりません。ただしXPではpepflashplayer有効だと動画再生以外の操作ができず、その状態で視聴することはないでしょう。
というわけで、XPを考慮する必要さえ無くなればArialで使えそうです。
まあ実際には、こんなことを考えたらフォント変化を前提とする既存のコメントは全部作り直さなければならなくなります。Chromeはニコニコの推奨環境ではありませんので、この件は無視するという考え方もできます。しかし現にChromeで視聴することはできるし、そのブラウザシェアは無視するには大きすぎます。
ただでさえネット視聴におけるAndroid・iOSのシェアは急速に伸びています。その結果、Windowsのシェアは相対的に下がっているだろうと考えられます。それがニコニコの視聴にどの程度影響しているのかはわかりませんが、この上Windowsの中でまでコメント表示に差異が発生するのはできれば避けたいなと思います。
ていうか、この話Chromeの「フォントがおかしい」 と書いてしまったんですけど、フォント変化はそもそも起きる方がおかしいのです。
例えばU+2588(ブロック文字)やU+2665(ハートマーク)は、Arialにもゴシックにもある文字です。にもかかわらず、それ自体や隣接した日本語がわざわざ中国語フォントや韓国語フォントに変わる意味はありません。フォント変化が起きなくなった今のChromeは、むしろ「安定した」と言えるのかもしれません。
ひょっとしたら、いずれニコニコのコメントはこういう挙動の方がふつうになるのでは?そんなことも思いました。
IE・FirefoxとChromeとの間でコメント表示の互換を図るとしたら、空白文字はどうしたらいいか考えてみます。
まず間違いないのは半角スペース(U+0020)かNBSP(U+00A0)です。
これらは元からArialだと思われ、CJKフォント変化の影響を受けません。Chromeでも同じくArialのようです。下図はU+0020をひらがなとU+2587(SimSun化文字)とで、それぞれはさんだところを比較しています。
U+2587がChromeでも全角幅なのは既に紹介した通りです。
下の図は2つの画像を重ね合わせたところです。
フォント変化は関係ないので両者のコメント幅に差は出ません。幅が短いため、空白部分をたくさん作りたい場合には文字数的に苦しいところです。
次に全角スペースU+3000です。Chromeではゴシックのようです。
IE・Firefoxでもフォント変化が起きなければゴシックですが、下図ではU+2587に隣接するとSimSunの全角幅となりChromeとはコメント幅に差が出ています。
U+2587のようなフォント変化文字と並べて使うなら、U+3000をゴシック状態に保つための仕掛けが必要になります。下図の下段のコメントはその例です。
空白部分をたくさん作るのであれば、今のところこれが現実的な方法なのかなと思います。
U+2001も見てみます。ChromeではArialのようです。
IE・Firefoxでは単独またはArialに隣接した場合Arial、ゴシックに隣接した場合はゴシックとなります。
SimSun化・Gulim化・MingLiU化の場合、これらのフォントにU+2001は無いため代替表示となります。フォントリンクによりMincosoft Sans Serifが使われると考えられます。Arialとは文字幅が違うので、U+2587ではさんだケースではChromeと差が出ています。
「あ」ではさんだゴシックのケースは、Arialと同様Chromeとは差が無いように見えます。
これはArialとゴシックでU+2001の文字幅の差が小さいからだと思われます。全く同じではありません。下図はU+2001を10個にして比較してみたところです。
ゴシックだとやはり差が出てしまうのがわかります。
ではArialで使えば大丈夫かと言うと、一つ問題があります。Windows XPではArialにU+2001が無いため豆腐になります。
ちなみにXP上のChromeではArial Unicode MSが使われるらしく、豆腐にはなりません。ただしXPではpepflashplayer有効だと動画再生以外の操作ができず、その状態で視聴することはないでしょう。
というわけで、XPを考慮する必要さえ無くなればArialで使えそうです。
まあ実際には、こんなことを考えたらフォント変化を前提とする既存のコメントは全部作り直さなければならなくなります。Chromeはニコニコの推奨環境ではありませんので、この件は無視するという考え方もできます。しかし現にChromeで視聴することはできるし、そのブラウザシェアは無視するには大きすぎます。
ただでさえネット視聴におけるAndroid・iOSのシェアは急速に伸びています。その結果、Windowsのシェアは相対的に下がっているだろうと考えられます。それがニコニコの視聴にどの程度影響しているのかはわかりませんが、この上Windowsの中でまでコメント表示に差異が発生するのはできれば避けたいなと思います。
ていうか、この話Chromeの「フォントがおかしい」 と書いてしまったんですけど、フォント変化はそもそも起きる方がおかしいのです。
例えばU+2588(ブロック文字)やU+2665(ハートマーク)は、Arialにもゴシックにもある文字です。にもかかわらず、それ自体や隣接した日本語がわざわざ中国語フォントや韓国語フォントに変わる意味はありません。フォント変化が起きなくなった今のChromeは、むしろ「安定した」と言えるのかもしれません。
ひょっとしたら、いずれニコニコのコメントはこういう挙動の方がふつうになるのでは?そんなことも思いました。
2012年8月18日土曜日
Windows 7:ケータイ絵文字などの追加
Windows 8のevaluation for developers(90日評価版)使ってみてます。快適です。
RPはちょっと古いデスクトップとノートにそれぞれ入れて試してました。ノートの方(某メーカー3年前のモデル)は元々7の動作が時々苦しげなスペックで、8RPでだいぶマシになったもののまだモッサリ感が気になってました。評価版はよく見る8の紹介映像そのままにぬるぬる動き、思わず「おお!」と声が出ました。もう7には戻したくないです。
さて本題は7の話なのですが、その最新版(というか製品版と同じはず)の8とも比較しながら見たいと思います。昨日こちらのドキュメントに気づきました:
An update for the Segoe UI symbol font in Windows 7 and in Windows Server 2008 R2 is available - Microsoft サポート
残念な機械翻訳版なのはともかく、要するに7のSegoe UI Symbolに8のEmoji Symbols追加したよという話らしい。見てみたら、いつの間にか7のSegoe UI Symbolが5.00から5.01にバージョンアップしてました。先の月例更新の時でしょうか?とりあえずCMapのデータを比較してみました。
8ほどの収録文字数ではないですが、5.01では拡張領域を中心に大幅に追加されています。差分の中身を見ると確かにケータイ絵文字や特殊記号が多いようでした。「古イタリア文字」や「ゴート文字」なんていうのもありました。絵文字は8の全部というわけではなく、追加されてないものも多数ありました。
ただし今のところコメントでは表示できないようです。これはChrome(pepflashplayer)でも同じでした。
フォント変化させてもダメでした。まぁ全部試したわけじゃないんですけど。
ZeroWatchのコメントパネルには表示されてました。
8ではこれまで見てきた通り、ちゃんと表示されます。
もっとも、これは7のコメントでSegoe UI Symbolが使われないということではありません。文字によっては表示されるものもあります。下図は5.00の時からあったグリフで、他のフォントにはありません。
ケータイ絵文字も同じように対応したらおもしろいんですが。
RPはちょっと古いデスクトップとノートにそれぞれ入れて試してました。ノートの方(某メーカー3年前のモデル)は元々7の動作が時々苦しげなスペックで、8RPでだいぶマシになったもののまだモッサリ感が気になってました。評価版はよく見る8の紹介映像そのままにぬるぬる動き、思わず「おお!」と声が出ました。もう7には戻したくないです。
さて本題は7の話なのですが、その最新版(というか製品版と同じはず)の8とも比較しながら見たいと思います。昨日こちらのドキュメントに気づきました:
An update for the Segoe UI symbol font in Windows 7 and in Windows Server 2008 R2 is available - Microsoft サポート
残念な機械翻訳版なのはともかく、要するに7のSegoe UI Symbolに8のEmoji Symbols追加したよという話らしい。見てみたら、いつの間にか7のSegoe UI Symbolが5.00から5.01にバージョンアップしてました。先の月例更新の時でしょうか?とりあえずCMapのデータを比較してみました。
| Segoe UI Symbol | 5.00(Win7) | 5.01(Win7) | 5.90(Win8) |
|---|---|---|---|
| BMP領域 | 2,693 | 2,842 | 3,823 |
| 拡張領域 | 171 | 908 | 1,410 |
| 計 | 2,864 | 3,750 | 5,233 |
8ほどの収録文字数ではないですが、5.01では拡張領域を中心に大幅に追加されています。差分の中身を見ると確かにケータイ絵文字や特殊記号が多いようでした。「古イタリア文字」や「ゴート文字」なんていうのもありました。絵文字は8の全部というわけではなく、追加されてないものも多数ありました。
ただし今のところコメントでは表示できないようです。これはChrome(pepflashplayer)でも同じでした。
フォント変化させてもダメでした。まぁ全部試したわけじゃないんですけど。
ZeroWatchのコメントパネルには表示されてました。
8ではこれまで見てきた通り、ちゃんと表示されます。
もっとも、これは7のコメントでSegoe UI Symbolが使われないということではありません。文字によっては表示されるものもあります。下図は5.00の時からあったグリフで、他のフォントにはありません。
ケータイ絵文字も同じように対応したらおもしろいんですが。
2012年8月12日日曜日
Chrome 21:フォントがおかしい件(ブロック文字について)
さらに前回の続きです。今回もWindows 7での話です。
ちなみにWindows XPではpepflashplayer有効のままだと原宿で動画の再生のみ可能(コメントその他の操作は不可)、ZeroWatchでは再生もできませんでした。他のブラウザに乗り換えるか、pepflashplayerを無効にするしかないでしょう。このため表示の差異の問題は、結果的には影響無いのではないかと思いました。
Windows 8 RPは見た限り7と同じでした。
さて、Chrome 21でブロック文字(U+2588)が縮む例を見ました。しかし特殊文字がなんでも縮むというわけでもないようです。IEやFirefoxとChromeとの間で表示の互換を図ることは、できなくはないかもしれません。
下図はおなじみな感じのコメントです。ブロック文字U+2581~U+2588を使用しています。
Chromeではフォントが変わっちゃってます。でもよく見ると縮んでいるのは一部です。
あらためて両者を比較してみます。
実はArialにはU+2584とU+2588しかありません。この二つだけがArialの縦長の字形で表示され、それ以外は代替表示だと考えられます。先頭のU+2581も縮んでいますが、またArial Unicode MSではないだろうか?ということで、前回のようにArial Unicode MSを削除した後が下図の表示です。
U+2581だけが細い字形に変わりました。MS Pゴシックかなと思いました。
それぞれのU+2581のグリフをBabelMapを使って出力してみました。まぁMS Pゴシックというのはあくまで憶測ですけど。
それ以外の5文字は何でしょうか。
継ぎ目が無いのでこれらも一見縮んでいるように見えますが、SimSunと同じく全角幅です。すき間が無い字形なのでMingLiU(かPMingLiU)かもしれません。下図はIEでのSimSun・PMingLiUの表示と、Chromeでの表示とを比較しているところです。
Segoe UI Symbolにも、サイズは小さいもののMingLiUとそっくりな字形がありました。もしかしたら他のフォントにもあるかもしれません。特定はできません。
いずれにしろ、この5文字については全角幅のままで使えるということです。例えばU+2588をU+2587で代用して、コメント幅が縮むのを回避することならできるかもしれません。
ただしChrome 21ではフォント変化が起こりません。他の文字との組み合わせはさらに検討する必要があります。下図は二つのU+2587の間に、それぞれ全角スペース(U+3000)・ひらがな・漢字を挟んだところを比較しています。
この場合、両者で同じ幅にできるのは全角の漢字を挟んだ一番下のパターンだけです。 なかなか簡単にはいかないですねw
ちなみにWindows XPではpepflashplayer有効のままだと原宿で動画の再生のみ可能(コメントその他の操作は不可)、ZeroWatchでは再生もできませんでした。他のブラウザに乗り換えるか、pepflashplayerを無効にするしかないでしょう。このため表示の差異の問題は、結果的には影響無いのではないかと思いました。
Windows 8 RPは見た限り7と同じでした。
さて、Chrome 21でブロック文字(U+2588)が縮む例を見ました。しかし特殊文字がなんでも縮むというわけでもないようです。IEやFirefoxとChromeとの間で表示の互換を図ることは、できなくはないかもしれません。
下図はおなじみな感じのコメントです。ブロック文字U+2581~U+2588を使用しています。
Chromeではフォントが変わっちゃってます。でもよく見ると縮んでいるのは一部です。
あらためて両者を比較してみます。
実はArialにはU+2584とU+2588しかありません。この二つだけがArialの縦長の字形で表示され、それ以外は代替表示だと考えられます。先頭のU+2581も縮んでいますが、またArial Unicode MSではないだろうか?ということで、前回のようにArial Unicode MSを削除した後が下図の表示です。
U+2581だけが細い字形に変わりました。MS Pゴシックかなと思いました。
それぞれのU+2581のグリフをBabelMapを使って出力してみました。まぁMS Pゴシックというのはあくまで憶測ですけど。
それ以外の5文字は何でしょうか。
継ぎ目が無いのでこれらも一見縮んでいるように見えますが、SimSunと同じく全角幅です。すき間が無い字形なのでMingLiU(かPMingLiU)かもしれません。下図はIEでのSimSun・PMingLiUの表示と、Chromeでの表示とを比較しているところです。
Segoe UI Symbolにも、サイズは小さいもののMingLiUとそっくりな字形がありました。もしかしたら他のフォントにもあるかもしれません。特定はできません。
いずれにしろ、この5文字については全角幅のままで使えるということです。例えばU+2588をU+2587で代用して、コメント幅が縮むのを回避することならできるかもしれません。
ただしChrome 21ではフォント変化が起こりません。他の文字との組み合わせはさらに検討する必要があります。下図は二つのU+2587の間に、それぞれ全角スペース(U+3000)・ひらがな・漢字を挟んだところを比較しています。
この場合、両者で同じ幅にできるのは全角の漢字を挟んだ一番下のパターンだけです。 なかなか簡単にはいかないですねw
登録:
投稿 (Atom)































