Etsushi Kato
ek.ka****@gmail*****
2006年 8月 23日 (水) 22:14:00 JST
On 8/22/06, YAMAMOTO Kengo / YamaKen <yamak****@bp*****> wrote: > うまく意図が伝わらなかったような気がするので、図示してみます。 > > Anthy等の一般的な連文節変換エンジンだけを扱う場合は、そのモデルで > 以下のようにほとんど問題なく対応できると思うんですが、 > > config (for each bridge) > | > V > bridge <------------------------ libuim <------------------- uim-anthy > UPreeditAttr_RawText preedit-rawtext > UPreeditAttr_Converted preedit-converted > > > SKKのような特殊なIMを扱う場合、以下のようにuim.hにSKK固有の定義 > が入り込み、layer violationが発生します。このような形態ではIMの > 実装が変化する度にlibuimと各ブリッジの改訂が必要になりmodularな > IM拡張性を破壊するので、uimとしては受け入れられません。 ぼくも、特殊化した attribute を入れたいとは思っていません。 > これを避けるため、IM内で以下のように汎用の意味レベルプリエディッ > ト属性にマッピングし直せば上記の問題は解決しますが、この場合ブリッ > ジに渡される属性は、それぞれがどのように装飾されるのかを見透かし > た偽りの意味を持つ事になります。例えば、「▼」は意味的にはraw > textではないし、converted unselectedでもありません。 > > config (for SKK for each bridge) > | > V > bridge <---------------------- libuim <------------------- uim-skk > UPreeditAttr_RawText rawtext <- skk-preedit-mode-mark > UPreeditAttr_Converted converted <- skk-preedit-head > UPreeditAttr_RawText rawtext <- skk-preedit-okuri > UPreeditAttr_??? ??? <- skk-preedit-conv-appendix UPreeditAttr_1, UPreeditAttr_2 とかでもいいかもしれません。 > このように、IMの動作上の意味をもってプリエディット属性の抽象化を > 行うと、特殊な、または事前に想定していない動作モデルのIMに正しい > インタフェイスを提供する事が原理的に難しくなります。偽りの属性に > マッピングした場合は意味レベルの属性を導入した意義を根本から破壊 > するし、個別のIMの都合でuim.hの定義を頻繁に更新するようでは、IM > フレームワークの存在意義が無くなります。 ある程度は converted とかの汎用的な意味付けの名前で、残りの 特殊なものは上に書いたように attr1、attr2 とかでいいような気が します。 ぼくとして気になっていた部分は、UPreeditAttr_Underlined とか IM で指定されている属性に対して、ユーザー (ブリッジ) としては reversed やアンダーラインなしで使いたい場合もあるので、IM から 見た目を指定するのは違和感があるという点でした。とくに、これらを GUI などでカスタマイズする場合おかしなことになるのではないでしょ うか? > > > なので、落としどころとしては、'underline'や'reverse'に代わる「装 > > > 飾」レベルの抽象的な名前を追加するあたりじゃないでしょうか。例え > > > ば'emphasized'とか。ただ、それをするほどのメリットが得られるかど > > > うかは直感的な名前セットを考案できるかにかかっているので、それま > > > では現状維持の方がいいと思います。 > > > > どんなものを用意するかは難しいですね。 > > というわけで、加藤さん案のようなIMの動作上の意味ではなく、以下の > ように装飾レベルの意味で属性を定義しようというのが私の案です。こ > れなら少なくとも属性の意味の偽称は原理的に発生しなくなります。 なるほど。理解しました。ただ、装飾レベルがいいという点は、まだ 疑問があります。 > config (for each bridge) config (for SKK) > | | > V V > bridge <---------------------- libuim <------------------- uim-skk > UPreeditAttr_Underlined underlined<- skk-preedit-mode-mark > UPreeditAttr_Hilighted hilighted <- skk-preedit-head > UPreeditAttr_Underlined underlined<- skk-preedit-okuri > UPreeditAttr_Light light <- skk-preedit-conv-appendix > . . > . . > . . > > これはあくまでも例なので、実際に導入する場合は属性名のセットやそ > れらの重ね合わせ等について慎重に議論する必要があると思います。 > > 加藤さんの動機の半分は属性の種類が少ないという事だと思うので、そ > れについてはこちらの案でも解決できると思いますがどうでしょうか。 装飾レベルで多くの名前をつけるのは難しそうに感じました。 -- Etsushi Kato ek.ka****@gmail*****
