2010年09月

前回書いたことの続きです。今度はSimSunの方もいじってみました。

イメージ 1

前から不思議に思っていた、7ではなんで♡(U+2661)を明朝化させると「三」みたいになってしまうのか?SimSunにトランプのマークはありませんので、これもおそらくフォントリンクの設定によるものだろうと思われます。

下図はトランプマーク(U+2660~U+2667)を並べて、上段の明朝化を下段の丸文字化と比較しているところです。3文字めが問題の♡です。

イメージ 2

この「三」みたいなのはMicrosoft Sans Serifにあるやつではないか?というのは前にも書きました:

イメージ 3

トランプマークの中でなぜか2661だけがこの字形で登録されています。なんでだかは謎です。とりあえずSimSunの設定の一番上にMICROSS.TTF(Microsoft Sans Serif)がありますので、これを削除してみます。

ちなみにMICROSS.TTFがパラメータ有りのものと無しのもの二つ登録されています。このパラメータの意味はよくわかりませんでした。幅とか縦横の縮尺とかに関係あるのかもしれません。ここでは趣旨に関係ないので無視して両方削除しました。

イメージ 4

「三」みたいだったのがちゃんと表示されました。その他のトランプマークは変更前と同じようです。
じゃあこれは何かってことですが、次のPMingLiUにはトランプマークが無いのでその次のMS PMincho(MS P明朝)であろうと思われます。

イメージ 5

初期の設定では、フォントリンクの一番上のMicrosoft Sans Serifに2661のみあったためそれが表示され、他のマークは次にグリフがあったMS P明朝のものが表示されていた、ってことではないでしょうか。MS P明朝は2660から2667まで全てグリフがあります。

では試しにこのMS P明朝も削除してみます。

イメージ 6

明朝化の方のトランプマーク全体が丸文字化の方にそっくりな表示に変わりました。
これはフォントリンクの最後にある、Batang(Gulimと同じく韓国語フォント)ではないかと思われます。

イメージ 7

そっくりですが、よく見ると微妙にデザインが違いますね。

ところで明朝化の方で、今度は4文字めのダイヤが透明になっちゃってます。Batangにこのダイヤ(U+2662)だけ無いからでしょう。これはGulimも同様で、前に書いた話です→この日記
Gulimにも無いのに丸文字化の方で表示されているのは、おそらくGulimのフォントリンクにあるMS UI Gothicのダイヤマークなんだろうと思います。

Batang自体にもフォントリンクの設定はあって、そこにMS P明朝が登録されてはいます。が、ここではそのダイヤマークは表示されていません。フォントリンクはあくまで初期のフォント(この場合SimSun)の設定の中で代替のグリフがないか探すのであって、SimSunの設定にあるBatangからBatang自体のフォントリンクの設定に飛ぶ、ということはしないんだそうです。
なので、この結果で合ってるのかなぁと。まあ、とにかくちょっとすっきりしました。


前にも紹介させていただきましたが、いつもお世話になっています:
WpfFontViewer フォントビューア(Vector)

先日、oztoさんが投稿なさっていた記事がとても興味深かったです→気ままにニコライフ
Vistaや7の場合、XPと違って一つのコメントに明朝化と丸文字化が混在できないってところがポイントだと思いますけど、こうして見ると実にややこしいっすねw
(と言うか、wikiの方の説明がまたすごいです。よくもここまで整理なさったもんですねー)

ところでその記事の本題とはズレるのですが、ふと思ったことです。
たしかに7では「明朝化文字の丸文字化」が起こります。でもこれ、ほんとに「丸文字」と言えるんだろうか。ブロック文字の█(U+2588)はGulimのフォントにも含まれています。含まれていない明朝化系の文字はどうなってんだろう、ということであらためて見てみました(この例はU+3105~3109)↓

イメージ 1

上の段が♡(U+2661)を先頭に置くことで丸文字化させている状態です。中の5文字が、下の段の明朝化の表示とくらべてなんか丸文字っぽくなっとりますね。が、そもそもこれらのグリフはGulimなどの韓国語系フォントには含まれていないようです。じゃあこれ何よ、ってことですが:

イメージ 2

