Google 日本語入力のカナロックと入力モードの関係

Google 日本語入力 0.12.434.0 では、入力方式がローマ字入力であろうがかな入力であろうが、カナロック状態と入力モードの状態で次のような入力がされるようです。

カナロック
OFFON





直接入力半角英数半角カタカナ
半角英数半角英数この状態に遷移させる事は出来ない(?)
半角カタカナローマ字入力で半角カタカナかな入力で半角カタカナ
全角英数全角英数この状態に遷移させる事は出来ない(?)
全角カタカナローマ字入力で全角カタカナかな入力で全角カタカナ
ひらがなローマ字入力でひらがなかな入力でひらがな

入力方式のローマ字入力とかな入力の違いは?

入力方式のローマ字入力とかな入力の違いは、入力モードが変更された時のカナロックの制御の違いだけのようです。

カナロックの制御

入力方式
ローマ字入力かな入力





直接入力カナロックOFFカナロックOFF
半角英数カナロックOFFカナロックOFF
半角カタカナカナロックOFFカナロックON
全角英数カナロックOFFカナロックOFF
全角カタカナカナロックOFFカナロックON
ひらがなカナロックOFFカナロックON

Google 日本語入力 0.13.499.100 のカナロックの扱いを予想

Google 日本語入力 0.13.499.100 では、カナロックの扱いが変わるようです。

  • バージョン 0.13.481.100 で一時的に動作しなくなっていた、かな入力を再びサポートしました。また、このバージョンから、設定で「かな入力」を選択している場合は常にかな入力が、「ローマ字入力」が選択されている場合は常にローマ字入力が行われるようになります。この変更の影響で、カナロックキーを利用して一時的に入力方式を切り替えることはできなくなっています。また、親指シフト用の常駐ソフト等、キーボードのカナロック状態に応じて動作を切り替える一部のアプリケーションに影響が出る可能性があります。

あくまでも私個人の予想ですが、カナロックを常時OFFの状態に制御して、入力方式がかな入力の時には、Google 日本語入力の内部でかな配列のテーブルを持つようにしてキーイベントをかな文字に変換するようになるのではないかと予想しています。

次のようになると予想

ローマ字入力

カナロック
OFFON





直接入力半角英数半角カタカナ(?)
半角英数半角英数この状態に遷移させる事は出来ない
半角カタカナローマ字入力で半角カタカナこの状態に遷移させる事は出来ない
全角英数全角英数この状態に遷移させる事は出来ない
全角カタカナローマ字入力で全角カタカナこの状態に遷移させる事は出来ない
ひらがなローマ字入力でひらがなこの状態に遷移させる事は出来ない

かな字入力

カナロック
OFFON





直接入力半角英数半角カタカナ(?)
半角英数半角英数この状態に遷移させる事は出来ない
半角カタカナかな字入力で半角カタカナこの状態に遷移させる事は出来ない
全角英数全角英数この状態に遷移させる事は出来ない
全角カタカナかな字入力で全角カタカナこの状態に遷移させる事は出来ない
ひらがなかな字入力でひらがなこの状態に遷移させる事は出来ない

カナロックの制御

入力方式
ローマ字入力かな入力





直接入力カナロックOFFカナロックOFF
半角英数カナロックOFFカナロックOFF
半角カタカナカナロックOFFカナロックOFF
全角英数カナロックOFFカナロックOFF
全角カタカナカナロックOFFカナロックOFF
ひらがなカナロックOFFカナロックOFF

今までは、入力方式、入力モード、カナロックと3種類のモードの組み合わせで動作が変わっていてユーザーにとっては分かりにくいという問題がありました。特に言語バーをトレイに格納している場合はカナロックの状態を確認できないためお手上げ状態になってしまう事があったのではないかと思われます。
カナロックを廃止することで入力方式と入力モードの2種類のモードの組み合わせを考えるだけで良くなりローマ字入力の設定で使っているのに、いつのまにかカナロックがONになってローマ字入力ができなくなるというトラブルを防ぐ事が出来るでしょう。

