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

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

もずはっく日記(2006年8月)

2006年8月1日

Bug 5175 マウスホイールの動作はどうあるべきか #3 初回投稿日時: 2006年08月01日03時02分57秒
最終更新日時: 2006年08月01日03時04分24秒
カテゴリ: Mozilla Core
固定リンク: id=2006080100
リンク元: 0件
SNS: (list)

より自然なトランザクションを構築するためにリトライ中。現在のパッチは、

  • マウスホイールイベント直前のマウスの移動も無視するように改善
  • 各設定値を短くした

マウスの移動を無視するコードについては前回の修正時に全く気づいていなかったのだが、現在のコードはホイールイベント直後のマウスの移動イベントは無視するものの、直前のイベントは無視していない。これを無視するように改善したことで、ホイールイベントの前後あわせて倍の時間、マウスの移動を無視することができるようになったので、その時間を0.1秒に大幅に短縮した(つまり、実質は0.2秒無視される)。何度かテストした結果、ホイールを回した後、0.1秒以内に意図的にマウスを動かすのは極めて難しかったので、これで、全ての意図したマウスの移動イベントでトランザクションを分割することができると思う。

ちなみに、前回のエントリで、えむもじらさんから、

時間だけではなく、マウスの移動量も考慮してはどうでしょうか? 大きく移動させた後でスクロールを開始した場合は、無条件にマウスカーソル直下を対象にしてもよいと思います。

というご意見を頂いたが、これは却下。というか、以前のパッチはこれを意識するようになっていたが、結局、これの閾値が非常に難問だったので、自らボツにしていた。何故かというと、マウスの移動速度を取得できないからだ。仕方ないのでカーソル位置のスクリーンの解像度から適当な値を求めようとしたのだが、マウスの移動速度を変更するとやっぱり破綻してしまった。その結果が現在の時間軸での閾値の作成につながっているのである。

時間軸は多くの人にとって、PCの環境には依存せずに共通の基準があるように思う。(個人差はあると思うがそれはPCの環境差よりも小さいと思う。もちろん、マウスを利用しにくい障碍のある人であれば、このパッチはうまく機能しないが、それは、以前の動作と同じになるだけであって、おせっかいな動作でうまく機能しない訳ではないので、許容範囲内であると考えている。)

Bug 5175 マウスホイールの動作はどうあるべきか #4 初回投稿日時: 2006年08月01日03時12分01秒
カテゴリ: Mozilla Core
固定リンク: id=2006080101
リンク元: 0件
SNS: (list)

誤解されると困るので、一応強調するために書いておくが、このバグはユーザビリティを向上させることが目的である。アクセシビリティはこのバグ修正の影響を受けてはいけないし、この修正に対するアクセシビリティはこのバグの範囲内の話ではない。

このバグの修正はある意味ではうまく機能しなくても良い。うまく機能せずに、以前の動作と同じなら成功ではないが、問題は無いのである。だが、このパッチによって不自然な、意図しない挙動になってしまったとしたら、この修正は失敗なのである。

ユーザの質問に答えるっていうのは重要なんでしょうけど…… 初回投稿日時: 2006年08月01日04時35分03秒
カテゴリ: 雑談
固定リンク: id=2006080102
リンク元: 1件
SNS: (list)

ちょっと間が空きましたが、今更ながらにコミュニティの話をば。

鎌倉に来てくれた方との話の中でも情報交換というのは今更ながらに重要さを改めて感じたりしています。で、実際に(今回に限らず)ユーザの方や、もじら組のメンバーと喋ってみると、意外と、「え、この人からこんな質問が?」ということがあって戸惑っています(別に特定の人から受けた印象ではなく、結構多くの人と喋っててこんな感じです)。これはひとえに、私やMozilla Japanに限らず、情報を持っている人がそれを世間には広めれていないということなんでしょうね。

しかし、結構多くの関係者がblogを開いて、日々情報を書き込んだりしています。でもそれはユーザの求める情報とはズレがあるんでしょう。そうだとすると、もう質問のある人が能動的に質問するしか手が無くなってきます。(リサーチして、情報を発信しろよ、という意見があるかもしれませんが、それでうまく行っていないというのが現状ではないかと思います。)じゃあ、どうすれば質問ができて、識者がそれに回答できるかと考えてみると、これが結構難しいように思えます。

