YamaKen
yamak****@bp*****
2004年 11月 15日 (月) 16:01:14 JST
At Thu, 11 Nov 2004 03:58:07 +0900, tkng****@xem***** wrote: > On Wed, 10 Nov 2004 21:57:00 +0900 > YamaKen <yamak****@bp*****> wrote: > > > > > TOKUNAGA Hiroyuki tkng****@xem***** > > 2004年 11月 10日 (水) 20:00:55 JST > > > ウムラウトやアクサンなどを入力する方法としてはDead keyやMulti > > > keyがあります。これらをまとめてComposeKeyと呼びます。GTK+の > > > gtk_compose_seqsというテーブルにはdead keyとmulti keyの両方が定義し > > > てあるので、たぶんこれが正しい呼び方だと思います。 > > > > composeという用語は単にcharacter compositionから来ているだけだと > > 思うので、dead/multi key compositionだけを指して"compose"と呼ぶ > > のはまずいと思います。multi-key is a compose keyという表現ならい > > いと思いますが。 > > > > 私の認識ではrk等のローマ字かな変換もcharacter compositionの一種 > > なのでdead/multi key compositionだけをcomposeと呼ぶ事は避けたい > > です。 > > > > また、Xのcompose tableを見るとdead/multi key compositionだけれど > > 非ヨーロッパ系言語(アラビア語、ヘブライ語、ハングル、カタカナ等) > > なエントリも沢山あるので、dead/multi key composition == ヨーロッ > > パ系言語という仮定も置くべきではないと思います。 > > /usr/X11R6/lib/X11/locale/en_US.UTF-8/Composeでいろいろサポートできてる > （=ヨーロッパ系言語と非ヨーロッパ言語のサポートがテーブルを切替えずに同 > 時にできてる）実例があるなら、uimでもuim-composeとしてそういうのを作ると > いうのは選択肢のひとつとしてアリじゃないかと思います。 どんな言語向けのエントリを含むかにかかわらず、それに"compose"と いう名前を冠するのはまずいというのが私の主張です。なぜならrkや tcodeもa compose IMであり、その存在を無視してuim-composeというIM を作るとrkやtcodeはcompose IMではないという誤解を招くからです。 Xのテーブルが"Compose"という名前を持っていてもおかしくないのは全 てのcompose IMがその1つのファイルに集約されているからです。 また、XやGTK, Qtでは全ての言語向けのcomposeテーブルをまとめて1つ のテーブルとして扱っていますが、uimでは言語毎のテーブルは別々に 分けておいて用途に応じて結合して使うのが柔軟性を重視するIMフレー ムワークとしてあるべき姿じゃないかと思います。1つのファイルに複 数のテーブルを収めるのはいいと思いますが。 ちなみに今設計を進めているrkの後継には"compose"という名前を冠す る事も考えていました。だからuim-composeはやめときましょう。 この議論の発端となったQtでのdead/multi keyサポートについては後で 別途回答します。 ------------------------------- ヤマケン yamak****@bp*****
