Fcitxでもvi協調モード

vi協調モードというのはuimにある機能で、ようはviで編集モードの時にESCキーを押すとuimがオンになっていてもオフにしてくれる機能のことです。
vi（多くの方はvimをお使いでしょうが）ユーザーには、これがどのぐらいうれしいかはわかっていただけると思います。

Fcitxでこれを実現したい場合、fcitx.vimを使用するのが王道っぽいのですが、そんなに大掛かりなことをしなくてもいいのになーという気分ではありました。
そこでFcitx (简体中文)を見てみると、fcitx-remoteを使用する簡単な.vimrcが紹介されていたので、これを使うことにしました。中国語簡体字はまったく読めませんが、コピペすれば使用することができます。とても便利です。

vi/vimでFcitxを使用してバリバリ日本語を入力される方は、検討してみてもいいのではないでしょうか。

Ubuntu 13.10の日本語入力

Ubuntu 13.10の日本語入力も販売を開始しました。

goo blogはGumroadのURIが直接貼れないという腐った仕様なので、リンク先に詳細を用意しました。
初めて引っ越ししたくなったぜ……。

Wnn8のアップデートモジュールがリリース！

	Wnn8 for Linux/BSD
	クリエーター情報なし
	オムロンソフトウェア

Wnn8 アップデートモジュール

何を言っているかわからねーと思うが、俺も何をされたのかわからなかった……。
Wnn8は"Wnn8 for Linux/BSD"として発売されましたが、BSD(ここではFreeBSDのことらしい)がIIIMF非対応ということで、長らく、長らく、長らくアップデート待ちでした。
ついに、ついに、ついにFreeBSDに対応したばかりか、Linuxの64bit対応もされています！
オムロンソフトウェアに一体何があったのでしょうか……。

時系列はこんな感じです。
2005年01月14日…プレスリリース
2005年02月25日…発売開始
（発売後程なくして優待バージョンアップ版を購入。5712円だったらしい。ちなみにインストールしたことはない）
2006年04月25日…FAQアップデート前最後の更新
2007年11月30日…（関係ないけどATOK X3発売）
2009年03月23日…「Wnn8 for Ubuntu」の発売をプレスリリース（ちなみにエムズソリューションのWebサイトはなくなっています）
2009年03月30日…「Wnn8 for Ubuntu」発売開始
2013年11月21日…Wnn8 アップデートモジュール公開

Ubuntuの動作確認はないものの、インストールスクリプトを見る限りUbuntuも対応しているようです。
とはいえXIMにしか対応していないので、実用に耐えない可能性が極めて高いです。辞書も古いですしね……。
相変わらずSDKは配布していないので、ibus-wnnといったものの開発は不可能です。何年検討しているの……。？

どうしてこの時期に、というのは非常に気になります。てっきりこのまま黒歴史化するものだと思ってました。
考えられる要因としては、
1. ATOK Xが脱落したので、売上を伸ばしたい（でもIMModule対応を考えたらATOK Xのほうがいい気が……）
2. FreeBSDに対応するように強い圧力がかかった（どこから？）
3. Wnn9発売前の露払い
何はともあれめでたいことです。

Input Methodの変遷に思いを馳せる

なんでまたInput Methodが変わるようなことになっているんだ、一体何が起きているんだ、というのは、まぁ当然出てくる感想ではなかろうかと思います。
とはいえ、UbuntuでSCIMが使えるようになったのは6.06からで（その前にあったのは私の非公式パッケージ）、SCIMからIBusに変わったのが9.10からなので、Ubuntuの歴史9年間を考えるとそんなにコロコロ、ってわけでもないと思います。いや、どうなんでしょう。自信なくなってきました（ぉぃ

もうちょっと大きな流れで見てみると、
kinput2→SCIM→IBus(→Fcitx?)という変遷かと思います。Fedoraは確かKinput2→IIIMF→SCIM→IBusという流れですね。
よくよく考えてみると、これってその時々のニーズに応じた変更になっていることがわかるのです。
それを記憶ベースで書き出してみます。あくまで記憶なので間違ってたらごめんなさい。

Kinput2→SCIMはどんなメリットがあったのかというと、まずは1つのInput Methodで複数の変換エンジンを瞬時に変更できましたし、そればかりか言語をまたいだ変更も可能でした。GTK+（とQt）にImmoduleという仕組みが導入され、1つのInput Methodで複数（って2つしかないけど）のImmoduleをサポートする必要もありました。当時の時点で多言語化に優れていたのがSCIMで、これが選択されたと記憶しています。

SCIMは確かに優れていましたが、SCIMと変換エンジンを繋ぐIMEngineを書くのにC++が必要だったこと、C++で書かれていたからlibstdc++のバージョンに依存していたこと（のちにscim-bridgeで解決）、SCIMが落ちたらアプリまで落ちちゃうなど、いろいろな問題がありました。作者さんもTurbolinux→Novell→Googleと転職してアクティビティが下がったというのも原因の一つかもしれません。

