2012年5月31日木曜日

Excel:カッコを含んだファイル名によるエラーと謎な挙動

スラッシュや円記号などWindowsでファイル名に使えない文字というのがあります。
それとは別に、Excel固有の「使ったらまずい」という文字もあります。ファイル名に使うことはできるんですが:

Excel のファイル名にカッコなどの記号を含むとエラーメッセージが表示される - Microsoftサポート

例えばユーザー定義関数を含んだ「FileName(TEST).xlsm」という名前のファイルがあるとします。
関数の名前は「テスト」 で、他のブックから呼び出そうとするとします。


ブックの名前はシングルクォーテーションで囲まれていて一見問題ないように見えます。
しかしこのまま挿入すると「入力した名前は正しくありません」というエラーになります。


手動で入力すれば通るんですけど、「関数の挿入」では丸括弧で引っかかってしまうようです。

さて、 このカッコを含んだファイル名でおかしな挙動に気づきました。
上の例と同じく丸括弧を含んだ「FileName(TEST).xlsx」というファイルと、やはり非推奨の角括弧を含んだ「FileName[TEST].xlsx」というファイルがあるとします。丸括弧の方を開いてから角括弧の方を開いても何も起こりませんが、角括弧の方を開いてから丸括弧の方を開こうとするとエラーになります。


問題回避のためなのか、どうもExcelがファイル名の角括弧を丸括弧に置き換えようとするようです。

両方のファイルを開いたとします。それぞれアクティブなシートのセルA1に「角括弧」「丸括弧」という文字列を入れてあります。もう一つ別のブックから角括弧のA1を参照しようとすると、ブックの名前が丸括弧に置換されてしまうのです。


そして参照するのは丸括弧の方になります。って、なんじゃそりゃー

丸括弧の方は閉じて同じことをやってみます。


こうしても名前は丸括弧に置換されてしまいますが、今度は開いている角括弧の方を参照します。
角括弧も閉じて、どちらもフルパスで外部参照になっているところ:


角括弧の方の参照は()ではなく[]になりました。妙なことが起こりますね。

ただし角括弧の方は、これ以降は不正な参照先として認識されてしまいます。
セルを編集しようとすると「このワークシートの数式に、1つまたは複数の無効な参照が含まれています」というエラーになります。また一度保存して閉じてから再び開こうとすると、「読み取れない内容が含まれています」というエラーになり、リンクが削除されて「角括弧」という文字列に置き換えられてしまいます。

そう言えば知らなかったのですが、こういうエラーもあるそうです:

