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

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

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

2007年8月7日

改行関係のバグ、第二陣 #2 初回投稿日時: 2007年08月07日04時30分37秒
カテゴリ: Bugzilla-jp Mozilla Core
固定リンク: id=2007080700
SNS: (list)

一応最新の経過を。

一応、本家では様々な副作用が指摘されていて対策パッチをアップデートし続けている状態。対策は基本的には「Westernな文字っぽい開き括弧クラス」と、「Westernな文字っぽい閉じ括弧クラス」をでっちあげて(JIS X 4051にそんなクラスは無い)、「Westernな文字クラス」とそれらのクラスが隣接した場合は改行しないようにしている。つまり、改行される箇所は徐々に減らしている。

現在の見通しでは、基本的にURLに含まれない記号類とバックスラッシュ以外はそのようになると思われる(というか私が音を上げた)。

ただし、あくまで文字との組み合わせで改行を抑えるだけなので例えば(_ _)(_ _)のような場合、)(の間では改行される。

また逆に単語内にある最初のスラッシュとバックスラッシュは改行されない。これは、これらの文字を「Westernな文字っぽい開き括弧クラス」にするためだ。現状のtrunkではこれらの後ろで改行するが、「開き括弧」になるので、前で改行するように変更することになる。つまり、どいういう結果が得られるかというと、http://example.com/foo/bar/のような絶対URLは最初のスラッシュがまずは改行対象から外れ、その次のスラッシュも、前が「開き括弧」のスラッシュなので(イメージとしてはhttp:((これと同義)、二つ目のスラッシュも改行されない。ドメイン名の後ろに来るスラッシュで初めて改行が発生する。つまり、幅がとことん狭い場合、以下のようにレンダリングされる。

http://example.com
/foo
/bar/

1行目を見ると若干違和感があるかもしれないが、それも計算の内である。ディスカッションしていて思い知ったのだが、とにかくWesternな言語の人はハイフン以外で単語が分割されるという発想が無い。つまり、スラッシュで自然に終わると単語がそこで終了していると判断しかねない。

2行目に注目すると、スラッシュで始まっている。このため、これはパスの一部であることが、パスを知っている人にとっては一目で分かる。

3行目にも注目して欲しい。最後の文字がスラッシュの場合、特例措置として改行は発生させない。これによってスラッシュのみの行の生成を抑制できる。

Unixのパスで考えてみると、絶対パスの場合、/home/fooは、/home/fooになる。また、ホームを基準とした場合にも~/foo/barは、~/foo/barとなる。一つ目のスラッシュで改行が発生しないので~のみの行ができることはない。相対パスでもfoo/bar/foo2foo/bar/foo2となるので、必ずスラッシュが含まれている。../../fooの場合、../../fooとなる(最新のパッチでは、これはバグっているかも……)。似たような処理はバックスラッシュにも適用されているのでWindows形式のパスでも大丈夫だ。

またハイフンも引き続き、いくつかの特殊ルールが適用される予定だ。例えば日付の表示等のために。

将来的にはもう少しまともな処理が必要だが、今はとりあえずURLとパスの改行に的を絞ろうとしている。もし、これら以外に日本ではこういうパターンは改行されないとまずい、というのがあったら是非フィードバックが欲しい(bugzilla-jpに日本語で良いので)。

私が考えている日本にとって必要な最低限の改行すべき文字はスラッシュ、バックスラッシュ、パーセント、イコールの四つ。この四つに関してはなんとかしたいと考えている。(アンパサンドではなくイコールで改行するのは、アンパサンドだと欧米での望まれざる改行が多々発生する上、HTMLの仕様上、セミコロンでの改行も必要になってしまうためだ。)

Bug 5527 text-decorationの下線/取消線/上線の太さが一定にならないことがある #2 初回投稿日時: 2007年08月07日06時24分33秒
カテゴリ: Mozilla Core
固定リンク: id=2007080702
SNS: (list)

下線等の太さがテキストの場所(Y座標)によって変わったり、線とテキストの位置関係が不安定だったりした長年のバグ(たぶん。Fx2以前で発生していた記憶はあまり無いが、コードの原理的にはあり得る)。

ようやく修正完了。まだ位置関係の問題は若干の丸め誤差があるので発生するかもしれないが、ほとんど発生しなくなっている。Macで特にこの問題がひどく出ていたのでMacユーザには修正が一目瞭然かもしれない。

2007年8月8日

なかのひとを入れてみた 初回投稿日時: 2007年08月08日02時54分11秒
カテゴリ: WebStudio
固定リンク: id=2007080800
SNS: (list)

ちょっとおもしろそうなのでもずはっく日記に入れてみた。

2007年8月16日

Bug 5473 リンクの下線が表示されない 初回投稿日時: 2007年08月16日05時30分52秒
カテゴリ: Mozilla Core
固定リンク: id=2007081600
SNS: (list)

フォントと、その表示位置によっては下線の描画、再描画、消去がうまくいかなかったバグ。

例によって小数の丸め誤差の問題だが、Fx2以前とは違い、XPなコードで下線の下端がフォントのディセンダよりもベースラインより離れる場合、ディセンダを下線に必要な高さに置換するようにしたのでWin以外でも問題はなくなっているはず。

2007年8月22日

Bug 5091 [Cocoa] 日本語未確定の状態で他入力欄へ移動し、再び元の入力欄に戻った時の表示不正 初回投稿日時: 2007年08月22日02時59分07秒
カテゴリ: Mozilla Core
固定リンク: id=2007082202
SNS: (list)

修正完了。結局CarbonのAPIを使うはめになった。

それにしてもMacのCocoaはあまり使い物にならない。Cocoaは簡単なアプリを作るためのもので、Geckoのように低級なレベルからごにょごにょやりたい場合にはむかないのだろう。

今週の注目オンラインソフト 初回投稿日時: 2007年08月22日08時31分12秒
カテゴリ: Firefox 雑談
固定リンク: id=2007082203
SNS: (list)

ただ、Firefoxは、シンプルな本体にプラグインと呼ばれる拡張機能を組み込んで機能を強化することを前提に作られている関係上、使いこなしには自分の目的に合ったプラグインを探すなど、ある種の努力が必要になります。また「お気に入り」にあたる機能にIEとの互換性がないので、やはりIEに戻りたいとか、お試しでIEと平行して使いたいといった場合にちょっと不便です。そんなときにぜひ試してほしいのが、今回紹介する「Grani」です。

ぶーぶー。

2007年8月23日