雑記 もくじarrow  home prev  index  next    

circleかぶら屋 雑記 (5)

cocolog と UTF-8 (2003/12/09)

Blog なんて言っても、ウェブ上にあるページということではそんなに変わりがないんだし、記事として成立しているものを書くなら、更新が簡単だからと言って自由度の低い Web 日記やら Blog やらのアカウントをわざわざ取ることもなかろう、と思っていたけど、@nifty が Movable Type という有名なやつのバリエーションで、すでに会員であれば無料でサービスを始めると言うので、チェックしに行った。

まず、かなりサクサクと動作してるのに驚いた。ページは左右にリンクなんかを配置したりして、フレームを使わないけどカッコいい今のわりと標準というか、そんなのだから、ソースを見るとけっこうな量のタグが入ってるんだが、基本的に記事やコメントの追加があればページを更新するが、それ以外のときは CGI などは動かない、という静的なページ構成になっているらしい。それでいて、コメントを受けつけるし、画像もアップロードできるし、なかなかハイテク感のある画面。

いや、なんか裏技を使わないと、スタイルシートを自分でカスタマイズできないから、いろいろ痒いところに手が届かない印象もなきにしもあらずですが……、ま、いいんでは。

サクサク度確認、できること確認の後、新着記事リスト(短すぎるので、新着はすぐ消えていく)とか、cocolog ping サーバーがあるのに気づき、ニフティもかなり気合いを入れている印象なので、アカウントを取りました ⇒ 【 painter log 】

ところで、この cocolog、インターナショナル仕様なので使用文字コードは UTF-8 となっています。(どこかで設定変更できる気がしたんだけど、再発見できず。でも、Blog の世界で UTF-8 がデフォルトなら、それはそれでいいや。)

どどど さんに教えていただきました。文字コードの設定は「プロフィール」ページにありました。しかし、TypePad についての解説などを読むと、Shift-JIS は推奨されないようなので、UTF-8 にしておきます。

問題は、このソースをいつものテキストエディタで開くと文字化けしてしまうこと。ソースを見るというのは、ブラウザのキャッシュに一時保存しているファイルを開いているだけなので、いったんいつものテキストエディタで開いて、そこでファイルのパスを取得、そのパスから「さくらエディタ」というフリーで UTF-8 対応のエディタからファイルを開きなおし。

xyzzy などを使っている人はここで苦労がないのかもしれないが、使って慣れているエディタというのは、選んだ理由があるわけだし、そう簡単に変更できないので、とうぶんこれで。

しかし、とりあえず Opera 6 で日本語が不思議なことになってる。フォントが明朝系とゴシック系混じったようなぐあいで……。タグやスタイルシートとの兼合いかな。わたしはこういうのはちょっと保守的なほうなので、心配。設定場所を再発見したら変更するかも。

付記 ― cocolog のシステムはブラウザの javascript を要求しないし、フレームも使っていないところが、とっても気持ちいいです。

さらに付記 ― バックナンバー形式の選択で、「個別」の欄のチェックをはずした場合、コメントがつけられない、ということに今ごろ気がつきました。

けっこう墨絵ふう (2003/12/09)

cocolog のシステムを借りて 【 painter log 】 に手軽に描いた絵を出していこう、というのを始めて、そう言えばアップロードする絵に自分のマークとかつけてない、これは決まったパターンで出す絵だと、なんかちょっと物足りないし、と思ってたことを思い出し、これをきっかけに「かぶら」マークをつけてみることにした。

で、その「かぶら」の絵。前にベジエカーブで描いてみたりしたこともあるけど、なんかちょっと感触がチガう感じ。たぶん、自分の絵にはキッチリしすぎなんだろう。今回はいつもの愛用「水彩代用ブラシ」セットの fuzz watery のサイズを小さくして、黒で気楽に描いたら、なんかけっこう気に入った。これで原寸の 35% サイズ。

このブラシは Painter の普通の「塗潰し」系のブラシで、「bleed / にじみ」の数値を高くして筆圧で制御しているんだが、色変化の表情の幅が広い。このへん、やっぱり Painter は触ってて楽しいと感じるところ。

