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

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

もずはっく日記(2007年1月)

2007年1月1日

Bug 5097 [Cairo][GTK2] 日本語フォントがbold/italicで表示できない 初回投稿日時: 2007年01月01日10時49分24秒
カテゴリ: cairo Mozilla Core
固定リンク: id=2007010100
リンク元: 0件
SNS: (list)

まだ作業中のバグ。

Linuxのcairoでは今のところ、太字と斜体が、フォント側で用意されていない場合に動的に生成できない。日本語フォントでは当然のごとくそんなリッチな条件が揃っていないので、結果としてこういうバグになっている。

cairoがバックエンドとして利用しているFreeType2では太字化のAPIと、斜体化のAPIが共に実装されているが、ソースコードを読むと、まだunstableな状態のAPIであることが明記されている。もちろん、そういうAPIなのでドキュメント側にも記載されていない。しかも、斜体化の方に関してはビットマップフォントでは効果が無い、中途半端なデキだ。(でも画像処理が得意分野ではないので、AAまで含めたビットマップフォントの斜体化はやり方が明確にイメージできない。) LinuxのCJK圏でのビットマップフォントの利用状況がはっきりとは分からないが、Macのように明るい状況ではなさそうで気がかりではある。

太字の方に関してはfontconfigの助けもあって、既にcairoからFT2のAPIにアクセスするようになっていて、ビルドオプションで有効にしてしまえばなんとかなるようだ。そこで、このビルドオプションを無条件に有効にするパッチを出したのだが、tinderboxマシンでビルドに成功するかどうかは不透明。現在FreeType Projectの方で公開されているソースコードではFT2のどのバージョンから存在しているAPIかが不明なためだ。だが、どのみちtinderboxで公開しているビルドが太字を表示できないのであれば、CJK圏には何の意味も無いテストビルドになってしまうし、ましてやリリースビルドがそんな環境で作られては困るので、問題があるならビルドマシン側を変更するように話を持って行く必要があるだろう。

斜体の方に関してはもうひとつ問題があって、fontconfigで斜体を動的に生成しないといけないフォントかどうかを判断できる仕様にはなっていない。今からfontconfigにコミットしたとしてもFx3のリリースに対しては既に遅すぎるので、もっと直接的な対応が必要だ。今のところ、ハッキーな手段と、cairo側のインターフェースの変更の二つの案しか思いついていないが、なんとかなるかは不透明。まだまだ机上の空論のままである。

Bug 5514 [Cairo][Mac] bug 5486 による ts regression 初回投稿日時: 2007年01月01日10時55分08秒
カテゴリ: Mozilla Core
固定リンク: id=2007010101
リンク元: 0件
SNS: (list)

つい先日、MacにもFont Name Resolverが実装できた訳だが、そのキャッシュを馬鹿正直に起動時に全て作っているため、若干起動時間が遅くなってしまったので、どうにかしよう、というバグ。現在作業中。

現在のregression持ちの状態ですらMacだと私の環境ではFxは2.5秒で起動するという高速なプラットフォームなのだが、バックアウト論を封じ込めるために、若干の対策を政治的に行うしかない。今のところ、必要最低限の処理だけを起動時に行い、残りは逐次、必要になり次第システムから取得してキャッシュに追加していくという方式になる予定。

だがそのために若干メモリ消費量が上がるのは皮肉な話だが、まあ、シングルトンなクラスのメンバが若干増える程度なのでたいしたことは無いので心配はしないで欲しい。

Bug 5518 [Cairo][Mac] ヒラギノのW6を指定しても、テキストがボールドにならない 初回投稿日時: 2007年01月01日11時02分15秒
カテゴリ: Mozilla Core
固定リンク: id=2007010102
リンク元: 0件
SNS: (list)

font-familyヒラギノ角ゴPro W6を指定しても、太字で表示されないというバグ。現在作業中。

元々、最初のFont Name Resolverでは正常に機能していたのだが、それに修正を加えた時にregressionが発生してしまった。

