感激したのは食堂に案内された時である。「そこにいつも裕ちゃんが座ってビール呑んでたんだよね」とスチルマンの人が言う。「旭は、いつもあそこだった」と指さす。ッ、という感じである。僕は日活撮影所の小汚い食堂に佇み感慨に耽った。その日、僕とカトーくんが入れた撮影現場は女子プロレスの試合シーンだった。スタジオにリングが作られ、エキストラで観客が集められている。方のうちの一方向を埋めるだけの人数しかいない。カメラが別の方向の観客席を写す時は前に座っていた人と後ろの人を入れ替えていた。示を出すと、エキストラたちが実際の試合を見ているように騒ぐ。場をウロウロしている僕をカトーくんがカメラで追う。連載を重ね、何も言わなくてもカトーくんは欲しいカットを撮ってくれるのだった。今、振り返ってみると、日活撮影所に一緒に出かけた時から数えて、カトーくんの写真展が実現するのは10年後のことである。その写真展の実現のためにカトーくんは、ある時から同じ方法論で作品を撮り続けた。ハッセルブラッドのスクエアなフレームで撮るモノクロ・ポートレートだ。人物の間近からバンクライト1灯を当てるだけのライティングだった。カトーくんの撮る写真はひとつのスタイルを確立し、そのスタイルに彼が次第に自信を持ち始めたのもわかった。「あの感じで撮ってください」という注文も増えたようだった。その作品が溜まり写真展を開けるだけのものになったと彼が確信するまでには、4年の時間が必要だった。彼が僕の自宅までやってきたのは1992年の秋だった。──写真関連のメーカーギャラリーではやりたくないんです、とカトーくんは言った。僕は資生堂のギャラリー担当者に電話をしたり、パルコギャラリーのキュレーターを紹介してもらおうとしたのだが、話はうまく運ばなかった。表参道にあるスパイラルホールは会場費を聞いてすぐに諦めた。リクルートの銀座ガーディアン・ガーデンの担当者を紹介してもらい、カトーくんのポートフォリオを持って会いにいったのは、1993年があけてからのことだった。作品を評価してもらい、ギャラリーの写真部門のキュレーターをつとめる写真評論家の平木収さんの推薦文ももらえることになった。それからは写真のセレクト、伸ばし、案内状の準備、各媒体へのパブリシティ依頼など、時間に追われる作業がいろいろとあった。社のMさんを訪ね、試し焼きにも立ち会った。乗した僕の祭りの準備だった。雨は午後になってあがり、夕方近くには少し晴れ間も見えた。その夜、銀座・金春湯の前には人が溢れた。向かいにあるリクルートギャラリー「ガーディアン・ガーデン」でオープニング・パーティが催されたからだ。会場に入りきれない人々が金春通りにあふれ出していた。写真展の開催者であるカトーくんはパーティにきてくれた人々に「この写真展のプロデューサーのソゴーさんです」と僕を紹介してくれた。面映ゆい気がしたが、僕はおそらく自分の人生のハイライトのように、その夜を受け取っていた。カトーくんより舞い上がっていたかもしれない。「ピアノ・レッスン」の女性監督ジェーン・カンピオン、「ピアノ・レッスン」の音楽を担当した作曲家マイケル・ナイマン、「ふたりのベロニカ」のクシュシュトフ・キェシュロフスキ、「レザボア・ドッグス」で売り出したクェンティン・タランティーノ、「覇王別姫」のチェン・カイコー...僕は人々の喧噪から身を引くようにして通りからガラス張りのギャラリーを眺めた。モノクロームで写しとられたクリエイターたちの肖像が、美しいライティングの中に浮かび上がっていた。【そごう・すすむ】sogo@mbf.nifty.com年が明けると娘が成人式を迎える。先日、母親とふたりで振り袖を見にいったらしい。ある夜、カミサンがいきなり「振り袖買いましたから」と言う。値段を聞いて驚くしかなかった。DMがやたらに届くわけである。MailEnvrionment(OME)」でのローカライズについて、以前にも書いたが、文字コードの扱いそのものでもイレギュラーなことがあれこれ出てくることなどをご紹介した。今回はまだ手つかずな部分も含めて、ローカライズについてのはまりポイントをさらに説明をしたい。国際化の上ではすぐに分かることだ。Unicodeということへの視野はあったが、少なくとも、やってくるメールについてはUnicodeになることは遠い将来にはあるとしても、近々はないのではないかと予測できる。各国の固有のコードはなくならない。「そろそろ送信するのはUnicodeでいいんじゃないか」説もあるわけで、時代はじわじわと動いているのも事実だ。X自体は内部的にはUnicode化は進んでいるとしても、たとえばテキストエディットがUnicodeのテキストファイルを開くときにエラーを出すことがあるなど、まだまだという状況も見られる。少なくとも、日本語システムの使用状況を見る限りは、まだまだアプリケーションがUnicodeを素直に受け入れる状況とは言えないような気がする。アプリケーションのUnicode対応が進んでいるとは言え、いまだに、Shift-JISでテキストファイルを作る方がスムーズなのである。ストレージをテキストであると規定したOMEにおいては、メールの文字コード/文字セットと、保存するメールファイルの文字コード/文字セットも設定が必要になる。カスタマイズできるようにはしたが、よく考えると、ある日突然、Shift-JISからUCS-2にしました...といったとき、それはそれで「互換性の問題」が発生しそうでもある。1メール1ファイルは便利なのだが、そういったところでの新たな問題も発生するのだ。そこで考えたのは、現在のメールファイルがどんな文字セットで保存されているかをファイルに残すことだ。絶対に100%確実ではないが、メールのヘッダ(本文とは別に送信される一連のメール属性で、件名や送信日などが含まれる)に追加すればいいと考えた。いえ、これはとても場当たり的な方法であることはまぎれもない。なると、XMLでなんでも保存すればいいではないかという極端な考え方ももたげるわけだが、XMLになったファイルはプログラムが扱うのはいいとしても、人間が見るものではない。少なくとも、メールはファイルはプレーンでシンプルなテキストファイルである必要があると考えた。組み込むべき機能はたくさんある。しても必要な機能はなんとか組み込み、がんばって国際化してきたが、はたと手が止まった部分がある。送信メールの行末処理だ。メールの文面は適当な長さで改行を挿入し、なが~い行はさけるべきだとされている。理屈の上では、1,000文字程度までなら1行の長さは可能であり、メールサーバも1,000文字程度をめどに処理は正しく動くようになっている。ところが1パラグラフって、意外に1,000文字は超えるものだ。1,000文字ではなく、100,000文字なら、行末処理という仕組みは現状ではもうなくなったかもしれないが、1,000だと結局はやらないといけない範囲にぶちあたる上限なのである。RFC的には70バイト程度などとされていてあまり細かい規定はない。70バイトでぶつぶつ切っていると、日本語の場合はえらいことになる。エスケープシーケンスの問題もあって「バイト数で行を区切る」というのはプログラム上ではあり得ない話なのである。バイト数で切れない事情はそうした技術的なことだけではない。言語に深く根ざした仕組みをプログラミングしない。日本語だと、当然ながら「禁則処理」という厳然とした仕組みがある。頭に句読点があるのはおかしい。今みなさんが目にしているデジクリのテキストでも、編集の方がそうしたことを眉にしわを寄せてやっているんじゃないかと思う。メールソフトではそうしたことを自動的にしたいのである。英語は英語で行末処理は独自のルールがある。単語を2行にまたがっては記述しないというルールとも言えるし、2行にまたがるときにはハイフンを入れるが、その入れる場所も音節で決められて適当に切ることは許されない。それで、日本語メールの特徴だが、日本語と英語が混在するのである。日本語の部分は禁則で、英語の部分は、単語を切らないというルールで運用する。この処理は似ているようで微妙に違うのである。条件分岐でなんとかならないこともない。日本語と英語の境目は、半角スペースがあるかように扱えばいいか...などとまだまだその辺りは楽しいプログラミングの領域である。応していないが、なんとか動いている。国際化というところでどうしてもつまずいた。Unicodeでの文字処理が本格的になったとき、日英混在どころの話ではない。中日韓英混在もありうる。合テキストが普通になっているだけだ。興味深いが、ISO-2022-JPだと、日本語と中国語の混在は仕様にはないのである。(実は、ISO-2022-JP-2がそうした複合言語を切り替えるための仕様ではあるのだが、実際にはほとんど使われている形跡はない。した用途ではUnicodeを素直に使うようになっている。)つまり、一連の文字列に対して、行末処理はその一部分の言語に応じて対処しなければならない。改行が必要そうだというあたりで、今何語なのかを判別しながら処理をしないといけないのである。いう仕組みを入れないといけないのか...。