2010年04月25日

全角/半角の違いを誰が吸収すべきか問題【追記】4/27,5/4

昨日の続き(元々はこっちからつなげる積もりだったんですが、どっちでもいいや)。

昨日の話は郵便番号辞書の話でしたが、これは別に郵便番号辞書に限った話ではなく、いわゆる全角/半角の種別のある文字を変換する場合すべてについて言える。

簡単にまとめると、要するに、

・英数記号にはいわゆる全角/半角の 2種類がある(他に「ヴ」と「う゛」というパターンもある)
・全角を好むユーザもいれば、半角を好むユーザもいる
・なので、IME は両方に対応できなければならない
・この差異を誰が吸収すべきか(フロントエンド? 変換エンジン? 変換辞書?)

という問題です。

本音をぶっちゃけると、現状はこの差異を辞書が吸収してるんですが、リソースの無駄だと思うので、フロントエンドか変換エンジン側でやってくれたらなぁ、というお話です。

※uim-anthy はちょっと事情が異なるので、scim-anthy と ibus-anthy を主に念頭に置いて書きます

現在の動作は、

・数字や記号で全角を使うか半角を使うかユーザが選べる
・フロントエンドはユーザが選択した文字種(全角/半角)で preedit に表示
・フロントエンドはユーザが選択した文字種(全角/半角)をそのまま anthy に投げる
・anthy も、フロントエンドから送られてきた文字種そのままで辞書を検索する(除く、/usr/share/anthy/zipcode.t)

という感じだと思います。

ユーザが設定した文字種そのままで辞書検索されるので、例えば辞書に「ちゅう2 #T35 中2 中2 中二」("2" は半角)というエントリがあっても、ユーザが全角数字を使う設定にしていると、「ちゅう」("2" は全角)になるので、読みがマッチせず、「中2」等が一発では変換できない。

仕方ないので、辞書に「ちゅう #T35 中2 中2 中二」("2" は全角)というエントリも加えて、「ちゅう」("2"は全角)からでも変換できるようにしている。

「う゛」と「ヴ」も同様。
「う゛ぃーなす #T35 ヴィーナス」「ヴぃーなす #T35 ヴィーナス」の両方を辞書に登録しておくことで、「う゛ぃーなす」からでも「ヴぃーなす」からでも「ヴィーナス」に変換できるようにしてある。

でも、正直、こんなのひどいムダだと思うわけです。
ユーザが使うのは全角/半角(「う゛」/「ヴ」)のどっちか一方のエントリだけなのに、使われない他方のエントリのために辞書が肥大化してるわけなので。

今まではそれでも、こういう無駄エントリの総数がそれほど多くなかったのでまだ良かったんですが、郵便番号辞書を ~/.anthy/imported_words_* で使うとなると、この辞書は読みが半角のエントリだけで 12万(候補の方の全角半角を考慮するとその倍)、読みが全角のを合わせるとその倍、24万以上になるわけで、さすがにこれはちょっと…と思います。
【追記】4/27
郵便番号辞書は /usr/share/anthy/ に置けば anthy が全角半角の差異を吸収してくれるので、その限りでは問題にならない。

ユーザが「記号や数字を全角で」と設定していても、フロントエンドか変換エンジンが内部で半角に変換して、辞書検索は常に半角文字で行われるようにしてくれれば、辞書側には「読みに全角英数記号の入ったエントリ」は不要になるので、辞書サイズはその分小さくなる。

(尤も、メンテの手間は実は変わらない。というのも、今でもメンテ用辞書には一方しか登録していないので。リリース用辞書を生成するところで、機械的に他方のエントリを生成してる。)

読みのインデックスサイズが小さくなるので、検索もその分速くなる。その代わり、一方から他方に変換する処理とそれを戻す処理が入るので、その分遅くなる。
どっちの影響が大きいかは分かりませんが、少なくとも今より遅くなることはないのではないかと予想。

【追記】4/27
(続き)