どうにもこのフォントファミリーというのは扱いが難しい。複数のフォントで共有されている名前なので、ファミリー名から、代表のフォントひとつに対してリンクしないといけないが、フォントを列挙している段階ではそれが分からない可能性があるというのが悩ましい。(代表的なフォントが後から列挙されてくる可能性があるため。)

Bug 5514で提出しているパッチで、一部の初期化処理を遅延することにしたので、その設計がこのバグの解決に決定打となってくれそうだ。現在の案では、ほとんどのファミリー名は起動時に列挙され、ファミリー名から代表フォントへのリンクはその後、必要に応じて逐一解決されていくという寸法だ。つまり、解決を図る時点では既に全てのフォントが列挙されてキャッシュ内にあるのでリンクが確立できるのである。

Bug 5527 text-decorationの下線/取消線/上線の太さが一定にならないことがある 初回投稿日時: 2007年01月01日11時12分05秒
カテゴリ: Mozilla Core
固定リンク: id=2007010103
リンク元: 0件
SNS: (list)

昨年、最後に修正したborderとoutlineの問題と同じ問題。Windowsでは発生を確認していないし、Linuxでもどうも起きない模様だが、Macでは原理上、必ず発生する。これも現在作業中。

これらの線の太さもスタイルシステムレベルで解決できると非常に楽だし、再描画時のオーバーヘッドも減るので望ましいのだが、残念ながらそういった仕様はCSS3のドラフトにあるのみなので、現時点では描画時に逐一処理するしかない。だが、下線等は複数の箇所で描画が行われているため、まずはこれらを一本化する必要がある。

一応、コードを検索した結果では、Quirksモード用や、IME、スペルチェッカーの描画を行うnsTextFrame、standardモードのインラインレベル要素用のnsHTMLContainerFrame、standardモードのブロックレベル要素用のnsBlockFrame、そしてXUL用のnsTextBoxFrameに散らばっていたので、これらから共通の関数を呼ぶように修正し、さらにその関数内ではCSS3の仕様に対応できるようにやや複雑な作りにして、点線、破線、実線、二重線の描画が可能なようにして、パッチを提出している。もちろん、これらの機能は内部的に実装されるだけで、CSSからコントロールできるようになるのはまだ先の話である。ちなみに、破線が利用できるようになるので、WindowsのIMEの未確定文字列はIEにあわせて、破線に変更予定である。(別バグで)

Bug 5519 [Cairo][Mac] 下線が表示されないことが多い 初回投稿日時: 2007年01月01日11時21分17秒
カテゴリ: Mozilla Core
固定リンク: id=2007010104
リンク元: 0件
SNS: (list)

Macでは下線がほとんど表示されないというバグ。これも現在作業中。

簡単なパッチを提出していたのだが、後から作業し始めたbug 5527で修正できそうな感じだったので、一端取り下げていた。だが、実際にbug 5527用のパッチが出来上がってテストしてみると、Osaka-等幅では下線が相変わらず表示されなかった。

その原因はてっきり、bug 5473と同じく、クリッピングの問題かと思ったのだが、デバッグしてみると、なんとMacOSが太さをゼロと返してくるのが原因だと分かった。

これは酷い。他のバグを見ていても思うのだが、MacOS XのATSUIは非常に完成度が低いと思う。しかも、OSのバージョンがあがる度にAPIが廃止されまくるのだからたち悪い。これじゃアプリケーション開発者が付いてこないよ、と言いたくなるような状況だ。

愚痴はさておき、結果的に、gfx側でMacの下線等の太さは最低1ピクセルはあるように、値を補正するしかないようだ。これは印刷時に適切な値で描画できなくなる弊害があるのでパッチを取り下げていたのだが、結局そのパッチのレビュー申請を再度行っている。より良い解決策ははっきり言って思いつかないからだ。

Bug 5533 [Cairo][GTK2] pango_shapeの呼び出し回数の軽減すべき 初回投稿日時: 2007年01月01日11時36分42秒
カテゴリ: Mozilla Core
固定リンク: id=2007010105
リンク元: 0件
SNS: (list)

