2013年5月29日水曜日

Cyberfoxの日本語化

昨年Waterfoxの更新が滞りがちになった頃、同プロジェクトの掲示板でCyberfoxという新たなFirefoxの非公式64bitビルドの存在を知りました。Waterfoxが18.01で止まっている今ではすっかりメインブラウザとなっています。

Cyberfox | Free software downloads at SourceForge.net

Cyberfoxのいいところは、Waterfoxと同様Firefoxのプロファイルを使うことです。 FirefoxからCyberfoxに移行してもFirerfoxへまた戻っても、ユーザ設定やブックマーク、閲覧履歴などはそのままです。アドオンも変わりません(64bit非対応のアドオンはダメですけど)。
それと、今のところリリースが異様に早いです。Firefoxのバージョンアップに気づいた時には既に更新されています。

使い勝手だけでなく、速さも体感的にはWaterfoxと変わりません。Firefox自体も以前より目に見えて高速になりましたが、やはりニコニコを見てるとこれら64bit版と差を感じます。

配布されているCyberfoxは英語版です。最近、「Cyberfox」でググるとサジェストで「日本語化」と出てくるのに気づきました。Waterfoxと同じように言語パックを入れれば日本語化できます。


about:configで以下の2項目を変更します。
  • general.useragent.locale    en-US→ja-JPに変更
  • intl.accept_languages    en-us, en→ja, en-us, enに変更


後は日本語の言語パックを入れるだけです。言語パックはバージョンアップの度にインストールし直す必要があります。

CyberfoxダウンロードページのFilesタブを開くとLanguage Packsというのが置かれています。ここから日本語の言語パック「ja.xpi」を探してクリックします。一度、リリース直後でまだ置かれていないこともありました。その時はMozillaのサイトでインストールしました。

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest/win32/xpi/

2013/10/5追記:
現在のCyberfoxは公式のja.xpiを入れるとエラーが出て起動しなくなってしまいました。

クリックするとインストールの許可を求めるメッセージが表示されます。「Allow」をクリックしてインストールを実行します。


インストール完了のメッセージが表示されたらCyberfoxを再起動します。


メニューが日本語に変わっています:


なお、言語パックを入れると図のようにアプリケーション名の表記が「Firefox」になってしまいます。これを変えるアドオンもあるそうですけど、自分はむしろこの方が好きなのでこのまま使っています。

2013/6/26追記
Cyberfox 22では言語パックを入れた後もアプリケーション名が変わらなくなってました。

2013/12/12追記
26では言語パックを手動で有効にする必要がありました→この日記

2013年5月27日月曜日

Chrome 28:コメント幅だけLucida

Lucida化(仮)の件で妙なことがあったので。

下図は罫線記号U+2501とニコニコマークU+263Aを並べたコメントの、Chrome上での表示です。
先頭にシリア文字U+0701を置いたところコメントの幅が縮み、右側が中途半端なところで切れてしまいました。


アラビア文字やシリア文字にU+2501のようなLucida Sans Unicodeで表示されている文字が隣接して、その後ろにU+263AのようなArialで表示されている文字が並ぶとこの現象が起きました。

この縮んだ幅がなんなのかなと思ったら、Lucida化した場合のコメント幅のようでした。


U+263AだとLucidaの方が幅が短いですが、Lucidaの方が長いケースではそれに合わせるかのように空白部分が作られました。つまり、逆にコメント幅が伸びました。


IE上でも、フォント変化が起きた際に一時的に同様の現象が見られることがあります。 しかしこれはリロードすれば直ります。上のChromeの挙動はリロードしても変わらない、固定的なものでした。

Arialがアルファベットの場合はTimes化(仮)した場合のコメント幅に変わりました。



先日書いたひらがなと濁点記号の組み合わせでも、合成が起きた場合のコメント幅に変わりました。


そもそもなんでアラビア文字やシリア文字でこういうことが起きるのか見当がつかんのですけど、まるでpepflashplayerがLucida化の挙動をわかってて描画しているかのような現象です。
Arial・MS Pゴシック以外のフォントが表示された時点で、何かが起きてるんでしょうか。

2013年5月21日火曜日

合成用の濁点・半濁点について

ちょっと気になったので。

