ねこめしにっき(2004年5月前半)

2004年5月14日

Camino 0.8 まもなく (2004/05/14 - 12:25)

[ えむもじら 経由 ]

ちうわけで、マイルストーンベースでいうと、 0.7 以来、もう一年以上ぶりのリリースがまもなくなわけで。

A bug in 10.3 causes text in IFRAMEs to "float" as the window is resized and not repaint correctly when scrolled. This will be fixed in a future version of MacOS X.
10.3 のバグのために、スクロール時にウインドウがリサイズされて再描画が正しく行われず、インライン・フレーム中のテキストが "回り込み" してしまいます。このバグは Mac OS X の将来版でフィックスされます。

なんか和訳が意味不明なのですが、これはあれですやね。OSX10.3 の Camino 大好きッコを現在も悩ませ中の「ページスクロール時に iframe の中の文字がその場所に張り付いたままスクロールについて来なくて、仕舞いにゃ何重にもグチャグチャに表示される」アレかと。とりあえず as the window is resized のトコがよくわからんわけだが…。

ちなみに overflow なブロックに関しても同様の現象が起きてて、というかむしろそっちのケースでお目に掛かるのがほとんどなわけだが、この界隈 (何処) の巡回時にかなりの確率で死ねます。

ってこんなトコロで指摘を書いてても意味ネーわけですが。

Opera7.50 for MacOSX (2004/05/14 - 03:13)

でましたね。

同バージョンの正規版が他プラットフォームと同時に出るなんて、マカーの Opera 大好きッコにとってはきっと夢のような慶賀でござりましょう。正直マク版はこの 7.50 においても、「最速ブラウザ」の称号からはほど遠い現状なのだけど、このところの Opera 社のけなげながんばり具合には、おもわず景気づけにポロリしたくなりますね。何をだ。

で、さて、UI 方面がカオスの極みにあるような Opera なんで、できれば日本語な GUI で使いたいトコロ。そこでおなじみのランゲージファイルの登場ですよ。 Idiot's Site For Operaてすととして配布されてる build3714 用 japanese.lng はモチロン WinOpera 用なのだけど、いつかの頃にやったように、これをそのままマク用にぶち込んでみるテスツを敢行した次第。

  1. build3714 japanese.lng をダウソする。
  2. Opera 本体のパッケージ内 Opera.app/Contents/Resources/ を Finder で開く
  3. そこにある en.lproj フォルダを同じ場所に複製して ja.lproj と名付ける
  4. ja.lproj の中にある en.lng は捨て、かわりに さきほどダウソした japanese.lng をここに置く。んで一応 ja.lng と改名しとく。

おわり。言語リソースフォルダとか lng ファイルの改名とかは、実は不要かもしれないけど、まぁそれはそれ。それと Win 版向けのをムリクソ使うわけで、各所で不整合があるかもしれんけど、気づかないような不整合はあっても気にするなっ (←?) とりあえずすぐ気づく不整合は、クイック設定あたりにある「IE6.0 として認識させる」あたり。

