YAMAMOTO Kengo / YamaKen
yamak****@bp*****
2006年 8月 22日 (火) 08:37:50 JST
ヤマケンです。 At Sat, 12 Aug 2006 13:09:37 +0900, ek.ka****@gmail***** wrote: > > On 8/11/06, YAMAMOTO Kengo / YamaKen <yamak****@bp*****> wrote: > > 例えば、uim-skkでは'selected'や'converting'に相当する意味レベル > > のタグは以下のようにうんざりするほど専用的に細分化されています。 > > これらの高レベルタグを全てuim.hに収容したり、または汎用意味レベ > > ルタグに再度マッピングする等を行う手間をかけるほどのメリットは無 > > いと思います。 > > > > (define skk-style-ddskk-like > > '((skk-preedit-attr-mode-mark . preedit-underline) > > (skk-preedit-attr-head . preedit-underline) > > (skk-preedit-attr-okuri . preedit-underline) > > (skk-preedit-attr-pending-rk . preedit-underline) > > (skk-preedit-attr-conv-body . preedit-reverse) > > (skk-preedit-attr-conv-okuri . preedit-underline) > > (skk-preedit-attr-conv-appendix . preedit-underline) > > (skk-preedit-attr-direct-pending-rk . preedit-underline) > > (skk-preedit-attr-child-beginning-mark . preedit-underline) > > (skk-preedit-attr-child-end-mark . preedit-underline) > > (skk-preedit-attr-child-committed . preedit-underline) > > (skk-child-context-beginning-mark . "【") > > (skk-child-context-end-mark . "】") > > (skk-show-cursor-on-preedit? . #t) > > (skk-show-candidates-with-okuri? . #f))) > > まさに問題に思ったのは SKK に関してで、前に uim-fep の山本さんが > dcomp の色付けの話をされたとき、underline とか reverse という > uim のプリエディット表現では無理だな、と思ったのがきっかけだった > はずです。現状では、bridge は underline と指定されたのが okuri > なのか dcomp (appendix) なのか区別することはできないので、適切に > 色づけなどできないわけです。 > > また、anthy などのシンプルなものでも、入力中の変換前の文字、変換 > されたあとの文字で選択されていない文節のものを区別する方法が、両 > 方とも underline 指定されている現状では不可能です。ここはそれぞれ、 > segment ごとに、意味 (raw text とか converted unselected) とかを > ブリッジに渡した方がいいのではないかと思います。 うまく意図が伝わらなかったような気がするので、図示してみます。 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としては受け入れられません。 config (for SKK for each bridge) | V bridge <------------------------ libuim <------------------- uim-skk UPreeditAttr_SKKModeMark skk-preedit-mode-mark UPreeditAttr_SKKHead skk-preedit-head UPreeditAttr_SKKOkuri skk-preedit-okuri UPreeditAttr_SKKAppendix skk-preedit-conv-appendix . . . . . . これを避けるため、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 . . . . . . このように、IMの動作上の意味をもってプリエディット属性の抽象化を 行うと、特殊な、または事前に想定していない動作モデルのIMに正しい インタフェイスを提供する事が原理的に難しくなります。偽りの属性に マッピングした場合は意味レベルの属性を導入した意義を根本から破壊 するし、個別のIMの都合でuim.hの定義を頻繁に更新するようでは、IM フレームワークの存在意義が無くなります。 > > なので、落としどころとしては、'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 . . . . . . これはあくまでも例なので、実際に導入する場合は属性名のセットやそ れらの重ね合わせ等について慎重に議論する必要があると思います。 加藤さんの動機の半分は属性の種類が少ないという事だと思うので、そ れについてはこちらの案でも解決できると思いますがどうでしょうか。 なお、色情報の扱いについては[Anthy-dev 2662]で書いた通りブリッジ レベルの解釈に留めたいと思います。 ------------------------------------------------ YAMAMOTO Kengo / YamaKen yamak****@bp***** FAMILY Given / Nick
