Anthyの辞書強化がうまくいっていない。原因らしきものについて
先日、Anthyの辞書を強化してみた。
しかし、どうも登録したはずの単語が変換で出てこない。
ちょっと調べてみたところ、以下の不審な点が見つかった。
「/etc/anthy/diclist」に「/usr/share/anthy/dic」ディレクトリに入れた辞書ファイルの名前を登録した。
この後、
update-anthy-dics
コマンドを実行すると、「/var/lib/anthy」ディレクトリにまとまった辞書ファイル「anthy.dic」や「anthy.wdic」ができあがる。
update-anthy-dicsコマンドを実行した過程で、「/etc/anthy/dict.args」ファイルが更新される。
ここにはdiclistに書かれた辞書ファイル名と読み込む際の文字コードが指定されているようだ。
しかし、このファイルを見たところ
set_input_encoding eucjp
read /usr/share/anthy/dic/gcanna.ctd
read /usr/share/anthy/dic/gcannaf.ctd
read /usr/share/anthy/dic/gtankan.ctd
read /usr/share/anthy/dic/adjust.t
read /usr/share/anthy/dic/compound.t
read /usr/share/anthy/dic/extra.t
read /usr/share/anthy/dic/2ch.t
(中略)
set_input_encoding utf8
read /usr/share/anthy/dic/g_fname.t
build_reverse_dict
read_uc /usr/share/anthy/dic/udict
set_dict_encoding utf8
write anthy.wdic
done
となっていた。
Cannaの辞書ファイルである「.ctd」ファイルはEUC-JPで問題ないが、「.t」ファイルのほとんどはUTF-8のはずである。
なのにEUC-JPとして読み込まれているようなのだ。
これではうまくいくはずがない。
「/usr/share/anthy/dic」ディレクトリで以下のコマンド(シェルスクリプト)を実行してみた。
for f in `ls -1 .`; do echo $f : `nkf --guess $f`; done
追記
こんなことをしなくても
nkf --guess *
で良かった…。
追記終わり
すると
2ch.t : CP51932 (LF)
adjust.t : EUC-JP (LF)
anthy_userdic.t : UTF-8 (LF)
base.t : EUC-JP (LF)
bushu.t : UTF-8 (LF)
cc0jinmei.t : UTF-8 (LF)
cc0jisyo.t : UTF-8 (LF)
chimei.t : UTF-8 (LF)
compound.t : EUC-JP (LF)
extra.t : EUC-JP (LF)
(中略)
udict : EUC-JP (LF)
utf8.t : UTF-8 (LF)
x-conv2self-std.t : UTF-8 (LF)
zipcode.t : EUC-JP (LF)
となった。
Anthy用辞書である「.t」ファイルにもEUC-JPのものが結構あるようだ。
そして、意味不明なのが「2ch.t」である。
EUC-JPでもUTF-8でも、Shift-JISでもCP932でもなく、CP51932なのである。
eucJP-ms と CP51932 の違い コードページ932/ウェブリブログ
うっかりEUC（CP51932）とUTF-8化 - 十日日記(2009-04-02)
EUC-JPにWindowsの外字や機種依存文字が入った拡張された文字コードらしい。
これはもともと「/usr/share/anthy/dic」ディレクトリに入っていたはずだが、このままでAnthyは辞書として利用できるのだろうか？
今回は「.ctd」ファイルはそのままにして、「.t」ファイルをUTF-8に変換することにした。
「/usr/share/anthy」ディレクトリに「dic_utf8」という名前のディレクトリを作って、「/usr/share/anthy/dic」ディレクトリ以下で以下のシェルスクリプトを実行した。
for f in `ls -1 *.t`; do nkf -w $f > ../dic_utf8/`echo $f | sed 's/\.[^\.]*$//'`_utf8.t; done
「dic_utf8」ディレクトリ以下に
2ch_utf8.t
2ch_utf8_utf8.t
adjust_utf8.t
anthy_userdic_utf8.t
base_utf8.t
bushu_utf8.t
cc0jinmei_utf8.t
cc0jisyo_utf8.t
chimei_utf8.t
compound_utf8.t
extra_utf8.t
(中略)
utf8_utf8.t
x-conv2self-std_utf8.t
zipcode_utf8.t
ディレクトリを分けているのだから別にファイル名を変える必要はなかったことに気づいた・・・。
また、元々UTF-8であるファイルは変換しても同じで意味のない変換だ。
元の「dic」ディレクトリを名前を変更して、バックアップしておく。
そしてその元のディレクトリから「.ctd」ファイルと「dic_utf8」ディレクトリにコピーする。
「dic_utf8」ディレクトリを「dic」ファイルにリネーム。
「/etc/anthy/diclist」を名前を変えてバックアップ。
ls -1 > /etc/anthy/diclist
でファイル名一覧を「etc/anthy/diclist」に書き込む。
diclistに書き込まれると困るので上を実行したあとに、元のディレクトリから「udict」ファイルを「dic」ディレクトリにコピーする。
全部、先にコピーして
ls -1 |grep -v udict > /etc/anthy/diclist
でも大丈夫だと思う。
grep -v udict
でlsコマンドの出力からudictを除外している。
試しにこれで
update-anthy-dics
を実行してみる。
「/etc/anthy/dict.args」ファイルを見てみたがやっぱりおかしい。
どうも基本的にすべてのファイルをEUC-JPとして読み込んでいるようだ。
その上、変換されて存在しないはずの「g_fname.t」ファイルをUTF-8として読み込んでいる。
これだと逆にすべての「.t」ファイルをEUC-JPに変換した方がうまくいきそうだ。
XenialDogには「locate」コマンドは無かったが、「whereis」コマンドがあったので「update-anthy-dics」の場所を調べてみたら、「/usr/sbin」ディレクトリにあった。
以下のリンク先は同じシェルスクリプトだと思う。
どうやらいくつかのファイルはあらかじめ指定されているようだ。
「social-ime.ctd」とか「wikipedia.ctd」とか無いファイルが指定されている。
あったら欲しいところだ・・・。
これを書き換えて別のファイル名で保存して実行してみることにした。
変数「CANNADIC」に「/usr/share/anthy/dic」にある「.ctd」ファイルを書く。
「EXTRADIC」や「EXTRADIC_UTF8」はいらないので消す。
「addondics」と書かれている箇所とその下のfor文をutf-8で読み込む場所へ移動する。
「addondics」として読み込むファイル名一覧のうち、「.ctd」はすで読み込んだので、「.t」ファイルだけ読み込むように、「grep '.t'」を追加した。
ちょっと行がずれたところがあって、おかしなところはあるが差分はこんな感じになる。
--- /usr/sbin/update-anthy-dics 2015-03-15 20:37:34.000000000 +0900
+++ /root/apps/update-anthy-dics2 2017-09-28 22:26:13.332746412 +0900
@@ -2,9 +2,7 @@
set -e
-CANNADIC='gcanna.ctd gcannaf.ctd gtankan.ctd social-ime.ctd wikipedia.ctd'
-EXTRADIC='adjust.t compound.t extra.t'
-EXTRADIC_UTF8='g_fname.t'
+CANNADIC='g_fname.ctd gcanna.ctd gcannaf.ctd gkuten.ctd gt_okuri.ctd gtankan.ctd'
DICDIR=/var/lib/anthy
METADICDIR=/usr/share/anthy/dic
@@ -27,7 +25,7 @@
echo "set_input_encoding eucjp" >> $TMPDICTCONFIG
-for file in $CANNADIC $EXTRADIC
+for file in $CANNADIC
do
if [ -f $file ]; then
echo "read $METADICDIR/$file" >> $TMPDICTCONFIG
@@ -35,20 +33,14 @@
done
-addondics=$(sort -u $CONFIG| tr '\n' ' '| sed 's/\ $//')
+# start adding utf8 dict
+echo "set_input_encoding utf8" >> $TMPDICTCONFIG
+addondics=$(sort -u $CONFIG|grep '\.t'| tr '\n' ' '| sed 's/\ $//')
for file in $addondics; do
if [ -f $file ]; then
echo "read $METADICDIR/$file" >> $TMPDICTCONFIG
fi
done
-
-
-# start adding utf8 dict
-echo "set_input_encoding utf8" >> $TMPDICTCONFIG
-for utf_dict in $EXTRADIC_UTF8
-do
- echo "read $METADICDIR/$utf_dict" >> $TMPDICTCONFIG
-done
# end adding utf8 dict
echo "build_reverse_dict" >> $TMPDICTCONFIG
変更して作ったファイルは実行権をつける。
追記
「.ctd」ファイルはあらかじめ読み込むように「CANNADIC」に書いたので、「/etc/anthy/diclist」に「.t」ファイルだけ書き込むようにすれば、シェルスクリプトの中で「.t」ファイルだけを読み込むようにするコマンドはいらなかった。
ls -1 |grep -v udict |grep -v '\.ctd' > /etc/anthy/diclist
で良いかと思う。
追記終わり
これで実行してみた。
とりあえず、「/etc/anthy/dict.args」ファイルの内容は正しくなった。
再起動して、いくつか語句を入力してみたが、上手くいっている様だ。
「2ch.t」ファイルにある「きたー」の変換語句「キタ━━━━━━━━(゜∀゜)━━━━━━━━━！！」も出る。
幾つかの顔文字も「ヾ（＊´∀｀＊）ノ」「（＊°∀°）＝３」などという形で追加された。
国会議員の菅直人氏を揶揄した「姦直人」や「韓直人」も出て来てちょっと汚い言葉もおぼえてしまったのが気になる。
若干、余計な学習がされていて変換がおかしくなっている気もする・・・。
しばらく、これで様子を見てみよう。
それにしても、検索した範囲ではこの問題を指摘したものがないようだ。
通常の方法では、「.ctd」ファイルと一部の 「.t」ファイルだけが有効になっているはずだ。
Cannadic改の一部程度の強化でみんな「Anthyの変換精度が上がった」と思っていることになる。
これってバグとか改善点として、修正されるべきものでは無いかな？
「.t」ファイルをすべてEUC-JPにすれば問題ないということなのだろうが…。
ただし、「.ctd」ファイルが2回読み込まれる問題は残る。
「.ctd」ファイルは「/etc/anthy/diclist」には書かないというのが正しい指定方法なのだろう。
ノートパソコンのバッテリーを買った。
使っている中古のノートパソコン。
速度面など性能的には不満は無いのだが、バッテリーの駆動時間が少ないのがちょっと気になっていた。
バッテリーの容量が少ないというのは、中古ノートパソコンの宿命みたいなものである。
3時間程度は持つので中古品としてはかなりマシな方だが。
ケースを再利用したり、安いものを作ったりして、中身のリチウム電池を新しくしたバッテリーが安く手に入る。
プリンタのインクに純正のものと、別のメーカーが作った安いものがあるのと同じだと考えるとわかりやすいと思う。
Yahoo! ショッピングで、ノートパソコンの型番でバッテリーを検索したところ、以下の商品が見つかった。
商品ページにある「代替モデル」というところを見る。
そして、自分の持っているノートPCのバッテリーを外して、バッテリーの型番を確認する。
私の持っているノートパソコンで使われているバッテリーは「L12L4A02」だった。
確かにこの商品は、自分の持っているパソコンで使えるようだ。
Amazonでも同様の商品が買える。
これからヤマト運輸との契約によっては変わる可能性があるが、現在のところ、Amazonは2000円以上の商品は送料無料なので、商品によってはAmazonの方が安く買える場合がある。
今回は、Yahoo!ショッピングでクーポンがもらえたこともあり、Yahoo!ショッピングの方で注文した。
ただし、値段だけで判断してはいけないところもある。
バッテリーの容量が商品によって異なっている場合がある。
今回、買ったバッテリーは「2200mAh」のものだ。
しかし、Amazonで見ると同じ系統のバッテリーで「2600mAh」や「2800mAh」のものがある。
この値が大きい方がバッテリー駆動で使える時間が長いことになる。
買った新しいバッテリーはUbuntuのバッテリー管理アプリの情報によると、フル充電で4時間39分ほど使えるとのことだ(実際にはフル充電からいくらかバッテリーが減らないと残りの使用時間が表示されない)。
4時間39分は、4.65時間なので
2200 / 4.65 = 約473[mA]
となる。
つまり、平均473mAの電流消費量になるということだろう。
この計算値を元にして、2800mAhのバッテリーを使った場合を考えると
2800 / 473 = 約5.92[h]
となり、5.92時間、バッテリーでノートパソコンを使えるということになる。
2800 / 2200 * 4.65 = 約5.92[h]
とも言える。
1.27倍バッテリー駆動時間が長いのである。
今回は、Yahoo!ショッピングで買ったので手頃な価格が2200mAhのものしかなかった。
Amazonの方で考えると、2200mAhの方が4590円で2800mAhの方が5500円なので価格の比は約1.20でバッテリー容量の比よりも小さいから、お得と考えることもできるだろう。
買ったバッテリーは、予想していたよりもバッテリー駆動時間が短かったのでちょっとがっかりした。
しかし、純正のバッテリーにある情報を見ると、そのバッテリーの容量も2200mAhだった。
もともと、そのくらいの駆動時間なのだろう。
それほどバッテリー駆動でPCは使わないし、今回買ったものと古いバッテリーの両方を使えば7時間程度は使えるので十分だと思う。
また、表示は現在のバッテリー残量と消費電力から算出された推定値であって、必ずその時間内にバッテリーが切れることを意味してはいない。
実際には、使用状況によって変動するし、バッテリー残量が減るとCPUの周波数がダウンするなど省電力機能が働くので駆動時間は長くなる。
表示されている残り時間よりももう少し長く使えると思う。
追記
この記事を書いた後、実際に試してみたら通常のWebブラウジング程度であれば5時間以上バッテリー駆動で動作できることがわかった。
追記終わり
買うなら、メーカー純正のバッテリーの方が安心感はあるだろう。
しかし、今回、買ったような代替バッテリーよりも、2倍以上高い。
メーカーから直接、購入する場合には、会員登録などが必要な場合もある。
また、生産、販売を終了したマシンの場合には、なかなか手に入らないこともあるだろう。
代替バッテリーは5000円以下で手に入る製品が多いのも魅力だ。
バッテリーさえ、新品のころと同じ駆動時間で使えれば、まだまだこのマシンは使えると考える人も少なくないだろう。
バッテリーが使えなくなってきたら新しいPCを買うのではなく、バッテリーだけ新調するという選択肢があるというのは良いことである。
今回は、Yahoo!ショッピングでクーポンが使えたので、安く購入できてお得な買い物だったと思う。
使用期限がせまっていて、なくなってしまうポイントやクーポンがあって、使い道に困っている場合に、ノートパソコンのバッテリーを新調するというのもありかも知れない。
日本語入力ソフト・日本語変換エンジンに関する色々。歴史とかオンラインIMEとか
MozcのビルドやAnthyの辞書強化などをしたことで、ちょっと日本語入力ソフトあるいは日本語変換エンジンに興味が出てきた。
https://www.ospn.jp/osc2016-kyoto/pdf/OSC2016_Kyoto_openmanyo.pdfwww.ospn.jp
www.slideshare.net
同じ著者、組織のものだと思う。
日本語入力ソフトの歴史とそれぞれのソフトのアルゴリズムについて説明されている。
Anthy以前：
●1987年：FreeWnn
●1990年：Canna
●2001年：Anthy今時のかな漢字変換
●2010年：Mozc
●2013年：libkkc
という感じでの変遷があるようだ。
実際にはSKKやPRIME、そしてもちろんMS IMEなどもあるのでもうちょっと複雑なのだろう。
FreeWnnは今でもAndroidの日本語入力アプリのベースに使われていたりする。
Wnnって「うんぬ」って読むんだ。
知らなかった。
Cannaはバージョン2とか3あたりの初期のPuppy Linux日本語版では標準の日本語変換エンジンだった。
その後はAnthyに置き換えられた。
また、有志の人がrootで使えるMozcのSFSファイルが提供されており、それを使っている人が多いと思う。
あくまでもこのスライドを作った人の主観な訳だが、Anthy以前と以後で別れている。
Anthyは京大マイコンクラブで開発され、IPAの平成13年度未踏ソフトウェア創造事業として採択されている。
今では主要な開発者は身を引いており、ほぼ開発終了となっているようだが、Debianがメンテナンスを引き継いでいるのだそうだ。
Teams/DebianAnthy - Debian Wiki
DebianベースのUbuntuで現在でも、ibusやuim、fcitxでAnthyが使えるパッケージが提供されているのはそのためなのかも知れない。
Mozcが使えないという事態が起こったとき、セカンドチョイスとして考えるのはやはりAnthyだと思う。
Cannaよりも変換精度が良くて、使いやすいということで選ばれてきたのだろうと思う。
また、初期に提供されたMozcは、Windows向けに提供されていたGoogle日本語入力に比べて、辞書が貧相だったのか変換精度が悪かった。
今ではその辺の問題もほとんど気にならなくなったが、それ以前はAnthyを選ぶ人も少なくなかったと思う。
さらに使いやすくすることを目的にModified Anthy (anthy-ut)というものも作られていた。
Anthyはほぼ開発終了なので、今でもModified Anthy (anthy-ut)やG-HAL氏のパッチを当てたAnthyというものは、元のAnthyよりも優れているのだと思う。
この前、Anthyの辞書を強化して随分と使いやすくなったが、このModified Anthyをちょっと使ってみたい気もする。
憩いの場のPPAリポジトリにあるのはUbunt 13.04で、しかも32bit版のパッケージのものしかない。
使おうと思ったら、自分でパッチを当ててビルドする必要がある。
Anthyがおバカになる理由は入力語句を学習したファイルについて、後に入力された語句によって前の学習が削除されることにあるとの考えがある。
後の語句の解釈と学習が有効なら、より精度が上がるのだろうが、逆だった場合に前の学習結果が消えてしまうことで精度が下がるということのようだ。
そのため、Modified Anthyでは学習ファイルのサイズを大きくするとか学習時の文章の解釈の変更などの改良がされているようだ。
同じ考えで、通常のAnthyでも以下のような対応作があるらしい。
これは学習語句を記録しているファイルについて追記はできるが削除はできなくするという方法らしい。
日本語入力cannaを現代に蘇らせる アホな評判もなんのその - Linux
この人のように辞書さえしっかりしたものを用意すれば、Cannaの方が良いという人もいる。
Cannaは16.04でもパッケージは提供されているようで、使おうと思えば使えるのかもしれない。
Puppy LinuxではCannaなのかkinput2かscimの関係なのか、アプリの入力欄で方向キーなどいくつかのキーを押した場合に動作がおかしくなるということがあった。
変換精度以外のところで不具合があるようだとちょっと普段使うのは躊躇してしまう。
ここにも変換エンジンの歴史が書かれているので勉強になる。
MozcはAnthyとPRIMEの開発者が作ったものだというのはとても興味深い。
SocialIME(2016年にサービスを終了したそうだが)などネットワークごしに利用する日本語入力ソフトもある。
特にブラウザ上で使えるオンラインIMEは、海外のパソコンなど、日本語入力が使えないOS、マシン環境などで日本語で文章を入力する時にはこれを使うのが便利だ。
入力した文字や文章がネットワークを通じて外部のサーバへ送信されてしまうので注意が必要だ。
有名なものとしてAjax IMEというものがあった。
あったのだが、今調べてみたら本家のAjax IMEは「Internal Server Error」で使えなくなっていた…。
そして、なんとJavascriptを使ってローカルで日本語変換ができるタイプのAjax IMEが作られていた。
Ajax IME: Web-based Japanese Input Method
文章を変換して変換がおかしくても方向キーでおかしい部分に戻ったり文節を区切り直したりすることができないようだし、長音を表す「ー」を入力するとスペースで変換してくれないなど、決して便利とは言えないが、短い文節ごとに変換するなら十分に使える。
ブラウザ上でローカルでもこれだけのことができるようになっているのだなと感心した。
もう一つ、ブラウザで使えるもの、あるいはネットワークごしに入力データを送信することで使える日本語入力で有名なのはGoogle Japanese Inputである。
Try Google Input Tools online – Google Input Tools
こちらは文節ごとに変換候補が出て、方向キーで文節を移動でき、かなり使いやすい。
Mozc,Google日本語入力と同じ技術が使われているのだろうから、変換精度も高い。
絵文字などの特殊記号が使えるところも魅力だ。
この機能を使うAPIが公開されており、それを利用したソフトウェアもたくさんある。
SKKの辞書として使うことで変換精度を大幅に向上させているものもあるようだ。
この他、Baidu IMEもオンライン版がある。
オンライン IME | Baidu IME - 日本語入力システム -
「オンライン IME を起動」というボタンを押すとWebページ内にローカルアプリと同じようにIMEのツールバーが表示されるのがおもしろい。
顔文字が入力できたり、「記者が汽車で帰社した」が一発で変換できるところも注目すべき点だ。
ローカルアプリにも関わらず、パスワードやクレジットカード情報などを含む入力データの不正送信事件を起こしたBaiduのものなのでちょっと怖い気もする。
直接関係ないが、Android端末の黎明期にいち早く登場し、とても使いやすかったSimejiがBaiduに買収され、入力データの不正送信事件を起こしたのは残念だった。
直接、使えるデモページは無いが、Yahoo!Japanの変換ソフトもAPIが公開されている。
テキスト解析:かな漢字変換 - Yahoo!デベロッパーネットワーク
それを利用していると思われるWebサービスの一つがこれ
これもかなり変換精度が高い。
冒頭のスライドなどでも指摘されているように、現在ではMozcあるいはGoogle日本語入力一択といった状況にあるように思う。
確かにWindowsでもLinuxでもAndroidでも使える上、変換精度もとても高い。
これさえあれば何もいらないという感じだ。
ただちょっとさびしい気もする。
改めてMozc以外の日本語入力ソフトを利用するとメモリ消費量の少なさや入力の手軽さのような使い心地の違いがある。
uimやscim、fcitxといった入力メソッドとの相性、入力対象のアプリとの相性もあって、スポット入力がちょっとおかしいなどそれぞれの変換エンジンでちょっとした不具合やクセもある。
変換エンジンそのものの不具合や能力の問題ではないのでそれで変換エンジンの良し悪しを評価するのはちょっとフェアでは無い気もするが、使用する際の使いやすさの問題は小さくない。
日本語入力ソフトにはそれぞれ特徴があって使っていておもしろいというのもある。
SKKなどは代表的なものだろう。
漢字とひらがなの切れ目を自分で指定するのは独特で、変換ソフトがひらがなの羅列から漢字にすべき語句とそうでない語句、送り仮名などを判断する必要がなくなるので、構造がシンプルで動作も軽いソフトになっている。
私も一時期、使っていた。
http://ray-mizuki.la.coocan.jp/software/skk_jp.htmlray-mizuki.la.coocan.jp
バージョン2.3あたりまでを対象にしているので今でも使えるかどうか分からない。
バージョン2.3のころにはあまり良い日本語入力ソフトは無かった。
しばらくしてGoogle日本語入力もでてきたが、古い端末には重すぎた。
メモリが足りなくて、入力先のアプリが落ちたり、入力にものすごく時間がかかったりした。
特に今、使っているアプリがGoogle日本語入力が起動したがために落ちるというのは、まったく本末転倒だった。
もともと古い端末で使えるものではなかったのに文句を言うのもおかしいが。
SKK for Androidは軽くてちゃんと使えば変換も適切で使いやすかったのだ。
AndroidでもGoogle日本語入力が多く利用されていると思うが、スマホに最初から搭載されているものを使っている人もいるし、メモリ消費量や処理速度の関係で軽さを求める人もいる。
そのこともあってか、PCとは違って結構、色々な日本語入力アプリがある。
もっとも、変換精度向上よりも入力方法に工夫をこらしているものが多い印象だが。
ベースがWnnのものが少なくないのも興味深い。
色々、試してみると結構、楽しい。
PCもそういう選択肢があると良いと思う。
Mozcを使っていて思うのは、MozcやGoogle日本語入力が一般的になってから、入力スタイルが変わったように感じることだ。
サジェスト機能、ATOKでは推測変換とか省入力機能というらしいが、数文字入力した段階で辞書や過去の入力データから可能性の高そうな単語や短い文章が出てくる機能がある。
これがあることで、入力時間が短縮され、サジェストされる範囲の短い単語や文節をすいすい入力していくスタイルになった。
以前の、長々とひらがなのまま文章を書いて、スペースキーや変換キーを押して文章全体を変換させて、変換時間が遅いことにイライラし、誤変換や文節の区切りのおかしさに腹を立てながら、修正していくという入力スタイルは一体何だったのだろう。
サジェストするにも文章の解析やMozcの場合は検索ワードの分析が必要だろうが、サジェスト機能が搭載、充実していれば、連文節の変換精度の高さなどはあまり問題にならないかも知れないと思う。
AnthyやCannaにもそういう機能があれば、Mozcにこだわらなくても良くなるかもしれない。
Google日本語入力は検索ワードからいろいろ学習しているのでたまにとんでもない変換候補がサジェストされるようだが・・・。
Google日本語入力の一生使わないような予測変換が不意打ち過ぎる - Togetterまとめ
全く新しい日本語入力ソフトがないかというとそうでもない。
2013年、新しい日本語変換エンジンとしてlibkkcとそれを利用した入力ソフトが出てきたそうだ。
Ubuntuではibus-kkcとしてしかパッケージが提供されていないようだが、fcitxで使えるならちょっと試してみたい。
最近はAIで変換精度の向上をはかる試みもあるらしい。
また、WnnやAnthyを生み出した京都から新しい日本語変換ソフトも登場している。
www.slideshare.net
Releases · hashimom/Genji · GitHub
こういうものを使った使いやすい日本語入力ソフトが出てくると、もしかしたらMozc一強の勢力図は変わるかも知れない。
こんな感じで、ちょっと色々調べてみた。
日本語入力ソフトの歴史はとても興味深かった。
やっぱりMozcが出てきたことでそれを使う人が圧倒的に多くなって、そちらで不満もないものだから、その他の日本語入力ソフトに対する需要が少なく、多くのものの開発が止まってしまっているものが多いのは残念だ。
しかし、少ないものの新しい日本語入力、日本語変換エンジンも出てきていて、期待ができそうということもわかった。
日本語入力ソフトと言っても奥が深いものなのだということがわかった。
2007年の製品で、さらに32bit向けしか提供されていない。
今でも根強い支持があり、何とか新しいバージョンのLinuxディストリビューションでも使いつづけようとしている人たちがいる。
よほど使いやすいんだろうなと思う。
