ねこめしにっき(2003年10月上旬)

2003年10月10日

合計 640MB っっ (2003/10/10 - 16:02)

iBook 用 512MB メモリ届イタ━━━━(゜∀゜)━━━━ッ!!

装着シタ━━━━(゜∀゜)━━━━ッ!!

効能のほどは swap が溜まり始めるコレカラ━━━━(゜∀゜)━━━━ッ!!

需要供給曲線 (2003/10/10 - 12:05)

某 30 代無職で職歴が無いんじゃ聞くことも無いしねぇとか面接で言われてみたりする A 氏の場合は、体感によるとこんなんらしいです。

三重県の山奥の茶倉橋 (2003/10/10 - 10:45)

半月くらい前、三重県の山奥は茶倉の道の駅まで彼女たんを乗せてぶらりドライブ、んで二人して赤い服着て赤い茶倉橋を渡ったの巻。そんときの写真。本人写真は最重要個人情報につき取り扱い注意。

ありえない (2003/10/10 - 10:30)

<link href="D:/ホームページ/ArekorePopup/ArekorePopup.css" rel="stylesheet" type="text/css">
<script src="D:/ホームページ/ArekorePopup/ArekorePopup.js" type="text/javascript"></script>

ちょっとそれはあり得ないっす。三通りくらいのいろんな意味で。

2003年10月9日

Mac OS X v10.3 "Panther" 発売日決定ー (2003/10/09 - 11:10)

OSX マンセーのぼく的にはもちろん言われなくとも発売日に速攻お布施支払い速攻ゲット速攻インストがデフォなわけですが。何つってもえくすぽぜーが楽しみだわーい。

しかし。

To: Apple Computer

Please do not add the ugly look of brushed metal to the Finder, OR, if you must do so, please give us an easy way to turn off this monstrosity.

Sincerely,

[ Apple, Cut Out the Brushed Metal Petition より ]

I HATE UGLY LOOK OF BRUSHED METAL!
I HATE!
I HAAAAAAAATE!!!!

(OVERKILL の "I HATE" のサビの調子でヨロ)

昔、 QuickTime Player がメタル調ウィンドウになってから幾星霜。今でも相変わらずメタル調ウィンドウはすげぇ嫌いなんだっ。ホントに嫌いなんだっ。無難な感じが嫌いなんだっ。クールだと思わせる手軽な方便な感じが嫌いなんだっ。てか万事そもそも、モノトーン調とか金属テクスチャ調が嫌いなんだっ。 PowerMac G5 とかどこがかっこいいのか理解不能さ!いや「かっこいい」系が嫌いなのであった!あった!あった!

メタル調ウィンドウの唯一良い点は、ウィンドウの余白ならどこでも掴んでドラッグ窓移動できる点だけど、べつにそれ、現行 Aqua 調ウィンドウだってやろうと思えばできる事っしょ。

その Aqua 調も 10.3 からはシマシマストライプが無くなってぺったりのっぺり調になるわけで。これまた無難化ってやつ?鬱だ。鬱すぎる。つまんなさすぎる。灰色の面積が増えて無難化するほどに鬱になる。青ツルツルの林檎マークと三色玉が生存できただけで奇跡デスカ?

そりゃま、今のケバケバしい Aqua も嫌いな人は多いだろうし、好みは人それぞれなんだし、いいかげんテーマ機能を復活させやがれジョブズの禿。イニシエの Kaleidoscope2 みたく、矩形じゃないウィンドウとか、クローズボックス他をあさっての場所に置けるとか、そこまでのハッチャケぶりまでは(GUI に混乱をもたらすという主張は理解できるし)求めないからタノムヨー。せめて今の Aqua を選択できるようにシテヨー。

2003年10月8日

メンコミ参加サークル有志企画スタンプラリー中止 (2003/10/08 - 21:12)

