Etsushi Kato
ek.ka****@gmail*****
2006年 8月 12日 (土) 13:09:37 JST
On 8/11/06, YAMAMOTO Kengo / YamaKen <yamak****@bp*****> wrote: > Etsushi Kato wrote: > > あとヤマケンさんのコメントに関連してちょっと話が飛びますけど、 > > uim 自身の preedit 文字の属性って bridge 側からみると微妙だな > > と前から思ってました。見た目 (reverse とか underline) ではなく > > て意味づけ (converting とか selected とか) のほうがいいと思う > > のですけど。見た目は、ユーザ (bridge) がそれらの意味にたいして > > 変更できればいいので。 > > 気持ちはよくわかるんですが、私は今のところ現状維持派です。 > [Anthy-dev 418]あたりからずっと引きずってる問題ですが、「意味で > 規定」にも色々とレベルがありますね。 なるほど、そんな前に話があったのですね。 > 例えばSCIMではRGB形式でプリエディットへの直接色指定が可能ですが、 > これはツールキット側のテーマ変更等と連動しないので、周りと調和し > なかったり背景と同色になって文字が読めなくなったりしてしまうので > よろしくないです。足永さんも言ってましたが。 まあ、色指定に関しては uim-color で今でもできますよね。 テーマに関しては、前に gtk immodule で reverse されているプリエデ ィット文字の色付けをテーマに合わせるようなパッチを作って使っていた ことありますが、GTK_STATE_SELECTED とかの限られた色を使うことは可 能でした。ただ、表現の幅が少ないので、もう少し gtk+ 側に属性がないと効 果的ではないな、と思ってました。 > これに対して、'reversed'や'underlined'は「装飾」の意味を規定する > 一層上の抽象指定なので、ツールキット側で適切に解釈・描画されます。 > 現在のuimはこのレベルですね。これをさらにもう一層上の「テキスト > の論理的区分」レベルの意味で規定しようというのが加藤さんの案です > が、私は今のところあまりうまくいかないんじゃないかと思っています。 たしかに anthy の描画くらいだと今のままで問題ないです。 > 例えば、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) とかを ブリッジに渡した方がいいのではないかと思います。 > なので、落としどころとしては、'underline'や'reverse'に代わる「装 > 飾」レベルの抽象的な名前を追加するあたりじゃないでしょうか。例え > ば'emphasized'とか。ただ、それをするほどのメリットが得られるかど > うかは直感的な名前セットを考案できるかにかかっているので、それま > では現状維持の方がいいと思います。 どんなものを用意するかは難しいですね。 > それができたら、それぞれのタグをどう描画すべきかをブリッジ毎に > custom等で設定可能とする、あたりが目標になりますかね。今でも > uim-colorを通してある程度可能ですが、全ブリッジ共有設定だったり、 > 上述のSCIMの場合と同じくツールキット側の色設定と無関係だったりす > るので微妙ですね。 全ブリッジ共有とかテーマとかはそれほど問題ではないと思いますけど。 それよりも、属性の表現が少ないことが、uim-color の利用価値を下げて いるような気がします。 -- Etsushi Kato ek.ka****@gmail*****
