Wnn8のインストール時に試した構成などは以下の通り。
scim-wnn(0.2.4) + 別マシンのjserver:
wnnstatで見ると別マシンのjserverに接続しているようだったが、変換させようとするとサーバに接続できませんとのメッセージ。何でだ。後回しにしてWnn8LE回りを設定しているうちにそちらが動作するようになったので原因等は追求していません。
Wnn8LE:
いろいろ試してみましたが、Wnn8のrpmからiiimfも含めて一通りインストールして、ローカルに動かすのが一番とわかりました。
Gentooのiiimf(iiimsf+iiimxcf) + Wnn8LE:
httxが落ちました。ただし、iiimfの設定がまずかった可能性もありますが、同じく設定の悪かったiiimf-wnn8 + Wnn8LEでは落ちなかったことを考えるとだめだった可能性もあり。
ローカルではjserverを動かす前だったので、ローカルで動いていれば問題ない可能性はあります。試してはいませんが。
iiimf-wnn8 + Wnn8LE + 別マシンのjserver:
最初はiiimfの設定がまずくだれも利用できない状態だったり、~/.Wnn8/wnnlercを書いてなくて動かしていないローカルのjserverに接続しようとしていたりと設定にてこずってました。
ただ、それなりに設定してもだいぶん前にも書いた「予測辞書がうんぬん」のメッセージが変換後とに表示されます。一応動くし、変換効率自体はそこそこいいと思うんだけど実用的ではないな。
iiimf-wnn8 + Wnn8LE + ローカルのjserver:
問題なし。予測も表示されてますし、今のところ快適かな。
ただし、dpkeyservは別マシンのを参照しているけど、辞書はローカルのを使ってるわけでClient/Serverのメリットが台無しだなぁ。まあ、現状では他のマシンでWnn8を使う予定はないだろうからとりあえず我慢かな。

ネタ元はこのメール。
たとえば、serifのデフォルトのフォントに「FC-Minchotai-M」、そのBold体に「FC-Minchotai-B」とするならば以下の通り。

<match target="pattern" >
<test name="family" >
<string>serif</string>
</test>
<test compare="more" name="weight" >
<const>medium</const>
</test>
<edit mode="prepend" name="family" >
<string>FC-Minchotai-M</string>
</edit>
</match>
<match target="pattern" >
<test name="family" >
<string>FC-Minchotai-M</string>
</test>
<test compare="more" name="weight" >
<const>medium</const>
</test>
<edit mode="assign" name="family" >
<string>FC-Minchotai-B</string>
</edit>
</match>

ただ、デフォルトがちゃんと「FC-Minchotai-M」なのかどうかはきちんと調べてません。
フォントはどちらにせよ汚い感じがするので別のフォントを使うか設定を見直すかを考えないと。
その辺りはどうやって調べよ。fc-matchってないんだっけ。
ちなみに、こんな感じ。

フォントのせいか、AAのせいか、あまりきれいじゃないっていうか、ぶっちゃけ汚いけど。フォントを大きくすればいいんだけど。

ちなみに、インストールに成功しなかったのがDebianとArk Linux。
Debianはwoodyと結構前のsarge(network install用)を試したのですが、うまくハードを認識できずにインストールできず。
Ark Linuxは期待していたのですが、空いているパーティションのみにインストール方法がわからなかったために断念。メニューには項目があったのですが、選んでも動作しませんでした。
SUSE 9.2:
完成度はさすがに高い。YaSTから設定できる項目がかなり多いのは便利。
ただし、アップデートだけならYOUからわりと楽にできるが、supplementaryをYaSTから扱う方法が良くわからず。それさえできればKDEを3.4にあげてほぼ理想の環境とできそうだったんだけど。
そのリリース時のパッケージで十分であればいいディストリビューションでしょう。9.3をフリーでインストールできるならお勧めかな。(まだ、DVD live版しかないようだ)
Ubuntu(Kubuntu):
日本語でインストールしようとすると文字が化ける、デフォルトがUTF-8環境等のちょっとした引っ掛かりはあるもののその辺りは回避可能だし、わりといい感じか。mainだけではパッケージが少ないのでuniverseも利用する必要があるな。
で、利用しなかった理由としては Wnn8 がうまく動作させられなかったこと、KDEが/usr以下にインストールされていたこと。
前者は Wnn8LE がだめなら scim-wnn という手もあるだろうけど、skimがなかった。(scim-wnnはチェックせず)
後者は安定版に加えて、HEADやBRANCH+自前パッチなどの複数のKDEをインストールして切り替えて利用するスタイルの私には致命的。BCの壊れたライブラリをロードする可能性があり、デバッグの邪魔だったりするので。
もう少し成熟してくると使いやすくなりそうだな。
Gentoo:
インストールやパッケージ回りの処理が遅い。まあ、それはパッケージは基本的にコンパイルするというポリシーからは仕方がないところではあるけれど。
まあ、パッケージはわりと多いし、基本安定で一部はunstableなものをインストールというのも比較的楽。(Debian系もできるけど。私が慣れてないだけで)
Xの設定一つとっても他のディストリビューションよりも面倒だし、手間はかかるが柔軟性としてはあるのがいいところか。
まあ、そのまま再インストールでは芸がないのでLVMで/opt, /var, /homeを分離してみたので多少は管理が楽になったかな。
ただ、LVMを良くわかってないからもうちょっと調べておかないとな。