上の図は、U+3106の書体が特徴的なのでSimSunと比べているところです。どうもPMingLiU(またはMingLiU)っぽい。フォントリンクにあるだろうか?とレジストリを見てみました↓
※クラシックなウィンドウになってますがOSは7です。高速化のため半透明をオフにして使ってます。

イメージ 3

Gulimのところにいくつかフォント名が並んでいます。
そのフォントに該当するグリフがない場合、フォントリンクでは登録されているこれらのフォントの上から順番に代わりのグリフがないか探していく仕掛けだそうです。

XPだとここにGulimの設定なんてありません。代替表示には他の仕組みが使われてるのかユーザには不可視になってるのか?7ではGulimもここで変えられるようです。試しに一番下にあるSimSunをPMingLiUより上に変更してみました。実行結果↓
※レジストリをいじるのは大変危険な行為です。良い子はマネしないでね!

イメージ 4

ビンゴのようで、丸文字化でも明朝化と同じ書体で表示されました。おぉこういうことだったのか。
もう一つ、ついでに実験です。U+2588はGulimにもあると書きましたが、お隣のU+2587はありません。実際にコメントしてみると下図のようになります:

イメージ 5

2587の丸文字化状態はやけに幅が縮んでいます。何かというのは、上のレジストリの設定から容易に推測できます。MS UI Gothicですね:

イメージ 6

これもレジストリを変更して試してみました。やはり丸文字化と明朝化は同じ表示になりました:

イメージ 7

そう言えば7をいじり始めたころ、これMS Pゴシックかなぁ?と書いたことがありました→この日記
上の通り正しくはUIゴシックでした。すみません<(_ _)>

というわけで「明朝化文字を丸文字化」させるとフォントはGulimが選択されるけど、グリフが無いものはこうして中国語フォントや日本語フォントが表示されてるということでした。仮にSimSunにしかグリフがない明朝化文字があったら、丸文字化でも明朝化でも同じものが表示される?・・・そんな文字はなさそうですが。

ちなみにこうやって複数のフォント化けをいっぱい試していたら、♡がお豆腐になったりブロック文字が透明化したりする気持ち悪~い挙動に遭遇しました。そんなの初めて見ました。Arial化け?
こ、こえー(^ω^;)

フォントの切り替えというのはその分PC的に負荷がかかる動作だと思われます。
複数のフォント化けはあんまり多用しない方が安全でしょうね。てか自分が気をつけねばw

最近、メインで使っていたXPのPCが逝ってしまいました。たぶんHDDダメっぽい(TωT)
原因にいちおう心当たりはあるんですが・・・まあ確証はないので略。
とにかく修理してもらうまでは、サブでもろもろの実験用にしていた7のマシンを使っとります。その7で遊んでたらちょっと気づいたので。

以前、タイ文字がどうのという話のときにフォントはTahomaだと書きました(XPでは)。レジストリのSystemLinkでTahomaをいじったら化け方がその通りに変わったし、まあそうなんだろうと思ってました。
ただ気になってたのが、7ではタイ文字の書体がXPと違うこと。フォントのバージョンの違いじゃね?とかテキトーに思ってたのですが、メモ帳を利用してあらためて見てみました↓

イメージ 1

明らかにTahomaの書体じゃないですね。他のフォントでも見てみたのですが↓

イメージ 2

どうもArial Unicode MSが同じっぽい。ただしニコニコマーク(U+263A)はArialのデザインですね。

イメージ 3

ちなみに上はDokChampaというVistaから搭載されたフォントです。ラオス語・タイ語のフォントらしい。
これにニコニコマークは含まれていないようですが、代替で表示されてるのがゴシックと同じデザインです。そしてタイ文字の書体はArial Unicode MSと同じ。結果的に実際のコメントとよく似た感じになりました。
たまたま?なのかなあ。

なんにしろ7でのフォントの変化は、やはりXPより複雑だなということだけはわかります。それだけ代替表示の機能が強化されてるってことなんでしょう。
タイ文字化けをCAに使うことはありませんが(XPと表示が違いすぎるので)、他にもまだ気づいていないケースがなにやらありそうです。明朝化けのハートマークが「三」みたいになるのも、おかしなところにあったし。
この機会に7と慣れ親しみながら、そのあたりも気にしてみたいと思いますw

