2014年2月27日木曜日

CJKフォント変化における前後と隣接

下図はU+2588とU+3042(「あ」)を並べたコメントです。上下とも同じようにU+3042がU+2588によってSimSun化(いわゆる明朝化)しているように見えます。


ところが2文字の間にArialを挟むと結果が変わります。


下段のU+3042はゴシックに戻っています。

CJKフォント変化には3種類あるように思います。

  • 前後の並びによるフォント変化
  • 隣接によるフォント変化
  • 「フォントの連れ回し」

3つ目の具体的な発生条件はわかりません。

上の図においてArialを挟むと上下の結果が異なるのは、この種類の違いなのではないでしょうか。上段のU+2588の効果は前後の並びによるものであるのに対して、下段は隣接によるものではないかということです。
下段のパターンで後ろにもU+3042を置いてみます。


後ろのU+3042は、中段のU+2588に隣接しない状態ではゴシックに戻っています。これは先頭のU+3042の効果であることを下段のコメントが示しています。先頭のU+3042のゴシックが前後の並びで優先されたように見えます。

隣接によるフォント変化の発生は、Windowsコードページの定義の有無に左右されているように思います。
U+2588・U+3042ともにコードページ1250~1258には定義はありません。そしてCJKコードページにはあります。この条件に当てはまる文字で起きるフォント変化を、勝手にCJKフォント変化と呼んでいることは前に書きました。

Unicode cp932 cp936 cp949 cp950
2588 - A880 - A269
3042 82A0 A4A2 AAA2 -

CJKコードページにおける定義の有無について、わかりやすく以下のように考えています。

  • 932(日本語)に定義がある=ゴシック属性
  • 936(簡体字中国語)に定義がある=SimSun属性
  • 949(韓国語)に定義がある=Gulim属性
  • 950(繁体字中国語)に定義がある=MingLiU属性

U+2588との隣接によってU+3042がSimSun化するのは、SimSun属性を持っているからではないか。持っている属性が多いほど隣接によるCJKフォント変化の影響を受けやすい=フォント変化的に弱いということではないかと思います。
上の例のU+2588をMingLiU化文字U+02CDに替えてみます。


上段のU+3042はMingLiU化しますが下段はゴシックのままです。これはU+3042がMingLiU属性を持たないからではないでしょうか。

Unicode cp932 cp936 cp949 cp950
02CD - - - A1C5
3042 82A0 A4A2 AAA2 -

もう一つ別のケースを見てみます。U+2474はU+2588と同じく「SimSun化文字」です。


しかし後ろに「Gulim化文字」U+2661を置くとそれぞれの結果が異なります。


上段は隣接によるGulim化ではないかと思います。U+2588はGulim属性を持っていませんが、U+2474は持っています。

Unicode cp932 cp936 cp949 cp950
2474 - A2C5 A9E7 -
2588 - A880 - A269
2661 - - A2BD -

間にArialを挟めば、このGulim化は起きなくなります。下図は後ろにU+3042を置いて、Arialを挟む前と後のコメントを比較しているところです。


下段では隣接によるGulim化が無効になり、前後の並びによるSimSun化に変わっています。
「フォント変化文字」 という考え方はちょっと違う、みたいなことを前に書きました。要はこのように、前後・隣接・属性の有無による強弱の組み合わせなのではないかという意味です。

もっとも、これでは説明のつかないことがあります。
「ゴシック化(ゴシック保護)文字」U+30FBはcp932にだけ定義があり、フォント変化的には一番強いはずです。しかし後ろにU+2588やU+2661を置いても、ゴシックの字形には変わりません。
おそらくCJKフォント変化とはデフォルトのゴシックとその他のCJKフォントとの遷移なのであって、ゴシック属性とその他のCJK属性は並列ではないのだろうと思います。それが説明できるケースを今のところ思いつかないのですが。

2014年2月24日月曜日

Chrome 33:U+2001も全角幅にならなくなった

前の話の続きです。Chrome特有のフォントの挙動について、他のケースも見てみました。

「Lucida化」 によってArialがTimes New Romanらしき字形に変わる現象も起きなくなっていました。


また、これまでChromeでは合成が起きなかった文字で合成が起きるようになっていました。下図は全角の英字とダイアクリティカルマークU+0301の組み合わせです。


要するに上の2つの例はIEと同じ挙動になっていました。

一方U+2001のケースはU+2588と同様で、全角幅にはならなくなりました。


もっともU+2588とは異なり、これには対処のしようがあります。
Windows XPは間もなくサポートが終了します。StatCounterで国内のシェアを見ても、既に10%を切っています。XPを考慮するのをやめれば、U+200Xの空白文字はIEでArialにしても問題なくなります(XPでは豆腐)。
上のケースもU+2001をArialに隣接させることで、IEの表示幅をChromeに合わせることができるようになります。つまり元のゴシックより少し短くなりますが。

ダイアクリティカルマークを使ったケースで、Chrome 33になっても変化がなかったものもありました。下図はひらがなと合成用半濁点の組み合わせです。


ただし上の図のU+2501を、例えばU+2500に変えても(Lucida Sans Unicodeでなくても)結果は同じでした。この挙動は「Lucida化」とは別の問題だったようです。