次にgentooのほうへ。こちらがクライアントとしてメインの環境。最低限のインストールで済ますつもりでwnn8-le, wnn8-utilsを適当にebuildを仕立て上げてインストール。
iiimf環境はgentooのものを。が、うまくいかないな。設定か、他の問題かがよくわからんので、確実に動くはずの環境へということでiiimsfをunmergeして、iiimf-wnn8をインストール。/etc/init.d/iiimはiiimsfで使っていたものをそのまま使うのが楽か。virtual/iiimsfをebuildで作ってみたけれど、gentooのiiimsfが対応してないと意味がないんだろうな、多分。
インストール時にパーミッションが600とか、700になっていたところがあったようで、それらを644, 755に変更してようやく動作するように。ただ、なんか安定して使えないなぁ。
qtのiiimf用im-moduleがなかったり、xwnmo, kinput2, scimあたりもうまく扱えなかったり、自分の設定が問題だったりと試行錯誤しつつようやくwnn8-leが動く環境を構築。
が、変換していると「ユーザ予測辞書が読み込まれていません」と出る状態へ。なんでだ。wnn8-serverもインストールが必要なのか。それはあんまりやりたくないんだけどなぁ。
ところで、マニュアルにあったwnnlercはほんとに使われてるのだろうか。jserverなんて、uumrcにも設定があるし、geometoryは使われてないような感じが……。
動作検証用にDebianにgnomeの環境を作るのにも手間取ってる始末。さて、どういう検証をしていこうかな。

1. viの制御
アプリケーション側からIMのOn/Offくらいは出来てほしい。もう少し具体的にいうと、viのようなモーダルな環境でモードの移行時にユーザがIMのOn/Offを意識する必要がないようにできるようにしてほしい。
たとえば、編集モードからESCを押すとIMはOffに、そこからiやaコマンドでは事前の編集モードでのステータスに。rコマンドでは一文字を確定すればIMをOffになど。
今試してみると、KaoriYa.netさんの所のMS-Windows用gvimでは上記の作業が可能でした。
Gentooのgvim-6.3-r2では当然だめ。というか普通のIM経由の入力すら変だった。
2. たとえば辞書登録
ちょっと前にanthy-dev MLで辞書登録ツールで漢字欄と読み欄は最初からIMがOnになっててほしいとかって話題がありましたが、漢字欄で単語を変換したら、その読みが自動的に読み欄にコピーされるくらいの制御はできてもいいじゃないかと。いろいろややこしそうですが。
(ここから下はあまり期待とは関係なくなるけど)
3. 再変換
再変換機能はsurrounded textがあれば出来るのかな。Wnn8が再変換じゃないけど選択文字列の読みを表示できるって言うことはもしかしてこれはXIMでも出来る?
4. IMで補完
ここはもう全然関係ないけど、新たにエントリーを作る気にならなかったのでそのまま。
KDEとか、最近のGUI toolkitでは入力フィールドに補完機能を持たせたりしてたけど、IMが補完機能を持ってる場合、それに任せてもいいのかなとか。たとえば英語圏ではIMはあまり利用されてないと思っているけど、補完専用のIMなんかあると使われたりするのかな。そういうIMだとOn/Offってなくてもよさそうだな。日本語系で考えるとOn/OffのないIMって考えにくいけど、そういう方面で考えるとありうるかなと思えてくる。
で、補完に戻るけど、IMで無節操に補完してると大変かもって気にも。ってことは入力フィールドのプロパティーでも与えることが出来るといい?
まあ、補完そのものはアプリというかGUI toolkitが持っててもよさそうな。一長一短かなぁ。