Linux版のテキストレンダリングはほぼ、基本的な機能の実装は終わっているが、パフォーマンスが非常に悪いというのが問題になっていた。WindowsとLinuxでほとんど同じ構造のコードを書いてLinuxだけ極端にパフォーマンスが悪いのでpangoの性能がWindowsのUniscribeに比べて極端に悪いとしか言いようがない。そこで、各APIのパフォーマンスを測定してみた結果、現在のコードでは極端に時間を食っているpango_shapeの呼び出し回数を抑えれば高速かできそうだ、という結論に至った。そんな訳で、何故か年を越しながらのパッチ作成になった。

pango_shapeは最低、一回は呼び出さないといけない。だが、グリフの存在確認にこれを利用していたのが間違いだったようだ。もし、一つ目のフォントで全てのグリフが存在しなかった場合、フォントが見つかるまでpango_shapeを繰り返さなくてはいけないからだ。ならば、描画時にはリガチャのためにpango_shapeが必要でも、グリフの存在確認だけならUnicodeの文字単位で問題のない言語に関しては、先により軽いAPIで一文字ずつ確認するようにすれば、pango_shapeは最後に、必ず成功する状況になってから一回だけ呼べば良いという状況を作りあげることができるはずである。

幸運にもpangoのリファレンスを再度読み返しているとそういうAPIがあった(名前から推測するに、直接ccmapにアクセスして高速に処理してそうなもの)。そこで、これを利用することで、よりシンプルなコードを書くことに成功した。

だが、世の中、そんなに甘いものでもなく、通常の描画はほとんど高速化しなかった。(ケースによっては逆に遅い場合もあるようだ。) しかし、テストを重ねてみると、文字化け時等のハングアップするような以上な文字列の処理速度が劇的に高速化できた。文字化けすると若干待たされるという程度で1分近く固まるという状況は見られなくなっている。こちらが改善できたのがむしろ良かったかもしれない。

他にもpango_shapeの呼び出し回数を削減するプランはあるので、complex script用にその辺の実装も暇を見つけてやっていきたいと考えている。

Bug 5517 一部のマウスドライバでホイールが正常に動作しない 初回投稿日時: 2007年01月01日11時43分04秒
カテゴリ: Mozilla Core
固定リンク: id=2007010106
リンク元: 1件
SNS: (list)

Fx2.0.0.1でマウスホイールでスクロールできなくなる、というバグ。現在、レビュー中。

2.0.0.1用に入れたVistaのチルトホイール対応用のコードで、Win95向けのレガシーメッセージに対応したコードを壊してしまったのが原因だった。そのため、ごく一部の環境でしかこのバグは発見されていない。(現に、開発陣は誰も再現できないので、各所にテスト依頼を出したものの、本家Mozillazineで一件のレスが返ってきたのみだった。)

それにしても、未だにこんな古いメッセージを利用しているドライバがあったことに驚かされた。古い、一部のアプリへの互換性のためだろうという話もあるが、そうだとしてもWin98以降でサポートされた通常のメッセージを投げて、それで駄目ならレガシーなメッセージでリトライ、というのが普通な気がするのだが。

まあ、何はともあれ、私のここ最近の最も大きな失敗だった。迷惑をかけた方、すいませんでした。

Bug 5469 [Cairo] "Arial CE"を指定すると、bug 5322の現象がまだ発生することがある 初回投稿日時: 2007年01月01日12時57分49秒
カテゴリ: Mozilla Core
固定リンク: id=2007010108
リンク元: 0件
SNS: (list)

Font Name Resolverで解決できないフォント名がまだ一部あるというバグ。現在パッチレビュー申請中。

この件で初めて知ったのだが、Windowsではレジストリ上にFontSubstitutesというフォントのエイリアステーブルがあるらしい。レジストリからその情報を読み込んで対応するように修正するパッチを提出中。

Bug 5461 [Cairo][10.3.x only] ヘルプビュアーでヘルプが正しく表示されない(CSSのサイズ指定 "ex"が機能しない) 初回投稿日時: 2007年01月01日22時53分47秒
カテゴリ: Mozilla Core
固定リンク: id=2007010110
リンク元: 0件
SNS: (list)