そして、以前みたく「実装状況てすと」なるものをヒマにまかせてヤるような余力は今は無いわけで (略 ただ業務方面でちょちょいと 7.50b1 あたりを検証したときは、 DOM 方面もかなりイイ線行くようになってきたなと思った。ただ Safari 同様に、なんでそこまでできて今更この程度のことができやんの?というのがまだチラホラと。

2004年5月12日

岡崎律子氏逝去 (2004/05/12 - 04:00)

[ かしぶろぐ 経由 ]

えええ。

岡崎律子といえばかの声質なわけだが、なんと言っても海モモ最終回エピローグの凶悪すぎるタイミングで入ってくる最凶の泣かせ曲「約束」。あれほど「ヤラレタ」感を覚えた事はそれ以来無いわけで。アニメで泣いたこともそれ以来無いわけで。

しかし決してマカーにはならないの法則 (2004/05/12 - 03:53)

しかし、こういう人々の多くは、たとえ買う金があったとしても決してマクを買うことなど無いし、買ったとしてもメインマシンにすることは無いという法則を、ノベてみるテスツ。

姓名判断なんて (2004/05/12 - 03:16)

なんでこんなに体がおかしいんでしょうか?年々体調がおかしくなってきてます。不信に思い姓名判断してみるとぎゃーあー。ちなみにネット界の有名人とかしてみると面白いですね。

[ 歯車館 talk より ]

なんじゃあこりゃあああ!

そういえばぼくも連休明けの風邪引きさんで微妙に大変です。たばこが吸えなくなったらいよいよヤバイわけだけども、まだオーケーの模様。タバコは健康のばろめーたー。嫌煙家のミナサマにおかれましては卒倒するしかないフレーズですが。

2004年5月7日

最近の Camino 事情 20040507 (2004/05/07 - 03:37)

Camino trunk 2004/5/6 7102234Byte
Bug 222972 - [panther] drawing of the page is totally cluttered up with whitespaces and some areas are blinking. のパッチを追加で適用しています。このパッチにより、Mac OS X 10.3.xで発生していた"白抜け"の問題がFixしています。

OSX10.3 リリース以来苦節 7 ヶ月。常用ブラウザとしては致命的すぎる例のフレームページのすさまじい白抜け現象の Fix がようやくキター!!

あーでも CSS overflow なブロックの中身が消えてあさっての場所に何重にも描画されて、その末路のまっくろくろすけ (謎) がページ上に巣喰うバグは健在だ…。同根だとおもってたのだけど、ちがうのか…。ちぇ。

それと最近の h-sek たんの独自ビルドに適用されてる新しいタブは気に入っているんだけど、バックグラウンドでタブを開く設定で使ってると早晩 Camino が落ちるという欠点が。あとなんかページ読み込みプログレス風車 (?) の描画が負担なのか、ページロード中はけっこう動作が重い。そしてどうやら 10.2 の環境では途方もなく Camino 死亡率を上昇させてる気配。カイシャの OSX は 10.2 なもんで…。トホ。

2004年5月6日

- (2004/05/06 - 08:05)

ゴールデンウイーク終了。そして今日からおしごと。下のを書いていたら寝る時間がなくなったヨ… orz

紙メディア前提の漫画をコンピタで読ムは難シ (2004/05/06 - 08:05)

名作劇場 (謎)」で紹介した、ウチの奥さん作の創作少女系同人誌「プリズム」全編 Web 公開ページにおける、現存のテクノロジーで解決されうると希望的に観測されるユーザビリティ問題について。注:長いです

上記ページは全ページ、 CGI (Perl Script) による動的生成。ただ、諸事情でかなり急ぎの公開だったゆえ、公開開始 (4月29日) 時点では 10 分くらいでテキトーにデッチあげた CGI で稼働させてた。多少の不便はともかく一通り閲覧できる事が最優先の勢いだったユエ。で、そのあとちまちま改良を重ねている次第。そのへんの主に時系列あたりを念頭にして、以下を読んでくらさいな。

目線位置固定の必要性

こういう「ページめくり系」でまず大事なのがコレ。ゆえに以下のような指摘が来るのはわかっていたのだけど、公開当初は (略)

インターフェースとして使いやすいか、見やすいかというと残念なところである。ページをめくるたびに画面に収まるよう位置を直して見るもんで、ページごとに思考が止まる感じ。だからとって、綺麗にまとめるために別ウインドウ開いてそちらでごにょごにょがいいというものでもなし。いまのところは多少汎用性は落としてPDFかFlashで固めてしまうのが良いのかもしれない。見やすさを求める人は頑張って画像ファイル持ってきて漫画閲覧ソフトあたりで。

[ はてなダイアリー - べべべのべ より ]

現状は、画像ブロック部分に ID フラグメント識別子を設定し、ページ遷移の際に常にそこが頭出しされるようにした。「とりあえずマシになった」感じ。そしておっしゃるとおり、閲覧専用の別ウインドウをどうのこうのするまでもないというか、そういうフーにしたところで「とりあえずマシ」を遙かに超えた抜本的な改善があるわけでもなく、むしろ別ウインドウを開く事によるアクセシビリティ低下のデメリットが (略)

画像ピクセルサイズをどうすべきか

閲覧者のディスプレイ環境やウインドウサイズが可変不定である PC 環境において、ビットマップ画像を閲覧させたい際は、これが常に最大の問題点。画像のピクセルサイズは、作者 (奥さん) の了承ほかモロモロ勘案して、A5 見開きを約 800 x 600 pixel (約 72ppi 相当) の画像としてる次第。それと、本来のサイトレイアウトを破棄し、画像ブロック部分の view port に対する左右 margin を無くして、ウインドウ幅を最大限使えるようにというささやかな対処も一応してありつつ。

絵もネーム (セリフ文字) もいっしょくたにビットマップ画像となっている以上、可読性を確保するにはそれなりのピクセルサイズが必要。しかし閲覧者の環境は多様不定だから、「ページ全部が画面に入りきらなくて読みづらい」とか、もしくはその逆で「画面にはおさまっても字が読みづらい (もしくはまるで読めない) 」のどちらかとなりやすい。閲覧アプリ (ブラウザ他) に拡大縮小機能があるにしても、縮小すれば見かけ上の劣化が起きて可読性が下がり、拡大すれば単にピクセルが矩形に拡大されるだけで細かいところがより見えるようになるわけではない。

つまり、どういうピクセルサイズを採ったとしてもビットマップ画像である以上不満は無くならない。視覚メディア特性と現代のディスプレイ事情を勘案し、もっとも不満層の少なくなりそうなトコで決め打ちし、そこから外れる層には「ごめんね」で終了するほかない。これは PDF や FLASH に固めたところで、漫画閲覧ソフトを用いたところで、元がビットマップ画像である限りついてまわる問題。 (そういう観点で案を出してるんじゃないのでしょけど。一応オコトワリ)

近未来、世の中のディスプレイの大半が、 A4 見開きのサイズを実効解像度 600 ppi 程度で画面上に出せるにようになれば、このあたりのビットマップ画像の可読性問題はほぼ完全に無くなるけど、それは夢のハナシ。(参考: A4 見開き 42.0 x 29.7 cm の 600 ppi はだいたい 9921 x 7016 pixel ) もしくは、誰か奇特な読者さんが、手持ちの同人誌をイケニエに解体し高解像度スキャンし、それを元に完全なベクトルデータにしてくれたりしたら、 PDF なり FLASH なり SVG なりに固める意義が出てきそう。ベクトルデータであれば拡大縮小の表示劣化から逃れられるし、そのための PDF なり FLASH なり SVG なワケで。

(ちなみにネームだけベクトルデータのフォントにするってのじゃ、だめよ?コンピタ DTP 的写植が個人レベルで非現実だった昔はさておき、現代では、セリフ文字に手書きを選択するのも表現の一つであり、商業誌ではあり得ない同人ならではの選択なのでして。)

実は、画像のタテヨコピクセルをそれぞれ倍 (144ppi 相当程度) とするだけでも、細かい字がかなり読める域に来るのだけど、それでさえすでに、一枚まるまるが原寸では入らない人が総人口の過半以上を占めると思われるのだけど、漫画閲覧ソフトなんか常用しちゃってるユーザ層 (ny 層?ワラ) にとっては、そっちのデータこそが欲しいのかもしれない。しかしそういう高解像度ピクセルデータにしろベクトルデータにしろ、そーいう富豪すぎるデータを無料閲覧用に提供するのは、即売会会場の肉弾地獄に血路を開きやって来て、しかも限りある身銭を切ってまでこの本を買ってくれた、作家的に最も大事にすべき読者たちに対してアレである、という至極もっともな観点がありまして。 (これはぼくの同人価値観とも一致する考え方) そして本来、同人誌なんてもんは一期一会であり、売られてる期間に売られてる場所に行けなければ、どうあっても読めないものであるはず。 (これはぼくの価値観)

ナビゲーションをどう整備すべきか

最初に覗いた時点 (2004/04/29 - 04:45) では link 要素で prevnext が指定してされておらずページをめくり辛かったので、その旨を伝えるメールでも送ろうかしら、でしゃばりにならないカジャラ、なんて悩んでいたらいつの間にか指定されてしまっていたというこの根っからのピエロっぷり。

[ Diary < Black Box より ]

サイト各個にデザインされた (そしてそれゆえに使いづらい) ナビリンクなどよりも、各ブラウザに対して、そのアプリや OS 汎用の概念や UI を用いたナビゲーション手段を提供させたほうが良いわけで、そのために標準的メタデータを link 要素などで用意するのが良いわけで、そんなのは語りまくり済み語られまくり済みなのだけど、昨今は「基本からもう一度クドクド語ってみよう週間」(謎) なわけで

しかし現実には「サイト各個にデザインされた (そしてそれゆえに使いづらい) ナビリンク」のほうが圧倒的に使われるし、それしか使えない時代遅れブラウザ WinIE6 が世の多勢なわけで、 link 要素のほうの実装はいつも後回し。そんな理想論を追いかけるのも大事なれど、それより大事なのは、普通の閲覧者が普通に閲覧できること。それがどんなダサい手段であっても。

ページが CGI 生成だとラクだから、いきおい現在表示してるページの前後 10 ページ分それぞれへのリンクを用意とか、してしまいがちなのだけど、そういう富豪的ナビリンクは以下略。前後ページへのリンクと、物語的にキリのいいページへの頭出しリンクがあればそれで十分。任意のページを呼び出すフォームとかも用意してしまいがちなのだけど、そういうのも割愛。画像貼り付け板じゃないんだから。わら。

こういう一連の続きモノ画像を閲覧させる際に、同人系サイトでよくある UI が「その画像そのものが次の画像へのリンクアンカーになっている」というモノ。「一覧インデックスに戻るアンカーになっている」事もあるけど、まぁ閲覧順路を規定しているという意味では同じかな。フツーだと画像自体がアンカーになってたら、さらに大きい画像へのリンクだと思いがちなのだけど、そうじゃないところが醜悪気味。言われなきゃワカランという点においては、そのどっちも醜悪さで同等。(ワラ

今回は、この同人系特有のナビ概念をちと拡張して、見開きの左ページのあたりをクリックすると次ページ、右ページだと前ページへ移動するようにしてみてます。クライアントサイドクリッカブルマップ。言われ無きゃわからない醜悪な UI ここに極まれり。こういった操作説明を書き添えれば良いかといえば、それをクドクド書くのがすでに醜悪なわけで。どうすれば自然と分かるようにできるんだろう。

ほか、 Web は横書きだから、左右に並んだリンクがあれば、左のものは「前/戻る」、右のものは「次/進む」と解釈されるのが自然な流れ。しかし、漫画つーもんは右から左へ進むわけで。このへんが逆になってて混乱のモトとなっている。 link 要素を解釈してツールバーにナビボタンを配置するようなイマドキの良いブラウザにしても、ボタン並びは上記同様なわけで混乱誘発の事情は同じ。

見開きの妙 vs ストレスなき画像読み込み

そもそも、こんなに細かくページを分ける必要があるのかなぁとも思うのです。1 文書に画像をまとめて配置した方が、1 枚目を読んでいる間に 2 枚目が読み込まれ 3 枚目が読み込まれ…と、アクセシビリティ (と言うのだろうか) が上がると思うのですがどうでしょう。

[ Diary < Black Box より ]

答えはこれにつきます。

元々書籍 (つか同人誌) の形態となるべく描かれた漫画なのだから、たとえ Web 上のコンテンツとなろうとも、一度に目に入る情報は左右の見開きの 2 ページ分だけであるべき。

漫画は書籍の形態をとることにより、見開き 2 ページを最小構成単位としてストーリーとリズムを構成してく表現手法が発達したわけで、漫画描きにとってこれの見せ方は重要スキルなわけで (いわゆる「見開きの妙」)、 Web だからとこのスキームを破壊するのは作家性にかかわるわけで。

とはいえ次ページがサッサとでてこないのも妙技的にどうかと思うので、次善の策として、いま表示してるページの読み込みが終わり次第、次ページで表示予定の画像を裏で先読みしてます (JavaScript ON の時のみ)

画像の代替テキスト

表示してる各ページ画像の alt 属性はカラッポですヨ。ウチのサイトの展示イラスト画像などもそーですが。

何を代替テキストにすれというのか。そのページのセリフやら情景やらをノベればいいのか。むしろそれは longdesc ではないのか。仮にそうして longdesc を設定するして、そんな途方もない作業は現実ムリではないのか。というかそもそも絵や漫画を文字で語るのはヤボの極みではないのか。

イラストコンテンツはそれ自体が最小最大の情報なのであって、代替は存在しない。

結論

そもそも、紙メディア前提として描かれた漫画をコンピタで閲覧しようってのが、ムリ大杉なのである。

2004年5月5日

それでもシャッフル再生はしない主義 (2004/05/05 - 06:48)

フーン。

ケラリス教授は、ランダムなシャッフル再生は「MTV世代」――「脳がダメージを受け」、集中を長時間持続させられなくなった若者――に支持されている可能性が高いと述べている。

ワロタ。

iTunes4.5 の新機能のパーティシャッフルとかちょっとオモロそうな気がしつつも、基本的には「アルバムは通して聴くべきなのである」とかブツクサ呟いていたり頑固オヤジの気持ちを代弁していると自負している気配濃厚なわけで、てか実際オヤジ年代 32 歳だし、いいよもう。好きにしてくれよ。

iTunes4.5 で新設の矢印ボタンの挙動を変える (2004/05/05 - 06:30)

iTunes4.5 からいろんなトコにいちいち表示されるよーになった矢印マークのボタン (の様なもの) 。クリックすると日本からは買い物できねーことでおなじみの iTunes Music Store に飛ぶだけだったりで UZEEEEE ことこの上なし。いちおう設定で非表示にできるんだけどね。ただ Option + クリックすると、ライブラリのブラウズ表示でその曲が選択された状態になって、そこそこべんり。そこで、クリックのデフォルト動作をそっちに入れ替えてしまえという技。例によって defaults コマンドの発射でのみ設定可能の裏技系。よってここで紹介の技は OSX 版のハナシ。

…イイ!

ザ・遺物探訪:文書構造表示 CSS 2000 (2004/05/05 - 05:44)

さて、カスイケなど先人のサイトのCSSを参考にする際は、まずHTMLの構造を知らなければいけないわけで、そんなときはありみか氏作・Piro氏改造のエレメント構造表示ユーザーCSS (元がドコにあるのか分かんなかったです・・)を使うとわかりやすくていいです。

[ 構造化エディタ: Software Linkage より ]

は特に名を秘す某所でひっそり公開しただけでそのうち消えたブツだったんで、 Web 上のどこにもありませんでした。HDD の片隅にひっそり埋まってました。 Finder によるタイムスタンプは実に 2000 年 9 月 28 日の昔という。 Piro たんが「元ネタ」として示すのに困ってる感じが漂っているのを長いこと知りつつも、今更感にまかせて放置してた次第で。そしていまごろ気が向いて晒してみたりで。ヒドイ人ですねアリミカサン。

これの想定適用ブラウザは実用 (日常使用可能) レベルにおける当時の最新最強ブラウザ MacIE5 。 Gecko 系ブラウザは実用レベルにほど遠く、 Opera は ver5 頃で日本語がロクに表示できなかった (たしか) 。そんな頃の遺物。 Piro たんが改良した版のほうが出来がいいにきまっているので、この遺物は参考程度としてそちらを以下略。だいたい記述とかコメントとか CSS ビギナー風情漂いまくりで怪しいし。

つかいかたは、主にブラウザのユーザ CSS として適用したり外したり。いまならブクマクレットで動的かつ手軽に適用とかですかね。

ちうかですね、Firefox にしろ Camino にしろ、 Gecko 系ブラウザはいまだに、ユーザ CSS のオンザフライ (つまり再起動なし即座反映の) 適用・非適用もできねーわ、ファイルパス・ファイル名が決め打ち (ユーザプロファイルフォルダ/chrome/userContent.css) だわ、なにはさておき GUI でこのあたりの設定がいまだにできないのとか、このあたり、どうにかならんのですか。

2004年5月4日

結婚祝い大募集中 (2004/05/04 - 17:50)

ちなみに鉄アレイとかはいりませんので。

13:28:11 <***> じゃあおやびんのケコーン祝いにみんなで しーしー.jp とかとってプレゼンツするとかいう寂しい企画はいかが?

イイ!すごくイイ!今後5年分くらいのドメイン維持費コミとってもイイ!彼女たん改め奥たんのサイトも しーしー.jp に置かれて、本人だけでなくそのワンフーたちからも露骨にイヤな顔をされてみて、まさにオレはヒーローさ!

Myself.age++; (2004/05/04 - 17:03)

32...orz


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