XIMの開発者、樋浦秀樹さん亡くなる 33
ストーリー by soara
wingparser 曰く、
樋浦秀樹 (Hideki Hiura) さんが4月7日、癌のため亡くなられました。
本当に驚いています。
XIMの設計者としてLinuxでの多言語入力の礎を作られ、IIIMFも設計されました。
個人的には面識ないけれども、Anthy開発者のTabataさんとケンカのような議論をしていたのをネットで眺めていました。
心からお悔やみ申し上げます。
wingparser 曰く、
樋浦秀樹 (Hideki Hiura) さんが4月7日、癌のため亡くなられました。
本当に驚いています。
XIMの設計者としてLinuxでの多言語入力の礎を作られ、IIIMFも設計されました。
個人的には面識ないけれども、Anthy開発者のTabataさんとケンカのような議論をしていたのをネットで眺めていました。
心からお悔やみ申し上げます。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
マジでー(AAry (スコア:4, 興味深い)
ちょっと違うな。あれはモロにlocale依存で、例えば日本語localeで簡体字中国語を入力するみたいな使い方は想定されていない。ご本人もXIMの設計には満足していなかったようで、一刻も早く抹殺したいっておっしゃっていましたが…
あれはJava Stationに熱中していたSunの事情によるところが大きいけど、Solarisの入力フレームワークにいろいろ後付けして妙に複雑にしていた印象があって正直よくないと思った。そもそも今となっては思想が古すぎたな。今はUNIX風のOSもパーソナルコンピュータとして使うようになってるしね。まあジャストシステムがSolaris向けにATOKを作り続けているうちは死なないかもしれんが、結局IIIMFが広く受け入れられることはなかったな。そういや樋浦さんはSunを辞めてジャストに行ってたんだっけな。Xfyの仕事をやってたはず。
田畑氏は文章を書かせると日本語が不自由そうな人に見えてしまって、そこだけが残念でしたが…ｗ
ともあれお悔やみ申し上げます。
Re:マジでー(AAry (スコア:1, 興味深い)
Re:マジでー(AAry (スコア:1, 興味深い)
XIMとUTF-8が普及する前のUNIXは、Mule以外まともに日本語が通るアプリがなく、
Xの「日本語化」に酷いバッドノウハウの塊のようなことを強いられました。
まだまだUNIXの日本語環境には問題が残るとはいえ、当時を思うと
こうしてLinuxでMozillaから気軽に安定して日本語を使えること自体夢のようです。
感謝とともにご冥福をお祈りします。
Re:マジでー(AAry (スコア:1)
XIMは、もともとX11R5のXlib APIです。X11R5が出たのが1994年。この時代に多言語入力なんていっても鼻で笑われましたよ。 Unicode 1.0と統合されたISO/IEC 10646-1が出たのが1993年ですからね。だからって、世の中が一気に変わるわけじゃなかった。時代背景を考えてくださいな。
樋浦氏といえば、当時はhtt（「樋浦が徹夜で作った」の略）とか、やってたんだよなあ。
彼の具合が悪いらしいと聞いたのが、今月初めのこと。それが、もう訃報ですか。なんてことだ。無常を感じます。さみしいよ。
Re: (スコア:0)
Compound Textは当時からあったと思うけど。むしろDIS 10646の設計をかなぐり捨ててUnicode 1.0と統合されたことに日本(主にfj.kanji方面)では猛反発があったんじゃなかったっけ? 多言語=Unicodeと考えることこそ時代背景を無視してませんか?
Re:マジでー(AAry (スコア:1)
はいはい。Compound Textはありましたよ。もちろん、それを使ってマルチリンガル環境を構築することも可能だったかもしれません。
Unicodeも嫌われていました。私も嫌いだった。いまでも異体字がどうこうとかいう話は嫌になる。でも、当時のEUC-JPやShift_JISがそういう問題を解決していたわけではない。
でもね、たかが文字処理に（あえて「たかが」といわせてもらいます。たいていのプログラムにとってそれが主要な地位を占めてはいないという意味で）Compound Textのような複雑なエンコーディングを使うことが、現実的だったかどうか、それに、当時マルチリンガル処理がどれほど現実に求められていたか、ということを考えれば、XIMがlocale依存だったのも時代的制約のひとつですよ。
Re: (スコア:0)
Re:マジでー(AAry (スコア:3, 興味深い)
「まるで存在していないかのような軽さと安定性」が必要なのですが、
初期のIIIMFは非常に不安定で、悪い意味で「存在感」がありすぎでした。
事情を知らないユーザにしてみれば「Fedoraはよく固まる」ということになり、
初期Fedoraの悪評の一因になってしまっていたような気がします。
パッケージングもモジュールが多いので非常に大変でした。
Fedora版のソースRPMには公式リリースに含まれていないパッチが多く入っていて、
何をベースにしたらいいのか困りました。
Tabataさん-Hiuraさんの諍いからかAnthyのサポートが遅れたのも痛かった。
フリーで使える連文節変換エンジンがCannaじゃインパクトがないですから。
ユーザとしてIIIMFを愛用するには至りませんでしたが、
世界各国の優秀なメンバーを集めて多言語入力を議論する場を作ったことは
有益だったのではないでしょうか (IIIMFの"Owners [openi18n.org]"を参照)。
XIMなどの仕組みは、単に作るだけでなく、上流に取り込んでもらうための英語交渉力と人脈が必要です。
コードを書くだけでなく受け入れてもらうための交渉もできる人はなかなかいないと思います。
Re:マジでー(AAry (スコア:1, 興味深い)
＞Tabataさん-Hiuraさんの諍いからかAnthyのサポートが遅れたのも痛かった。
これは当時Anthyに興味を持っている人がuimに行っちゃったってのもあるけど、IIIMFのLE（言語エンジン）を作ること自体が敷居が高すぎたと思う。仕様が複雑な上に、ドキュメントがあるにはあるけど目に付くところにはなかった。SCIMにはAnthyを使った入力エンジンができてたし、im-jaみたいなフレームワークを介さずに直接ツールキット固有のAPIにアクセスするような実装（後にXIMサーバにもなったけど）でもAnthyは比較的早期にサポートされてた。
Re:マジでー(AAry (スコア:1, 興味深い)
諸行無常 (スコア:1)
iiimfの座を奪ったscimも、Fedora 11でiBusにその座を取って代わられたのですから、時の流れは早いものですね。
いまさらながら、ご冥福をお祈りいたします。
Re:諸行無常 (スコア:1, 参考になる)
まだ大きな変化が起こる余地はあると思うな。X Window SystemにXKB2を導入する話があるから。Re-designing input methods with XKB [blogspot.com]も参考までに。
というか、今になってやっとこの発想が出てきたかという感想。コンセプトだけ見ればWindowsのTSFなんかはずっと先を行ってるからねえ。
Re: (スコア:0)
iiimf と scim は開発者どうしの話し合いの結果、
ibus に統一されたって感じがありますが
とにかく合掌
NEA-OSS WG3/SWG1 (スコア:3, 参考になる)
前にも書いたんだけど、北東アジアOSS推進フォーラムのワーキンググループ（NEA-OSS WG3/SWG1）で入力メソッドエンジンのSPIの標準化の話 [srad.jp]だね。樋浦さんも去年戻ってきて、The world is adapting to the standard born at WG3 (PDF) [ipa.go.jp]という発表資料を出してる。
で、仮にこれが実現すれば、IMフレームワークの実装を取り替えても同じIMEをそのまま使い続けることができるようになるわけで、プロプラのIMEベンダーなんかは商売しやすくなるよね。まあ日本はIMEベンダーがほとんど死滅しちゃってるけど、中国はまだ乱立しててそれなりにモチベーションはあるし。
Re:諸行無常 (スコア:1, 参考になる)
Re: (スコア:0)
> まぎらわしいですが、それはimbusです。
なるほど。勉強になりました。
黙祷
驚きました…ご冥福をお祈りいたします (スコア:3, 興味深い)
昨年お会いしたときは、元気そうだったのに…。
メールでやりとりしているときは「気むずかしそうな人だなあ」という印象でしたが、実際に会ってみるととても気さくな方でした。
ご冥福をお祈りいたします。
Linux国際化 (スコア:3, 興味深い)
Linux 研究会 NLS 部会では大変お世話になりました。
おかげさまで Glibc 2.x の国際化機能も実用的になり、今多くの国の人が自国語で不自由なく Linux を利用しています。
ご冥福をお祈り致します。
Re: (スコア:0)
glibc 2.0.xの頃にはwcsmbs-localeでお世話になりました。ありがとうございます。
でも、glibcのメンテナって口の悪さで有名なUlrich Drepper大先生ですが、国際化機能に関わった方々はいろいろ大変な思いをさせられたりしませんでしたか？
結局何が良いの？ (スコア:2)
Re: (スコア:0)
複数ツールキット対応は後付けだと思います。まずはプロトコルドライバやUIなどの各種IMEで共通して使える機能の提供と、そして複数IMEの切り替え器としての機能。
合掌。
残された課題は (スコア:1, 興味深い)
muleとかkinput2とかを使っていた頃と比べて、Linux/BSDの国際化は格段に進みましたが
残された課題は何でしょうか。
欧米人が開発したソフトウェアであっても自動的に、あるいは簡単なプログラム作法を
守ってもらうだけで国際化対応したソフトウェアになる、という状況になればと思います。
文字コードはUnicodeで決まりですね。ISO2022とかロケールとかを扱わざるを得なかった
時代と比べ、格段に状況は良くなりました。ヨーロッパ人もUnicodeを必要としていますから、
黙っていても勝手にやってくれるでしょう。
フォントについては、いまどきツールキットが面倒見てくれますから問題なしですね。
日本語（多国語）入力についても、同様でしょう。
しかし、内部でのテキスト処理は、まだ課題として残っているようです。
日本語は（中国語も）単語の切れ目に空白文字を用いませんから、たとえば
改行処理を空白のところでやるようなソフトウェアは、なんとかしないといけません。
コンソールにおける文字幅も問題ですね。欧米人に「wcwidth()を使って下さいね」
と言ったところで、どこまで理解してくれるか。それに、すべてのソフトウェア
開発者に理解してもらうなんてのは無理ですし。
ほか、何かありますでしょうか？
Re: (スコア:0)
国際化の基盤みたいな部分はだいぶ整備が進んだ気がするな。最近のOSならクメール、ミャンマー、インド諸言語なんかも対応できてるでしょ。あとは例えば自然言語処理とか、その部分を頑張るべき時期に来ていると思う。
Re: (スコア:0)
> ヨーロッパ人もUnicodeを必要としていますから、黙っていても勝手にやってくれるでしょう。
おれがヨーロッパ人なら、面倒だからUTF-8は2バイトまで対応とするかも。
Re: (スコア:0)
>欧米人に「wcwidth()を使って下さいね」
wcwidth()は記号類とかキリル文字などでユーザがほしいEUC-JP的な幅を返してくれないとおもうけど。
その問題は解決されたんだっけ？
それに1文字しか拾えない文字幅関数で合成文字をどうしろと。
日本人だってその程度の知識なんだから、端末の表示幅なんて解決しないよ
彼の好きだったもの、嫌いだったもの (スコア:1)
彼はプログレッシブ・ロックが好きだと聞いていました。そっち方面はまるでくわしくなかったので、誰のどの曲が好きとか、そういう話まではわかりませんが。もし、お別れ会とか、そういうのが開かれるのであれば、彼の好きだった曲で送ってやりたいと思います。どなたかご存じではありませんか？
彼氏は、タバコが嫌いでした。禁煙運動の急先鋒だったようです。そんな彼がアメリカに行ったのは、おそらくとても良かったのだろうと思います。でも、病気は肺のあたりのガンだったと聞きました（又聞きです。あまり信用しないように。）。もし本当にそうだとしたら、とても皮肉なことだと思います。
彼は、シリコンバレーグルメマップなるものをつくっていたと聞きました（完成したものなのかどうかもはっきりしませんが）。まあ、とにかく、飯のうまい店をよく知っていて、あちこち連れていってもらいました。いまでもいくつか覚えていますが、私自身が、そちらにいくことがこの10年近くなかったので、いまでもそれらの店があるのかどうかまではわかりません。Mountain ViewのCastro Streetに「富臨門」（ふれもん）という中華料理屋さんがあったと思いますが、まだあるんでしょうかね。
なんか、とりとめなくなってきたので、いいかげん終わりにします。まだ彼がいなくなったという実感が湧いてこないのです。すみません。
htt (スコア:0)
SunOSのhttにお世話になった人も多いんではないでしょうか？
なんでインプットメソッドって枯れないの？ (スコア:0)
Re:こういう会社が日本語を壊してどーするよ(スコア -42: オフトピ) (スコア:1)
先に英文を書いて、それを直訳したのかもしれない、と思いました。
（右上のドロップダウンリストを English にすると英文に切り替わります）
Re:こういう会社が日本語を壊してどーするよ(スコア -42: オフトピ) (スコア:1)
確かにこういうときは 「逝去」と [megasoft.co.jp]か永眠って いうのが 定番っていうか常識 [cyber-u.ac.jp]でしょうけど。
Re: (スコア:0)