IIIMFの作者とSCIMの作者で新しくimbusというのを作ろうとしたものの、コミュニケーション不足やらそもそも構想が壮大すぎるやらでさっぱり進まなかったので、その構想を手っ取り早く実装したのがIBusと、私は理解しています。設定ツールやらIMEngineやらいろいろなものを独立したプロセスにして、プロセス間通信を使用するとか、そのあたりです。あとは全体をPythonで書いてC++の知識がなくてもIMEngineを書けるようにしたとか、SCIMから着実に改良しています。もっとも、パフォーマンスの問題でコアはC言語で書きなおされましたが。IBusの作者さんも、元はRed HatでしたがGoogleに転職しています。

IIIMFは少なくともLinuxディストリビューションでは主流になることはありませんでしたけど、Solarisではよく使われましたし、ATOKでも使用していました（います、ですね。現在進行形です）。あ、SolarisでもATOK使えるし同じじゃん。
これが主流にならなかったのは、たぶん大きすぎ複雑すぎたのが原因じゃなかろうかと思います。セキュリティの問題もありましたけど、のちに修正されています。まぁそれが遅すぎたというのはあると思いますけど。あとはパッケージャー泣かせでもありました。

uimは確かに主流にはならなかったですけど、息は長いですし、Debianではデフォルトですし、筋が良かったのは間違いありません。そもそもメンテナーが何人も(5人？)交代して10年以上継続しているInput Methodってこれしかないわけです。これはすごいことです。主流になれなかったのは中国語対応が弱かったからでしょうか。SCIMもIBusもFcitxも作者は中国人ですね。

Fcitxに関しては、どう評価すればいいのかよくわからない、というのが本音です。というのも、私が中国語を知らないのでIBusと比較してどういうメリットがあるのかわからないのです。
Input Methodとしては、IBusよりもSCIMに近いというか、IBusとSCIMの中間というか、若干戻った感じもします。IMEngine（という言い方をするのかは知りませんが）はC++ですし。
とにかく細かな設定ができるのがFcitxの特徴だと思います。ただ、最初にそれを見たときはあまりに設定項目が多すぎて困ったし、実際自分で使う気にはなりませんでした。twitterでつぶやいたら作者さんもそうだよね、でも最新版ではまた変わってるから試してみてって言われたので、実際試してみたらわりといい感じだと思いました。今は当時よりもさらに項目が減っていますが（減っているというか隠してあるだけですけど）、このぐらいならいいと思います。
Fcitxが注目されたのは、やはりIBus 1.5の失策によるものという感は否めません。IBusも最初GNOMEと統合すると聞いたときはいい事だと思ったのですが、あんなに機能を削られるとは思いませんでした。シンプルというのと機能を削るのはイコールではない気がします。LinusもGNOMEに関して似たようなことで怒っていましたよね。それでもGNOMEは概ね正しい方向で進化しているとは思いますけど、なんであんなにフォークされまくるんでしょうか。

なんだかうざい昔語りになってしまいましたが、Input Methodの変更にはそれなりのメリットがあったのだよ、というお話でした。

GTK+ 3.0対応のIIIMGCFをATOK X3で使用してみる

以前ATOK X3（というかIIIMF）のGTK+ 3.0対応IIIMGCFがないと言いましたが、どうやらあったようです。

んで、試しに動かしてみたところがこちら。
確定前の文字列（プレエディット）の一番後ろの|（キャレット）の下に候補ウィンドウが来ていますが、これが正しく動作している証拠です。XIMだと候補ウィンドウが左下に出ますからね。
ビルドは結構大変というか、これができる人はUbuntu Japanese Teamでパッケージャーやってみませんか？　という感じです。
今のバージョンでのUbuntuでは必要ありませんが、11.10では必要になることはハッキリしています。おいおい対応を考えていきたいところです。

ATOK X4を考える

ATOK X3のリリースから4年目になり、諸処の事情で継続して使うのが困難になってきています。
Ubuntu 11.04のパッケージルールの変更に追随できてません。いろいろなことを考えれば、10.04で使い続けるのがいいのかなぁと思います（私はそうしています）。
そろそろATOK X4が出てもいいのかなーと思うわけですが、具体的にどのぐらい現実性があるのか考えてみました。

・IIIMFの継続使用はしんどい
ATOK X3はIIIMFで使えるようになっているわけですが、これはもともと当時Sunに在籍していた樋浦さん（故人）が開発したものです。もちろん開発者はSun以外の人もいましたが、Oracleに買収されてどうなったのかよくわかりません。少なくとも開発リポジトリにはもうずいぶん前からアクセスできません。
最近のトピックとしてGNOME 3があるわけですが、言うまでもなくGTK+ 3を使用しているわけです。で、これ用のIMModuleが必要なわけですが、たぶん今のところ存在しません。すなわち、XIMで使用することになってしまうわけですね。
（余談ですが、現在のOneiricにあるIBusは今のところGTK+3に対応したIMModuleを有効にしておらず、なかなか悲惨です）
もちろんジャストシステムがこれを開発することもできるわけですが、あまり前向きな対応とは言えません。
Solarisのことを考えるとIIIMFの方がいいかもしれませんが、特に考慮しなくてもいいような気がします。