フォント変化ではありませんが、書式制御文字による左右反転も変わりないようです。下図はこれを利用してChromeでの幅の縮みを補完する例です。


「Lucida化」と呼んでいた現象はおそらくバグで、それが修正されて起きなくなったんでしょう。この左右反転はIEとChromeどちらが正しい挙動なんですかね。

2014年2月21日金曜日

Chrome 33:U+2588が全角幅にならなくなった

今日Chromeをアップデートしたところ、コメントの表示に変化が見られました。

Chrome 32までは「Lucida化」によりU+2588が全角幅に変わる現象がありました。


これがChrome 33では起きなくなっていました。


元々バグみたいな現象だったので、いずれこうなるのではないかと薄々思っていたのですが。
PepperFlashはちょっとバージョンアップしていました。

上:Chrome 32/下:Chrome 33

他のフォント変化の挙動についてはまだ確認していません。

2014年2月20日木曜日

Excel 2010:フィルターと書式のコピー

シート上の表の書式を新規の別シートへコピーしようとした時のことです。
図はWindows 7上のExcel 2010です。


列幅もコピーしようと列ごと選択したのですが、うっかりフィルターがオンのままやってしまいました。


可視セルの部分しかコピーされず、列幅はコピーされていません。

さて、この後おかしなことに気づきました。コピー先のブックを2003形式(.xls)で保存しようとしたところ互換性チェックで引っかかりました。


図の通り5列×4行しか使用していないのに、256列か65536行を超えていることになっています。
最終セルへ飛んでみると、なぜかシートの最下部付近に同じものがコピーされていました。


どうもフィルターのかけ方に何らかの規則性があるようで、フィルターオンで列ごと書式をコピーしたからと言って必ずこの現象が起きるわけではありませんでした。ただし一見何も起きていないように見える場合でも、最終セルは同じように最下部付近が認識されました(保存すると見た目通りの最終セルへリセット)。

Excel 2003でも試したところ同様で、以前からあった挙動のようです。またExcel 2013でも同様でした。どういう理由なのかはわかりません。

2014年2月9日日曜日

Cyberfox 27:再びXMLパースエラー

Cyberfox 27を日本語化してふつうに使っていたところ、前に書いた「XMLパースエラー」が再び起きて開かなくなってしまいました。

また言語パックが引っかかってるなというのはわかったので、とりあえずセーフモードで起動しました。
アドオンタブを開いてみたところ:


27の言語パックが2つ並んでいます。それぞれの詳細を開いてみると:


上はCyberfoxのページからインストールした言語パック、下は公式の言語パックでした。

実は、26ではWaterfoxを日本語化して使っていました。この時に入れた公式の言語パックが自動更新していたようです。念のため両方削除してCyberfoxの言語パックを入れ直しました。

Cyberfoxの言語パックのファイル名を見ると、開発元の名前が入っています。


以前は公式と同じファイル名で、インストールすると上書きされていた気がします。公式とファイル名が違うので27の言語パックが重複してしまったみたいです。

GINZA:改行コメントの表示が変わるらしい

ニコニコの開発者ブログが久しぶりに更新されてるなと思ったら、おもしろいことが進行していました。

コメントアートが中画面以外のサイズでも再現しやすくなりました! - ニコニコ動画開発者ブログ

なんともありがたい御配慮です。ちょっと見てみました。

下図のコメントはいわゆる「big16行」 のコメントを重ね合わせています。赤以外のコメントは、上下のズレ具合を見るためにそれぞれ別の色を2つ重ねてあります。合計で5コメントです。

上:現行の表示/下:新仕様の表示

中画面では一見変わりはないように見えます(よく見ると幅が少し違います)。
これを大画面に切り替えてみたところ:

上:現行の表示/下:新仕様の表示

新仕様では右に空白部分ができて全体が左へ移動しています。また、下部の隙間も無くなっています。
動画の絵の上で下部にコメントが表示されるようにして見てみました。 まず中画面:

左:現行の表示/右:新仕様の表示

一方、大画面:

左:現行の表示/右:新仕様の表示

上下位置のズレが大きく改善されているのは一目でわかります。行間が広がってるみたいです。
左に移動しているのは左側で位置を合わせようとしているんでしょうか。 フルスクリーンでも同様でした。

ちょっと気になるのは、「二重リサイズ固定を多用したコメントアート等」が崩れるとされている点です。

2014/3/11追記:
以下の問題はとりあえず回避された?ようです。→続き

下図は「big10行」のコメントです。冒頭の図と同様に5コメント重ね合わせています。

上:現行の表示/下:新仕様の表示

たしかに新仕様では激しく崩れました。避けられないなら止むを得ないんですかね。

下図はちょっと思いつきで、新仕様で崩れないように「big9行」にしてみたところ。現行の表示では崩れます。

上:新仕様の表示/下:現行の表示

いずれにしてもChromeやWindows 8のフォントの問題をクリアしないと、少なくともWindows上で表示の互換を図ることはできないんですが。とは言え、動画プレーヤーが変わってもこうしてコメントで遊び続けられるのは良かったなと思います。