この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2011年2月)

2011年2月17日

Firefox + ATOKで未確定文字列と候補ウインドウのフォントが違うという件 初回投稿日時: 2011年02月17日13時18分08秒
カテゴリ: CSS Firefox Mozilla Core
固定リンク: id=2011021700
リンク元: 0件
SNS: (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はアプリからフォント指定が無い場合、まずはシステムデフォルトフォントにフォールバックしていると推測できます。そして、システムデフォルトフォントが日本語フォントではない場合に決め打ちでMS ゴシック等にフォールバックしているのではないでしょうか。

もし、私の推測が正しいのであれば、システムデフォルトフォントが日本語フォント以外の場合、メイリオの存在する環境ならメイリオ、それ以外ならMS ゴシック等にフォールバックするのが妥当だと思いますが、いかがでしょうか。

2011年2月23日

Geckoの未確定文字列処理とWebアプリケーションとの相性は良くない 初回投稿日時: 2011年02月23日17時59分49秒
最終更新日時: 2011年02月23日18時01分23秒
カテゴリ: Firefox HTML Javascript Mozilla Core 雑談
固定リンク: id=2011022300
リンク元: 0件
SNS: (list)

某氏から教えてもらった愚痴。

まーーーーーーーーたFirefoxのバグか!!(日本語入力関係)本当にいらっとするね!!Firefox滅びろ!!!!(暴言)

Firefoxでは、keypressイベントをセットしているtextareaで日本語入力中にoverflow-y: scroll;をつけたりけしたりすると文字が謎にコピペされるバグがあるようです。バグ報告したら直してくれるのかもしれないけど、Firefoxだしどうでもいいや。

ああもうイライラする。Firefoxのkeypress、keydownイベントで変なバグが。ChromeとIEなら許せるのにFirefoxだと異常に腹がたつのはなぜ!!どんだけ俺Firefox嫌いやねん!!あああFirefox絶滅しろー!!

DOMやHTMLの仕様でIMEの未確定文字列に関する挙動というのはほとんど定義されていなくて(例えば、inputElement.value = "foo";で、未確定文字列があった場合、どうするの? という基本的な挙動が未定義だったり)、何をもってバグと言われているのか全く想像できませんが、まあ、Geckoの未確定文字列がある状態での挙動の不審さは自覚しております。

でも、Geckoは未確定文字列がある場合の挙動は不自然なので、極力、特に日本語環境では未確定文字列がある状態ではキーイベントを生成しないようにしています。これは、未確定文字列の有無を意識せずにWebアプリケーションの開発者がキーイベントのハンドリングをできるというように、という配慮でもあります。こうしておかないと、IMEを使うことがない言語圏の開発したWebアプリでのIMEの利用というのが絶望的になってしまうからです。

Gecko独自のcompositionイベントとかtextイベントを拾ってまで無理矢理処理しているのであれば、それはWebアプリケーションの開発者の自己責任としか言えない面はあります。ここに互換性とか求められてもこれから改善していくにあたって確実に変更を入れなくてはいけないところなので(まあキーイベントも実はDOM2には正式仕様がないイベントですが、これってWebアプリ開発者にはさすがに釈迦に説法かと思います、というか思いたいですが)、既にこれらのイベントをハンドリングしているWeb開発者の方はFx4の次のバージョンでの互換性にご注意ください。

現在は、次のアルファ版でDOM3のキーイベントやcompositionイベントまわりの下準備が終われば良いな、ぐらいの感覚で作業中です。レビュアーとあまりもめなければ、Gecko 2.0の次のコアではかなりこの辺はDOM3 Eventsに対応して、Webアプリケーションが作りやすくなるのではないかなと思います。

2011年2月28日

Bug-org 636131 iBus freezes when it retrieves surrounding text and if the caret is at end of line (IA__gtk_im_context_set_surrounding: assertion `cursor_index >= 0 && cursor_index <= len' failed) 初回投稿日時: 2011年02月28日23時00分16秒
最終更新日時: 2011年02月28日23時00分41秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2011022800
リンク元: 0件
SNS: (list)

今月唯一成功したバグ修正となりました。

タイ語等のためにサポートするようになった、gtkのIMのsurrounding textのサポートにバグがあり、iBusがハングアップしてしまう、というもので、ギリギリに報告されたものの、hard blockerに指定されたので修正することができました。

もともと、Windows用のコードを流用してそれをベースにしてLinuxで利用していましたが、キャレット位置より前にある改行を探すコードに問題がありました。Windowsでは改行コードはCRLFですから、キャレット位置から前方向にLFを検索するだけで良かったのですが、Linuxでは改行コードはLFですから、キャレット位置のひとつ前から検索しないと、キャレット位置の直後に存在するLFに引っかかることがありました。

このため、想定していたキャレット位置よりも前にあるはずのLFのオフセットが、キャレット位置よりも大きいという状況になり、unsigned int同士の引き算で、小さい数字から大きい数字を引く状況になり、その結果の大きな数字を元にiBusがメモリ上のあらぬアドレスを参照しておかしくなっていました。