アップロードした絵は、Fireworks でこのシリーズ用に使っている 300 x 300 のファイルに、メインの絵を適当に縮小してこのサイズで切り取って貼り付け、その上に「かぶらマーク」(もっと小さく 12.5% に縮小したもの)を乗算モードで乗せて JPEG 書き出し。

画像をスッキリ眠気取り (2003/12/11)

fotolog というのにアカウントを取ったので、縮小したデジタルカメラ画像をアップロードする機会が増えた。縮小する場合はとくに見ばえ優先のレタッチが有効なようだ。

レタッチ作業には Paint Shop Pro 8 を使っている。Photoshop 7 は(Photoshop Elements でも)起動が遅すぎてふだんは使えない、というのと、Photoshop と違って Paint Shop Pro は JPEG ファイルに「Photoshop で作ったよ」とかムダな情報を入れないので。さらに Paint Shop Pro 8 はいろいろなフィルタをボタンにしてツールバーの好きな場所に入れておけるので、ちょっと Painter のカスタムパレットな感覚で(Painter のスクリプトをカスタムパレットのボタンにしたものには負ける)便利に使えるのもいい。

しばらくレタッチをいろいろやって少し慣れて、トーンカーブというものが非常に柔軟性があって便利なのがわかり、レタッチと言ってもこれで 1 回処理するだけのことが多い。設定をいくつか保存しておいて、画像の傾向によって切り替えて使う。

今回はその設定の中から、「画像の眠気取り」としてよく使う、お気に入り設定を紹介。トーンカーブに慣れた人ならすでにわかっていることですが、こんなヘンなカーブもなかなか有効です。

設定保存はないけれど、Painter でも「色補正」でトーンカーブが使える。デジタルカメラ画像のトーンカーブによる調整の一般論は 【 Komin のフォトページ 】【 トーンカーブによる階調補正 】 がよくわかる。

fotolog でちょっと世界が変わった (2004/01/12)

「世界が変わった」というのは、自分にとっての「写真」とか「写真集」の概念が変化したこと、自分にとってはまったく馴染みのない地球上の場所の日常風景を当たり前のように見られるようになって、(これはその場所の言語がおまけでついてくるので、さらにインパクトがある)、そういう場所が心理的により近しいものになったこと、である。

2003 年 11 月に 【 fotolog 】 というのにアカウントを取ったのだが、自分のアカウントを持ってそこに画像をアップロードし、そこにコメントをつけてもらうのも楽しいが、Friends & Favorites というサムネイルのあるリンク集経由で無限にブラウズしていけるあたりは、単なる訪問者にとっても「圧倒的に巨大な写真集」として、ひじょうに利用価値があると思う。

まず、プロの写真家のカンペキな写真がタダで見られる場所は、そんなには多くない。Fotolog の「1 辺の最大が 500 ピクセル」という大きさはギリギリ鑑賞に堪える。プロが「気に入ったのはプリントを買ってください」と自分のウェブサイトに置いているサムネイルはもっと小さい。それだけ見ていては不満になるサイズに意図的になっているのだからしょうがないが、見るほうとしては「たまには買ってもいいけど、見せるのもあまりケチらないでほしいなあ」という気分になる。Fotolog の 500 ピクセルは賢い設定だと思う。

次に、プロもアマも今日から始めた人も、参加者としては対等というのがいい。さらにその多数の参加者の存在が、無意味な混沌になっていないのがいい。Friends & Favorites に入れたり入れられたりのつながりという形で、お互いの評価(写真に対して and/or 有意義なコメントをつけたことに対して)がとても意味をもち、訪問者はまたこの Friends & Favorites のリンクを、何しろそこにすでにサムネイルがあるのだから、非常に高い確率でたどっていくわけで、広い Fotolog の世界のなかに繋りの構造がすでに構築されている。

このサムネイルの力には、画像というもののもつ威力を再認識させられた。一瞬見ただけで何らかの判断ができるだけの情報が得られる、脳へのインプットの帯域幅の広さというものの威力である。こういうものが有効になる(一瞬でそこそこの画質の画像が表示される)ためにはネットのインフラの進化も必要だったのだが、やっとそういう時代になったわけだ。