Excel のファイル名に全角の引用符 (") が含まれるとダブルクリックでファイルを開くことができない - Microsoftサポート

確かに開けませんでした。
まあ角括弧だの全角引用符だの、ふつうファイル名に使うとは思いませんけど・・・Excelの使い方って人によってほんと千差万別なので、こういうこともあるんだと覚えておこうと思いました。

2012年5月27日日曜日

縮む三角(U+25E2~U+25E5)

下図のコメントは改行を利用して「S」の字を作ったところです(サイズはsmall)。
使っている文字は三角がU+25E2~U+25E5、四角がU+2588です。これらはいずれもSimSun化文字で、文字自体もSimSunで表示されていると思われます。


7とXPではだいぶ表示が異なります。7の方で特に三角が縮んでるのが目につきます。
これをZeroWatchで見ると、三角の縮みがそれほどでもなくなります。ただしZeroWatchの特性というわけではありません。


右図の通り、原宿でブラウザのズームを使っても同様の表示になります。拡大縮小の問題のようです。
ドットは四角だから、三角の斜辺部分は拡縮すると影響が出やすいということでしょうか。U+2588の方もよく見ると継ぎ目の出方に差がありますが、三角ほどは目立ちません。

ちなみにZeroWatchには原宿と同サイズにする「中画面」というモードもあります。


原宿と同様の表示になりました。通常の画面のままズームで縮小するとXPで異変が起きたのですが:


描画の問題なので、ちょっと素人には仕組みを調べようがありませんwただ、こんなふうに継ぎ目なく表示されるのが一番きれいです。
フォントを変えればできなくもないです。下図は各行をMingLiU化したところです。


SimSunと何が違うのか、それぞれの字形を見てみました。下記のサイトを利用させていただきました。

Font Viewer - myFontbook.com


SimSunは枠とのすき間が多いのに対して、MingLiU(PMingLiU)は枠いっぱいのデザインになっています。特に三角は差が大きい。きっとこの違いなんだろうなと思いました。

GulimもU+2588はやはり枠いっぱいのデザインで継ぎ目をなくせるのですが、三角のグリフは持っていないので代替表示が起きてしまいます。


ここではフォントリンクでMS UI Gothicが表示されていると思われます(Microsoft Sans Serifに三角が無いため)。MS UI Gothicの三角はSimSun以上に小さいですね。


なお上の例はXPでの表示を全く考慮していません。MingLiUの問題は以前に書いた通りです。

2012年5月21日月曜日

Excel:イミディエイトウィンドウでコピペができなくなる件

先日ふと気づいたら、VBEのイミディエイトウィンドウでコピペができなくなってました。
右クリックメニューの「切り取り」「コピー」 「貼り付け」がグレーアウトしていて、Ctrl + X・C・Vも使えませんでした。試しているうちに、プロジェクトがロックされているブックがアクティブだとそうなることがわかりました。

マクロ有効ブックBook1・Book2を開いているとして、Book2はプロジェクトをロックしてあるとします。
Book1の方がアクティブであれば問題ないのですが:


Book2の方がアクティブだとイミディエイトウィンドウでコピペ(切り取りも)ができなくなります。
入力・消去はふつうにできます:


前からそうだったけ?と思って2003でも試してみたら同様でした。イミディエイトウィンドウは頻繁に使うので、今まで気づかなかったのか不思議です。
っていうか、どうしてこういう仕様なんでしょう。調べてもわかりませんでした。

2012年5月17日木曜日

Windows 8 CP:4つめのU+2001

下図は、キリル文字U+0460の字形がフォントによってかなり違うことを示しています。


デフォルトはArialで、「a」(半角英数字)に隣接してもこれは変わりません。
「◯(U+25EF)」は「ゴシック化」文字で、これに隣接するとMS Pゴシックの字形に変化しています。「☉(U+2609)」はSimSun化文字ですが、SimSunにU+0460はありません。ここではフォントリンクにより、Microsoft Sans Serifが代替で表示されているのだと思います。


上のケースを踏まえて本題です。
全角幅の空白文字U+2001も上のU+0460と同じような挙動をとります。ただしWindows XPと7とではフォントが変化した結果が異なります。
下図の空白部分はU+2001を10個並べています。先頭の2文字のうち、フォント変化に直接かかわるのはU+2001に隣接する2文字めだと考えられます。1文字めは各コメントの条件を同じにするためのもので、U+2001が同じ幅であればコメント全体の幅も同じになるはずです。


XPのArialにはU+2001が無く、豆腐になっています。7のArialにはU+2001があります。
MS PゴシックはXP・7ともにU+2001があり、どちらも同じように表示されています。
「◯」と「a」を入れ替えただけの二つのコメントは、U+2001に隣接する文字の違いによりフォントが変わっています。7でコメント幅が少し違うのは、ArialとゴシックのU+2001の幅に差があるということではないでしょうか。
先頭に「ゴシック化」文字があったら、U+2001はゴシックじゃないのと思われるかもしれません。しかしそれはデフォルトがCJKフォントで表示される文字の場合で、U+2001のデフォルトは冒頭のU+0460同様Arialだと思います。

SimSunはXPも7もU+2001がありません。7の方はU+0460のケースと同じくMicrosoft Sans Serifだと思われます。一方のXPはMicrosoft Sans SerifにもU+2001はありません(というかSimSunのフォントリンク自体がなく、代替表示は内部的な処理で行われるようです)。
では別のフォントかと言うと、おそらくそうではありません。U+2001を他のU+200Xの空白文字と置き換えても、全角幅のまま変わらないからです。U+200Xの空白文字は文字によって幅が異なります。

スペース ‐ 通信用語の基礎知識

様々な幅ができた経緯は調べてもわかりませんでしたが、組版などで利用されるらしいです。

XPでの空白部分は何かのU+2001なのではなく、「表示できるものがない」という意味での全角幅の空白であると考えられます。このことに気づいたのは2年前でした。まとめると以下の通りです。


Windows XP Windows 7
 Arial  なし→豆腐   あり 
 MS Pゴシック  あり   あり 
 SimSun  なし→全角幅の空白   なし→Microsoft Sans Serif 
(Microsoft Sans Serif)  なし   あり 

7では図の通り幅がそれぞれ違います。つまり同じU+2001でも3種類あると言えます。
なお7のGulim化・MingLiU化についても、SimSun化と同じくフォントリンクでMicrosoft Sans Serifとなります。

ところがWindows 8CPで想定外の表示がありました。


SimSun化の幅が7よりずっと短くなっています。
しかも隣接させるSimSun化文字によっては、7と同じになります。


これまで見てきたWindows 8での表示からすると、幅が短い方のU+2001はSegoe UI Symbolかもしれません。Windows 8CPのフォントリンクは7とほとんど同じですが、なぜかフォントリンクより優先してSegoe UI Symbol(と思われる字形)が代替表示される場合があります。
下図はSimSunには無いU+263Aの代替表示の様子です。7の方はフォントリンクでMS P明朝が表示されていると思われます。



これだけで断定はできないですけど。
いずれにしろ、現時点では4つめ(の幅)のU+2001が存在しているようです。RP版でも変わらないだろうか。

2012年5月4日金曜日

U+200BとU+200C

ZeroWatchの修正が早速来ていました。

ZeroWatch修正、設定の追加やチューニングなど - ニコニコ動画開発者ブログ

やはりコメント入力については要望が多かったようで、「常にコメント入力フォームをプレーヤー下に表示」 というオプションが追加されていました。


改行の入力もできるようになっていました(Ctrl+「.」)。しかしおそらく想定されていたとは言え、開発なさっている方々はGWだというのに大変ですね・・・UIを一新するという試み自体はいいことだなと思うので、フィードバックを活かしながらさらに改良を進めてくださることを期待したいです。
ちなみに新たな入力フォームでAlt+「160」(U+00A0)単独での入力はエラーになりました。まぁそんなことしてるのは自分だけかもしれませんが。
追記:
その後Alt+「160」(U+00A0)単独で入力できることを確認しています。プレーヤーの修正と関係あるのか、この時はコメント自体が弾かれただけだったのかはわかりません。

さて前々回の日記の中で、U+200C(ゼロ幅文字)を使ってフォント変化文字の隣接による影響を無効にする例を紹介しました。これについて、「U+200B(同じくゼロ幅)じゃダメなのか?」というツッコミをいただきました。
ゼロ幅文字と言えばなぜかU+200Cをいつも使っていたので、考えたこともありませんでした。今さらながら確かめてみました(オワニン開さんご指摘ありがとうございました)。

今度はGulim化で見てみます。SimSun化でも同じはずです。


上図の「a」をゼロ幅文字に置き換えてみます。
コードポイントU+200Xの並びには、5つのゼロ幅文字があります:

  • U+200B    Zero Width Space
  • U+200C    Zero Width Non-Joiner
  • U+200D    Zero Width Joiner
  • U+200E    Left-To-Right Mark
  • U+200F    Right-To-Left Mark

それぞれ別の名前がついているのは機能の違いを示していますが、ここでそのことは関係ないと思われます。下図が実際に置き換えてみたところ:


U+200Bだけダメですねwこれは知りませんでした。
U+200Bと他とは何が違うんでしょうか。少なくともコードページの定義には違いがありました。

Unicode cp1250 cp1251 cp1252 cp1253 cp1254 cp1255 cp1256 cp1257 cp1258
200B - - - - - - - - -
200C - - - - - - 9D - -
200D - - - - - - 9E - -
200E - - - - - FD FD - -
200F - - - - - FE FE - -

1255はヘブライ語・1256はアラビア語です。U+200Bだけどちらにも定義がありません。
なおCJKコードページにはいずれの文字も定義はありません。

自分が勝手に言ってることですが、ニコニコプレーヤーの既定のフォントはArialであり、ArialがサポートするWindowsコードページに定義がある文字はそのままArialで表示されていると思われます。

Code Pages Supported by Windows - MSDN

Arial - Version 5.05 - Microsoft typography

そしてArialで表示されている文字は、冒頭の図の「a」のように隣接の影響を無効にします。U+200Bだけダメなのは、そういうことじゃないのかなと思いました。

じゃあU+200Bのフォントはなんなのか・・・は、長くなるので割愛します。調べてみたものの特定はできませんでした。さしあたり実用的な意味では上の結果だけわかればいいですよね^^;

本題とまったく関係ないんですけど、この件を調べてておもしろいものを見ました。
Windows 7でarialbd.ttf(Arialの太字)を無効にしたところ、英字が斜体になりました。


Arialが太字らしいことはわかってたのでどうなるんだろと思ったのですが、こういう挙動をとるとは。

2012年5月1日火曜日

ZeroWatchで見てみた

事前の告知通り、ニコニコは今日からプレミアム会員のみを対象に新バージョンZeroがリリースされました。
新しい動画視聴ページ・ZeroWatchは、ずいぶん大胆に変えたなーという印象です。動画に集中しやすいようなシンプルなデザインや話題の「ニコる」機能など、いろいろ考えられてるなとは思いました。
まだ公開されたばかりでこれから仕様の変更や修正はいろいろあるんでしょうが、とりあえずコメント機能に限って気づいたこと。

コメント入力欄が画面の中に表示されるのは賛否ありそうです。いや、否が圧倒的・・・?


他のコメントの中に自分もコメントする、みたいな一体感を狙ったんでしょうか。だとしたらアイディアはいいかなと思いましたが、正直不自然だし使いづらいw
それと改行の入力(Alt+「10」およびCtrl+「.」)は現時点ではできませんでした。ただCtrl+「.」というコマンドも後からわざわざ追加されたものなので、いずれは実装されるのかもしれないですね。Alt+「160」(U+00A0)は入力できました。

5/4追記:
上の件については、「常にコメント入力フォームをプレーヤー下に表示」というオプションが追加されました。 また改行の入力も実装されました。

前回の日記でも書いたように、コメントのサイズはやはり既存のプレーヤーをズーム125%にした状態と同じように見えます(いつもFirefoxで見てますが、これはChromeでやりました)。上下のズレ方も少し見た限りでは同じようでした。
下図は、いわゆる二重リサイズ・big10行(上下固定)のコメント表示を比較しているところです。
※既存のプレーヤーの画面は4:3です。そのことはここでは特に関係ありません。
 

全く同じかはわかりませんが、ズームした時と似たようなズレ方をしてました。
また、下図はshita smallのコメントを積み上げてみたところ。既存のプレーヤーだと17文字目は入り切らずに弾幕モードで浮いてしまいますが、Zeroでは入り切ってしまいました。


これは既存のプレーヤーを125%にしても同様でした。ふだんそんなことしないので知りませんでしたがw

と言う訳で、これまでのCA全体がぐっちゃぐちゃになるような事態ではないみたいです。しかしコメントによっては上のようなズレで影響を受けます・・・まあ、これは今までもあったことですけど。自分自身、今のモニターではプレーヤーが小さすぎるのでいつもズームして見てます。近眼だし。

それよりこのプレーヤー、新機能が追加されてるだけにたぶん重いです。つい最近それなりのスペックのPCに換えたばかりで個人的にはそれほど感じません。でも動画を見てると、「重い」というコメントを見かけます。これだけデザインを一新してしまった以上、改善されるとしても限界があるかもしれません。
改行や弾幕など再生への負荷が高そうなコメントは、これまで以上に配慮が必要とされるのかなと思いました。