2007年1月1日
まだ作業中のバグ。
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側のインターフェースの変更の二つの案しか思いついていないが、なんとかなるかは不透明。まだまだ机上の空論のままである。
つい先日、MacにもFont Name Resolverが実装できた訳だが、そのキャッシュを馬鹿正直に起動時に全て作っているため、若干起動時間が遅くなってしまったので、どうにかしよう、というバグ。現在作業中。
現在のregression持ちの状態ですらMacだと私の環境ではFxは2.5秒で起動するという高速なプラットフォームなのだが、バックアウト論を封じ込めるために、若干の対策を政治的に行うしかない。今のところ、必要最低限の処理だけを起動時に行い、残りは逐次、必要になり次第システムから取得してキャッシュに追加していくという方式になる予定。
だがそのために若干メモリ消費量が上がるのは皮肉な話だが、まあ、シングルトンなクラスのメンバが若干増える程度なのでたいしたことは無いので心配はしないで欲しい。
font-familyでヒラギノ角ゴPro W6を指定しても、太字で表示されないというバグ。現在作業中。
元々、最初のFont Name Resolverでは正常に機能していたのだが、それに修正を加えた時にregressionが発生してしまった。
どうにもこのフォントファミリーというのは扱いが難しい。複数のフォントで共有されている名前なので、ファミリー名から、代表のフォントひとつに対してリンクしないといけないが、フォントを列挙している段階ではそれが分からない可能性があるというのが悩ましい。(代表的なフォントが後から列挙されてくる可能性があるため。)
Bug 5514で提出しているパッチで、一部の初期化処理を遅延することにしたので、その設計がこのバグの解決に決定打となってくれそうだ。現在の案では、ほとんどのファミリー名は起動時に列挙され、ファミリー名から代表フォントへのリンクはその後、必要に応じて逐一解決されていくという寸法だ。つまり、解決を図る時点では既に全てのフォントが列挙されてキャッシュ内にあるのでリンクが確立できるのである。
昨年、最後に修正したborderとoutlineの問題と同じ問題。Windowsでは発生を確認していないし、Linuxでもどうも起きない模様だが、Macでは原理上、必ず発生する。これも現在作業中。
これらの線の太さもスタイルシステムレベルで解決できると非常に楽だし、再描画時のオーバーヘッドも減るので望ましいのだが、残念ながらそういった仕様はCSS3のドラフトにあるのみなので、現時点では描画時に逐一処理するしかない。だが、下線等は複数の箇所で描画が行われているため、まずはこれらを一本化する必要がある。
一応、コードを検索した結果では、Quirksモード用や、IME、スペルチェッカーの描画を行うnsTextFrame、standardモードのインラインレベル要素用のnsHTMLContainerFrame、standardモードのブロックレベル要素用のnsBlockFrame、そしてXUL用のnsTextBoxFrameに散らばっていたので、これらから共通の関数を呼ぶように修正し、さらにその関数内ではCSS3の仕様に対応できるようにやや複雑な作りにして、点線、破線、実線、二重線の描画が可能なようにして、パッチを提出している。もちろん、これらの機能は内部的に実装されるだけで、CSSからコントロールできるようになるのはまだ先の話である。ちなみに、破線が利用できるようになるので、WindowsのIMEの未確定文字列はIEにあわせて、破線に変更予定である。(別バグで)
Macでは下線がほとんど表示されないというバグ。これも現在作業中。
簡単なパッチを提出していたのだが、後から作業し始めたbug 5527で修正できそうな感じだったので、一端取り下げていた。だが、実際にbug 5527用のパッチが出来上がってテストしてみると、Osaka-等幅では下線が相変わらず表示されなかった。
その原因はてっきり、bug 5473と同じく、クリッピングの問題かと思ったのだが、デバッグしてみると、なんとMacOSが太さをゼロと返してくるのが原因だと分かった。
これは酷い。他のバグを見ていても思うのだが、MacOS XのATSUIは非常に完成度が低いと思う。しかも、OSのバージョンがあがる度にAPIが廃止されまくるのだからたち悪い。これじゃアプリケーション開発者が付いてこないよ、と言いたくなるような状況だ。
愚痴はさておき、結果的に、gfx側でMacの下線等の太さは最低1ピクセルはあるように、値を補正するしかないようだ。これは印刷時に適切な値で描画できなくなる弊害があるのでパッチを取り下げていたのだが、結局そのパッチのレビュー申請を再度行っている。より良い解決策ははっきり言って思いつかないからだ。
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用にその辺の実装も暇を見つけてやっていきたいと考えている。
Fx2.0.0.1でマウスホイールでスクロールできなくなる、というバグ。現在、レビュー中。
2.0.0.1用に入れたVistaのチルトホイール対応用のコードで、Win95向けのレガシーメッセージに対応したコードを壊してしまったのが原因だった。そのため、ごく一部の環境でしかこのバグは発見されていない。(現に、開発陣は誰も再現できないので、各所にテスト依頼を出したものの、本家Mozillazineで一件のレスが返ってきたのみだった。)
それにしても、未だにこんな古いメッセージを利用しているドライバがあったことに驚かされた。古い、一部のアプリへの互換性のためだろうという話もあるが、そうだとしてもWin98以降でサポートされた通常のメッセージを投げて、それで駄目ならレガシーなメッセージでリトライ、というのが普通な気がするのだが。
まあ、何はともあれ、私のここ最近の最も大きな失敗だった。迷惑をかけた方、すいませんでした。
Windows版は相変わらず壊れたまま。現在レビュー申請中。
Font Name Resolverで解決できないフォント名がまだ一部あるというバグ。現在パッチレビュー申請中。
この件で初めて知ったのだが、Windowsではレジストリ上にFontSubstitutesというフォントのエイリアステーブルがあるらしい。レジストリからその情報を読み込んで対応するように修正するパッチを提出中。
borderはAA無しで描画されるのに、outlineだけAAが効いた状態で描画されるというバグ。現在、パッチレビュー中。
OS X 10.3でのみATSUIからmetricsを取得してもx-heightが取得できないというバグ。
パッチを作ってみたが、10.4しか無いのでテストできない。10.3を持っている人は是非ビルドしてテストしてみて欲しい。
ただ、10.4上でmetricsに返ってくる値と、今回追加したコードの返してくる値には若干誤差がある。原因は不明。こんな重要なAPIがちゃんと動作しなかったり、APIによって値に差があったりと、Macは何を信用してプログラミングすれば良いのか分からない……