画像がメインということで、ここはほんとに国境がいちばんないところ。人間はけっこうマシな方向に進歩してるんじゃないか、という希望を持てる場所。言語という便利だけど限界だらけの(帯域幅最小の)ツールに助けられて進化する段階がそろそろ終息するのか。だとしたら面白い。

滑らかな線 (2004/02/09)

Painter の特徴のひとつが、滑らかな線。これはブラシエンジンに「細かいブレを補正する」機能が内蔵されている(ブラシ設定の「間隔」設定にある「滑らかさ」および「キュービック補間」で強度設定)からである。

最初に本格的に使ったグラフィックソフトが Painter だと、他のアプリケーションを使ったときに線が思ったように引けないのでちょっとびっくりする。特に Photoshop。これは値段も高いし全体に高機能なだけに、この点では Painter とはすごく違うので驚く。Photoshop 7 でブラシ設定が複雑になり、いろいろアナログっぽい表現もできるようになったのだが、この「ブレを補正」する機能がない。ブラシ設定に「スムージング」というのがあるが、これはタブレット入力(マウスでも)で受け取って処理する「間隔」を小さくする設定で、入力と出力の間にワンクッション置いて、そこでいったん計算処理を入れてブレを取るというようなことはしていないようだ。

Painter のこの機能はペンツールでも有効。フリーハンドでベジエ曲線がきれいに描ける。どうも Expresshon で描くよりフリーハンドの曲線がきれいなようだ。さすがに Illustrator だと Painter と同等かそれ以上に補正が効いている。

OpenCanvas はドローに対するペイントに徹して、ちょっと Painter っぽいブラシ描画を追及している。線もそんなに悪くない、と思っていたが、画面表示を縮小して描いてから等倍にしたら、なんだか非常にガタガタになっていたので、ブラシの描き味についての徹底はまだ不足のようだ。これはちょっとガッカリ。せっかく OpenCanvas 3 Plus では縮小表示でもアンチエイリアスをかけたきれいな表示にできるのに。

そういうわけで、線を引くことについては Painter はまだまだ優位なのだが、画面の縮小表示についてはどの倍率でもアンチエイリアスがかからない(Macintosh 版の Painter 6 までをのぞく)、というところが弱点。

SPAM を条件で振り分け (2004/04/30)

このごろますます増えてる SPAM。とくにニューズグループ(英語)でも使っているメールアドレスにやたらと来る。まともなメールが埋もれてしまうので迷惑なことこの上ない。で、しばらくの間、メールのヘッダを観察していたのだが、英語の SPAM は特定の業者から来るのではなく、「差出人」関係ではフィルタリングできない。いっぽう「宛先」のほうはちょっと規則性があるのを発見。

SPAM 用のアドレスのリストというのがどういうルートで出回るのかよくわからないが、ともかくこの @Nifty のアドレスにくる SPAM については、自分ではない @Nifty のアドレス、あるいは、自分のアドレスと並んで他の @Nifty のアドレスが宛先になっているのが多い。(そうでないものは、たぶんリストの入手元が違うのではないかと思う。)

そこで EdMax の振り分けで、宛先の文字列を正規表現を使って分類できないか、とやってみた。正規表現はけっこうむずかしいので、うまくいった例をメモ。ここでの振り分け条件は「宛先に @Nifty のメールアドレスで、@ の前が kaburaya でないものがあれば、ゴミ箱に移動」というもの。[^abkruy]+ という正規表現で kaburaya では使わない文字が 1 つ以上連続している場合を指定できるはずなので、[^abkruy]+@nifty.com という表現で @ の直前が kaburaya ではないものはかなりの確率で一致してくれる。もっと完璧な表現を模索中。EdMax の正規表現の実装が変則であるような気もする(. が ? として解釈されている、ような)。

[ 追記 (2004/05/01) ] 上の例は結局、[^a]@nifty.com でフィルタリングするよりダメなフィルタになってしまうので、間抜けな例だった。発想の最初に「普通の正規表現では、(何らかの文字列) + [^abkruy] + (何らかの文字列)+ @nifty.com で自分のメールアドレス以外にヒットさせることができるはず」というのがあったのが失敗のもと、だと思う。EdMax だとここに半角スペースを追加してみたりしてもうまくいかない。しばらく、この [^a]@nifty によるフィルタと「宛先に @nifty.com が入っていて、かつ、宛先に kaburaya が入っていない場合」(後者だけだとメールアドレスが併記されている場合にヒットしない)というのを併用で行ってみることにする。