OS X 10.3でのみATSUIからmetricsを取得してもx-heightが取得できないというバグ。

パッチを作ってみたが、10.4しか無いのでテストできない。10.3を持っている人は是非ビルドしてテストしてみて欲しい。

ただ、10.4上でmetricsに返ってくる値と、今回追加したコードの返してくる値には若干誤差がある。原因は不明。こんな重要なAPIがちゃんと動作しなかったり、APIによって値に差があったりと、Macは何を信用してプログラミングすれば良いのか分からない……

2007年1月2日

2007年1月6日

Bug 5533 [Cairo][GTK2] pango_shapeの呼び出し回数の軽減すべき #2 初回投稿日時: 2007年01月06日04時21分33秒
カテゴリ: Mozilla Core
固定リンク: id=2007010602
リンク元: 0件
SNS: (list)

修正完了。

一応、最終バージョンではcomplex scriptの場合も先にグリフの存在確認を行うようにして、コードの単純化と高速化を実現した。ただ、予想ができないのでcomplex scriptの場合にはshapeの後に全てのグリフがきちんと揃ったか確認するコードを入れている。不要かもしれないが、私の知識では分からない。もし、このコードが不要ということが説明できる人が居れば、bugzillaで説明して欲しい。(もちろんbugzilla-jpで日本語でもかまわない。)

テストしてくれた方の話では、文字化け時に数分固まる場合であっても10秒以内に表示されるようになったとのこと。理論的には通常のページの表示速度はミリ秒単位では遅くなっていることがあるが、よほど価値のある修正になっていると思う。

Bug 5514 [Cairo][Mac] bug 5486 による ts regression #2 初回投稿日時: 2007年01月06日07時13分29秒
カテゴリ: Mozilla Core
固定リンク: id=2007010607
リンク元: 0件
SNS: (list)

第二弾のパッチを投入したものの、tinderbox上では効果なし。私の環境では効果あったんだが……

だが、現時点の知識で削れるものは全て削ったので、これ以上の高速化は無理。結局、第一弾のパッチで高速化した分のみしか回復できなかった。(ただ、元が高速なのでどのみち体感は無理。)

相対単位はfont-sizeから算出されるのが正しいのか、font-size-adjustで補正された値が正しいのか 初回投稿日時: 2007年01月06日09時12分12秒
最終更新日時: 2007年01月06日15時59分49秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2007010608
リンク元: 0件
SNS: (list)

font-size-adjustを実装したものの、表示結果がおかしいという話が出た。

仕様書を読み直したものの、正解がよく分からない。ひょっとするとFx2までの表示は間違っているかもしれないが、CSS2の仕様書の書き方がひどく曖昧で、私には判断つかないので、dbaronに問い合わせてみた。

ただ、exの場合のみ、補正後の値で計算しているのでどのみちバグはありそうだ。それにしても同じテストケースをLinuxで表示してみるとえらく補正後のフォントサイズに差があることに気づいた。Windows版の計算結果はどうにもおかしいように見えてきたが、Fx2も同じ表示……テスト結果がWinとLinuxで大きく違ったのは最小フォントサイズ設定の影響だった。現実には問題にならないだろうが、ちょっとまずいような気もする。

2007年1月21日

new text frame 初回投稿日時: 2007年01月21日05時40分29秒
カテゴリ: Mozilla Core
固定リンク: id=2007012100
リンク元: 0件
SNS: (list)

まだ有効になってないものの、既にtrunkにはnew text frameが入っている。Rocの素晴らしい仕事の結果だ。

全体的に今までのコードが整理されて、構造もgfxと密接に連携するようになったためにかなり見やすくなっている。(以前のtext frameは膨大なCSS処理を不自由なgfxのインターフェースで実現するためと、省メモリ化と高速化の両立のためにすごい状態だった。スパゲッティの一歩手前だった。人によっては既にスパゲッティに見えていたかもしれないが。それから考えるとよくここまですっきりしたもんだという感じにまとまっている。やっぱりインターフェースもユーザ主体に書き換えないとこうなるんだな、という感じ。)

