この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
400GのMaxtorのHDDが突然、悲鳴をあげながらWindowsをハングアップさせてクラッシュ。
買って1年経っていないHDDが落下とかの事故もなくクラッシュしたのは初めて。MaxtorのHDDは二度と買わないようにしよう……
キャプチャしたアニメのエンコード済みファイルの保管庫だったので吹っ飛んでも痛いものではなかったのが不幸中の幸い(どうせ見る時間など無いし)。これを機にシステムドライブ以外は全てeSATAで外付けにするか。
昨日IRCで聞かれたネタ。Javascriptを使えば算出は可能。
display: none; font-family: 調査したいフォント名; font-size: 32px; /* 大きいほど精度が高く、UAの最小フォント設定に邪魔されない */
font-family: inherit; /* 不要? */ font-size: 1ex;
getElementByIdが楽ちん)getComputedStyle(element, null).getPropertyValue("font-size").replace("px", "")で算出値を取得する(もし算出値がpxじゃないUAがあればpxへの変換が必要だが、簡単なので省略)一応、font-size以外のプロパティを使えば一つの要素で処理可能と思います。
だそうです。Acid2もクリアしてますね。
文字化け時にランダムにクラッシュしていたバグ。
uniscribeの内部で落ちていたのは分かっていたのだが、原因がよく分からずに後回しにしていた。
printfで地道にログを吐いてみると、どうもshapingを無効にした状態でScriptShape APIにサロゲートペアの文字を渡すとランダムにクラッシュすることがある模様。
本当にサロゲートペアの場合だけなのか、またサロゲートペアでも問題無いものもあるのかどうかは分からないが、プロプラなWindowsではこれ以上調査不能なので、サロゲートペアの文字はshapingを無効にするときにU+FFFDに置換するようにして回避。StuartがMSに問い合わせてくれるそうなので、ちゃんとした修正が後ほど入るかも。
Linuxで最初の候補のフォントで表示できない文字があると表示できるフォントを探すのが致命的に遅いというバグ。
今はtext run cacheがあるので、text run内で表示直前の状態を一時的にキャッシュするようにした。
テキストをレイアウトするときと描画する時で最低2回はshapingが必要なので、その部分が今回のキャッシュでヒットすればかなり高速化するが、それに失敗すると今まで通り。どうも失敗することもあるようなので要研究。
Font Name ResolverがLinuxではきちんと動作していなかったバグ。既に修正済み。
LinuxでもCSS2のfont-size-adjustをサポートすべきというバグ。
gfxPangoFontで実装したので、LinuxとBeOSの両方で有効になっている。
Macの行高算出に関するバグ。
Macでシステムから取得できるleadingはAppleのドキュメントを読むと、external leadingだったが、Thebesではそれをinternal leadingとして扱っていたのが原因。
取得したleadingをexternal leadingに保存し、internal leadingはascentとdescentの和から元のサイズを引いたものを利用するように修正した。
ようやく解決の糸口が見えてきた。
Cocoaの高レベルだけど融通が利かなさすぎる仕様に悩まされてえらく時間をロスしてしまったが、結局ATSとかATSUIのおかげでなんとかなりそう。(CFStringのバグか仕様かよく分からない挙動にもかなり悩まされたが……)
実装完了。いくつか問題は残っているのでそれは順次対応予定。
これで開発が始まったOS/2版以外には全てFont Name Resolverが実装されたことになる。結果としてコールバック関数で解決するようにしたのは正解だったようだ。ベタにやっていたらLinux/BeOSの実装は大変だっただろうし、WindowsでもFontLink実装の目処は立たなかったと思う。
Windows版ではえむけいさん、Linux版では大島さん、takenさん、松浦さん、Mac版では本家でphilippeさんにとてもお世話になったし、こういった協力が無ければ、現在のクオリティでできなかったかもしれない。とりあえず、オープンソース万歳と言っておく。
MacのFont Name Resolverで解決。
Vladの意向で、フォントリストの一覧は旧バージョンよりも他のcocoaアプリケーションに合わせるようにしたため、現在、デフォルト設定等の表示がうまくいかなくなっているが、それはまた別のバグ。
ローカライズされたフォント名にも問題があり、その問題はWindowsにも昔からあるので、この機会に直してみる必要がありそう。
こちらもMacのFont Name Resolverで解決。
このバグの修正で、ようやくMacでもちゃんと日本語が表示されるようになった。
-moz なぞ私が CSS に付記する気はサラサラないので、昨日のはてな記法を Gecko 系で開くと、ひどいことになっていた。
まだ問題が残っているので未来への互換性のために-moz-を取り除いていないんですが……斉藤さんの書き方だとバグ持ちでも削除しろと言ってるように見えます。
ちなみに、まだ勧告前の仕様を使うのだから、それなりに自覚して使ってください。一応、仕様案としては既にstableなようですが。
私が対応しないといけなさそうだったバグをSimonが修正してくれてラッキー。
これでWindowsのテキストレンダリングで、常用で困るレベルのバグは全部消えたかな?
borderの太さが一定しないというバグ。
dbaronがcomputed valueの段階で丸めるべきだと言ってたが、CSS2.1仕様とは食い違うのでそれはマズイと言ったら、珍しく私の方が正しかった。というわけで、内部的にはちょっと面倒な形になってしまっている。
実際の修正内容はCSSのborderの情報を格納している構造体をちょちょいといじっただけなのだが、問題が問題なので結構てこずった。今まではspecified value(ただし、長さは内部処理用のtwipsに変換されている)とcomputed valueの二種類を内部で持っていたが、実際にはレンダリング用のactual valueが必要なわけだ(actual valueでレイアウトもやってしまおうというのがdbaronの案)。で、actual valueを新規に保持してしまうと、メモリ使用量が上がってしまうので、どうするか悩んだのだが、調べてみると、計算無しにspecified valueとactual valueからcomputed valueが導き出せるようなので、computed valueを保存していたところにactual valueを保存することにした。これでメモリ消費を抑えることができた。しかし、actual valueをspecified valueに変換する際にtwipsから物理ピクセルへの変換情報が必要なので、それをキャッシュするために4バイト使ってしまった(増えてしまった)。だが、今のところこれは仕方がないだろう。悩んだものの、良い解決策は思いつかなかった。
で、実際にどういうことをやるようにしたかと言うと、まず、specified valueがゼロの場合は、actual valueもゼロに、それ以外の場合は最低でも1物理ピクセルを確保するようにした。また、specified valueが物理ピクセルに対して端数がある場合、近い方の物理ピクセルに丸めるようにしている。
つまり、actual valueがゼロならゼロ、それ以外ならspecified valueがcomputed valueになるわけである。
これでIEとは互換がとれたが、Operaは何故かゼロに丸めてしまう。単純な四捨五入だけやっているということなのだろうか。だが、この処理はWebデザイナの意図をくみ取れていないと思う。borderが非ゼロなら、デザイナは線を引こうとしたのだから、表現可能な最低限の太さで表示させるべきだと私は思う。
更に、dbaronの調査によると、safariは切り捨て、KonquerorはIEと同じらしい。うーむ。まだ揉めてるのかな?
また、同じような仕様のoutlineに関しても同様の処理を入れている。今まではborderとoutlineの間に隙間ができることがあったが、この修正でそれも解消している。(アンチエイリアシングの問題で微妙な隙間ができることはまだあるが。) ただ、元からoutlineの内部処理はborderと若干異なっているのでソースを読む方は注意して欲しい。
しいたけ。
やっぱり、登録しませんか? AMOに。 > 裸電球さん