飛鳥カナ配列・かえで****あすか・TRONかな配列・新JISかな配列(JIS X 6004)・JISかな配列(JIS X 6002)向けに使えそうなエミュレータに関する要求仕様。

(過去:「タイムシフト」にもKISSの原則を適用してみた。 - 雑記/えもじならべあそび)


 シフト系の基本的ロジックは↓で、いわゆる「新JIS論文方式」

 この元ネタは1983年にリリースされてる話だから……1983年以前のはもうすぐ全て特許が切れるし、1983年以降のは「こういう前例が四半世紀前に発表されてる」から大丈夫……と。一応確認は必要だと思うけど*1
 シフトロジックについては……英数モード&カナモードで共通、かつ親指シフトキー&小指シフトキーも共通で、つまり「全部同じシフトロジック」でオッケー。


 これで、次の追加機能を満たしてくれればだいたいはイケるとおもう。

  • 親指シフトキーの指定(左=無変換、右=変換、の固定仕様)を行う機能。
  • 左Shiftキーと左親指シフトの交換&右Shiftキーと右シフトキーの交換を行う機能。
  • Shiftキー押下状態・右親指シフト状態・左親指シフト状態・アンシフト状態の配列をそれぞれ定義する機能。
    • できれば「Shiftキー押下状態」「Shiftキー押下+文字キー押下による英数モードへの移行〜単独Shiftキー押下によるカナモードへの復帰」での英数入力挙動が、MS-IMEと等価であること。


 このロジックを使うときのメリットは2つ。

  • 「シフトキーを押す」タイミングと「文字キーを押す」タイミングがほぼ同時だった場合、従来は1/2の確率でシフトしていたものが、(打鍵間隔の半分程度のタイムシフトを行っていた場合に)事実上シフトミスせずに済むようになる。
  • 「シフトキーを離す」タイミングと「文字キーを押す」タイミングがほぼ同時だった場合、従来は1/2の確率でシフトしていたものが、(打鍵間隔の半分程度のタイムシフトを行っていた場合に)事実上シフトミスせずに済むようになる。

 このロジックを使うときのデメリットは2つ。

  • 入力速度が速すぎる(=10keys/sec程度以上となる)場合、ソフトウェアによる「タイムシフトのエミュレート精度」に起因するシフトミスが影響してくる。
  • 親指シフトキーは専用で用意しないといけない(ここで示した「かえで化した」ロジックを使う場合、シフトキーと単独操作キーを共用するタイプのロジックを作るのは非常に面倒)。


 個人的には「無変換」「変換」の2つのキーをシフトキーとして潰すことに不満はない*2ので、正直これで良いのではないかと思っていたり。
 ……ってゆーか、こういうソフトを作る力があればなぁ……と、毎回思いはするものの、私には腕がないために何も出来ず。むむむ……。

ちなみに。

 BTRON(超漢字を含む)の同時打鍵ロジックは「文字キーのリリース時に文字が確定する(キーDownではなくキーUpで文字の出る順序が決まる)」仕様らしく、今回の「タイムシフト」とは挙動が異なります。


 タイムシフトの一番いいところは「文字キーを押した時点で、どのシフトモードであっても例外なく、必ず文字を確定できる」というところ。
 親指シフト系でたまに言及されることがある「キーを押してから文字が出るまでの間の、ほんのわずかのズレが気に食わない」という話とは、原理的に無縁である……というところ(=親指シフト系だから遅れる、という説明が恒真というわけではない)がポイント。

*1:……と思っていたら、実際には「出願の日から20年」だった……すでに大丈夫、ということか。

*2:そうであっては困る!という方は、従来法の「リッチな」同時打鍵判定ロジックを採用するエミュレータを使用していただければいい話、ということで。