2011年09月

以前の話の補足です。

CJKコードページにおける定義の有無が、フォント変化の挙動と関係あるらしいと書きました。その際に参照したのが、ユニコードコンソーシアムが公開しているcpXXX to Unicode tableというコードページとユニコードの対応表でした(→cpXXX to Unicode table)。
ところでフォント変化文字は私用領域(U+E000~U+F8FF)にもあることが知られていますが、cpXXX to Unicode tableには私用領域が含まれていません。

他で定義があるんだろうなと思ったら、もう一種類の対応表がありました:


これらがcpXXX to Unicode tableと何が違うのか、いちおう解説があるのですが→readme
読んでみてもようわかりませんw(英語だし)
おそらく、そのコードページで未定義の文字は定義がある他の文字で代替するようにして、cpXXX to Unicode tableを拡張したものかな?と思いました。

下図はCJKのcpXXX to Unicode tableを、このWindowsBestFitと並べてみたところです。
CP932にのみ定義があるもの(=ゴシック化文字)で絞り込みを行っています。

イメージ 1

例えばU+3232(丸カッコつきの「有」)のWindowsBestFitの方を見てみると、CP932以外にも定義があります。これらはいずれもU+6709(ふつうの「有」)のことです。つまり日本語以外では定義が無い丸カッコつきの「有」は、ふつうの「有」で代替するということのようです。

もちろんニコニコのコメントでそのような挙動は起こりません。SimSun化に対してもGulim化に対してもU+3232はMS Pゴシックで表示され、ゴシック化文字としてふるまいます。
ちなみに、その次のU+3239(丸カッコつきの「代」)も同様です。WindowsBestFitの936・949・950で定義されているのはU+4EE3(ふつうの「代」)です。

さてこのWindowsBestFitですが、cpXXX to Unicode tableには無かった私用領域の定義があります。調べてみたところ、私用領域のフォント変化についてはどうもこれが関係ありそうでした。

イメージ 2

はじめの方は4つとも定義がありますが、途中で949の定義が終わるところがあります。

イメージ 3

定義があるU+E0BBと定義が無いU+E0BCのフォント変化に違いがあるか、以前と同じやり方で見てみました。表示はWindows 7です。

イメージ 4

4つとも定義があるU+E0BBはパターン4、949だけ定義が無いU+E0BCはパターン3と同じ挙動でした(→パターン3・パターン4)。

さらに先を見ると、932の定義が終わるところがあります。

イメージ 5

上と同様にU+E757とU+E758を比較したみたところ:

イメージ 6

936・950にだけ定義があるU+E758はパターン2の挙動です(→パターン2)。

さらに先では936が終わり、定義があるのが950だけになります。

イメージ 7

U+E864とU+E865を比較してみたところ:

イメージ 8

