Mac OS X Leopard、10月26日発売決定。シングル・ユーザーライセンス$129.00。
iPod touchの件もあって、わたしのアップル熱はすっかり冷め切っていて、Steve Jobsにもう１セントも儲けさせたくないんだけれど、TigerをスキップしてしまってぼちぼちフリーウェアでもJaguarでは動かないものが増えてきたから、今回は降参して、eMacに入れることになりそう。
でも、Leopardはともかく、IT業界にいるものとして、そろそろ一台くらい家にWindows Vistaの入ったマシンがあってもいいかとも思う。OLPCを買うのは決めたけれど、ASUSのEee PCもいよいよ発売されるようだし、年末年始にかけて、コンピュータ関連の出費がかさみそうだ。
よっしゃあ、自力でソースを直してワープロで変換途中の文字がちゃんとした位置に出るようにしてやる、かどうかはまだ覚悟ができていないが、OLPCを買うんだったら、うちのPCにFedora 7が入っているとなにかと便利なことがあるんじゃないか？とおもった。
いちばん簡単なのはいまつかってるDell Dimension 2400のパーティションを切り直して、Fedoraを入れるという案。しらべてみるとPartition LogicというPartition Magicと同じようなことができるフリーウェアもいまはある。
でも、メインのマシンを実験用に使い回しするのはもうやめたいなー（ぼくも大人になった。笑）。
ということで、Dimension 2400を買う前に使っていた、933MHz Pentium III (しかもSlot 1。笑）メモリ768MBといういかにも中途半端なマシンに入れることにした。でも、ディスプレイがないので、IOGEAR GCS62 MiniView Micro KVM Switchというスイッチで切り替えさせることに決定。＄２５。
面白くなってきた。
OLPCのワープロで日本語変換したとき、変換途中の文字がへんな場所に表示される問題について（しつこい）。
OLPCのワープロが土台にしているAbiWordの問題じゃないかとおもって、Googleでサーチしてみたら、こんなのが見つかった。
● AbiWord-2.5.0 complex script testers please?
● Bug#:10756 Somewhat broken Japanese input
残された道は、自力でコードを修正することか（あきらめるか）。
性懲りもなくワープロでの変換文字の表示位置の問題を解決すべく、uim-anthyではなくて、scim-anthyで再挑戦してみた、が、ダメでした。ワープロの入力メソッドは”X Input Method”で動いたが、やっぱり左上に出る（uimのときとちょっと位置が違う）。”Embed Preedit String into client window”という設定オプションがあるのでいじってみたが、結果は変わらず。よく見たら、この中国語の例も、左上に出てるし（uimのときと同じ位置）。うーん。ワープロ側の問題かなぁ。
leafpadという簡単なテキストエディタだとちゃんと”On The Spot”変換するので、テキスト入力はそいつを使うことにして、本当にワープロが必要なときだけ使うということにするか（本当に必要なときはWindowsでMS Wordを使うだろう。笑）。
一応自分の覚えがきとして設定方法を簡単にまとめておこう。
0. /etc/X11/xorg.conf 変更。
1. Ctrl-Alt-3
2. login as root
3. yum intall scim-anthy
4. IPAフォントインストール(/usr/share/fontsにttfをコピー）
5. /home/olpc/.xinitrc のsugerを呼ぶ前に、
LANG=ja_JP.UTF-8 ; export LANG
scim -d &
XMODIFIERS=@im=SCIM ; export XMODIFIERS
GTK_IM_MODULE=scim ; export GTK_IM_MODULE
USE_XOPENIM=t ; export USE_XOPENIM
の行を追加（参照ページ）。
6. chown olpc:olpc .xinitrc
7. killall -i X
日本語はこれでとりあえずいいとして、じゃあつぎはOLPCでGoogle Earthだ！ということで試してみた。
インストールは、落ちてきた.binファイルをchmodしても動かすことができず、/bin/shのパラメータで渡してやるとなぜかうまくいった。
で、動かしてやると、libGL.so.1がないとか言ってくるので、mesa-libGLというのをyum installで入れてやったら、Google Earthのロゴが出て、喜んだものつかの間、Xがリスタート（したみたい）。
マシンの能力的にこれは無理そうなので、Google Mapsでがまんするとするか。というか、そういうときは素直にWindowsのラップトップを使えばいいのだ（笑）。
うーん、どうも変換途中の文字が表示される位置が変だ。でもとりあえずuim-anthyでOLPCのワープロに日本語を入力することができそうだぞ。
自分以外だれの役に立つのかわからないが、手順は、
1. Ctrl-Alt-3でコンソールを出して、rootでログイン（デフォルトはパスワードなし！）。
2. yum install uim-anthy uim-gtk2
で、uim, anthy, uim-anthy, uim-gtk2をインストール。ブラウザの日本語入力だけなら、uim-gtk2はいらないみたい。ワープロはuim-gtk2を入れずに”X Input Method”で入力しようとすると固まった（原因不明）。
3. cd /home/olpc
4. vi .xinitrc
Ctrl-Alt-3のコンソールでviの画面が崩れるのだが、他のエディタは知らないし…
5. .xinitrcの終わりあたり、sugarを呼ぶ直前に、
LANG=ja_JP.UTF-8 ; export LANG
GTK_IM_MODULE=uim ; export GTK_IM_MODULE
uim-xim &
XMODIFIERS=@im=uim ; export XMODIFIERS
を入れて、セーブ。
5. chown olpc:olpc .xinitrc
6. killall -i X
です。
OLPCの日本語表示のつづき。
なんかフリーの日本語アウトラインフォント「IPAフォント」の一般公開が始まったということなので、このOLPC in Chineseの手順にしたがえば、たぶんそれをダウンロードして、/usr/share/fontsにコピーしてやれば日本語が出るのではないかと思い、QEMUエミュレーター環境でためしてみた。
WindowsへのQEMUのインストール、OLPCイメージの動かし方はここに書いてある通り。デフォルトだとフォントが小さくなりすぎるので、ここにある変更を/etc/X11/xorg.confに加えました。使ったイメージは安定版ではなくて最新版の10/4ビルド。ただあたらしい方がいいかとおもっただけで、特に意味はないです。
マシン（セレロン2.4G 1Gメモリ）が遅いのか、QEMUが遅いのか、もともとOLPCが遅いのかよくわからないが、ブラウザの表示はやたら遅い。でも、簡単に日本語は出た。ただし、フォントサイズの調節方法はわからず（笑）。Ctrl-+とかやったがだめ。まぁ、そういうのはそのうちやりかたがわかるのであろう。うんうん。
つぎは日本語入力か。ここ５年ほどまじめにLinuxで日本語入力していないが、ちょっと調べたところ、uim-anthyあたりを使うのが今風らしい。たぶんFedora 7用のRPMがそのまま使えるんじゃないかと思えるから、また試してみるとしよう。
Engadget経由。New York Timesのサイトに載った、OLPCをレビューするビデオ。見れば見るほど欲しくなる。
CPUやグラフィックスのパワーではあきらかに上回るPS3が売り上げでWiiに完全に負けているいま、ラップトップの分野でも、もう必要なのはスペックではなくて、ハード・ソフトをひっくるめた優れたパッケージなのではないかとおもう。
まだ気が早いが、OLPCを年末までに手に入れることができたとして、やっぱり日本語を表示させたいものである。OLPCはLinuxベースだから、日本語表示くらい簡単にできそうだけれど、どんな感じに見えるのか知りたいと思い、サーチしたら、日本語は見つからなかったが中国語表示の情報が見つかった。
スクリーンショットを見る限りでは、かなり期待できそう。よしよし。
日ごろ写真のレタッチにはPhotoshop Elements 4を使っていて、大きな不満はないのだけれど、立ち上げに少し時間が掛かるので、もう少し軽いフリーのレタッチソフトがないものかと思い、Paint.NETというのを試してみた。
.NET Frameworkを使っているせいか、素晴らしく軽快、というわけではないが、立ち上がりなんかは、Photoshop Elements 4よりはずっと速い。機能的にも充実（アンシャープマスクがないのは残念）。でも、フィルタ類がやたらと遅い。そういえばGIMPを以前試したときも（最新版は知らないが）、フィルタが遅かった。Gaussian Blurをやると、Photoshop Elements 4なら瞬時に処理が終わるのに、Paint.NETではステータス・バーを出しながら、ちんたら処理をしている。その上、半径を大きくすればするほど、待ち時間は飛躍的に長くなる。駄目だ、これでは使えない。
やっぱりこういうところのパフォーマンスの最適化は、フリーソフトに期待するのが（まだ）無理ってことなのかなぁ。
民の帳面 