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

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

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

2006年12月4日

またしてもHDDクラッシュ 初回投稿日時: 2006年12月04日01時47分25秒
カテゴリ: 雑談
固定リンク: id=2006120400
リンク元: 0件
SNS: (list)

400GのMaxtorのHDDが突然、悲鳴をあげながらWindowsをハングアップさせてクラッシュ。

買って1年経っていないHDDが落下とかの事故もなくクラッシュしたのは初めて。MaxtorのHDDは二度と買わないようにしよう……

キャプチャしたアニメのエンコード済みファイルの保管庫だったので吹っ飛んでも痛いものではなかったのが不幸中の幸い(どうせ見る時間など無いし)。これを機にシステムドライブ以外は全てeSATAで外付けにするか。

x-heightが何pxかを調べる方法 初回投稿日時: 2006年12月04日13時49分57秒
最終更新日時: 2006年12月04日14時11分39秒
カテゴリ: CSS Javascript
固定リンク: id=2006120401
リンク元: 2件
SNS: (list)

昨日IRCで聞かれたネタ。Javascriptを使えば算出は可能。

  1. 不可視の要素を二つ作り、一つを親、一つを子とする。
  2. 親要素のスタイルを以下のように設定する
    display: none;
    font-family: 調査したいフォント名;
    font-size: 32px; /* 大きいほど精度が高く、UAの最小フォント設定に邪魔されない */
    
  3. 子要素のスタイルを以下のように設定する
    font-family: inherit; /* 不要? */
    font-size: 1ex;
    
  4. 子要素をJavascriptで取得する(getElementByIdが楽ちん)
  5. getComputedStyle(element, null).getPropertyValue("font-size").replace("px", "")で算出値を取得する(もし算出値がpxじゃないUAがあればpxへの変換が必要だが、簡単なので省略)

一応、font-size以外のプロパティを使えば一つの要素で処理可能と思います。

2006年12月11日

Reflow branch合流 初回投稿日時: 2006年12月11日01時35分52秒
カテゴリ: Mozilla Core
固定リンク: id=2006121100
リンク元: 0件
SNS: (list)

だそうです。Acid2もクリアしてますね。

Bug 5359 [Cairo] 文字化け時にクラッシュすることがある。 初回投稿日時: 2006年12月11日01時40分40秒
カテゴリ: Mozilla Core
固定リンク: id=2006121101
リンク元: 1件
SNS: (list)

文字化け時にランダムにクラッシュしていたバグ。

uniscribeの内部で落ちていたのは分かっていたのだが、原因がよく分からずに後回しにしていた。

printfで地道にログを吐いてみると、どうもshapingを無効にした状態でScriptShape APIにサロゲートペアの文字を渡すとランダムにクラッシュすることがある模様。

本当にサロゲートペアの場合だけなのか、またサロゲートペアでも問題無いものもあるのかどうかは分からないが、プロプラなWindowsではこれ以上調査不能なので、サロゲートペアの文字はshapingを無効にするときにU+FFFDに置換するようにして回避。StuartがMSに問い合わせてくれるそうなので、ちゃんとした修正が後ほど入るかも。

Bug 5490 [Cairo][Pango] Itemizingの高速化 初回投稿日時: 2006年12月11日01時50分06秒
カテゴリ: Mozilla Core
固定リンク: id=2006121102
リンク元: 0件
SNS: (list)

Linuxで最初の候補のフォントで表示できない文字があると表示できるフォントを探すのが致命的に遅いというバグ。

今はtext run cacheがあるので、text run内で表示直前の状態を一時的にキャッシュするようにした。

テキストをレイアウトするときと描画する時で最低2回はshapingが必要なので、その部分が今回のキャッシュでヒットすればかなり高速化するが、それに失敗すると今まで通り。どうも失敗することもあるようなので要研究。

2006年12月14日

Bug 5481 [Cairo][Mac] 'Lucida Grande'でline-height: normal;とすると行高が大きすぎる 初回投稿日時: 2006年12月14日14時14分12秒
カテゴリ: Mozilla Core
固定リンク: id=2006121401
リンク元: 0件
SNS: (list)

Macの行高算出に関するバグ。

Macでシステムから取得できるleadingはAppleのドキュメントを読むと、external leadingだったが、Thebesではそれをinternal leadingとして扱っていたのが原因。

