Google 日本語入力のカナロックと入力モードの関係
Google 日本語入力 0.12.434.0 では、入力方式がローマ字入力であろうがかな入力であろうが、カナロック状態と入力モードの状態で次のような入力がされるようです。
カナロック | |||
---|---|---|---|
OFF | ON | ||
入 力 モ ー ド | 直接入力 | 半角英数 | 半角カタカナ |
半角英数 | 半角英数 | この状態に遷移させる事は出来ない(?) | |
半角カタカナ | ローマ字入力で半角カタカナ | かな入力で半角カタカナ | |
全角英数 | 全角英数 | この状態に遷移させる事は出来ない(?) | |
全角カタカナ | ローマ字入力で全角カタカナ | かな入力で全角カタカナ | |
ひらがな | ローマ字入力でひらがな | かな入力でひらがな |
入力方式のローマ字入力とかな入力の違いは?
入力方式のローマ字入力とかな入力の違いは、入力モードが変更された時のカナロックの制御の違いだけのようです。
カナロックの制御
入力方式 | |||
---|---|---|---|
ローマ字入力 | かな入力 | ||
入 力 モ ー ド | 直接入力 | カナロックOFF | カナロックOFF |
半角英数 | カナロックOFF | カナロックOFF | |
半角カタカナ | カナロックOFF | カナロックON | |
全角英数 | カナロックOFF | カナロックOFF | |
全角カタカナ | カナロックOFF | カナロックON | |
ひらがな | カナロックOFF | カナロックON |
Google 日本語入力 0.13.499.100 のカナロックの扱いを予想
Google 日本語入力 0.13.499.100 では、カナロックの扱いが変わるようです。
あくまでも私個人の予想ですが、カナロックを常時OFFの状態に制御して、入力方式がかな入力の時には、Google 日本語入力の内部でかな配列のテーブルを持つようにしてキーイベントをかな文字に変換するようになるのではないかと予想しています。
次のようになると予想
ローマ字入力
カナロック | |||
---|---|---|---|
OFF | ON | ||
入 力 モ ー ド | 直接入力 | 半角英数 | 半角カタカナ(?) |
半角英数 | 半角英数 | この状態に遷移させる事は出来ない | |
半角カタカナ | ローマ字入力で半角カタカナ | この状態に遷移させる事は出来ない | |
全角英数 | 全角英数 | この状態に遷移させる事は出来ない | |
全角カタカナ | ローマ字入力で全角カタカナ | この状態に遷移させる事は出来ない | |
ひらがな | ローマ字入力でひらがな | この状態に遷移させる事は出来ない |
かな字入力
カナロック | |||
---|---|---|---|
OFF | ON | ||
入 力 モ ー ド | 直接入力 | 半角英数 | 半角カタカナ(?) |
半角英数 | 半角英数 | この状態に遷移させる事は出来ない | |
半角カタカナ | かな字入力で半角カタカナ | この状態に遷移させる事は出来ない | |
全角英数 | 全角英数 | この状態に遷移させる事は出来ない | |
全角カタカナ | かな字入力で全角カタカナ | この状態に遷移させる事は出来ない | |
ひらがな | かな字入力でひらがな | この状態に遷移させる事は出来ない |
カナロックの制御
入力方式 | |||
---|---|---|---|
ローマ字入力 | かな入力 | ||
入 力 モ ー ド | 直接入力 | カナロック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 のかな入力では、入力モードに応じてカナロックを自動制御しているのですが、カナロックを直接操作すると、表示されている入力モードと実際に入力される文字の入力モードが食い違うという問題があります。
次の図の右側で赤枠で示したところが表示される入力モードと実際の入力モードが食い違っています。
ibus-anthy-1.2.0.20090917 の親指シフト対応の改善
ibus-anthy-1.2.0.20090917 で親指シフトを使うと、次のようなケースで同じ文字が2回入力されてしまうという不具合があったので、パッチを作ってみました。
- 'B'キーを押し下げる
- ';'キーを押し下げる
- '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 になって同じ問題が繰り替えされてしまいました。
技術的にカナロックを使用する事で解決する問題ですが、現実に使うとなるとカナロックの完璧な制御は難しく、かな入力の使い勝手を著しく低下させてしまう事になります。
そこで次のようにする事を提案します。
- xkeyboard-config の jp106 のキーマップで右シフトキーの隣の
のシフトキーを押さないときに入力される文字を backslash から underscore に変更。 - 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モジ セイカツ ガ デキマス。