じつは CPU 速度を下げてもかなり平気 (2004/06/13)

最近は Tablet PC なんかも買ったし、まあパソコンを買うのも秋葉原に行くのも好きなわたしではありますが、じつは 「Painter と現在のマシン環境」 で紹介している自作機をまだ使っています。すでに 2 年半を過ぎました。当初からの変更は Barracuda の 160GB のハードディスクを追加してそこにシステム(Windows 2000)を再インストールしたくらいしかありません。(古いハードディスクも元気にスクラッチファイル置場として稼動中。)

このマシンの CPU は AMD Athlon 1800+ で、ベースクロックが 133MHz のとき 1533MHz で動作、このときの super pi が 1 分 15 秒。しかし、このところずっとベースクロック 100MHz で使っています。このほうが CPU 温度が低いから。(そもそもは BIOS 設定を 133MHz にするのを忘れただけ、でも使ってて設定の違いに「気がつかない」のならそれでいいんじゃないか、と継続使用。) この状態だと CPU クロックは 1147MHz、super pi も 1 分 45 秒。しかし、この CPU が出た当時の 記事 によると、対抗馬である Pentium 4 2GHz で 1 分 35 秒なんだし、何よりも、普通に使ってて まったく問題ない のです。

いや、わたしは当然 Painter 8 とか使ってたりするわけですが。さすがにフィルタ処理(効果関係)は遅い。でもそんなのめったにつかわない。あと、Painter だけを使うわけではない、というとき、(わたしはテキストエディタを使ってる時間がいちばん長いです)、速くて熱い CPU はなんかすごくムダに感じるわけで。

Tablet PC の hp tc1100 の CPU は Pentium M 1GHz で、こっちはスピードステップとかいう、CPU がヒマなときは速度落とす機能が最初からついています。電気消費量や発熱を考えるとこれは据置パソコンの CPU でもついてたほうが便利ですよね。

遅くても平気、とか言ってますが、持ってる iBook が G3 500MHz でやっぱり辛いので、なんとかしたいところ。

そろそろ HTML の見直し (2004/09/18)

2003 年 12 月に Nifty が cocolog を始めたのに続いて、「借りられる blog」が急速に増えた。Movable Type とその仲間(ライバル?)がウェブで急に目立ち始めた。これに伴って「ウェブページの基準」がかなり動いた。基本的に新しい仕様への移行が一気に進んだ印象がある。「古いブラウザでの表示の互換なんて気にしないでスタイルシートをバンバン使え」という時代に、ちょっと無理やりになってしまった。

前回 HTML を勉強したのはいつだっけ、と考えると、これも Nifty が CGI の使えるウェブスペースを提供しはじめた 1999 年である。Nifty はインターネットに最初につながった(Nifty へのダイヤルアップ接続からウェブに出ることができるようになった)ときだって、えらくスピードが遅かったし、@Nifty のホームページサービスについても長いこと CGI に障害が出たり重かったり、ぜんぜん「満を持して」サービスを開始してないようだけど、それでもそれぞれの時点で必要なサービスを追加してきたのは、けっこう偉いのかもしれない。まあ、いずれにしても、それが動機づけになったので、ちょっとありがたいんである。

ともかくも 1999 年の知識はかなり古くなってしまった。そのころと違って今ではウェブ上の詳しい解説をいつでも読めるので、ちょっと勉強してそのうち XHTML でちゃんとスタイルシートを使ったページにする予定。うちのサイトは解説ページが多いので、印刷用スタイルシートをちゃんとしたいです。

最初につくったサイトのデザインはフレームを使ってたなあ。今回「推奨」関係を読み直したら、さっさと HTML じゃなくて XHTML にしなさい、で、フレームはダメ、とか書いてあって、それもそういう推奨がかなり以前に出てることを知って、けっこうびっくり。