今度のメンズコミック参加サークル有志によるメンコミ再活性化祈願企画、サークルまわってスタンプ集めて壁紙 CG 集をゲトしよう!…が諸般の事情で中止となった模様。うーむむ。微力ながらぼくも絵を供出しようと思ってたのだけども…。とはいえまぁ、シメキリがマジ切迫してこないと描き始めないってのは誰しもそうなわけで(断言)、ぼくまだ何も描いてなくてこれから描く(あるいは既存の線画に着色してデッチ上げる)ってありさまだったわけで、つまり何もしてないわけで、現状では事の推移をただ見てただけに違いないわけで、後から口では協力するつもりだったとか中止残念とか何とでも言えるわけで(ry

地元同人誌即売会イベントが「便箋ラミカ交換所兼コスプレ撮影場」ってな廃墟になった後でも、日本中からサークルや一般をかき集めてたメンコミの、その今の凋落ぶりには(まぁたしかにそうなる必然ともいうべき騒動がいろいろありましたが(ワラ)開催 6 回目の頃から参加してた(最近しばらくぜんぜん参加してなかったけどネ)地元男性向けサークルとして忸怩たる思いがあるわけで、その、次回があるなら依然協力するつもりはあるですよ?と今のうちに書いておく。

Re: Lists and Margins (2003/10/08 - 17:03)

In English

In the trackback for my previous entry, Anton complains about Safari's misrendering of the list items at this URL.

As far as I can tell, Safari's rendering is correct. Mozilla seems to be ignoring the negative margin placed on the divs with class="title". If you change the display of the list items to block, Mozilla stops ignoring the negative margin and behaves like Safari.

This appears to be a bug in Mozilla to me, and I believe Safari's rendering is correct.

[ from Lists and Margins - Surfin' Safari ]

I think that Safari's rendering is incorrect.

inside
The marker box is the first inline box in the principal block box, after which the element's content flows.

[ from 'list-style-position' - CSS2 Specification ]

Safari's rendering is not carried out as this specification. First of all, the marker of list item that set to 'list-style-position:inside' only shifts it's position horizontally, and overlaps with the contents (texts etc) of the list item.

Since the CSS of that example is complicated, I prepare the test page which simplified the problem. I examine the correct rendering in this test page along with specifications.

  1. The marker box of list item that set to 'list-style-position:inside' becomes the first inline box of the list item.
  2. The block boxes (div elements) exist in the list item from the beginning. Therefore the marker box becomes anonymous block box.
  3. Negative 'margin-top' of the following div element should offset height of this anonymous block box (the marker box).

The negative margin seems to be no longer disregarded when we set the list item to 'display:block', simply because the anonymous block box (the marker box) that offsets negative margin is lost. isn't it?

日本語

Anton 氏この例をあげて、 Safari のリスト項目の整形はおかしいという訴えを、ぼくの過去記事へトラックバックしてきてた。

ぼくの知る限りだと Safari の整形が正しい。Mozilla は <div class="title"> の負の margin を無視してるっぽい。リスト項目の displayblock にしてみると、 Mozilla は 負の margin を無視しなくなって、 Safari とおなじように振る舞うんだけど。

これは Mozilla のバグだとボクは思う。んで Safari の整形のが正しいんじゃないんかと。

[ Lists and Margins - Surfin' Safari より ]

Safari のほうがおかしいんじゃないのかな。

inside
マーカーボックスは、主要ブロックボックス内の最初のインラインボックスになり、主要ボックスの内容はマーカーの後ろに流し込まれる。

[ 'list-style-position' - REC-CSS2 邦訳 より ]

Safari はこのとおりに整形してない。そもそも、 list-style-position:inside にしたリスト項目は、マーカー表示位置が単に横にずれるだけで、リスト項目の内容(テキストとか)と重なったりしてるし。

例示されたページの CSS はちと複雑なので、問題を単純化したテストページを用意してみた。このテストページにおける整形を、仕様書に沿って検討してみる。

  1. list-style-position:inside なリスト項目のマーカーボックスは、リスト項目の最初のインラインボックスになる。
  2. リスト項目内には元々ブロックボックス (div 要素) が存在してる。よってマーカーボックスは匿名ブロックボックスになる。
  3. 後続する div 要素の負の margin-top は、この匿名ブロックボックス(マーカーボックス)の高さを消費するはず。

リスト項目を display:block とした際に divmargin が無視されなくなるように見えるのは、単に、負のマージンを消費していた匿名ブロックボックス(マーカーボックス)が存在しなくなるからでは?

ってか英訳がすごく変カモ?

2003年10月7日

ラポート倒産のうわさ (2003/10/07 - 17:55)

ファンロードとかでおなじみのラポートが倒産したとかいう説が一部で流れてる 次スレんですが。どうなの実際。ゆかりのある作家が本人のサイトで言及してる以外にソースが無いみたいなんだけど。

えーと自分的には大昔にラポートのアンソロコミックの仕事を数回させてもらった事もありの、今現在は彼女たんの有力なオシゴト先でもありの。さてはて。

追記

とりあえず、出版関係の別系統からも「銀行が無茶な回収をして不渡りを出した」という話は目にしました。

[ void GraphicWizardsLair( void ); // より ]

SideTrack 0.7.2 (2003/10/07 - 08:38)

PowerBook や iBook のトラックパッドのタテヨコのフチを指すりすりすることでスクロールホイールの代替にしてしまえる OSX 用ナイスユーティリティ(てかカーネル拡張)SideTrack の 0.7.2 が出てたので、早速 iBook (Opaque 16VRAM) に入れてみたのだけど…。

…。

……どうしようマトモに使えないよドラエモーン。0.7 を残して無かったの大後悔だよーん。

指すりしてもスクロールにならない「空振り」が異様に多いなりーん(泣)。 以前の版でもちょっと気になってはいたのだけど、ここまででは…。いや、縦スクロールをトラックパッドの右フチ、横を下フチに設定すれば「空振り」は少なくなるんだけど、右利き的にそこに割り当てるとマウスポインタが意図どおり動かねーとかでストレスが溜まるし、どーしても左フチ&上フチにしたい次第なのだけど…。

ってか、前バージョンのころでも、左フチと上フチは、スクロールホイール扱いにする「幅」を最大にしないとどうも「空振り」してて、逆に右と下だと最小幅でもやたらに広い範囲がスクロールホイール扱いになってたわけだけど。 0.7.2 ではもう左と上は最大幅でも足らなくなった、みたいな感じ?あ、ちゃんとトラックパッドキャリブレーションはやってありますよ?うぐ。誰か 0.7 残ってたらください…。

2003年10月6日

mi に寄付をした (2003/10/06 - 16:08)

mi開発支援の寄付を募っているのはご存じのとおり。初めて使ってからもうかれこれ 4 〜 5 年毎日使ってきてて、このエディタなしには何もできない体なのでして。というか mi があるかぎりマクからどっかへメイン環境を移行することはあり得ないとか、そこまで言ってみる。まぁともかく感謝を込めて先々週の金曜に寄付を送金した次第。

でも寄付はクレヂトカードが使えないとダメなネット決済オンリーだったりしたので、作者様に銀行振り込み先をメールで聞いたりして却って手間を取らせてしもたオチ。しかしあれですよ、寄付金額の実に 3 割にも達する銀行手数料はどうかと思った。しかも取り扱いは午後 2 時までとかヌカしやがって。サービス悪杉。というわけで、ついでに送金した他のシェアウェア 2 つは…ってか、できるかぎり送金手段は郵便振替を選ぶ次第なりー。国営事業ばんざいー。郵便局だいすきー。民営化反対ー。わらい。

下り線の海老名 SA 使えねぇ (2003/10/06 - 15:11)

しかし。東名高速下り線海老名サービスエリアは、食い物屋テナント乱立入居方式になってから、ロクな食い物屋が無くなった。ムカツク。アキバのてんやで天丼喰ってから帰ったほうがマシってのはどういうことだ。

あれこれ批判要望 (2003/10/06 - 02:00)

JavaScriptをデフォルトでオフにしている今日この頃。問題ないサイトがほとんどだし。というか、あれこれポップアップを実装するサイトには、有効無効を切り替えるインターフェイスを提供して欲しい。できればデフォルトはオフで。

[ Hatena::agenda より ]

むぅ。とりあえず作業に着手…。なんかじかんかかりそ。

ってか例のいつものやつまだ出るし。むしろ悪化?

こっちにも問題あるっぽいのでちょっときれいに書き直してみたいと思います…。

[ Note - 煤け小姫 より ]

むぅ。title 属性値ツールチップ aka 例のいつものやつの抹殺処理(= title 属性値を消して ap:ec-title 属性値として退避)は、マウスポインタでその要素を触れた際の一回きりしか行ってないのです。 a:hover スタイルの追従性悪化をなるべく抑えたくて。

よって、その退避処理のあとにふたたび title 属性値を動的付加 or 変更すると、例のいつものやつが出てくるわ、ポップアップにはその変更は反映しないわ、というオチ。…どうしたもんだか。いちお退避処理済みか否かのフラグ属性 ap:evacuated を要素に付加しないように(ArekorePopup.js の v1.2.5 であれば 553 行目をコメントアウト)してしまえば、とりあえずは解決しますが…。

レヴォから帰還 (2003/10/06 - 02:00)

  • サンシャインでのレヴォとはいえ秋のレヴォなのでわりかしマターリ。
  • やっぱし昨今のコミケットに比べりゃ買い手の人々の熟練度が上ですね(濃いともいう)。列とか何も言わんでも勝手に直角に曲がってるし。
  • 友達とはいえまるで作風や傾向のちがうサークルでの委託頒布なので、捌け戦線は自ずと厳しいわけだけども、そこそこ奮闘。
  • なんか夏コミの時より買った本の数が多いんですけど。

2003年10月4日

あれこれポップアップ v1.2.5 リリース (2003/10/04 - 19:10)

おとといの今日でヒジョーに申し訳のない気分。

んじゃそーゆーわけでレヴォ行ってきまっさ。

なんかアーカイブダウンロードへのリンクがミスってますた。すいません。

2003年10月3日

FileMerge (2003/10/03 - 21:42)

しかし Developer Tools についてくる FileMerge って、いじった箇所が見やすくて良いですね。 diff -u な形式の差分出力とか、それを使ってのパッチあて(?)とかできればなお良いのになー。

…ってホントの使いみちが何なのかはまじシラネ。

追記

比較するテキストファイルの改行コードは LF か CRLF じゃないとダメですよ。メールにてそのへんのフォローをしとくよーに、との要望がありましたゆえ一応追記。

それと、 FileMerge.app/Contents/Resources/English.lproj/Instructions.rtfd によると、なんか RTF 文書やディレクトリの比較もできるらしい。ふーむ。

夏コミ本の再版分 (2003/10/03 - 18:10)

フツーだとこの時期の同人誌専業印刷屋ってめちゃくちゃ納期が速いモンなんだけど、ウチが使ってる印刷屋は今はもはや同人印刷がメインじゃないもんで、むしろ逆、みたいな。ようやく刷り上がったなり。んで発注をうけてたとらのあなへ今送ったトコ。って月曜に受け取って今まで寝かしてたというー。

いやべつに、こんどの日曜のレヴォで、知り合いのサークル様んトコで委託販売するから意図的にとかそゆんでなくてヨ。ホラ、「あれこれ」にアレコレだったり、知り合いの腰掛けマカーのマクの面倒を数日にわたって見ていたり、とかとかで。

ちうか「どうやっていいのかわかんない」は「わかんない」でいいけど、どーして自分で調べて自力解決しようとはしないのかな。ちうかそもそもですね、こちとら棺桶 OS のことなんてとっくに大半が忘却の彼方で、今さら以下略なのですよ。

あれこれバグ発見 (2003/10/03 - 17:20)

あれこれポップアップ v1.2 ですが、というか以前の版でもそうだった気がするのだけど、 WinIE6 の Standard モードにてポップアップの表示が大崩壊したり、ポップアップ表示位置が画面のスクロールに取り残されて妙な位置に出たりのバグが発見されましたー。 WinIE6 の DOCTYPE スイッチってなんかスクリプト方面に大きな差が出るのですね。んだったら CSS のスイッチももっとキバれ。 XML 宣言のある XHTML も Standard モードになるようにすれ。

そのへんはもう修正できたけど、配布の準備がまだ。なにが面倒ってドキュメント書き。

それと、ポップアップ上に表示した画像が、ページ上の select 要素と重なるとき、 CSS で何をどうあがこうとも、画像だけが select 要素の下に埋まる珍現象も発見されましたー。これは WinIE の仕様のようなので放置しまっす。

2003年10月2日

あれこれポップアップ v1.2 リリース (2003/10/02 - 10:50)

日記も更新しないでずーっとコレをやっていたオチ。目玉はやっぱ、ポップアップ内に画像を表示するアレでしょーか。というか、

  • 1.0 には a:hover の反応が極端に遅くなる問題
  • 1.1 にはスタンダードスタイルで常に JS エラーが出る恥ずかしいバグ
  • 双方、大きなページだとロード完了後の結構長い時間、ブラウザが操作不能になるという大問題

がありますゆえ、古いのを使ってくださってる方はおねがいですから 1.2 にしてください。ぺこ。

以下、 v1.1 や 1.2b の頃に受けた指摘など。

ポップアップする内容の横幅と、ポップアップさせる場所とをうまく割り出して、横スクロールが出ないようにして欲しい感じです。ポップアップした内容が見られないとあまり意味がないという気がするので。

[ securecatのMT より ]

WinIE でリッチスタイルポップアップのときにそういう感じだったのですが、だいたい(謎)直ったです。

いちおうバグ報告的なものも併せてしておくと、なんか一定以上の長さになると(というのが原因なのかわかりませんが)、右のほうが切れますね。切れるというか、1ピクセルずれるというか。

[ securecatのMT より ]

WinIE での「リッチスタイルポップアップ」の表示状況に関して」に言い訳というか何というか…。

DOM で作ったtitle 属性だといつものやつも一緒に出てきたり。

[ Note - 煤け小姫 より ]

対処しますた。ってか、「事前処理を HTML 読み込み完了時に一括して行うか否か」で「逐次行う」にしてください。ってか、 v1.2 ではそれがデフォです。

画像オフ時の動作は期待通りに動いてるようなのですが、CSS オフ ( MozillaFirebird で No Theme ) の時はちらつくだけでポップアップもツールチップも出ないようです。

[ klee - notiz より ]

対処しますた。 No Theme を選んだときに ArekorePopup.css も当然無効にされちゃうわけですが、その次にポップアップを出す際に ArekorePopup.css を強制的に有効にするよーにしたです。

また、WinIE の場合画像リンクの Alt のツールチップと同時にポップアップ表示してしまうようです。

[ klee - notiz より ]

対処しますた。ってか WinIE だと alt 属性値もツールチップることをトンと忘れとりました。

Safari 1.0 でスタンダードスタイルを使用している時、<a> 以外の title, href 属性をもつ要素で、ポップアップしないことがある

[ AYNiMac の nakamuxu さんからのメール より ]

Safari はなんだか、 mouseover 系統の応答が遅いっぽくて(たとえば a:hover スタイルの反応も元から遅い)、比較的遅いマクだとそのような状況になるような感じでした。とかいうメールのやりとりをしてるうちに、 nakamuxu さんは G5 をゲッツしてしまった(笑)

1.2 でポップアップの生成処理をより負担の少ない感じに変えたので、ひょっとしたらすこしは改善があったかも。うちの遅い Win 機の IE6 で、巨大なページにてポップアップを出そうとするとかなり辛そうだったのが、これによって割と改善した次第でして。

href 要素のみのポップアップを抑制できないか?= Nice titles と同様、「 title がある場合だけ href (URI) も表示」というのは難しいですか?

[ AYNiMac の nakamuxu さんからのメール より ]

メールでは「しません」とか答えたのだけど、けっきょくコレ付けました(笑)

ポップアップ、うざいんですけど。

[ にゃおりんが会うなり叫んだセリフ より ]

→「適用サイト利用者向け FAQ

なんかー、でてきてー、そこにアドレスが書いてあるのにー、あれってクリックできないの?それ見ながら手で打てって事?

[ 尾崎大先生(誰)のありがたいお言葉 より ]

URL 系の属性値はリンクアンカー化してポップアップに出すようにしたゆえ、クリックすればリンク先に飛べるようになりまして候。


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