950にだけ定義があるU+E865はパターン1の挙動、すなわちMingLiU化文字です(→パターン1

ちなみにU+E864は見慣れない字形で表示されています。XPのSimSunには無いのですが、バージョンアップでこの辺に字形が割り当てられているようです。

イメージ 9

MingLiU(またはPMingLiU)には字形が無いので、フォントリンクでSimSunのU+E864が表示されているのだと思います。

さらに先を見ると950の定義が終わるところがあります。

イメージ 10

U+F848とU+F849を比較してみたところ:

イメージ 11

4つとも定義が無いU+F849は、フォント変化に影響を及ぼさないと考えられます。「あ」の状態は2文字めのフォント変化文字に従っています。

ただしブロックの最後の方にちょっと謎な部分がありました。

イメージ 12

定義がバラバラにありますが、試してみてもフォント変化に影響は無いようでした。
というか、定義にある「00ff」などはcpXXX to Unicode tableの方では「UNDEFINED」となっておりユニコードとは対応付けられていないものでした。これらが何なのかはわかりません。

といちおう調べてみましたが、実際のコメントで私用領域の文字を使うのはあまりお勧めできません。
例えば上で見たU+E864は、XPでは字形が無いため全角幅の透明スペースが表示されました。もし透明だと思って使ったら7では先の字形が表示されてしまいます。
インストールされているものによってどうなるかわからないので、なるべく避けた方がいいように思います。

前から知られていることらしいのですが、つい先日初めて気づいたので。

下図はExcelのシート上に置いたコマンドボタンです。
このボタンの上でウィンドウを分割すると、片側のペインでクリックしたらもう片側では変な斜線が表示されました。斜線の方はクリックすることができません。

イメージ 1

ウィンドウ枠の固定でも同様でした。
下図はボタンが四分割されるように固定してみたところ。クリックしたペイン以外では斜線が表示されて、クリックできなくなりました。

イメージ 2

なおここでは2003で見てますが、下記のリンク先の回答者の方は2007で再現しておられます:


自分の環境では2007での再現はできませんでした。
その後の更新で解決されたのか、2010も一緒にインストールしているためなのかはわかりませんでした。

その他のコントロールでも試してみました。基本的に同じ結果でした。

イメージ 3

表示するだけのラベルとイメージは斜線が出ませんでした。でも描画がなんか変でした。


OfficeドキュメントでのWindowsフォームコントロールの制限事項(MSDN)
※「OfficeドキュメントでのWindowsフォームコントロールの相違点」内の「コントロールの動作」に記載が。

わざわざ斜線が表示されるということは、不具合というより意図した仕様なのかもしれませんが・・・
新しいウィンドウで開いても同じ現象が見られました。下図は元のウィンドウから新しいウィンドウを三つ開いたところ。一番右が元のウィンドウです。

イメージ 4

三つの新しいウィンドウではボタンをクリックすることができず、元のウィンドウでクリックすると図のように斜線が表示されました。見た目は元の方も新しい方も一緒なので、クリックできないとフリーズしているようにしか見えませんw

前回の補足です。
実際にこういうことをやるとはあんまり思ってないのですが、挙動を確認する実験として見てみたいと思います。

下図は先頭にMingLiU化文字U+02CDを置いたコメントです。Windows 7でMingLiU化しているのと、XPでの表示とを比較しています。
XPではフォント変化が起きないのではなく、MingLiUが表示されない代わりに他のフォントが使われるというのはこれまで書いた通りです。この例ではMS Pゴシックが代替で表示されています。

イメージ 1

漢字はゴシックでも全角幅で、MingLiUと変わりません。かな文字のせいでXPでは7より幅が短いコメントになってしまっています。かな文字も全角幅にしてコメント全体を7と同じ幅にするには、SimSunかGulimにするしかないでしょう。

XPは7・Vistaと異なり、1行に複数のフォントが混在できます。この特性を利用すれば、先頭にMingLiU化文字があっても途中から他のフォントに変化させることが可能です。ただし、単にSimSun化文字やGulim化文字を置けばいいわけではありません。下図は2文字めにSimSun化文字U+3105を置いてみたところです。

イメージ 2

前も書いたように、U+3105はSimSun化文字ですがCP936・CP950いずれにも定義があります(パターン2)。
このためXPでは950化が有効なままで、漢字・かな部分に変化はありません。と言うか、U+3105自体がここではあくまでMingLiUの代替で表示されているだけであって、SimSun化文字ではなくなっていると考えられます。
ちなみに7ではU+3105の字形が変わっていますが、これはMingLiUにもあるからです。

そこで今度はCP936にしか定義がない(パターン1)SimSun化文字U+2609に変えてみます。

イメージ 3

XPでSimSun化が起きました。が、CP950に定義がない文字が隣接したことにより、U+02CDが豆腐になってしまいました。この挙動については前回も見ました。
そこで、ここにCP950に定義がある文字をはさんでみます。先のU+3105を使ってみました。

イメージ 4

XPではU+02CDが同じ字形のまま、U+2609以降がSimSun化しました。コメント全体が7と同じ幅になりました。
たまたまSimSun化文字であるU+3105を使いましたが、これ自体のSimSun化は無効になっています。別にフォント変化文字である必要はありません。ポイントは、
2文字め:CP950に定義があるもの(ただし7・XPで同幅で表示されるもの)。
3文字め:CP950に定義が無いフォント変化文字(ただし7・XPで同幅で表示されるもの)。
下図は、参考までに先頭もU+2609に変えたSimSun化コメントと比較しているところです。幅はみんな同じですね。

イメージ 5

仮にこんなことをほんとにやるとしたら、途中に空白文字をはさんだりするかもしれません(例えばbig10行)。
要注意なのは、全角スペース(U+3000)がMS Pゴシックだと全角幅ではないということです。

イメージ 6

XPの表示の上段は全角スペースをU+2609の前に置いてしまったため、950化でMS Pゴシックとなっています。その分全体の幅が縮んでいる状態です。

さて、同じ理屈でXPでの表示を次はGulimにしてみます。下図はGulim化文字にU+249Cを使ってみたところです。

イメージ 7

この文字はMingLiUに無いので7ではフォントリンクが参照され、MS明朝が表示されています。この幅がGulimと同じなので、結果的にコメント全体の幅は7もXPも同じになっています。
一つ失敗なのは、XPでは「温泉」がゴシックになってしまっています。これは「温」がCP949に無い文字だからと思われます。Gulimの場合このような漢字のフォント変化解除文字がけっこうあるので、あまり実用には向かないかもしれません。

なおGulim化にU+2661を使わなかったのは、7ではSimSun化と同様「三」みたいな字形になってしまうからです(フォントリンクのMicrosoft Sans Serifによるもの)。GulimのU+2661は全角幅ですから、XPより短くなってしまっています。

イメージ 8

XPが無くなってしまえば、こんなことを気にせずSimSun・Gulim・MingLiU3種類のフォント変化を使い分けられるかもしれません。でもXPのサポートは2014年まであります。当面はそういうわけにもいかなそうですね。

↑このページのトップヘ