区切り位置指定ウィザードはいろいろと便利でよく使うのですが、先日おかしなことがありました。

下図左のようなデータがありました。文字と文字の間には半角スペースが入っています。このA列を選択してウィザードを実行したところ、右のような結果になりました。

イメージ 1

ポイントは1~3行が空なこと。この部分がデータ範囲として認識されず、4行目以降を分割した結果が1行目から出力されてしまいました。ウィザードの「表示先」はデフォルトでA1。出力先としては間違ってないんですけど、上に詰まった分元のデータが下に残ってる・・・こんなことが起こるとはw

1~3行がデータ範囲として認識される場合もあります。例えば1~3行を一度削除してから、その位置に再び3行挿入します。つまり最初の図と見た目は同じ状態。これでやってみると1~3行も範囲として認識され、結果は下図のようにうまくいきます。

イメージ 2

ただしこの削除・挿入の操作後に一度保存してしまうとデータ範囲の認識がリセットされるらしく、冒頭と同じ結果になります。そう言えば前にも似たようなことがありました→この日記

正直今までそんなことは気にしてなかったのですが、空の行を範囲として認識しない場合と認識する場合の違いはちゃんとウィザードのプレビューに表示されていました。

イメージ 3

認識していない場合プレビューに1~3行は表示されません。
なので、この場合はウィザードの最後の画面で「表示先」をA1からA4に変えて実行すれば問題ないのですが:

イメージ 4

見た目は同じ状態からやってるのに動作が変わるって・・・なんか納得いかない。
っていうか、だったら「表示先」も自動でA4に変えろと(^ω^;)
ちなみにこの挙動に気づいたのは2003でしたが2007・2010でも同じでした(図は2010)。

先日書いたことのつづきっていうか補足っていうかです→この日記

XPではU+200X系の空白文字は半角文字に隣接したり単独だったりすると化けちゃいますが、7(Vistaも?)では表示されます。でもゴシックや明朝・丸文字化けで表示されるものとは幅が違うみたいでした。
前の日記では2004・2005・2006の様子を見てみましたが、コメントでもっとよく使われている(と思われる)2001はそもそもどうなのかをあらためて確認。

下図は3文字めがU+2001です。上と下で1文字めと2文字めを入れ替えているのは、フォントを変化させるためです。すでに微妙に幅の違いが現れています。

イメージ 1

下図右は、わかりやすくするためU+2001を10個にしてみたところです。
上の段は「a」に隣接することでArial、下の段は「あ」に隣接することでゴシックになっていると思われます。Arialの方が少し短いようですね。

イメージ 2

ちなみに図の右は上下とも最後に「あ」を足したところです。
こうすると「あ」に隣接している効果によりどちらもゴシックとなり幅は同じです。200Xを全角・半角文字と並べて使うなら、こうした挙動を理解してないといけないのか。

とは言っても、Arialの方が短いとか今のところは無駄な検証です・・・XPでは上の段はお豆腐になりますので。XPでニコニコ見てる人は当分いるでしょうからねー
後ろに「あ」をつければ7と同じ状態になります(下図右)。

イメージ 3

こうして見ると、200X系は使わない方がいいのかなとも思ってしまいます。
でも下の段の状態にしておけば7でもXPでもだいじょうぶっぽいわけなので、そうとも言えないかなと。いろんな幅の空白文字を使える方が便利だし。

下図はいちおう各フォントで幅を見てみたところです。
上からArial・ゴシック・明朝・丸文字(と思われる状態)です。明朝・丸文字でまた幅が違うのが面白いですね。これはなんなんだろう。※「At」とか「・・」は、「ㄅ」や「♡」と幅を合わせているだけで深い意味はありません。

イメージ 4

XPでゴシックと明朝の幅が一致していますが、明朝の方には違う幅の200Xを置いても同じ結果になります。というか透明になる特殊文字は全部同じ幅になるだろうと思われます。この話は前に書きました。

下図は念のため上の図を重ねてみたところ。ゴシックだけはXPでも7でも同じですね。たぶん。

イメージ 5

↑このページのトップヘ