BBS等のフォーラムを使うと、システムと質問者が余程しっかりとしてないと「過去ログ読め」という回答のオンパレードになるのが目に浮かびます。そういったノイズが増えると、余計に過去ログは埋もれていきます。フォーラムというのは手軽なコミュニケーションを提供しますが、データベースには向いていません。

質問者がblogに疑問、質問を書いて、識者がそれを見たら本人のblogで反応する、というのも考えましたが、Mozilla界隈で有名なblogが質問を書けばうまくいくかもしれませんが、そうではない人の場合、質問そのものが埋もれてしまう可能性が大なのでやっぱりうまくいかないでしょう。それに、回答が各所に散らばるのもよくありません。しかし、Spread Firefoxのblogをうまく活用できれば解決するかもしれませんが、質問者側の問題の解決策が私には思いつきません。(それに悲しいことに、現在のWindowsのTrunkビルドではSpread Firefoxは一部のページがブラクラと化してしまっているので私はまったく活用してません。多言語の動的なサイトというのは難しいものですね。)

誰かが、質問メールを受け付けまくってそれを識者に答えてもらって、回答をSpread Firefoxでまとめて公開する、というのが良いかもしれませんが、誰がやるんだという話になってきますし……難しいものです。

2006年8月2日

チルトホイール 初回投稿日時: 2006年08月02日04時00分08秒
最終更新日時: 2006年08月02日04時00分26秒
カテゴリ: Memo Mozilla Core
固定リンク: id=2006080200
リンク元: 0件
SNS: (list)

GeckoはMicrosoftのマウスのチルトホイールにうまく対応できていない。

ページ全体を横スクロールしたい場合等、うまく機能することもあるのだが、ページ内のoverflow: auto;なスクロールバーをチルトホイールで操作しようとしても、そのコンテンツを一度クリックしていないとうまくいかない。

原因はGeckoの貧弱なOSとの連携と、Microsoftのドライバ側のQuriksによって現在の中途半端な動作になっている模様。

Microsoftのドライバは、ウインドウクラスがMozillaWindowClassの場合、チルトホイールの操作で常に右矢印か、左矢印のキーが押されたことをメッセージでエミュレートする。このため、Geckoでも横スクロールという結果が得られることもあるが、キャレットがキーボードの入力をハンドリングしている状態(エディタとか)ならキャレットの移動になってしまう。

別アプリとの互換性のため、ウインドウクラス名は当然変更できない。WM_HSCROLLに対応しておけば将来のマウスドライバでは動作が改善されるかもしれないが、なまじ、今のドライバで動いているだけに、ドライバが変更を加えれば動作がよりベターなものになるということを気づくとも思えない。

それに、WM_HSCROLLはチルトホイールのための専用メッセージではないので、このメッセージを受信した時にマウスカーソルの位置からスクロールターゲットを判断するのもおかしいかもしれない。(他の外部アプリケーションがこのメッセージをどのように使うのかにもよるが、このへん、全く分からない。)

とりあえず、Bug-org 236257Bug-org 315727あたりを見ていると、WM_VSCROLL共々、なんらかの形でサポートはするべきみたいなので、暇になったら見てみよう。

チルトホイール #2 初回投稿日時: 2006年08月02日16時58分51秒
最終更新日時: 2006年08月02日17時00分31秒
カテゴリ: Mozilla Core
固定リンク: id=2006080201
リンク元: 0件
SNS: (list)

Bug 5291に登録してみた。意見があればよろしく。

チルトホイール #3 初回投稿日時: 2006年08月02日23時44分39秒
最終更新日時: 2006年08月02日23時45分00秒
カテゴリ: Mozilla Core
固定リンク: id=2006080202
リンク元: 0件
SNS: (list)

えむけいさんよりWinVistaで新しいメッセージがチルトホイール用に追加されるということなので、それへの対応をBug 5292に登録した。

Bug 5291はキャプチャソフト等への対応に絞って、ページ全体をスクロールする命令として扱うべきだろうか。

2006年8月3日