あ、現時点でもこのサイトで「パターンのサンプル表示」に CGI で生成したフレーム構成ページを使ってます。マジでフレームを完全に除去できるのだろうか。テキスト領域の横幅制限はスタイルシートでできるようになった(そういうスタイルシートに対応しているブラウザでの閲覧者が多くなった)ので、テーブルの除去は近いうちにやろうと思えばできる。でも、どうせならデザイン見直し、とか、構成見直し、とか、考え始めるとどんどん複雑になるので、時間がかかるかもしれない。

ブルグミュラー 25 練習曲 (2005/01/28)

昔習ったので曲を知っているから、昔使ったのと同じ全音の楽譜を買ってあって、たまに通しで弾く。ふと気がつくと、ブルグミュラーというゲルマン系の作曲者名なのに、それぞれの曲の題名はフランス語だ。表紙の曲集名はドイツ語。経歴を見ると、ドイツ人だけどパリに出てフランスに帰化したとのことで、フランス語の題名には納得。表紙がドイツ語なのは、ドイツ版の楽譜を原版に使ったのかもしれない。楽譜関係は「原語主義」のようで、一般的になかなか複雑なことになっている。音楽用語がイタリア語だから、この日本で発行された日本語解説つきの楽譜には、日本語のほかに、イタリア語、フランス語、ドイツ語が入っている。さらに、「目次」のところに Table という英語が添えてある。

楽譜って、かなり最強にマルチリンガルだったんだなあ、とあらためて思った。楽譜、という、まったく別の表記システムの付属物としての通常言語だから、重要性はあまりないが、音楽には言語バリアがないということとも関連するのかもしれない。

ところで、各曲のフランス語の題名にはその日本語訳がついている。子供のときから「進歩」っていう題名には違和感があった。練習曲の題名にしてはそぐわない概念だし。(子供のときは「概念」なんて単語は知らないから、「ちょっとひっかかる気がする」といった印象のみ。)

Progrès がその原語。曲は音階中心なので、「進行」のほうがふさわしい。この「進行」の内容は音の進行のことなので、「音の進行」とか「音階」と言うとさらにわかりやすい。

それにしても、普通の出版物の様相がどんどん変化していくのと比較すると、出版物としての楽譜はほとんど変化していない。輸入物なんかだと、すでに版がすりへったような原版のページをツギハギしてできてるものもある。楽譜作成ソフトもそろそろ「どんなものでもきちんと表記できる」ようになったようだが、(それでも、デジタル作成のものには、ページの切れ目ルールや、臨時のシャープやフラット、その後のナチュラルの表記法を守ってないピアノ譜が多い)、文章と違って(文章だと文法や意味コンテキストがチェックサム的に働く)、書き写しにエラーが混入したときに間違いとわかりにくいので、古い版を使うのが安全なのかもしれない。

その結果、楽譜にはすでに通常の印刷物では見られない、古い字体の漢字が残っていたりする。奇妙なようでもあり、思いがけない発見でうれしいようでもあり。

映画 DVD での翻訳確認 (2005/02/01)

『指輪物語』が映画化されたものの上映にあたって、日本の原作読者が字幕にクレームをつけたことは、かなり話題になった。消費する末端がわが「翻訳」にかかわるものについて苦情を言ったという、「翻訳」関連ではまれな例である。そういう読者を日本にも得た原作者は幸運だったのだろう。

『指輪物語』の翻訳が版を重ねていたのは知っていたが、そんなに読まれているとは知らなかった。「ハリー・ポッター」のような売れかたはしなかったから、現象として目立ちにくかったのかもしれない。(わたし自身は、英語版しか読んでいません。)

もとの翻訳者である瀬田氏の英語能力については、英語にかかわる者の間ではかなり疑問が出ていたが、(これは一般論であって、わたし自身はこの作品の誤訳を検証したことはありません)、この作品については後から大幅に修正が入ったのも、作品としては幸運な例。