カナロックを使わず Google 日本語入力内部でかな配列のテーブルを持つようになるのだとしたら、実はJISかな配列以外のかな配列対応への布石なのかもしれないと思っています。あくまでも個人的な予想に過ぎませんので、あまり期待しないように。

tagtypeのフリック入力拡張案

以前、 iPhone に tagtype を! という事を書いたのですが、iPhoneではフリック入力で日本語入力でき、これがなかなかの優れもののようで、iPhone で tagtype を使えるようにする意義は薄れてしまったかなと感じています。

しかし、iPad の日本語入力は、今のところQWERTY配列でのローマ字入力しかサポートされていないようなので、もっと簡単に使えるものが欲しいところ。50音配列のソフトキーボードはぜひ使えるようにしてもらいたい。


その上でタッチパネルの特性を活かした入力方式が使えるようにしてもらいたという事で提案してみる。

まずボタン(キー)は、四角形である必要はないのでは? という事で六角形のボタンにしてみる。
そしてtagtypeの入力方法をフリック入力に拡張してみる。


という発想から次のようなものを思いつきました。


初期状態:

  • 50音表の「あかたさな…」を表示


「あ」を押した状態:

  • 初期状態の「あ」のボタンに周りに「あいうえお」ボタンを表示。入力方法は2通り。
    • (1) ボタンから手を離さずに周りに表示された「あいうえお」のどれかのボタンに指を移動させて、そこで指を離すと文字が入力される。文字が入力されたら初期状態に戻る。
    • (2) ボタンから指を離しても、回りの「あいうえお」は表示されたままの状態にしおく。「あいうえお」のいずれかのボタンを押す事で文字が入力される。文字が入力されたら初期状態に戻る。文字入力したくない場合は、「閉」のボタンを押せば初期状態に戻る。


「ら」を押した状態:

フリック入力だと指が邪魔して何が表示されているのか確認しずらいという問題があるので、指をどけて確認できるようにして、初めての人でも安心して使えるように考えてみました。

かな入力の状態遷移改良案

現在、日本語入力でのかな入力をしている人の割合は、それほど多くないという事や過去の経緯から、かな入力環境の際に不可解な動作をしてしまうことがあります。

MS-IME のかな入力では、入力モードに応じてカナロックを自動制御しているのですが、カナロックを直接操作すると、表示されている入力モードと実際に入力される文字の入力モードが食い違うという問題があります。
次の図の右側で赤枠で示したところが表示される入力モードと実際の入力モードが食い違っています。

MS-IME かな入力の状態遷移 - Microsoft(R) IME (10.0.6001.0)

通常言語バーをタスクトレイに入れている場合、カナロックの状態を確認できないために、ユーザーとしては表示される入力モードと実際の入力モードが食い違ってしまうと何が起きているのか分からず、半角/全角キー(漢字キー)などでの入力モード切替でも右側のモードに留まってしまうために内部の動作を理解していないとお手上げになってしまいます。

そこでカナロックを切り替えたときにも表示される入力モードと実際の入力モードが一致するように次のような状態遷移の改良案を提案したいと思います。

MS-IME かな入力の状態遷移改良案

あとローマ字入力に設定している時にカナロックの操作が行われた場合は、カナロックを強制的にOFFにして、ローマ字入力でカナロックがONになる状態に遷移しないようにする。言語バーがタスクトレイに入っている場合にはカナロックの状態を確認できないため、意図せずにカナロックが操作された場合に混乱してしまう為です。

ibus-anthy-1.2.0.20090917 の親指シフト対応の改善

ibus-anthy-1.2.0.20090917 で親指シフトを使うと、次のようなケースで同じ文字が2回入力されてしまうという不具合があったので、パッチを作ってみました。

  1. 'B'キーを押し下げる
  2. ';'キーを押し下げる
  3. 'B',';'キーを離す