濁点・半濁点の記号には「゛(U+309B)」・「゜(U+309C)」とは別に、合成用のU+3099・U+309Aという文字があります。下図は、実際にこれらをひらがなにくっつけて試しているところです。
U+309B・U+309Cは合成されませんが、U+3099・U+309Aは合成されているのがわかります。


左図のU+304BとU+3099が合成されたものは、元々合成されている「が(U+304C)」と同じに見えます。ひょっとすると、合成された方もU+304Cの字形で置き換えているのかもしれません。しかし右のような本来ありえない組み合わせでも、いちおう合成して描画されています。

IEでフォント変化を起こすと、少しおかしなことが起こります。下図左では濁点記号が消えてしまったように見えます。右図を見ればわかりますが、一文字分右にずれてしまうからでした。


U+3099・U+309Aは、SimSun・Gulim・PMingLiUにはありません。上のケースではフォントリンクによる代替表示がされているのだと思います。この場合のU+3099・U+309Aは、ゼロ幅ではなくなってしまうということでしょうか。

一方、Chromeではまた別の挙動が見られます。


U+304BとU+3099はIEと同様に合成されますが、U+3042とU+309Aは合成されません。
他の組み合わせでも試してみると、どうも「本来ありえない組み合わせ」では合成を行わないようです。この件に限らず、Chrome(というかpepflashplayer)はIEでは参照されないなんらかのプロパティを参照して、文字の区別をしているように思います。

妙なことに、先日来書いているLucida化(仮)を適用するとU+3042とU+309Aの合成が起きました。


この現象はArialに対してだけ起きるものだと思っていました。そんな単純なことではないようです。

2013年5月19日日曜日

Chrome 27:U+2584・U+2588の全角化とゼロ幅文字

「Lucida化(仮)」の話の続きです。Chrome 27は、なぜかまだ安定版がリリースされていないためBetaです。

CMapのデータを見ていて、ゼロ幅文字のU+FEFFがArialには無くLucida Sans Unicodeにあることに気づきました。試したところ、これでもLucida化が起きました。下図はU+2588をChrome上で全角幅にしているところです。
 

ダイアクリティカルマークもゼロ幅ですから、まるで何もないのにU+2588が全角幅に変わっているように見えます。IE上でもコメント幅に影響はありません。

ところがこれができるのはWindows 7だけでした(Vistaはわかりませんが)。まず下図左のようにXP上のChromeではLucida化が起きません。また8上のChromeではLucida化が起きますが、IEでU+FEFFの部分がゼロ幅でなくなってしまいました。


XPではダイアクリティカルマークに例えばU+0320を使うとLucida化が起きましたが、この組み合わせはIEで合成が起きません。しかもXP・7・8で表示の結果が異なりました。


7上でも、もう少し見てみました。下図はU+2584とU+2588を全角幅に変えているところです。


上の図ではU+FEFFを使ってもU+2501を使っても結果が同じです。しかし下の図のように途中へArialを挟んだ場合、U+2501の方ではTimes New Romanと思われる字形へフォントが変化します。これを仮にTimes化と呼んでおきます。
U+FEFFの方ではこのTimes化(仮)が起きません。Lucida化が起きると言っても、どうもU+FEFFはU+2501やU+2587とはまた違うようです。

ところで、上のTimes化はゼロ幅文字U+200Cを使うと回避できます。


次にこのU+200Cについて、もうちょっと実用的なケースで見てみます。
下図は文字列の両側をU+2582~U+2588で挟んだコメントです。下段はLucida化によりU+2584とU+2588を全角幅に変化させています。


コメントの一箇所にダイアクリティカルマークをつけており、かつU+2584・U+2588がいずれもその他のブロック文字(Lucida)に隣接しているため、このようになるのだと思います。途中の文字列がごシックであればこの挙動に影響を与えないようです。
しかし途中の文字列がArialの場合、上で見たTimes化が起きます。


ちなみにXPだと化け方がちょっと違います。


図の通り文字列の右側ではTimes化が起きません。それによく見るとU+0020が豆腐になっています。元はシンボルフォントで、アルファベットだけTimesで代替してるんでしょうか。
また、8ではTimes化が起きません。文字の組み合わせによるのか、Times化自体が起きないのかはまだわかりません。


7とXPでも、文字列の両側にU+200Cを挟めばTimes化が起きません。