すべての翻訳について、これだけ細かい検討がなされれば、日本の翻訳関係はもっとよくなるはずだ。この件に関連して、「クリシェはやめて」という、単なる誤訳ではなく、「翻訳文体の困った部分」に触れる意見も出ているし、翻訳業界の文体に染まっていない人のコメントは貴重だ。が、この動きはこの作品だけで収束してしまったようで、ちょっと残念。いや、これを続けたところで、かなり前にちょっと話題になった別宮貞徳さんの「誤訳指摘本」のように、例を並べるだけになってしまう。翻訳をやる当事者のほうがこういう意識を持つようにならないと、状況はよくならない。

ところで、映画の字幕の誤訳を検証する際に、DVD の英語字幕を「原文」として使っている例が多いようだが、英語字幕は実際のセリフとは違うこともある。あれは「字幕」であって「セリフを書き起こしたもの」ではない。これは作品によって違い、ほとんどセリフと同じである作品もあるが、検証しようとする場合、英語字幕をもう一度セリフと比較するとより正確を期すことができる。(これは勉強法としてもおすすめ。) また、作品によっては closed caption が入っているが、この英語がまた、英語字幕とも実際のセリフとも違うものだったりするので、この 3 種類を比較検討するとベスト。もちろん字幕にするにあたって、意味が変わったりするような改変はない、が、ちょっとだけニュアンスが変わる場合はある。

『指輪物語』については、英語が意図的に古い(とくに会話)ようなので、(読んだのがずっと前なので、キャラ名を忘れるほど記憶が曖昧です、すいません)、現代英語だけでなく、中世英語の知識もあると語りやすいのではないだろうか。それにしても、言語学者の書いた話なので、言葉関係が複雑でたいへんな本ではある。

Rivendell が「裂け谷」と訳されているのに、ちょっと驚いた。いや、「馳夫」がすでにイヤなので、かなりいろいろ訳文には最初から(昔、立ち読みくらいはしたことがある)違和感がある。(映画版で「韋駄天」になったそうで、確かにそれもちょっと、かも。) Rivendell の riven も dell も古語。現代日本語の単語ではダメなんじゃないか、と思う。あと、「け」のあとに「だ」という音の繋がりが。「毛ダニ」みたいだ。とか。もとの音の美しい響きのカケラもない。「た」だとしても、名古屋弁も知っていると「裂けましたよ」という意味にしか考えられない。日本の地名でこれにあたるものを探すとか、できなかったのかなあ。

ちょっと何が言いたいのか不明気味。たぶん、「元の英語の固有名詞の響きはどうでもいいのか」とか、世の中にはもっとすごい誤訳がいっぱいあるので、そっちもよろしく、とか、言葉はむずかしいよね、とか、そういうのがごちゃまぜです。

猫のゴロゴロの周波数 (2005/02/26)

このごろうちの猫(ハナコ 13 歳)がわたしの右耳に背中(尻に近い部分)をくっつけて寝る(首と肩の間のあたりの空間を占拠、少し肩と顔の上にも乗っている状態で)、というのをやるのですが、どうも「起きてメシを出せ」というプレッシャーのようです。というのも、この体勢でゴロゴロいうのですが、右耳に密着しているので大音量で響くんですよ。

このゴロゴロを聞いてたら、ゴロゴロの回数というのは 1 往復の往と複がそれぞれ 12 回くらいあるようで、また、1 分間のゴロゴロの往復回数は、これは呼吸の回数と同じになりますが、16 回でした。すなわち、1 分間に「ゴロ」は 16 x (12 x 2) = 384 となります。ヘルツに換算すると 6.4 ヘルツです。1 往復あたりの「ゴロゴロ」回数はもう少し多いかもしれません。

ウェブ検索すると猫のゴロゴロは 50 ヘルツくらいとありましたが、これは「音程」のほうのヘルツですね。1 秒に 50 回になると人間の耳ではもう「ゴロゴロ」という単位では聞こえないと思います、普通は。

ついでに検索すると、人間が感じる「振動」というのは 4 から 8 ヘルツがもっともよく感じるということです(住環境の防振についての調査より)。もっと遅ければ「揺れ」(動き)になり、もっと速ければ「音」になるわけです。ひょっとして肩こりにうまく使えないだろうか、とか考えたりもするのですが、猫は基本的に非協力的なので。

    もどるreturn  home prev  index  next