正常な場合は、「へん」という文字列が入力されるのですが、「へへん」と入力されてしまいます。

パッチ

--- engine/engine.py.orig       2009-11-28 00:43:39.246057223 +0900
+++ engine/engine.py    2009-11-28 00:46:43.395983810 +0900
@@ -1019,6 +1019,7 @@
         def on_timeout(keyval):
             if self._MM:
                 insert(thumb.table[self._MM][self._SS])
+                self._MM = 0
             else:
                 cmd_exec([0, RS(), LS()][self._SS])
             self._H = None
@@ -1094,6 +1095,7 @@
                 elif self._MM:
                     stop()
                     insert(thumb.table[self._MM][1 if keyval == RS() else 2])
+                    self._MM = 0
                 else:
                     self._SS = 1 if keyval == RS() else 2
                     start(T1())
@@ -1115,6 +1117,7 @@
                 if self._MM:
                     stop()
                     insert(thumb.table[self._MM][self._SS])
+                    self._MM = 0
                 elif self._SS:
                     stop()
                     cmd_exec([0, RS(), LS()][self._SS])

ibus-anthy をJISかな入力対応させる為の提案

Fedora 11 に標準搭載の ibus-anthy では、JISかな入力で「−」(長音)が正しいく入力できないという問題があります。これは、scim-anthy でも同じ問題があって対応された問題だったのですが、ibus-anthy になって同じ問題が繰り替えされてしまいました。


技術的にカナロックを使用する事で解決する問題ですが、現実に使うとなるとカナロックの完璧な制御は難しく、かな入力の使い勝手を著しく低下させてしまう事になります。


そこで次のようにする事を提案します。

  1. xkeyboard-config の jp106 のキーマップで右シフトキーの隣の のシフトキーを押さないときに入力される文字を backslash から underscore に変更。
  2. ibus-anhty の JISかな入力のキーマップを backslash で「ー」(長音)、underscore で「ろ」が入力されるように変更。


これをデフォルトの設定にしていただくだけで ibus や ibus-anthy のコードを修正する事なく対応可能です。


もともと、JIS配列キーボードのJIS規格 JIS X 6002 では、右シフトの隣のキーでシフトキーを押さずに入力される文字は定義されていません。106日本語キーボードの元になった IBM 5576-A01 というキーボードでは、backslash のキー刻印がされていたため、106/109日本語キーボードに引き継がれる事になりました。なので、右シフトの隣のキーでシフトキーを押さずに入力される文字が backslash の代わりに underscore であっても JIS規格外の独自拡張の部分を変更するので大きな問題ではないと考えます。


複雑な実装をしても、それにともなって新たな不具合が生じるリスクがあるので、シンプルは方法で実現できる事はシンプルな方法を採用するというのも一つの考え方だろうと思います。

漢字廃止で韓国に何が起きたか

ひらがなせいかつ への いざない という記事を読んで、「漢字廃止で韓国に何が起きたか」という本の事を思い出した。

漢字廃止は、同音異義語の問題を回避するための言い換えが必要で平易な表現になるなどのメリットがある一方、文化の継承という点ではマイナス面があるという指摘があります。


私は「ひらがなせいかつ」=「漢字廃止」とは思っていません。
ひらがなせいかつをすることで、日本語における漢字の持つ意味というのを捉えなおす事ができ、もしかしたら、無自覚に漢字を使っている人よりも、効果的に漢字を活用することができるようになるんじゃないかなとか、漢字に頼らないで平易な表現をする訓練になって、かな漢字混じり文を書くときであっても、わかりやすい文章を書けるようになるかもしれません。


いろいろな試みがなされて、日本語の表現の幅が広がる可能性を秘めていて面白いという風に考えています。


最後に、キーボードネタを、


JISカナ ニュウリョク ガ デキルト ANKモジ ヲ チョクセツ ニュウリョク スル コトガ デキル ノデ ANKモジ セイカツ ガ デキマス。