取得したleadingをexternal leadingに保存し、internal leadingはascentとdescentの和から元のサイズを引いたものを利用するように修正した。

2006年12月20日

Bug 5486 [Cairo][Mac] 与えられたフォント名から実フォント名への変換機能が必要 初回投稿日時: 2006年12月20日05時43分03秒
カテゴリ: Mozilla Core
固定リンク: id=2006122000
リンク元: 0件
SNS: (list)

ようやく解決の糸口が見えてきた。

Cocoaの高レベルだけど融通が利かなさすぎる仕様に悩まされてえらく時間をロスしてしまったが、結局ATSとかATSUIのおかげでなんとかなりそう。(CFStringのバグか仕様かよく分からない挙動にもかなり悩まされたが……)

2006年12月24日

Bug 5486 [Cairo][Mac] 与えられたフォント名から実フォント名への変換機能が必要 #2 初回投稿日時: 2006年12月24日14時48分29秒
カテゴリ: Mozilla Core
固定リンク: id=2006122400
リンク元: 0件
SNS: (list)

実装完了。いくつか問題は残っているのでそれは順次対応予定。

これで開発が始まったOS/2版以外には全てFont Name Resolverが実装されたことになる。結果としてコールバック関数で解決するようにしたのは正解だったようだ。ベタにやっていたらLinux/BeOSの実装は大変だっただろうし、WindowsでもFontLink実装の目処は立たなかったと思う。

Windows版ではえむけいさん、Linux版では大島さん、takenさん、松浦さん、Mac版では本家でphilippeさんにとてもお世話になったし、こういった協力が無ければ、現在のクオリティでできなかったかもしれない。とりあえず、オープンソース万歳と言っておく。

Bug 5467 [Cairo] フォント設定の選択リストで、日本語フォント名が表示されない 初回投稿日時: 2006年12月24日14時52分35秒
カテゴリ: Mozilla Core
固定リンク: id=2006122401
リンク元: 0件
SNS: (list)

MacのFont Name Resolverで解決。

Vladの意向で、フォントリストの一覧は旧バージョンよりも他のcocoaアプリケーションに合わせるようにしたため、現在、デフォルト設定等の表示がうまくいかなくなっているが、それはまた別のバグ。

ローカライズされたフォント名にも問題があり、その問題はWindowsにも昔からあるので、この機会に直してみる必要がありそう。

2006年12月28日

Re: white-space:pre-wrap 18:04 初回投稿日時: 2006年12月28日02時51分25秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2006122800
リンク元: 3件
SNS: (list)

-moz なぞ私が CSS に付記する気はサラサラないので、昨日のはてな記法を Gecko 系で開くと、ひどいことになっていた。

まだ問題が残っているので未来への互換性のために-moz-を取り除いていないんですが……斉藤さんの書き方だとバグ持ちでも削除しろと言ってるように見えます。

ちなみに、まだ勧告前の仕様を使うのだから、それなりに自覚して使ってください。一応、仕様案としては既にstableなようですが。

Bug 5272 [Cairo] ビットマップフォントやベクタフォントが優先指定されている場合に、それらのフォントに含まれていない文字をそのフォントで描画してしまうことがある 初回投稿日時: 2006年12月28日03時05分37秒
カテゴリ: Mozilla Core
固定リンク: id=2006122801
リンク元: 0件
SNS: (list)

私が対応しないといけなさそうだったバグをSimonが修正してくれてラッキー。

これでWindowsのテキストレンダリングで、常用で困るレベルのバグは全部消えたかな?

Bug 4355 px以外の単位を使うとborderの太さが一定にならない 初回投稿日時: 2006年12月28日03時34分52秒
カテゴリ: CSS Mozilla Core
固定リンク: id=2006122802
リンク元: 2件
SNS: (list)

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と若干異なっているのでソースを読む方は注意して欲しい。

2006年12月31日

Fwd: しいたけ 初回投稿日時: 2006年12月31日16時28分56秒
最終更新日時: 2006年12月31日16時29分29秒
カテゴリ: Firefox
固定リンク: id=2006123100
リンク元: 0件
SNS: (list)

しいたけ。

やっぱり、登録しませんか? AMOに。 > 裸電球さん