しかしspacing周りのコードを目で追ってるが(まだこのフレームはパッチ無しには機能しない)、いくつか悩ましい点とかバグは発見。もうしばらく忙しい日々が続きそうだ。(改善点の方が大きいので一時的なregressionを悲観してても仕方無いのだが。)

2007年1月22日

Bug 5517 一部のマウスドライバでホイールが正常に動作しない #2 初回投稿日時: 2007年01月22日01時15分58秒
カテゴリ: Mozilla Core
固定リンク: id=2007012200
リンク元: 0件
SNS: (list)

報告するのを忘れていたが、既に修正されていて、再現していた人たちからのフィードバックでもnightlyで問題なくなった様だ。つまり、Fx2.0.0.2では修正されているはずである。全ての協力者に感謝。あと、すみませんでした。

チルトホイールに完全対応完了 初回投稿日時: 2007年01月22日01時22分54秒
カテゴリ: Mozilla Core
固定リンク: id=2007012201
リンク元: 0件
SNS: (list)

MSの情報収集をおこたっていて気づいていなかったが、昨年12月5日にIntelliPoint 6.1がリリースされていた模様。このバージョンではVistaで追加される新メッセージを他のWindowsでも送信してくれるように修正されているようだ。このため、チルトホイールによる横スクロールがMSのマウスでは正常に機能するようになっている。

Bugzilla-jpでのログを見ると、11月23日に私がMSにフィードバックしていたのでリリース直前に修正を入れてもらえたことになる。素晴らしい。そして、開発現場の方、ごめんなさい。でも、MSのマウスへの好感度がさらにアップ。

そして、ベータ版のドライバをわざわざテストしてくれたえむけいさんにも感謝。いつもありがとうございます。

2007年1月26日

Bug 5564 [GC] CSSのcountertで何も表示されない 初回投稿日時: 2007年01月26日04時56分17秒
カテゴリ: Mozilla Core
固定リンク: id=2007012600
リンク元: 0件
SNS: (list)

どうもセキュリティバグのregressionだった模様で、本家でも誰も気づいていなかった様だ。1.8 branchでも発生していたので、そのまま2.0.0.2がリリースされたらヤバイところだった。

報告したら数時間で修正してくれたが、内容を見たら、前のバグで本当にテストしたの? という感じの修正だった。これは良くない。

それにしてもこんな風に、コンテンツを作っていてバグを登録して、本家に修正してもらうというプロセスがすごく懐かしい。なんか近頃は自分の修正するバグのためにしか報告してないことが多いもので。

2007年1月29日

display: inline-block;display: inline-table;のサポート 初回投稿日時: 2007年01月29日01時55分44秒
最終更新日時: 2007年01月29日03時04分43秒
カテゴリ: Mozilla Core
固定リンク: id=2007012900
リンク元: 1件
SNS: (list)

Trunkでようやく修正された模様。いくつか適当にテストケースを書いてみる。

シンプルな例

inlineinline blockinline

text-decoration: underline;のテスト

inlineinline blockinline

vertical-alignのテスト

inlinevertical-align: baseline;vertical-align: middle;vertical-align: top;vertical-align: bottom;vertical-align: text-bottom;vertical-align: text-top;inline

2007年1月31日

Bug 5550 [Cairo][GTK2][BeOS] fontconfig関連のコードは共有すべき 初回投稿日時: 2007年01月31日04時08分13秒
カテゴリ: Mozilla Core
固定リンク: id=2007013100
リンク元: 0件
SNS: (list)

コードのリファクタリングのみのバグを修正。といってもロジックの変更は一切なし。

LinuxとBeOSは共にfontconfigとpangoに依存しているのに、thebes内でpangoのコードは共有、fontconfigは同じコードが二重に存在するという状況だった。その、二重化している部分を共通のクラスに追い出してコードのメンテナンス性を普通の状態に戻している。