IE上ではU+0323がちょっと表示されてしまう以外に影響はないように見えます。


なお、この例でU+2581は使っていません。U+2581はLucida Sans Unicodeに無いからです。というか、それがLucidaじゃないかと思ったきっかけでしたが。

2013年5月6日月曜日

Chrome 26/27:U+2001の全角化

まずChromeでU+2588などを全角化する話の補足です。
U+0323は、くっつけた文字が化けない限りどこにあるかは問題ではないようです。要はダイアクリティカルマークがコメント内にあること、全角化したい文字がLucida Sans Unicodeで表示されている文字(下図の例ではU+2586)に接していることが現象の発動条件らしい。


とりあえずこの現象をLucida化(仮)と呼んでおきます。
上の右図では、途中に半角のaを挿入すると両側のU+2586と一緒に別のフォント変化が発生しています。その結果U+2584・U+2588はLucida化しません。これが全角のaであればLucida化に影響しませんが、このaをU+2584とU+2586の間に挿入してしまうとU+2584がLucida化しなくなります。

次にIEでの話です。例えばダイヤのマークU+2666は下図のような挙動を取ります。「a」に接している場合はArial・「あ」に接している場合はゴシックで表示されていると思われます。


コメント自体が「ゴシック化」されていもその条件は変わらないようです(上の右図)。

空白文字U+2001もこれと同じ挙動を取ります。下図のコメント1段目と2段目の違いは、最後の「a」と「衣」の順番です。「衣」と接している2段目のU+2001はゴシックだと思われ、全角幅です。1段目はArialと思われ、それより少し短くなっています。


Chromeでは1段目も2段目もIEの1段目と同じ幅で、Arialだと思われます。これが冒頭のU+2584・U+2588と同様にLucida化→全角化することに気づきました。


1段目と2段目の最後のU+2501は、ChromeではLucida Sans Unicodeで表示されていると思われす。2段目でこれにU+0323をくっつけているのは、「Lucida化処理」です。Chromeの表示がIEと同じ幅になっています。U+2001の数を増やすと「Lucida化処理」の有無による差が広がってわかりやすくなります。


ちなみにWindows XPの場合、U+2001はArialにありませんがLucida Sans Unicodeにはありました。このため、Chromeでは「Lucida化処理」をしなくても2段目と同じ幅で表示されます。
関連フォントのU+2001の有無を下表に示します。

Windows XP  Windows 7 
Arial 無し 有り
MS Pゴシック 有り 有り
Lucida Sans Unicode 有り 有り
Microsoft Sans Serif 無し 有り

SimSun・Gulim・MingLiUはU+2001がありませんので、IEでフォント変化が起こるとWindows 7ではフォントリンクによりMicrosoft Sans Serifが表示されると考えられます。ゴシックやArialよりずっと幅が狭く、実用的とは言えません。一方、XPではそのような代替表示自体が起きません(SimSunでは表示するものが無いという意味の全角幅の空白になります)。

下図は以上の検証をいわゆる「big10行」(二重リサイズ)のコメントで試しているところです。
空白部分はU+2001・pinkで表示されているのはU+2588です。U+2001はU+2588によりSimSun化しないようゴシック保護の処理をしてあります。


3つ目の画像のLucida化は、U+2001だけではなくU+2588にも適用させています。これによりIEと表示の互換ができているように見えます。

下図は上のコメントをFullコマンドで投稿して二重リサイズが起きないようにしています。左右に黄色の枠が表示され、幅の違いがわかります。重ね合わせの都合で10行を16行に変更しています。


「Lucida化処理」をしていない2つ目では、U+2588を含んだpinkのコメントだけでなく色なしのコメントも幅が縮んでいます。U+2001がArialのままだからだと思います。

空白文字は見た目は幅でしか判別できませんので、Lucida Sans Unicodeだと言っているのは今まで見てきた情況証拠からの推測に過ぎません。なんにしろIEと表示の互換が図れればいいなということです。
なお同じ事ができるケースはそれほど多くないと考えられます。
Chrome上で元はArialで表示され、かつLucida Sans Unicodeに全角幅の字形があるという条件に当てはまる文字は、数が限られています。さらに冒頭でも触れたような別のフォント変化も確認しています。まあ、まだ他にも未知の挙動があるのかもしれませんが。