azoo-key-skkserv

AzooKeyKanaKanjiConverterを変換に利用するskkservです。
AzooKeyKanaKanjiConverterから参照される、ニューラルかな漢字変換システム「Zenzai」で利用するモデルはzenz-v1を利用させていただいています。

zenz-v1はKeita Miwa (𝕏)さんによって開発され、CC-BY-SA 4.0で提供されています。

Linux環境向けのバイナリにはllama.cppのShared Objectを同梱させていただいております。
かつ RUNPATH を $ORIGIN にpatchさせていただいております。

受け取った読みをAzooKeyKanaKanjiConverterで漢字変換し、候補を辞書として返すskkservです。
これにより例えば:

• 配達業者 などそれぞれの熟語は辞書に入っているけれど、繋がったものは登録されていないケースでも候補を表示できます。
• 送り仮名が不明瞭であったりする際、送り仮名ごと入力しても候補が表示されます。
• SKKの流儀とは反しそうですが、Zenzaiの強力な変換力により、長文をそのまま変換することも可能です。
  • SKKの仕様上ユーザー辞書にそのまま登録されてしまうと思うので、その点はご注意ください。

macOS版はGUIアプリケーションを配布しています。(mtgtoさんありがとうございます！)
Releasesに .dmg ファイルが置いてあるので、そちらからインストールしてください。
CLI版も配布しているので、お好みでお使いください。(GUI版の方がmacOS App Sandboxが設定されているので、より安全です。)

macSKKから使用する場合にはIncoming CharsetにEUC-JP、macSKKの応答エンコーディングにUTF-8を指定してください。

Linux版はCLI版の配布のみです。
Releasesよりご自身のarchに対応したパッケージをダウンロードし、お好きなところに配置してください。
パッケージ内の azoo-key-skkserv が実行ファイルです。

こちらのLinux検証環境だと libgomp.so.1 が見つからないエラーが出ました。
もし見つからない場合は、以下のようなコマンドでインストールしてください。

apt install libgomp1

azoo-key-skkserv [--port <port-number>] [--incoming-charset <charset>] [--inference-limit <limit>] [--help] [--version]

EUC-JP範囲外の候補があるため --outgoing-charset オプションはなく、サーバーからは常にUTF-8で返します。

macOSであれば、ログイン項目にGUI版のアプリケーションを登録しておくのが楽です。
そうでなければ、以下のようなコマンドがログイン時に実行されるようにしてください。

nohup ~/opt/azoo-key-skkserv/azoo-key-skkserv --incoming-charset EUC-JP >&/dev/null &

skkservの標準に準拠しているつもりです。
入力の1文字目を opcode とし、それ以降を operand とした場合:

swift run azoo-key-skkserv

macSKKと結合して動作確認

動作未確認

macOS上で動作するDockerにて、netcatで動作確認

一応コンパイルできていそうなのですが、エミュレータだとうまく実行できていません。

まだまだ使いながら調整したりしてる段階なので、不具合や不安定なところがあるかと思います。
もし何かございましたら、Issueでご報告いただいたりPRを投げていただけると大変助かります🙇