2012年9月26日水曜日

Chrome 22:U+2009による幅の補完

Chromeが22にバージョンアップしました。Flash Playerのことで言えば、組込みのプラグインは古い方のNPAPI(gcswf32.dll)が消え、PPAPI(pepflashplayer.dll)だけになりました。これで完全に移行したということなんでしょうか。自分で試してる環境ではニコニコは一応pepflashplayerでふつうに視聴できています。

それより今日気になったのは、突然の「ニコニコ新バージョン」というニュースでした。
ZeroWatchは本来いいもののはずだと思っています。プレーヤーを再読み込みせずに動画を移動できるのは、画期的な仕様です。しかし重すぎるのとUIの使い勝手が悪すぎたのとで、これだけ不評を買ったんじゃないでしょうか。だからバージョン2的なものが開発されてるんじゃないかと期待してたのですが・・・まさか全然別のものが出てきたりしないですよね?

さて、前回書いた話の続きです。
以前U+2001がフォントによって幅が変わるという話を書きました→この日記
ここでArialとかゴシックとか言っているのはあくまで推測なのですが、とりあえずそういうことにしておきます。U+200Xはゴシックの方がArialより少し幅が広いようです。ところがU+2009だけ、なぜかArialの方が広いことに気づきました。


上の図の空白部分はU+2009を10個並べてあります。
IEでは空白部分に直接接する文字をU+30FB(「ゴシック化」文字)と半角の「a」とで入れ替え、U+2009のフォント状態をそれぞれゴシック(上段)・Arial(下段)に変化させています。ChromeのU+2009はArialだと思われます。
(ゴシック化にカギカッコをつける理由はいつか別の機会に書きたいと思います)
ゴシックとArialの幅の差を、Chromeで縮む幅の補完に使えないだろうか?

シャープ記号のU+266FはIEでゴシック、ChromeではArialで表示されます。文字幅にかなり差があります。


U+266FもU+30FBと同様「ゴシック化」文字なので、これに接したU+2009もIEではゴシックだと考えられます。
これでU+2009をはさんでみたところ、U+2009を20個にしたところで全体のコメント幅に差がなくなりました。



20個も空白文字を並べるのが実用的かっていう疑問はありますがwちなみにWindows 8でも同じでした。
Windows XPでは使えません。XPのArialにU+200Xは無いからです。Lucida Sans Unicodeにはあったので、それが表示されているのかなと思いました。



少なくともArialとは幅が違うようです。

XPはいずれ考慮の必要がなくなるでしょうが、悩ましいのがArial Unicode MSです。
星マークのU+2606はやはりIEとChromeで幅が異なります。こちらではU+2009が7個でコメント幅がそろいました(U+2606に接したU+2009は、IEではやはりゴシックのはずです。説明は長くなるので省きますが)。



ただし上の図でChromeが表示しているU+2606はArial Unicode MSです。Arial Unicode MSが無い場合U+2606はゴシックと同じ字形で表示され、コメント幅がIEより広くなってしまいます。


仮にこの手が使えるとしても、何の文字の調整に使うのかが問題です。
実はArialやその代替に使われる(と自分が勝手に推測している)Lucida Sans Unicodeは、それほど特殊文字を持っていません。Arial Unicode MSで表示されるものがかなり多いです。Arial Unicode MSがどの程度インストールされているものなのか、わかるといいんですが。

2012年9月23日日曜日

Chrome 21:合成用文字による幅の補完(1)

こういう方法もあるかもという話です。
Windows 7で見ただけで、よく検証したわけではありません(XPではたぶん無理?)。

下図は大文字のAの後ろに合成用文字U+0304というのをつけて入力したところです。IEとChromeいずれもU+0304はAに合成されています。形としてはChromeの方が正しいんでしょうか。


これが文字の組み合わせによっては、IEでは合成されるのにChromeでは合成されないケースもあることに気づきました。

下図はその例です。全角の大文字CをU+2587で挟んでいます。CはIEではSimSun化され、Chromeでは何も起こらずゴシックで表示されます。SimSunの全角幅のCに対して、ゴシックのCは少し幅が縮みます。
下段のコメントでは、このCにU+0301という合成用文字をつけています。


IEではCとU+0301は合成され、上下のコメント幅に差はありません。ところがChromeでは合成が起こらず、その分下段のコメント幅が長くなっています。これを利用できないだろうか。
※ちなみにIEではゴシックだった場合も合成は起こります。

下図も上と同様、U+0301をつけた場合とつけない場合とを比較しているところです。


見た目がちょっとアレですけど、あくまでコメント幅の実験なので(^ω^;)下図は2つの図を重ねてみたところ。


U+0301をつけた方はIEとChromeでほぼ同じくらいの幅になりました。

ほんとは特殊文字でこれをやりたかったのですが、豆腐になるものが多くて使えそうな組み合わせを見つけられませんでした。 ただ合成用文字はたくさんあるので、うまいこといく場合もあるのかもしれません。

2012年9月18日火曜日

Excel 2010:未登録のアドインもカウント

VBAのコードを書いたブックをアドイン形式(.xlam)にする場合があります。
メリットとしてはシートをユーザーが表示できないという点です。.xlsm形式で全てのシートをxlSheetVeryHiddenにするということはできません。また、ウィンドウを非表示にしてもユーザーが再表示できてしまいます。
ただし.xlam形式だとちょっと不便な時もあります。

今、.xlam形式と.xlsm形式のファイルを1つずつ開いているとします。


ここで以下のようなコードを実行するとxlsmの方だけが捕捉されます。

Dim wb As Workbook
    For Each wb In Application.Workbooks
        Debug.Print wb.Name
    Next


Workbooks.Countは1です。.xlamもWorkbooksで直接名前を指定すると捕まえられるので、いまいち腑に落ちないんですが。


WorkbooksがダメならAddinsかと思うと、こちらは登録されているアドインだけが対象です。ただ開いただけの.xlamは無視されてしまいます。Addins.Countは5です。

Dim A As AddIn
    For Each A In Application.AddIns
        Debug.Print A.Name
    Next



最近になって気づいたのですが、いつの間にかAddins2というコレクションがありました。どうも2010で追加されていたようです。

<参考>New Objects, Collections, and Enumerations_Excel.Dev - MSDN

これだと未登録の.xlamでも開いていれば対象にするらしい。

Dim A As AddIn
    For Each A In Application.AddIns2
        Debug.Print A.Name
    Next


Addins2.Countは6でした。

2003では拡張子の区別がなく、.xlsのままIsAddinをTrueにするなんてこともやりました(いい使い方ではないと思います)。その時に、このFor EachやCountで困ったことがありました。2003でこれがあったら助かったんですけど。
それにしてもこういうのが新たに追加されたということは、.xlamを普通のブックのようにただ開かせるという使い方もけっこうあるんですかね。

2012年9月15日土曜日

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追記:
今はゼロ幅にならないことに気づきました。→この日記

2012年9月9日日曜日

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

2012年9月2日日曜日

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

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


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


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

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

まず1つめの例です。


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


ちょっとアレですけどw
さらに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と同じ幅になったように見えます。

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