(メモ)MS-IMEでの利用を前提とした、親指シフト方式用キーコード送出法素案。

  • OSの「カナロック」は使用せず、キーボード側で独自に「キー→単字分ローマ字」変換を行う。
    • 出力するローマ字綴りは、JISX4063準拠とする。
    • 変換しているかどうかを示すために、キーボード側に「RConv」LED灯を追加する。
    • ランプが点灯している間は、文字キーコードに関しては50msec遅れで入力されたものとして処理する(新JISかなで却下された、シフトキー打鍵遅れの補正案に同じ)。
  • ひらがなキーを押した場合には、ひらがなキーコードを2回送出してからRConvモードをOnにする。
    • ひらがなモードからCapslockを押して、さらに全角半角キーを押した場合、ひらがなキー1回ではなく2回押さないとひらがなモードに復帰しないため。
  • 英数キーを押した場合には、ひらがなキーコードを送出してから英数キーコードを送出して、RConvモードをOffにする。
  • 全角半角キーを押した場合は、全角半角キーコードを送出してから、RConvモードをOffにする。
    • このトグルはキーボード側からモードを取得できないため、RConvモードをOnにするためにつかうべきではない。日常的には(ワープロ時代と同じく)ひらがなキーと英数キーで使い分けてもらう方向で。
  • GHキー2段下にはスペースを、FJキー2つ下にはそれぞれ指を模したアイコンがついたキー(内部利用専用のキーでキーコードは吐かない)を、DKキー2つ下には、それぞれ無変換・変換キーを配置する。
  • ロッキングシフトモードの概念がないPOSキーボードでは、ひらがなキー・英数キー・左右小指シフトキーを廃止する代わりに、左右小指シフトキーをそれぞれ2分割して「英大・英小」キーを配置する。この場合、RConv灯もRConvモードは不要で、シフトキーのタイミング制御はたぶん不可能。
  • ……POSキーボードで実際に作ってしまう方が早そうな気も^^;。

いつの間にやら、使い始めて一ヶ月……。

 さいきん段平さんから「最新版と290の差はどーなのよ?(注:意訳)」というコメントを頂いて、とりあえずの感想を記させていただいた……のですが、そうこうしているうちに「あしゅかはいれちゅ」の使用期間が一ヶ月に迫りつつある以上となっていることに気づきました。
 #というか、ここのところオフラインが忙しくて、なかなか思うように日記が進まなかったり。


 今使っているのは「あしゅかはいれちゅ改0訂0案8版」で、その後にひとつふたつの問題点が出てきました……が、結局はそのままの配列で使い続けています。
 かな系配列の場合は、結局のところ「(行段系配列よりは自由度があるとはいえ、)すべてにおいて理想の姿を追求することはできない」わけで、今のところの「あしゅかはいれちゅ」が目指すべき方向性においては、現行の改0訂0案8版かその近傍あたりが、最終的な答えになるのかなぁ……と感じています。


 この辺はオーディオとも通じるモノがあるのかもしれないですね。
 どこまで追求するか・どこまで気づくか・どこまで突き詰めるか……というあたりの感性や感度が人によって違う以上、最終的に到達する配列が差を生んでしまうのは、ある意味仕方がないのかもしれません。
 例えば昔、私は漢触こーどというモノを作りました。もしもわたしに努力とか記憶力とかいうモノがあるのならば、本当は「親指シフト方式+漢直」で運用したかったのですよ……実際に「飛鳥21c290+漢触こーど」の定義はしばらく実用環境に投入していたのですが、結局は漢直部分を覚えることができず、(飛鳥の新版を評価打鍵し始めた時点で)この環境をお蔵入りにしました。


 うーん……飛鳥の最新版は「動作経済の理屈に合う速さ」という視点では良いできだと思いますし、その方向性ではだいぶよい感触を得た……のですが、個人的には「ここにこのカナがなければダメだ!」という意図が強かった様に思う21c290と比べて、どちらかというと「ここにこのカナを置く方が速い!」という意図が強いように思う最新版は、使っていてどうにも【落ち着いて使えない・どうしても弄りたくなってしまう】気がしました*1
 いまでは実際に、配列はなるべく崩さず&方向性は大きく変えた「あしゅかはいれちゅ」などというモノを作ってしまった(そして使っている)のですが、何もせずにいると「あしゅかはいれちゅ」を一生使い続けてしまいそうで怖かったりします^^;。


 動作経済からみた速さ=快適さと、人間が感じる速さ=快適さの間に、どういうベクトルでどの程度の差があるのか……という点については未だに判然としない*2のですが、このあたりについてはのんびりと追いかけていきたいと思っています。

*1:この点は配列の善し悪しとは全く関係がない。その配列近傍に有用な配列が多くあるか否か(ピークが鋭いか緩いか)の問題。GA配列では異なるピークを探すために「わざと配列が崩れる要素」をつっこむらしいのだけれど、その理由はまさにこれなのかも。

*2:これが解ったら、それだけで一生食うに困らない気も。少なくとも、トヨタ式(大野方式時代を含む)には、こういう観点は存在していないと感じた。