Firefox + ATOKで未確定文字列と候補ウインドウのフォントが違うという件
初回投稿日時: 2011年02月17日13時18分08秒
カテゴリ: CSS Firefox Mozilla Core
固定リンク: id=2011021700
SNS:
Tweet (list)
twitterで以下のようなやりとりあったようで、技術的な内容を書いておきます。
@atok_js firefox上でそうなりますが、確定後はClearTypeが効いてます。試しに候補ウインドウの「表示フォントを固定する」にチェックを入れると、今までClearTypeが効いていた場所で効かなくなってしまいます。表示フォントの選択方法はあるのでしょうか？
@tks310 この場合はFirefoxの問題だと思われます。IEやChromeでお試しいただけると違いがご理解いただけると思います。ATOK上の表示フォントを変更することはできません。フォントの違いで変換中の文字と確定した字形が異なったり文字化けするなどの問題が発生しますので。
@tks310 途中経過です。Firefox特有の問題のようですが、調査に時間がかかるようです。わかり次第ご案内させていただきますので、少々お時間くださいますようお願いします。
@atok_js 特に急いでいるわけではないのでいいんですが… IE上でも候補と確定文字のフォントが違うんですが、それでもFireFox特有の問題でしょうか？
結論から書くと、未確定文字列と候補ウインドウ内のフォントが完全に同一にならないのは仕様というか、OSレベルの制限です。アプリ側から、候補ウインドウ内のフォントをひとつだけ指定できますが(少なくともIMMでは。TSFでは知りませんが、Firefoxはデフォルト設定ではIMMを介して動作します)、CSSではひとつのコンテンツに対して複数のフォントを指定でき、ブラウザは文字単位でグリフの有無をチェックしつつ、優先順位の高いフォントからフォールバックしていくため、特定のフォントをFirefoxが指定したからといって、同じ表示が保証されるわけではありません。また、downloadableフォントとか使われると、そのフォント指定が可能なのかどうかすら怪しくなってきます。
最初の日本語フォントだけを指定すれば良いのでは無いか、という意見もあるかもしれませんが、Geckoの場合、少し難しいです。もちろん、やってやれなくはないと思うのですが、はっきりいってコードの量、複雑さと実現できることがあまりにアンバランスです。つまり、コストパフォーマンスが悪すぎます。
で、ここからは私の推測です。
今回の問題はATOK側のフォントのフォールバックがベターなものではなくて、それが問題になっているんだと思います。最初のコメントを見ると、この方はClearTypeの有無にこだわっているからです。確かに、ClearTypeの有無は見た目のインパクトが違うので、アンチエイリアスが好きな人にとっては、ビットマップフォントでの表示は耐えがたいものがあるかもしれません。
私の環境ではFirefox上でATOK 2011を利用していても、候補ウインドウはメイリオで表示されているため、おそらく、最初のコメントの人はシステムフォントを変更しているか、日本語版以外のWindowsを使っているのではないかと思います。Windows Vista/7では確認していないのですが、少なくともXPの時にはシステムのテーマをいじると、システムフォント設定が欧文フォントに変わってしまう、という問題があったので、この方が意図的にフォント設定を変更していないとしてもそれに引っかかっているのではないかと疑っています。
このことから、ATOKはアプリからフォント指定が無い場合、まずはシステムデフォルトフォントにフォールバックしていると推測できます。そして、システムデフォルトフォントが日本語フォントではない場合に決め打ちでＭＳ ゴシック等にフォールバックしているのではないでしょうか。
もし、私の推測が正しいのであれば、システムデフォルトフォントが日本語フォント以外の場合、メイリオの存在する環境ならメイリオ、それ以外ならＭＳ ゴシック等にフォールバックするのが妥当だと思いますが、いかがでしょうか。