・じゃあIBusは？
IBus本体には可能な限り手を入れず、IBus-ATOKみたいなブリッジと設定画面を作成し、これをプロプライエタリなライセンスで販売することはできるのでしょうか？
あくまで私が理解している限りですが、これはできます。
IBusは設定画面を好きに作ることができます。現にMozcはQtを使用した設定画面にしています。ATOK X3の設定画面はかなり作り込んでいますが、これと同様のものを用意するのはそれほど難しくないでしょう。
さらにIBusはプロセス間通信を採用しているので、ライセンスも特に気にすることなくプロプライエタリなものにできそうです。
というわけで、IIIMFからIBusにする技術的な問題は特になさそうです。
余談ですが、IBusは樋浦さんやSCIMの作者James Suが取り組んでいたIM-Busのコンセプトを、今あるもので実装したものです。IM-BusでもD-Busを使うことを検討したものの、プラットフォームに依存する部分があるのでBus(IPCシステム)の作成から始めるつもりだったと、樋浦さんからお聞きしたことがあります。まぁそれじゃあいつまで経っても出せませんよね。
さらに余談ですが、JamesもIBusの原作者Peng Huangも今はGoogle社員です。Jamesが転職してコミュニケーションが取りにくくなってさぁと樋浦さんが愚痴っていたのを思い出します。

・問題はどのぐらい売れるか
はっきり言って、ATOK X4が出たとしてたいして売り上げは見込めません。
大口の顧客(?)であったTurbolinuxはもはや見る影もありませんし、購入するのはおそらくUbuntuユーザーぐらいのものでしょう。5桁の売り上げが見込めるかどうかぐらいでしょうか。根拠はありませんが。
Ubuntu Software Centerで販売すれば外国人による購入も見込めるかも知れませんが、英語サポートが必須なのでなかなか厳しそうです。
Turboも一応原点回帰して新バージョンを出したいという意向を表明していますが、アテにするにはリスクが高すぎます。
他のもろもろを考えても、少なくとも私にはこれだけの売り上げが見込めますという数字は出せません。
Ubuntuがいろいろなところで採用されそうという話はちらほら耳にしてはいるのですけどね。

商売としてやっている以上売り上げが見込めないと出すわけにはいかないわけで、現実的にはなかなか厳しいのかなぁと言うのが現時点での私の考えです。
もちろんこれが間違いであり、サクッと出してくれるとうれしいのですが。もし出たら2ライセンスは買います。

……なんか樋浦さんとの思い出話になってしまいましたね。てへぺろ(・ω<)

最新版Mozc(1.1.690.102)のちょっとしたメモ

Google 日本語入力の開発版をアップデートします。（1.1.690.10x）

これ、Mozcに関してはすでにソースコードが配布されているので、手元でビルドしてみました。

ビルドにはlibzinnia-devが必要で、手書き文字認識を使用する場合はtegaki-zinnia-japaneseが必要です。

文字パレットを起動する場合は
/usr/lib/mozc/mozc_tool --mode=character_palette

手書き文字認識を起動する場合は
/usr/lib/mozc/mozc_tool --mode=hand_writing

を実行します。

SCIMで試してみたところ、再変換機能は動作しませんでした。まだ実装されていないようです。
現行版のIBusには、再変換に必要な機能が実装されていません。

今のところパッケージの配布は行っていませんので念のため。

Mozcがアップデートされましたよ

Google 日本語入力の開発版をアップデートしました。(0.12.422.10X)

ご愛顧いただきましたMozcアイコンはこれにてお役ご免となりました。
今までありがとうございました。
新しいのをインストールする前に、自分でインストールしたアイコンは消しておいた方がいいかもしれません。特に悪さはしませんが、ファイル名とか変わっているものもあるのでゴミになってしまいます。

Mozcアイコンのライセンスについて

Mozcアイコンは、できはともかくライセンス的にはMozcと一緒に配布しても問題ないように心がけています。今までに2つの問題を解決しました。

1. 使われているフォントがライセンスに抵触する可能性がある
→問題のないM+にしたので、懸念される方は最新版に差し替えてください

2. ライセンスはMozcと一緒だけではなく、2-clause BSDにもして欲しい
→そうします。Mozcと一緒、あるいは2-clause BSDのどちらかを選択してください。そういう事情があるというのはちょっと想像できませんが、両方にしたいという場合もOKです。

ほかにも懸念事項がある場合は、伝えていただければ解決の努力をします。

というか、私がやるべきなのはMozcアイコンの作り方を書くことだと思うんですよねぇ。

追記:
アイコンそのものはココにあります。

Mozc用アイコンをまたまたアップデート

フォントをM+に変更しました。ほかにも文字数を減らすとかいろいろ変更しています。
M+フォントの作者さんには本当に感謝しています。商用のフォントと区別が付かないと、ちょっと見ただけでもおかわりいただけるでしょう。

Mozcアイコン
ツールアイコン
辞書アイコン
設定アイコン

ライセンスはもちろん前と同じくMozcと同じとします。