tomoemonさんによる「打鍵のtomo2」プラグイン関連コメント。
(言及: http://d.hatena.ne.jp/tomoemon/20080216#p1 )
http://d.hatena.ne.jp/maple_magician/20080215/1203005634
の件を含めて、tomoemonさんからお返事を頂きました。ありがとうございます！
#……というか、15日のソレは「コメントとしてまとめて投稿できる状態にならなかったので、とりあえず手元に書いていたメモ」でした。
まずは、順序が逆になりますけれども「フィルタリングの問題点について」。
「手入力部分とエミュレータが吐いた部分」の切り分けについて、何も手がかりがないものだと思い込んで書いていました……が、tomoemonさんの記事にあるように「ほぼ同時かどうか、でおおむねは判別できる」という手がかりがあるとなれば、ほとんど心配する必要はなさそうですね。
無理やり怪しそうなパターンを探すとなると……「打鍵効率があまりよくなく(＝打鍵速度が速くなりがちで)、シフトをほとんど使わず、かつキーを1回押すごとにキー入れ替えソフトがキーコードをひとつだけ吐く(＝単純な英字配列の入れ替え)」ような配列──たとえば非拡張Dvorakや、非拡張Colemakなど──を使って、利用者の利き手でアルペジオ打鍵をやられた場合は、(打鍵順序と配列入れ替えの内容次第では)切り分けが難しくなるかもしれません。
とはいえ、
- キーを押した後に、キー入力入れ替えソフトがキーコードを吐く(逆はありえない)。
- キーを押してから、キー入力入れ替えソフトがキーコードを吐くまでの時間が安定しているはず。
- 最終目的が「後から読むためのログを記録すること」であり、即時には利用しない(→仮に表示するカウントが多少遅れたとしても、実使用上は問題ない)ので、全てのキーが離された後から(＝リアルタイムではなく、打鍵ストリームが途切れた時点で)打鍵内容を解析することも可能である。
ということが利用できると思われますので、現実的には問題なくいけそうですね。
つぎに、「ソフト入力のフィルタリング方法について」。
思いつく限りの入力法を当たってみて、それをtomoemonさんが書かれたルールで分離すると
- 「 > 」でつなげて定義できる配列(JISX4063ローマ字入力など)。
- 「 |> 」でつなげて定義できる配列(JISX6002かな入力など)。
- 「 > 」と「 | 」で同一定義を書けば定義できる配列(さくら配列など)。
- たとえば、【さ】を入力するための定義として「 J > F = x 」と「 J | F = x 」(それぞれ、さくら配列の場合)の2つを定義する。
- 「 > 」と「 |> 」で同一定義を書けば定義できる配列(JISX6004かな入力など)。
- たとえば、【ら】を入力するための定義として「 shift > D = o 」と「 shift |> D = o 」(それぞれ、JISX6004の場合)の2つを定義する。
- 「 | 」でつなげて定義できる配列(飛鳥カナ配列・龍配列・NICOLA(小梅含む)・姫踊子草入力法・下駄配列など)。
- 連続的にシフトさせるか否か……という点では切り分けせずに、全て分析ロジックで差異を吸収する。
- どのキーをシフトキーとして使うか……という点については、問題なく「 | 」でつなげて定義できる。
- 「 | 」を複数連ねれば定義できる配列(速記系入力法一般)
- 「 | 」か「 |> 」でつなげた定義を巻き込んで「 > 」でつなげれば定義できる配列(蒼星、M式など)
- たとえば、【ちょう】を入力するための定義として「 shift |> K > shift |> W = a)4 」(蒼星の場合)を定義する。
……というふうに表現可能かと思います。
「 | 」「 |> 」「 > 」の使い方がtomoemonさんの提示とは若干異なってしまいましたが、これは「同時打鍵系と呼ばれる配列は、ほとんどが姫踊子草入力法のように打鍵順序を問わない入力法である(シフトが連続的に効くかどうか・どのキーをシフトキーとして使うかという差異があるのみ)」ということに由来しています。
「 | 」「 |> 」「 > 」のそれぞれ単独使用だけでは、全ての入力法を表現するのは難しいと思います……けれども、構成要素はまさに「 | 」「 |> 」「 > 」でピタリとあっていて、あとは「組み合わせが必要か、あるいは単独で使うか」という違いになりそうです。
#……って、もしかすると記号の使い方(というか解釈)を間違っているかもしれません^^;。
以下に、上記分類を書く元となったメモを貼っておきます……役に立つかどうかは不明ですけれどもorz。
JISかな(JIS X 6002 )
- 既に想定されているとおり、「 |> 」でつなげて書く方法。
さくら配列( http://fiercewinds.net/siki/pub/2006/07/08_230925/ )
- 基本部分は全て同時打鍵ではない( > でつなげて書けばよい)ものの、「押しっぱなしシフト」というルールがある( | でつなげて書けばよい)。
新JISかな(JIS X 6004、 http://jisx6004.client.jp/jisx6004.html )
- 基本部分はJISかなと同じシフト方法( |> でつなげて書けばよい)ものの、小指シフトキーの単独打鍵後に文字キーを打鍵するとシフト側の文字が出る( > でつなげて書けばよい)。
飛鳥配列と龍配列( http://aumtyper.hp.infoseek.co.jp/ryuu2.html )
- シフトキーを単独打鍵するとそのキーのコード(親指シフト系であれば無変換・スペース・変換が主に、まれにAlt・ひらがななど。中指シフト系であれば該当文字キー)が出る。シフトキーと他の文字キーを同時に押すと、シフトキーが押されている間に押された文字キーは全てシフトで修飾される( | でつなげて書けばよい)。
- キーコードでは同時打鍵(シフトのキーがUpする前に文字キーがDownする)となっていても、同時打鍵判定ロジックの影響で「それぞれのキーの単独打鍵」として処理される場合がある。「姫踊子草」「繭姫」「やまぶき」はそれぞれ指定可能なパラメータと挙動が異なっており、かつ「やまぶき」は動的にタイミングが変化するため、エミュレータの挙動を内部的にエミュレーションするのは手間が掛かりすぎ。「打鍵のtomo2」側で対応するなら、結局のところは「吐かれたキーコードから、キーボード由来のものとエミュレータ由来のものを推測して分離する」ほうが、汎用性がありそう。
親指シフト(NICOLA)と姫踊子草入力法と下駄配列( http://urawa.cool.ne.jp/kou-y/geta.html )
- シフトキーを単独打鍵するとそのキーのコード(親指シフト系であれば無変換・スペース・変換が主に、まれにAlt・ひらがななど。中指シフト系であれば該当文字キー)が出る。シフトキーと他の文字キーを同時に押すと、シフトキーが押されている間に押された文字キーのうち、いずれか1組のみがシフトで修飾される。
- 飛鳥配列と龍配列では「文字キーDown→親指キーDown→他の文字キーDown」の場合に両方の文字キーがシフト修飾される可能性があるが、NICOLAと下駄配列では必ずどちらか一方の文字キーみがシフト修飾される。
- これも、「打鍵のtomo2」側からみれば、飛鳥配列と龍配列で起きる問題と同種なので、これもまとめてキーコードから推測するほうが汎用性がありそう。
速記系入力法( たとえば http://d.hatena.ne.jp/stenoyaro/ )
- 順不同で多数のキーを押下していき、キーをすべて離した時点で「それまでに押されたキーの組み合わせ」で定義された文字列を出す( | を複数使って書くことになる……のだろうか)。
蒼星( http://onpumoe.hp.infoseek.co.jp/keyboard/sousei.html )とM式( http://121ware.com/apinfo1/content/mworld/ )
- 同時打鍵動作( | でつなげて書けばよい)または普通の小指シフト動作( |> でつなげて書けばよい)を含む文字キーの打鍵か、あるいは単独文字キー打鍵の手順を、一回または複数繰り返して( | か |> でくくった定義を含む定義を、> でつなげて書くことになる……のだろうか)定義された文字列を出す。