Bug 5227 添付ファイル名のRFC 2231違反 (`*' がエスケープされない) 初回投稿日時: 2006年08月03日02時44分39秒
最終更新日時: 2006年08月03日02時51分51秒
カテゴリ: SeaMonkey Thunderbird
固定リンク: id=2006080300
リンク元: 1件
SNS: (list)

時間がないということで、えむけいさんがとりあえず全文字をエスケープするパッチを提供してくれて、修正完了している。

Trunkと1.8branchの双方で修正済み。もし、別のメーラとの連携で問題があったら即報告して欲しい。(受信テストを行ったのは、ThunderbirdとBecky!2、そしてQMAIL3の三つだけ。報告がなければ、このままリリースまで突っ走ること間違い無しなので環境をお持ちの方はテストよろしく。)

肝心のテストの方法を書くのを忘れていた。デフォルト設定の送信設定のまま(mail.strictly_mime.parm_foldingが2)、添付ファイル名を日本語と、ASCIIのアルファベットや数字を交えたものにして自分に送信して、テスト対象のメーラで受信し、そのファイル名がきちんと表示されていればOK。

ASCIIのアルファベットや数字は今まではエスケープされていなかったが、今回からエスケープするようになっているので、デコード処理が変なメーラがあると破綻する可能性がある。

ちなみに8月2日のビルドには間に合っていないので、テストは8月3日以降のビルドで。

2006年8月7日

Bug-org 346417 RTL justify code is wrong in nsTextFrame 初回投稿日時: 2006年08月07日18時42分01秒
カテゴリ: Mozilla Core
固定リンク: id=2006080700
リンク元: 0件
SNS: (list)

別のバグの調査でレンダリングのコードを調査していたときに偶然発見したバグ。

メモリ節約のためにメンバ変数代わりに使っている変数のカウンタが予期しない幅計算処理で使い切られてしまってたため、実際のレンダリング時にうまくそれらのカウンタが機能していなかった。こういう処理を知っていないとすぐにバグってしまうコードの設計は問題ではあるのだが、他にやりようが無いし、困ったものだ。

そういえば、メモリを使いすぎだと批判している人は、こういう危険性を犯してでもメモリ節約のコードが入っていることは知っているんだろうか? 考えられるメモリ節約コードは既に入っているので具体的にどこに無駄があるのかは難しい問題である。もちろん、見つけられたらbugzillaで提案して欲しい。

2006年8月8日

バグを修正したいんですけど、どうすれば良いですか? 初回投稿日時: 2006年08月08日03時13分36秒
カテゴリ: Firefox Mozilla Core SeaMonkey Thunderbird 雑談
固定リンク: id=2006080800
リンク元: 1件
SNS: (list)

よく聞かれることなので、FAQをば。

バグを修正するにはどの程度の知識が必要ですか?

修正するバグに依ります。

例えば、UI上の動作を修正したい場合、ほとんどの場合はJavascriptを少しいじれれば可能です。この場合、ビルド環境すら必要ありません。最新のTrunkビルドと、zip形式の解凍、圧縮ソフトとテキストエディタがあれば十分です。

レンダリングや、ネットワークの機能を改善したい場合、C++に関する基本的な知識が必要になります。もし、OSやツールキットに対してネイティブな箇所を修正しようとするのであれば、そのプラットフォームの知識が必要になりますが、より多くの箇所は完全にクロスプラットフォーム化されているため、その知識すら必要ありません。

そして、基本設計に関わるような大きな問題では無い限り、大抵はひとつのモジュール(大抵は2から3の.cppファイルや.hファイル)を修正するだけです。つまり、全体を把握する必要はありません。局所的にソースコードを読むことができれば、それは修正するのに十分な知識であることが多いです。

どのバグから修正すれば良いのですか?

修正したいバグから修正してください。本家のバグ登録件数は既に30万件を突破しており、修正済みのものを差し引いても、十分すぎる数のバグが存在しています。

ただし、いきなりenhancement(要望)の修正に挑戦すると挫折することになるかもしれません。enhancementの修正はある意味で最も日本人が不得意とする分野でしょう。enhancementを修正するためにはかなりのディスカッション能力を要求されることが多々あります。

UIの変更もこれに似ているので、やはり最初はバックエンドから取りかかった方が無難と言えます。

英語が苦手なのですが、どうすれば良いですか?

あなたには二つの選択肢があります。

一つ目は、片言の英語であっても無理矢理相手との意思疎通を図る努力をすることです。私も英語の会話能力は全くありません。しかし、高校に進学できた人の英語力であれば、大抵の場合、bugzillaでの会話はなんとかなります。リアルタイムの会話ではないので分からない単語は辞書を使えば済むことです。

二つ目は、bugzilla-jpを活用することです。私が賛同できないenhancementの修正を除き、私が代行作業を行うことは可能です。この方法での修正には既に実績があります。bugzilla-jpで私をCCに加えて、代行を依頼してください。

ソースコードが巨大すぎて、どこを修正すれば良いのか分かりません

私も日常茶飯事のことです。特定のモジュールで作業しているハッカー以外はおそらく全員そうでしょう。

Bugzillaで似たようなバグで修正済みのものを探してください。そうすれば余程古いバグ(Netscape社が主導権を握っていた時代のもの)でない限り、修正パッチがバグに添付されています。そのパッチから関連するモジュールのソースコードを見つけることができます。

2006年8月11日

Bug-org 342366 make cairo gfx faster (on Windows) 初回投稿日時: 2006年08月11日02時37分12秒
カテゴリ: Mozilla Core
固定リンク: id=2006081100
リンク元: 1件
SNS: (list)

Windowsのthebes高速化のためのバグ。

テキストレンダリングが高速化されるパッチが投入された。が、うちのPCではよく分からない。通常のテキストの表示なら今までのgfxとほとんど変わらないんじゃないだろうか。ソースコード見る限りでは。

Bug-org 343655 optimize win32 image rendering 初回投稿日時: 2006年08月11日02時39分22秒
カテゴリ: Mozilla Core
固定リンク: id=2006081101
リンク元: 1件
SNS: (list)

Windowsでの画像の描画の高速化パッチが投入されている。

こちらはかなり明確に速くなっている模様。amazonとか、細かい画像が多いサイトでフリーズしてしまう現象がなくなってるかもしれない。

GeckoでサポートしているIMEはなんですか? 初回投稿日時: 2006年08月11日03時15分04秒
最終更新日時: 2006年08月11日15時05分03秒
カテゴリ: Mozilla Core 雑談
固定リンク: id=2006081102
リンク元: 2件
SNS: (list)

またFAQ。

GeckoでサポートしているIMEはなんでしょうか?

現在のところ、TrunkではFx3でIMEのサポートが大きく改善される予定です。これはIMEの制御に主眼がおかれていますが、各IMEとの個別の連携についても随時修正可能なものは修正を入れていく方針です。

現在、私の手元で確認できるのはWindowsではMS IME 2000、MS IME 2002、MS IME 2003、ATOK 2006、Japanist 2003、WXG4、VJE Delta ver.4.0と、その他Microsoftが公開している日本語以外のグローバルIMEです。LinuxではFedora Core 4のIIIMF、Fedora Core 5のSCIM、Turbo Linux 10F...のATOKの環境を整えています。MacではIntel Mac(MacOS X 10.4)上のことえり、egbridge Universalを用意しています。(ATOKも近日揃う予定)

もちろん、これら全てを常用している訳ではありませんので、定期的なテストは行っていませんが、バグ報告があれば、確認、修正を行うことが可能です。このサポートは(もちろん、「できる限り」ですが)Firefoxがリリースノートでサポート表明しているOSに対応しているIMEに対してのみ行われます。

また、このリストに無いIMEであってもテストに協力してもらえるのであれば、対応が可能です。原因究明が非常に困難な場合は手詰まりに陥るかもしれませんが、原因が判明し、それがGeckoアーキテクチャ上、不可能、もしくは極端に困難な場合を除き、修正を行います。もちろん、修正確認は手伝ってもらう必要があります。

もちろん、日本語以外のIMEに関する問題でもかまいません。日本語以外を利用する日本のユーザも当然居ると思われるのでそれは必要な対応だと私は考えているためです。

最後に、IMEに関するバグは本家bugzillaではなく、bugzilla-jpの方に必ず報告してください。私は本家bugzillaで新規に報告されるバグを毎日はチェックしきれていませんので誰かが私をCCに加えない限り、そのバグは放置されることになるでしょう。(Bugzilla-jpでは報告されたバグを全件チェックは入れています。)

○○という国際化バグはいつ修正されますか?

まず、そのバグがBugzilla-jpに登録されているかどうかを確認してください。もし、登録されていて、そのバグ内での動きが活発なら、修正の時は近いかもしれません。しかし、何ヶ月も新しいコメントが無いようなバグの場合は開発者にとってもテスタなとっても優先順位がまだ高くなっていないため、まだしばらく修正されない可能性が高いです。

もし、そのバグがBugzilla-jpに登録されていない場合、おそらく私や他のテスタ、開発者もそのバグの存在を知りません。即、適切に報告を行ってもらわないと永久に修正されることはないでしょう。

2006年8月14日

Re: Schroepfer のインタビュー 初回投稿日時: 2006年08月14日02時17分45秒
最終更新日時: 2006年08月14日02時20分22秒
カテゴリ: Firefox 雑談
固定リンク: id=2006081400
リンク元: 1件
SNS: (list)

何でそんな面倒くさいようになっているのだろう.Linux に載せられているのは何故アップデートを見に行く機能が削除されているのだろう.

政治的理由は把握していませんが、単純にバイナリレベルで互換性が無い可能性があります(互換性がなければ当然、どうしようもありません)。例えばビルドオプションが違っていたりとか、ビルド環境そのものが異なったりとか。故に、MFとしては、誰かが自前ビルドしたものを再配布するなら、それはそっちで責任持てとしか言えないはずです。

URLの折り返し問題はGecko(Firefox)のバグなのか? 初回投稿日時: 2006年08月14日03時32分35秒
最終更新日時: 2006年08月14日03時42分40秒
カテゴリ: CSS HTML Mozilla Core XHTML
固定リンク: id=2006081401
リンク元: 17件
SNS: (list)

URLの折り返し問題はGecko、つまりブラウザで言えばFirefoxのバグなのか。この辺をよく理解できていない方がいるようなので私見を書いておこうと思う。

現時点で、Web表示、つまりレイアウト時における文字列折り返しに標準仕様は無い。つまり、Geckoは間違えた実装をしている訳ではない。(CSS3のテキストモジュールでline-breakプロパティがあるが、まだ標準仕様と考えるには時期尚早だと思われるし、ここで厳密な処理が定義されている訳でも無いことに注意が必要である。)

では、現在のGeckoの表示は適切か、と聞かれれば、答えはシンプルに適切ではないと言い切れる。明らかに一部のレイアウトとの相性が良くないためだ。これは仕様云々の話ではない。

つまり、Geckoは間違えた実装をしている訳ではないが、まだまだベターな実装はあるはずである、という状況である。そこで、GeckoはUAX#14をベースとした実装を追加しようとしている。

では、UAX#14とはなんなのか。あれは、Unicodeの仕様である。しかし、CSS3の草案でもこれの利用が推奨されているのみで、これの厳密実装はブラウザは行うべきではないと私は考えている。

何故か。その理由はシンプルで、これだけでブラウザに期待される表示はおそらく不可能である。おそらくUAX#14は通常の自然言語を前提にした仕様と思われる(まだ仕様書を読破できていないので断言はできない)。

そう、よく問題に上げられるURLという書式は単なる記号としての文字の羅列であって、これに自然言語のルールを当てはめてもうまく行かないケースが出てくるはずである。このため、UAX#14はWebデザインのための標準仕様としては力不足の側面がある。

私はこの問題がブラウザ間で完全に互換性がとれる日は来ないと思う。そもそも改行処理の定義は難しい。UAX#14の問題から分かるように、どこで改行すれば人間にとって期待通りになるかという問題はそのテキストのコンテキスト、つまり文脈等に依存する。そう、あらゆる文脈で通用する仕様を定義するか、あらゆる文脈向けに仕様を作るか、このどちらかが実現しなくては標準化ができないが、どちらもまず無理だろう。百歩譲って、それが実現したとしても、今度は文脈を判定するというとんでもなく困難な問題に直面する。例えば自然言語で考えてみても、未だに日本語と中国語を機械的に判定するのは難しい。おそらく、辞書を用いた解析が必須だろう。そして、URLのように辞書が使えない文脈も判定する必要が出てくる。例えば、2006-08-14という文字列があったとしよう。これを日付のフォーマットなのか計算式なのか判別しなければいけない状況を想定するといかに無茶な話なのか分かってもらえるのではないかと思う。

最後に、ひとつだけWebデザイナ側の問題点だけは指摘しておこう。

URLが折り返されないことが原因でレイアウトが崩れた場合、それはそのサイトの構造に問題があることが多い。レイアウトが崩れる場合、それは折り返されなかったことによって文字列の幅が祖先要素の幅を期待したものとは異なる結果にしてしまったということである。この状況をCSS2.1仕様に照らし合わせると、shrink-to-fitには関係無いことが分かるので、問題が発生しうるのはテーブルのセルの内部だけということが分かる(他のケースでは内容のテキストによって祖先の要素幅が変わることは無い)。

display: table-cell;を用いたひねくれた、現実的では無いケースを除き、そのセルはHTMLによって定義されたテーブルのセルであると考えるのが現実的だ。つまり、レイアウトが期待通りにいかなかった場合には二つのケースが考えられる。

  • URLに関する表を書いたが、期待通りにURLが折り返されなかった
  • テーブルを本来の目的とは異なるレイアウトのために利用したため、幅の固定に失敗した

前者の場合(これはレアケースとは思うが)はブラウザ側の問題である。Webデザイナを責めてはいけない。彼らには何の落ち度もないし、現在のレイアウトの仕様上、仕方のない問題である。だからといってブラウザに全ての責任をおしつけるのも適当とは思えないが。

だが、最も発生している、そして問題とされている後者は明らかに不勉強なWebデザイナの失態である。本来の目的外の利用を行ったことで意図通りに表示されなかったことをブラウザのせいにされても困る訳だ。StrictなHTMLとCSSでデザインすることによって同じ内容のコンテンツを作ってみれば分かる。URLは要素からはみ出すが、そのおかげで横スクロールしなければ他のコンテンツを読むことができないという事態は発生しない。ただし、floatした要素等と文字が重なることで、不適切な表示になる可能性はある。この重なってしまうことに対してブラウザに文句なり、要望なりを出すことは妥当である(要求が通るかどうかはともかく、筋としては正しい)。だが、横スクロールしなければコンテンツを読むことができない、(ブロックレベルの)レイアウトが期待通りにならない、というのはWebデザイナ側の問題であってブラウザ側の問題ではないのだ。

2006年8月17日

Re: firefoxのurlライン・ブレーク問題 初回投稿日時: 2006年08月17日04時08分25秒
最終更新日時: 2006年08月17日04時10分44秒
カテゴリ: Mozilla Core
固定リンク: id=2006081701
リンク元: 5件
SNS: (list)

geckoはそもそもライン・ブレーク問題を解決するような実装をしていないのであって、UAX#14はさらに間違った方向に行っているのではないか?そもそも他のブラウザができてfirefoxが出来ないのは何故なのだろう?

少し誤解があるようなので現在の改行仕様を紹介しておく。

現在のGeckoは二種類の改行仕様を利用している。ひとつはJIS X 4051(実際にはタイ語と、一部記号への対応のために拡張されている)。名前から分かるように日本語のための改行仕様である。これはテキストのフラグメントにCJK文字が含まれている場合にのみ利用されている。この仕様に従った場合にのみURL文字列内でも改行は発生するため、該当バグのテストケースにあるような不思議な現象を見ることができる。

もうひとつの改行仕様はそれ以外の言語用のもので、それ以外の言語は単純に空白をワードセパレータとして利用しているという前提のもと、半角スペースのある場所でのみ改行するというものである。

一般的なURLは後者のケースに当てはまってしまうため、空白以外の場所では折り返されない。

で、先月に作業していたのは、JIS X 4051を更に拡張し、これをあらゆる場合に適用したものだったが、ご存知の通り、一部の特殊なコンテキスト(例えば日付の表記やドイツ語用の引用符等)で破綻してしまった。

結局の所、このバグの修正にはまず自然言語用の一般的な規則が必要である。これを私たちは現在、UAX#14に頼ろうとしている訳だ。だが、UAX#14の仕様ではURLやファイルパス、プログラムのコード、日付や時間表記といった特殊なコンテキストには対応できない可能性があるので、UAX#14をさらに拡張し、そのへんの調整を時間をかけて行っていく必要があると考えている。(私が先の記事でブラウザ間の完全互換が難しいといったのは、この拡張しなくてはいけない部分にある。)

私がrocから取り付けている妥協案は、ASCII(厳密にはU+100未満の文字)のみのフラグメントにのみUAX#14を先行して適用してしまうというものである。これなら影響を受ける範囲をわずか数十文字に押さえ込むことができるため、テスト期間を大幅に短縮できるという発想だ。

2006年8月18日

Bug 5247 [Cairo][Win] CJKの文字に対してはfont.name(-list)が無視されている 初回投稿日時: 2006年08月18日04時01分48秒
最終更新日時: 2006年08月18日18時25分58秒
カテゴリ: Mozilla Core
固定リンク: id=2006081800
リンク元: 1件
SNS: (list)

修正完了。

Windowsでlang属性が適切に指定できていない日本語のページを見ると、変なフォントが選択されたり、異常な処理落ちが発生していたのはこのバグが原因。

このバグが発生するページで多かったのは、

  • lang="ja"と書くべきところを、lang="jp"と書いている
  • 翻訳したサイト等で、lang="en"等のまま、修正していない場合

どちらもイージーミスのたぐいだが、前者の間違い方はjajpの違いを理解できていない場合も多そうな気もする……

Stuartのパッチで削っていた場所に必要な箇所が含まれていたため、うまく修正できていないようなので再開して作業中。

2006年8月19日

Bug 5180 [Cairo][pango] pangoによるフォントスイッチングがデタラメ 初回投稿日時: 2006年08月19日03時00分29秒
カテゴリ: Mozilla Core
固定リンク: id=2006081901
リンク元: 0件
SNS: (list)

ブロックしていたバグのパッチが入ったのでようやく修正再開。

Windows版のロジックをほぼそのまま利用して、pangoを使って文字列をアイテマイズし、各アイテム毎にフォントを選択し、描画するように修正予定。今のところ、シンプルなページでは問題なくなっているが、letter-spacing等の処理が失敗しているのと、グリフ単位でのフォント選択ロジックが不完全な点、そして表示できるフォントが設定から見つからない場合の総当たりがまだできていない。

2006年8月21日

Bug 5180 [Cairo][pango] pangoによるフォントスイッチングがデタラメ #2 初回投稿日時: 2006年08月21日05時26分48秒
カテゴリ: Mozilla Core
固定リンク: id=2006082100
リンク元: 1件
SNS: (list)

Fedora Core 5を使ってテストしているんだが、よく分からない。

Fedora Core 5にデフォルトで入っている日本語フォント(ダイアログでリストアップされるもの)は「さざなみゴシック」と「さざなみ明朝」だけのようなのだが、これらを明示的に指定してレンダリングさせるとアンチエイリアシングがかからずに非常に汚い。だが、これらを指定しないと、「Sazanami Gothic」もしくは「Sazanami Mincho」が利用されてアンチエイリアシングの効いたレンダリング結果が得られる。しかし、フォントの一覧にこれらは無いし、fonts.confでは「sans-serif」や「serif」のエイリアスになってるっぽい。これらのフォントは別物?? よく分からない。

2006年8月24日

2006年8月25日

Bug 5180 [Cairo][pango] pangoによるフォントスイッチングがデタラメ #3 初回投稿日時: 2006年08月25日04時05分52秒
カテゴリ: Mozilla Core
固定リンク: id=2006082500
リンク元: 0件
SNS: (list)

パッチの機能そのものは完成。

シンプルなページ(これが大半)でのパフォーマンスが若干低下しているので、Windowsと同様に処理を単純化した関数を作成して先にそちらでの処理に挑戦するように修正すれば完成。

2006年8月26日

2006年8月27日

2006年8月30日

Bug-org 349727 random crash due to trashed nsWindow::mIMEData 初回投稿日時: 2006年08月30日02時55分47秒
カテゴリ: Mozilla Core
固定リンク: id=2006083000
リンク元: 0件
SNS: (list)

またしても謎のクラッシュバグ。とりあえず修正済み。

前にも書いたような気がするが、GTK2で、親ウイジェットが先に無くなり、子ウイジェットが残る場合がある模様。だが、その再現方法等が分からないので、branchでの修正許可が下りていないバグなんてのもあったりする。どなたか、情報をお持ちなら是非私にコンタクトをとって欲しい。

Windows Vistaの価格 初回投稿日時: 2006年08月30日03時22分29秒
最終更新日時: 2006年08月30日03時23分01秒
カテゴリ: Software 雑談
固定リンク: id=2006083001
リンク元: 0件
SNS: (list)

いつものごとく流出しちゃったので、もはや意図的ではないかと思ったりもするが、まあそれはともかく、思ったよりもUltimateが安い模様。といっても、高いことは高いのだが。

ところで、オフラインフォルダ、資料によってどのエディションに積んでいるのか違いがあって困るのだが、いったいどのエディション以降になるんだろう……。