ねこめしにっき（2003年1月下旬）

2003年1月31日

OSX 用 Carbon IE5.x で PNG を直表示 (2003/01/31 - 19:13)

どこぞの掲示板で自分のセミヌード画像（ PNG形式）のURLを示したら、プラグインがないとか言われて見られない、と管理人のひとに言われた。そのひとの使っているブラウザやOSが古いのかもしれないと思い、ソフトウェア・アップデートで最新版にした手元のIE 5.2.2で見てみると・・・選択されたファイルの処理法方が不明です。（以下略）とか言われた。一瞬、理解に苦しむ。

[ PowerMac G4 - MDD その三 - Rj's SkaaRj Page_131 の「その他」の項の 2003/01/27 分 より ]

OSX 用の Carbon 版 IE5.x で PNG を直表示しようとすると、「処理方法が不明です」とか言われてできない件の解決法は、 FAQ だと思ったのですがー。そうでもないのかな。

  1. IE5.x の環境設定ダイアログを開いて、「ファイルヘルパー」の項を見る
  2. 拡張子 .png の設定項目を探す。ひとつだけでなくて、image/png と image/x-png の物、 2 つが見つかるかも。
  3. それらそれぞれ、「変更...」ボタンを押して設定画面を出し、「処理方法」を「ブラウザで表示」に設定。

ここまでは常識の範囲で設定できる事なのだけど、いったん IE を終了しちゃうとこの設定変更がなぜか元に戻っているという怪奇現象がでるわけですやね。それを防ぐためには、以下の手順もしなきゃいけないのですー。

  1. アップルメニューから「システム環境設定」を開き、「QuickTime」アイコンをクリック
  2. 「プラグイン」ペインにある「MIME 設定...」ボタンを押す
  3. リスト中の「Images - Still image files」の三角トグルをクリック
  4. その中の「PNG image file」のチェックを外す

以上でどうでしょー。

Safari の表示崩れは放置中です (1) (2003/01/31 - 09:08)

まっきんのはなし。Safari Developer Newsの一月二十九日の記事にて、WebCoreHMDT v53 for Safari v51というのを知る。WebCore v53(0.8.1.1)とJavaScriptCore v53(0.8.1.1)をSafariで使えるようにしたものです。でわ早速....

....取りあえず、さとみかんが凄いことになっているスクリーンショットそのいち、さとみかんが凄いことになっているスクリーンショットそのに。ファイルサイズが300キロバイト程あるので注意。スクリーンショットそのにを見ると分る通り、ページの途中からはちゃんと見えているのですが。

[ Onion Software HomePaGe! より ]

それら最新の Framework を入れたものでなくて、フツーに配布されてる v51 の Safari でも、ウチのサイトの「ぴんくすとらいぷ」スタイルは表示が壊れ気味。原因は、 ブロック系要素に対する :before / :after 疑似要素の content プロパティで自動生成したモノの表示が正しくないとゆー CSS バグ。生成要素の前後に勝手に改行が入るというか、 display:block 固定というか、しかも親要素の margin / padding をブチ抜いてしまうというかの、ナニコレ状態。まぁ飾り画像等の配置がブッ壊れてるだけなので放置してます。あ、アンカーを内包するインライン要素の左右マージンが効かなくなりがちとゆーバグもあるっけ。

というか、Safariは最新のインターネット 標準規格 に応じてWebページを適切にレンダリングするので、最新のHTML、XML、CSS、JavaScript、Java仕様を使ったページを正しく表示します云々と堂々言ってるんだから、甘やかしはしないぞー。 like Gecko を名乗る以上、 Gecko 同等を求めるぞー。みたいな。ちうか、今から新しく世に出るブラウザなら、 :before / :after や content くらいは楽勝で正しく扱えて当然な時代。…と言い切ってしまいたいほど CSS スタイラーたちは鬱憤がたまっているッ！（笑）

「Safari の表示崩れは放置中です (2)」へ続く。

XSLT でナビリンクをラクチンにしたい系 (1) (2003/01/31 - 08:38)

ナビリンクを自動的に作り出すような仕組みは前々から欲しかったというか、それも XSLT をやりたいと思った動機でもありまして。

今のトコはとりあえず、各日記ぺーじの元 XML には自分自身のファイル名が書き込んであって、ファイル名の羅列を記した別ファイル (XML) の中から、自分の前後に当たるページがどれなのか探るという、単純でカンターンなもの。それと、01c.xml#d31n01 てな属性値を与えるだけで、そこの ID にあるテキストを引っ張ってきてリンクアンカーを作れるテンプレとか。

今年分のにっきしか XSLT 前提の XML になってはいないんで、つまり、同ディレクトリ内の事しか考えてないからサッサと出来たって事もあるんだけど。ディレクトリ階層が上下しても大丈夫なようにしたいところ。さんざん苦労しまくりしそうな気分。

全てのファイルパス情報やリンク先 URL なんかを、あるディレクトリを基準とした仮想的な絶対パスでやれば多少はラクな気がするけど、リンクは可能な限り相対 URL でヤリたい所存でして、そういうテンプレなり補助スクリプトなりを考えなきゃならないのかなぁ、とか滅入っていたところ、さすぐぁ PaGe さんっっ！すでに作ってくれてたっっ！

実際につくったのは絶対パスを相対パスにする( a/b/c.xml と d/e/f.xml から ../../d/e/f.xml を作る、みたいなの)テンプレート(abs2rel.xsl)なんですが、標準関数にはないし、XT拡張で使える JavaAPI を探しても見つからず(まぁ、これについては探し方が悪かったのでしょうが…)。

…と思ったら Not Found ゆくえふめいー。がーん。

「XSLT でナビリンクをラクチンにしたい系 (2)」に続く。

disable-output-escaping のコト (2) (2003/01/31 - 07:52)

XSLT の変換において、 & を & ではなく & のまま属性値に含ませて出力したいの件「disable-output-escaping のコト (1)」に反応をいただいたです。

現在の XSLT 2.0 WD では xsl:attribute 要素の属性として disable-output-escaping 属性が用意されてます。つまり…そういうことらしいです。残念ですが。

[ Locus より ]

むむぅ。そういうことですか…。くやしいなぁ。

いちおう試しに xsltproc (libxml 20426, libxslt 10022 and libexslt 713) と Xalan-Java (2.4.1) で <xsl:attribute name="attr" disable-output-escaping="yes">&amp;#64;</xsl:attribute> を試してみたですが、文法ミスにわりかし寛容な xsltproc は disable-output-escaping 属性を無視してそのまま通して attr="&amp;#64;" となり、 Xalan-Java では "disable-output-escaping" attribute is not allowed on the xsl:attribute element! と怒られてみるオチ。

…で今はしかたなく @ そのままのメールアドレスになっているのですが、こころなしか spam が増えたような。そうでないような。つか、なんでこんなにたくさん spam がくるのでしょー。ぼくのメアドわ。くっそ。 1 日に 20 個とかって世間的にはどうなんでしょー。

2003年1月29日

Mac 版 Opera 存続ピンチ (2003/01/29 - 23:06)

[ べた日記 経由 ]

これは、Appleが今月、独自のブラウザ「Safari」を発表したことによる。Operaの最高経営責任者（CEO）Jon von Tetzchner氏は「これは本当にApple次第だ。Macプラットフォームは当社にとってもはや現実的ではないかもしれない」と語る。

MacIE5 が出てデフォブラウザになってから 3 年 (2000年5月) 、 OSX が出てから 2 年 (2001年3月)、 OSX がだいたい実用になってきた 10.1 から 1年半 (2001年9月) 。使用感はかなり良いものの MacIE5 は元々遅いブラウザである事、そして特に OSX 上でかなり遅い事、他に代替となる「現役」かつ「時代遅れ」ではない「速い」ブラウザの選択肢の無い事。これが、ここ 2〜3 年のマカ最大の不満だった。 Chimera や Safari が登場するまでは。

Opera は、この不満を満たすハデな登場をするチャンスだった1年以上の時間を、みすみすムダにしたんじゃん、と思った。いったいどれだけの間、Opera5 のベータ段階を続けてたん？ Opera6 にしても、2001年11月の Win 版 に遅れる事何ヶ月？（13ヶ月）

事実上の実用バージョンである 6 を、マカがいちばん欲しかった時期に出してくれず、やっとこ出てきから使ってみれば、依然として Mac らしい操作感の乏しいままで、 Win 版のようにすんげー速いわけでも無いどころか MacIE5 と大差無かったり（@日本語ページ）。これでマク世界のデフォブラウザ地位を奪う気マンマンだったっていうのも、たしかに虫の良すぎる話だった印象。

もし Opera7 の Mac 版を出すとすれば、 Safari 代替ブラウザの地位を Chimera と争うことになるかと。 Chimera って、Gecko が単体なら実はすげー速いって事の実証と（笑）、その高度なレンダリング性能を XUL の変態 GUI でわなく Cocoa な GUI 部品でカッチリ固めて、OSX アプリ普遍の操作感で使えるようにしましたってだけの、言ってみれば質実剛健かつ面白みの薄いブラウザなわけで。 Opera のウリは速さの一方、面白味の部分もあったハズだから、生存余地はありそうな。ただ、開発リソース的になのか信念が無いせいなのか知らんけど、マクらしい操作感の会得はどうにも期待薄っぽい印象が、やっぱガンか。

(*ﾟДﾟ)ﾆｮｫｫｫｫｫｫｫ!!!!!!!! (2003/01/29 - 02:20)

にょーと言われて黙っているわけにわいかんのですっ。

2003年1月28日

disable-output-escaping のコト (1) (2003/01/28 - 23:37)

XSL も XML ゆえ、 & とか < とか > とかは文字参照しないと使えないのでありまして、変換出力もその文字参照のまま出されちゃうわけで。 それじゃイヤンな場面に、文字参照を展開し（元に戻し）た状態で変換出力するには、 <xsl:value-of> とか <xsl:text> を使って disable-output-escaping 属性値を yes にすりゃいい、それはわかりました。では、出力ソースのとある要素の属性値に、文字参照を元に戻した状態のモノを持たせるにはどうすれば？？

たとえばこんなテンプレ

<xsl:template match="/">
  <xsl:element name="elem">
    <xsl:attribute name="attr">
      <xsl:text disable-output-escaping="yes">&amp;#64;</xsl:text>
    </xsl:attribute>
    <xsl:text disable-output-escaping="yes">&amp;#64;</xsl:text>
  </xsl:element>
</xsl:template>

Xalan-Java または xsltproc どちらの XSLT プロセッサでも、出力されるソースはこんなんになっちゃう。

<elem attr="&amp;#64;">&#64;</elem>

つまり、いくら disable-output-escaping 技を使ったところで、要素の属性値になるものだと、強制的に文字参照化が掛かってしまうとゆー。どうしたらいいのでしょう。 CDATA セクションとして直書きするしかないのでしょーかー。汚くなるからいやだなぁ…。

具体的に何がしたいのかというと、spam 防止のために <a href="mailto:..."> のメールアドレス中の @ を &#64; に変えておくっていうアレをヤっときたいのです。

そういえば最近、メールアドレスを暗号化して spam を防止すると称して、メールアドレスを数値文字参照化するだけ、もしくはそれを適当に分割して document.write で繋いだ HTML ソースを出力、というツールを見かけた。そうかーそれを暗号化と言うのかー…というのはさておき（笑）、メアド収集ロボットが数値文字参照を解釈できず、カンタンな JavaScript 構文解析さえできない状態で、いつまでいてくれるだろーか、みたいな根本的心配もあったりする昨今ー。

「disable-output-escaping のコト (2)」に続く。

2003年1月25日

XSLT やっとこ始動 (2003/01/25 - 21:40)

ここんとこずっとやってた、はぢめての XSLT 。日記の更新がかろうじて可能なトコロまで、よーやく XSLT スタイルシートが出来てきた。でもまだ 5 割方の進捗度だし、ゆくゆくは全ページを XSLT 変換方式にしたいし、変換発動コマンド打ち→アプロードの自動化の手はずもまだだし、苦闘は続くー。

変換元ファイルは、日々のソース手書きがラクチンにできるように、見出しとそれに暗示的に従属する本文部分が平たく並んだ、いわゆる「フラットでリニアな HTML 」的な XML にしてみた。これを従来手書きしてた XHTML2 的 section/h 構造的 div 鬼入れ子 XHTML1.1 へ XSLT で変換して、んでアプロードするって案配。 mi の補助があるにしても、セクション構造明示の入れ子が深い HTML/XML ソースを直書きするのは、やっぱタイヘンだしー。フラットリニア見出しズラズラ式のが、 日々のソース書きはラクチンにきまってるしー。

しかしそれは、フラットリニアなモノを元とすると、構造の取り出しや取り扱いにヒジョーな困難が伴うっつー具体例を満喫できる罠であった。…って、「フラットな文書を構造化」で紹介されてる、そふぃあさんの XSLT のロジックをかなり参考にしたというかパクっただけだろというか。いちおう再帰呼び出し式に変えたりしたけど、かえってワケワカになった気が。うへ。

さて、 div.section 鬼入れ子式になってる既存の HTML ソースをフラットリニア XML へ変換する方のスタイルシートも、完成をいそがねば。そっちのほうはいくぶんラクではあるのだけど、なにぶんマークアップポリシーに揺らぎがありまくるファイル群が相手だから、そこがなぁ…。

2003年1月22日

プロトコルからして違います (2003/01/22 - 00:54)

村のＨＰは二〇〇一年三月に開設され、総アクセス数は計約三万件だった。しかし、問題が表面化した十五日以降、接続が急増し、二十日午前までの六日間で四万件を超え、書き込み欄「夜なべ談議室」には一千件以上のメールが殺到した。

記事の本筋自体は、典型的なバカバカしい悪平等感覚が腐ってるにちまいないってだけの話で、どうでもいいんですが（そうか？）、新聞とかテレビとかのレガシーメディアってなんで、 Web 掲示板への書き込みのことをメールって呼んでる事が多いんですかぁー。

- (2003/01/21 - 00:00)

id 振り間違えて、この項は欠番。…。

2003年1月21日

VideoLan Client 0.5.0-test3 (2003/01/21 - 22:50)

[ っき日記 経由 ]

もち MacOSX 版をお試し。おお。いいかんじ。音量をスライダーで調節できるよーになったのがまずステキで嬉しい。それと、日本語リソースが最初から用意されてるのもイイ。

OSX における 0.4 系列では、音量がやけに小さいとか、再生時間の表示が出ない事があるとか、再生位置つまみの表示位置が妙になりやすいとか、再生位置を飛ばすと再生が止まりやすいとか、時々アプリケーション終了が効かないとか、いろいろあったけど、ちょっと試した範囲ではだいぶ解消されてるような気分。プレイリストというか再生履歴みたいなのがドロワーに出るのもナイスー。

ただ、メニューバーのメニュー項目表記が、まだ OSX 向けには調整されてないっぽ。 開く(_O)... 全画面化(_F) とゆー具合に、キーボードショートカットのキーアサインがメニュー項目の文字列中に入っちゃってる。これはマク以外のどこか別世界の流儀ですやね。

Copyright © 1998-2006 ALIMIKA SATOMI/NYAN-NYAN-HANTEN.