厄介なのは、単に「『ユーザが記号や数字を全角で』と設定していても、辞書検索時は半角に変換して検索する」というだけでは不十分で、「全角に設定しているユーザには全角の候補を、半角に設定しているユーザには半角の候補を優先して出す」ということをしなければならない点。

たとえば、「数字を全角で」と設定しているユーザには「中2」(半角)よりも「中2」(全角)を先に出し、「数字を半角で」と設定しているユーザにはその逆、「中2」(全角)より「中2」(半角)を先に出す、という動作を、ということ。

これは「かな英字交じり文を一度に変換する方法のまとめ【追記】4/22」の後半に書いたことも同様ですが。

フロントエンドと変換エンジンのどっちがやるべきか、と言えば、「候補の並べ替え」ということが必要である以上、「変換エンジン」ということになるのかな、という気はします。
さらに言うと、フロントエンドは複数あるので、全部がそういう動作になってくれない限り、辞書は「どっちかの読みに統一する」ということができないが、変換エンジンなら現状 anthy のみなので、anthy さえ対応してくれれば、辞書はすぐに「どっちかの読みに統一する」ことができる、というのもあります。

とまあ、こんなことを考えてました。

ついでに言うと、フロントエンド、変換エンジン、変換辞書の各々の開発が別個に行われるのはいい面もありますが、連携しなければならないような話をできる場がない、というのは何とも…。
自分も他人を責められた義理ではないのですが…。

【追記】5/4
G-HAL 氏によれば
9100a〜9100h の、どこか途中から、 変換時に「ヴ」を「う゛」に変換してから辞書検索する様に変更になったので、 読み仮名「ヴ」の辞書登録は不要の模様です。
→ src-worddic/word_dic.c : anthy_get_seq_ent_from_xstr()
とのこと。情報ありがとうございます。

imported_words_default.d/ で簡単に確認したところ、確かに「う゛」の方だけ登録しておけば、フロントエンドが「ヴ」でも変換できました。

察するに、「ルイヴィトン」で落ちるのを修正したあたりからですかね。
何と言うか、まぁ……。

それから、
辞書のエントリを全部、 いわゆる全角、かつ「う゛」、かつ平仮名、に固定して、 重複削除してみましたが。
451776エントリ → 451301エントリ で、0.1%しか減りませんでした。
リソースの無駄とか処理速度とか、気にする程には影響は無さそうです。
について。

これは上にも「今まではそれでも、こういう無駄エントリの総数がそれほど多くなかったのでまだ良かったんですが」と書いた通り…って、ここも取り消し線引いちゃってた orz ← 戻した。

ええと、どう説明すれば…。
まず、現状では「動作に問題が出るほどの数はない」というのは認識しておりました。取り消し線引いてしまっていましたが…。

「郵便番号辞書を適宜更新しながら使うには、imported_words_* で使うしかない」と思い込んでいたので、「郵便番号辞書は 12万行くらいある。しかも、imported_words_* では全角半角の違いが吸収されないので両方の読みが必要だから…」ということで書いたわけですが、これも、/usr/share/anthy/zipcode.t を上書きしていけばいいと判明したので、問題なくなりました。

ただ、先に書いた英単語や頭字語の場合もありますし、「面句点コード辞書」(面句点コードを読みとして、対応する文字に変換する辞書)のような場合もあります。ついでなので言うと、「そうかく3」という読みで「川」とか「上」「下」みたいに 3画の漢字を出すような辞書を考えてたりもします(まだ作業中で、いつできるか分かりませんが)。

また、一般論としても、やはり「辞書で何とかする」よりは、「フロントエンドか変換エンジンで」と考えるのが順当かと思うのですが。

※今の状況では、こういうことを書くと、まるで G-HAL 氏に「やって下さい」と言ってるかのようになってしまうのが、自分としても何とも書きづらいところなのですが、「やる/やらない」「誰がやる」というのは抜きにして、一般論として聞いて頂ければと思います。
でないと、書きたいことが書けなくなってしまうので…。
posted by vagus at 01:07| 東京 ☀| Comment(0) | 日本語入力 - アプリ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。