上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
--.--.-- -- l スポンサー広告 l top
前回キー取得に関しての考察とか言いながら全然キー取得の話まで到達しなかったので
今回はそのキー取得方法の考察の話から

とはいえ現時点では
英字入力はQWERTY,Dvorak
日本語入力はローマ字,かな入力,DvorakJP,JLOD,NICOLA,skkime(の入力方法)
しか考慮してない(というかそれぐらいしか知らない)

まず通常のローマ字入力やQWERTY,Dvorakは前のキーにより次に打つキーに変更が加えられることはないのでそのまま実装可。またNICOLAもシフト、変換、無変換、スペースでそれぞれ独立したキーアサインが出力できれば問題なさそうだ。

作者さんが作ったDvorakJPファイルはカ行に関して文字が確定するまで文字を表示しないので、出力文字ではなく今後もキーストロークによる判断を続けたほうがよいと思われる。

標準かな入力は濁音時に一度表示した文字を消して濁音の文字を入れなおしているようだ。
ア段出力つきJLODおよび私が定義したカ行入力時にCまたはKが表示されるDvorakJPファイルも同様にいったん出力した文字を消して表示しなおしている

この場合「c」と打ったあとカーソルを動かして別の文字を修正しようとすると他の文字を消してしまうので注意しないといけない。同様にア段JLODもキーアサインに後退が多数使われているので注意が必要
だがバックスペースで戻る場合は、作者さんがストロークを破棄するように暫定設定してくれているので現在起きないようになっている。だが「←」キーで戻った場合は破棄されないので注意

またバックスペースまたは「←」キーが押された回数だけスタックされたストロークを破棄する方法も考えられるが、平仮名に変換された部分はストローク回数と文字間の移動回数に狂いが生じるため、
(A)現在の入力位置からすでに平仮名に変換された部分を間に挟むときは追加変換を諦める
(例・「kじにへんkします|」(それぞれkに二重母音を足して変換しますにしたいが、素直にkを消して「かん」と打ち直す))
(B)設定ファイルの各マップキーの横に出力文字数も併記させて、平仮名確定時に平仮名文字数だけ保存
この場合漢字に変換されるまでは、現在入力位置から何文字目にkがあるか(上記の例の場合3文字)という情報のみを保持。
上の例だと(k・4文字・k・3文字)といった形で内部に保存
バックスペースや←キーで戻った時にこれらをカウントして適切なキーアサインを行う
ただしマウスによるカーソル移動が行われたときに適切な回数のストロークを破棄する方法がない。

この問題に「TSFを使うとしたらこことかここら辺の話になるのかな?
この場合カーソル位置が動くたびにのカーソルの直前○文字を取得とかできたら、
逆決定木(*後述)を使用して即効でキーアサインを確定可能。
そもそもストロークの記録も必要なく上記の問題もすぐ解決っぽいけどね
(そもそもそんなAPIが用意されているのかどうか分からないけど)

次にキーストロークの取得や破棄の問題について。
前述で(A)を選択した場合は現在とさほど変わらず、文字入力ごとにマッチングを行いマッチングに該当指定キーがなければ破棄すればいい。
バックスペースや←→キーを打ったときは保存されているストローク自体を変更。(消したり、移動したり)
DvorakJPに関しては他にスペース、エンターキーが押された時は全てのキーストロークを破棄したいところだが
同時打鍵でスペースキーに機能を割り当てている人はストロークを破棄してほしくないと思うので
設定ファイルで「現時点でのキーストロークを全て破棄、○文字破棄、出力」といったストロークバッファの設定はできたほうがいいのかもしれない
(スペースやエンターキーだけではなく、普通のキーにもこの設定ができるように。すると、DvorakJP上では母音、準母音、数字、記号出力時にストローク破棄。他の設定では別のキーを押したときに破棄など柔軟な設定が可能。なお、設定ファイルは複雑化しそうなので効率的な設定ファイル記述方法を考える必要がある。また通常のキーでのストローク管理を諦めて、特殊キー(バックスペース、デリート、スペース、シフト、エンター、変換、無変換などのキー)でのみ管理できるようにする方法もあり。)

(B)のほうはスペース、エンターで全ストロークを破棄。
バックスペースや←→キーを打ったときは保存されているストローク自体を変更。(消したり、移動したり、ストロークを数字に変えたり)

整理するとAの実装方法、Bの実装方法がありいずれも利点と欠点はある
Aは実装が楽(ストロークバッファ直接の管理方法を除いて)だが2文字以上前の文字の追加修正はできない
Bは実装が大変だけどスペースやエンターで漢字変換や文字確定するまで文字の追加修正は可能
TSFでカーソルの前○文字の取得が可能であればかなりラクに前述の問題二つが一気に解決する

*逆決定木
設定ファイル内で
(ケース1)/* c */
-17[…
(ケース2)/* d, h, t */
-23, -24, -25[…
(ケース3)/* dn, hn, tn */
-18-26, -24-26, -25-26[…
(ケース4)/* cy, ch */
-17-14, -17-24[…
(ケース5)/* cc */
-17-17[…
とあった場合、今までは前からストロークの候補を絞っていった
(例・
最初入力(C)→(ケース1)
続き入力(H)→(ケース4)

そしてそうやってケースを決める決定木を決めていたと思う

しかしTSFを使用した場合は、カーソルから逆順に文字が入ってくるため、
(例・
最初入力(H)→(ケース4かケース2)
続き入力(C)→(ケース4)

という決定方法を採用しないといけない。これが逆決定木

カーソル前一文字比較→該当ケースを探索
カーソル前二文字比較→該当ケースを探索
カーソル前三文字比較→該当ケースなし
よってカーソル前2文字によるケースが確定
という方法もあるが、探索が非効率
2010.04.27 Tue l DvorakJ l コメント (1) トラックバック (0) l top

コメント

No title
どうもありがとうございます。
 たしか、ATOK が TSF に対応していません。TSF で操作できればいろいろな処理がはかどる、とは思っているのですが……
 やはり、データ構造をきちんと考えて探索をする必要がありそうですね。
2010.04.28 Wed l blechmusik. URL l 編集

コメントの投稿












トラックバック

トラックバック URL
http://omine3.blog119.fc2.com/tb.php/103-6f8e6096
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。