Masahito Omote
omote****@t-bas*****
2005年 8月 18日 (木) 09:45:48 JST
おもてです。 On Thu, 18 Aug 2005 04:51:02 +0900 TOKUNAGA Hiroyuki <tkng****@xem*****> wrote: > > その部分のコードは以下のようになっています。 > > lenやbufを使っていないのでRkGetKanjiを呼ぶ意味がないような気がするので > > すが、ここでRkGetKanjiを呼ばないといけない理由があるのでしょうか。 > > > > for (i = 0; i <= tmp_segment_num; i++) { > > int len; > > RkGoTo(cc->rk_context_id, i); > > len = RkGetKanji(cc->rk_context_id, (unsigned char *)buf, BUFSIZE); > > #ifdef UIM_CANNA_DEBUG > > printf("segment: %d, buf: %s\n", i, buf); > > #endif > > } > > たしかにRkGetKanjiを呼ぶ必要は無さそう…というか、単にdebug目的で呼んでい > るように見えますね。しばらく使ってみた感じでは問題なさげなので、そんな感 > じでtrunkにコミットしちゃっていいんじゃないかと思います。 > > # なにか問題があったらrevertして下さい > 表さん コードを見直してみましたが、debug目的で各文節ごとに漢字をprintfで出力している だけみたいなのでforのところ全体を#ifdefで囲ってしまってOKです。 それと_update_statusをcallしているのは_update_segmentだけなのでこの2つの 関数を統合してしまってもいいかな。 ただ、Cannaでは変換が遅くなる現象は実装した当初から確認していないので、これで 症状が改善しないのであればimeproxyの実装にも問題があるのではないかと考えてい ます。 uim-cannaの実装をマトモにするのであればRk系APIを使うのではなくてjrKanjiControl とjrKanjiStringを使って実装しなおすべきです。ただし、その場合preedit層がuimから Canna側に移るのでcanna.scm, canna.cの大幅な書き換えが必要になりますが。 -- Masahito Omote(omote****@utyuu*****, omote****@sapme*****, omote****@debia*****)
