多言語入力プラットフォームSCIMについて ２００６年３月２３日 JUS関西勉強会 足永拓郎

本日の話題 自己紹介 背景 SCIM概観 日本語IMEngineの現状 デモ SCIMの構造 SCIMの今後 まとめ

自己紹介 元機械屋 現オープンソースプログラマ 作っている物 / 関わっている物 自称Bolt & Nut Guy: 切ったり貼ったりは得意 小難しい理論は苦手 現オープンソースプログラマ 作っている物 / 関わっている物 GImageView: 画像ビューア 風博士: GeckoベースWEBブラウザ sylpheed-gtk2: Gtk+2版Sylpheedの実験的実装 （終了） imime: Windows版Gtk+2用の多言語入力モジュール SCIM用日本語入力モジュール

OSS IMフレームワークを取り巻く現状 中国内でのIMの乱立 IMフレームワークの自由競争状態 - 3つの要因 複数の実装 フレームワーク統一化の必要性 IMフレームワークの自由競争状態 - 3つの要因 Gtk+ / Qt の2強時代の到来 Gtk+2、Qtのimmodule機構 XIM互換性が不要に 特定の実装に縛られない構造 IIIMFの立ち遅れ 実用的OSS IMの不在 複数の実装 IIIMF、SCIM、uim、etc… 複雑なネスト関係 scim-uim、uim-scim、uim-iiimf、scim-openvanilla-uim、etc… 採用実績は2極化 商用プロダクトはIIIMFを好む傾向 OSSプロダクトはSCIMを好む傾向 uimはニッチな需要をがっちりキープ?

OSSのIMサポート概観 主に4つのパスが存在 アプリケーション GUIツールキット (Gtk+, Qt...) 例: Emacs GUIツールキット (Gtk+, Qt...) 例： mlterm 例: gtkimuim 例：gtkimprime IMフレームワーク (uim, scim, IIIMF...) 各種インプットメソッド、変換エンジン

SCIMとは Smart Common Input Method platform http://www.scim-im.org/ 中国のJame Suさんが開発 XIM（X Input Method）を置き換えるべく開発中の、 新たな多言語入力フレームワーク Windows の IMM（Input Method Manager）に相当 特定の実装への依存を回避する、徹底したプラグイ ン構造 プラグインにより対応言語を拡充可能 マルチプラットフォーム化を指向

主な言語モジュール（IMEngine） 中国語入力モジュール 日本語入力モジュール ハングル入力モジュール その他の言語 scim-pinyin、scim-fcitx、scim-ccinput: 簡体字中国語 scim-chewing: 繁体字中国語 日本語入力モジュール SCIM IMEngineプロジェクトにて開発中 詳細は後ほど ハングル入力モジュール scim-hangle その他の言語 scim-m17n-lib scim-tables 他のIMフレームワークへのブリッジ scim-uim scim-kmfl scim-openvanilla

SKIM 中国のLiu Cougarさんが開発 SCIMのKDE親和性を向上させるパッケージ コアはSCIMを利用（SCIMにリンク） 以下のモジュールのセット KConfigモジュール KDEベースのPanelプログラム KDEベースの設定用GUIインターフェース KDEのセッション管理に組み込まれる ~/.xsession等で手動起動する必要無し

SCIMを標準で採用する ディストリビューション Fedora Core Fedora Core5よりデフォルトに SUSE Linux Mandriva Linux KNOPPIX日本語版 Ubuntu (次バージョンのDapperより) その他のローカルディストリビューション

パッケージが存在する ディストリビューション Debian GNU/Linux Gentoo Linux FreeBSD Vine Linux Momonga Linux etc etc…

SCIMの長所 （比較的）実用性が高い （比較的）見栄えの良いGUI （比較的）設定が容易 （比較的）安定性が高い Windowsと操作感が似た日本語・中国語・ハングル 用IMEngineが存在 m17n-libによる多言語化 IMEngnineの開発コストが低い 反面、FrontEndの開発は真面目にやると大変 ユーザ・OSSディストリビュータにとって必要な物が ひと揃い揃っている

SCIMの短所 他と比較すると、本質的問題の数は少ない ただし、一つ一つの問題は根が深い 開発言語としてC++を採用 実質的に開発者が一人 ABIが壊れやすい 最近の不具合報告のほとんどがこの問題 gccの影響を受けやすい・ユーザーの目につきやすい 商用IMの互換性維持が困難 開発者がやや絞られる 実質的に開発者が一人 良くも悪くも James Su さんが全てを握っている 現在のところはうまく機能している 柔軟過ぎる 構成がやや複雑 実装上の細かい不具合 時間が解決

SCIM IMEngineプロジェクト http://scim-imengine.sourceforge.jp/ 2004年11月に発足 日本語専用の IMEngine / Helper を開発するプロ ジェクト SCIM本家とは関係のない、勝手プロジェクト 意外と混同されがち IMEngineがpluggableである利点 - 責任範囲の分離 SCIM本体に問題があれば、バグフィックス等も行う アクティブな開発者は3～4人前後 各々が好きなIMを勝手に開発 最近の開発は収束気味

SCIM IMEngineプロジェクトのプロダクト scim-anthy: Anthyを利用した日本語IMEngine scim-skk: SKKライクな日本語IMEngine scim-prime: PRIMEを利用した日本語IMEngine scim-canna: Cannaを利用したIMEngine scim-wnn: FreeWnn、Wnn6～Wnn8 ほのかたん: 実験的IMEngine? scim-tomoe: 手書き入力パッドHelper scim-sinhala: シンハラ語IMEngine

scim-anthy かな漢字変換エンジンAnthyのSCIM用モジュール 他のOSS IMよりはリッチなＧＵＩ 既存の商用IMに似た挙動 比較的豊富な設定項目 辞書管理はkasumiに依存 既存の商用IMに似た挙動 各種IM風キーバインド F6～F10によるカタカナ／ローマ字直接変換 大文字・小文字の入れ替え Shift + Spaceでの別幅空白入力 テンキー入力時の半角／全角制御 JISかな配列・親指シフト配列をサポート 細かな問題あるが、概ね受け入れられている模様 ほのかたん由来の逐次変換機能 Anthyの予測 & 再変換機能に対応 単漢字検索機能が欠如

scim-skk SKKの基本機能は実装済み ddskkと同等並の機能を目指して?開発中 SKKサーバを含む複数辞書の串刺し検索 Tab補完 GUIによる設定 SKKユーザでは無いので、詳細は知りません

scim-prime 予測入力システムPRIME用のモジュール 日本語予測／英語予測 インライン予測 用例の色分け表示 SCIMがper user daemonであるため 足永のまわりでは１番人気

scim-canna 現在はCannaの高レベルAPIのみをサポート 高レベルAPIの制限による、機能制限 GUIでのキー設定が困難 scim-cannaには３つの存在意義 SCIMのCannaプロトコルサポート .cannaファイルのリサイクル 単漢字検索 Cannaプロトコルの応用例 えせCanna 経由での商用IMへの接続 IME Proxyによる、Windows（Cygwin）上でのIMEの利用

scim-wnn & ほのかたん 元は scim-wnn 複数変換エンジンへの対応を期に名称変更 現在は実験的IM の色が強い 独自のプラグイン機構による複数変換エンジンへの対応 Wnn、Anthy、Canna、PRIME、SKKに対応 複数変換エンジンの同時使用 予測と通常変換で別々のエンジンを使用可能 独自のプラグイン機構による様々な入力方式への対応 現在はローマ字入力、かな入力、T-Codeのみ 独自の設定用UI自動生成機構 その他、謎な機能が盛り沢山 日本人は「ほのかたん」と呼称すべし Honoka、scim-honoka 等は不可 名前の由来は聞いてはいけません

scim-tomoe SCIM用手書き入力パッド 2005年8月末に最初のリリース後、開発は停滞気 味 手書き文字認識エンジンはTomoe 現在は最低限の機能に留まる 今のところ日本語専用 手書き文字認識エンジンはTomoe PRIMEの小松さんのプロトタイプを元に高速化 そこそこの認識精度 インクリメンタル検索 基本的なソフトウェアキーを装備 Enter、Space、Back Space 辞書は現在のところ第一水準漢字まで

リリースは毎月29日 肉の日 日本語IMEngineのどれは一つは必ず肉の日 にリリースされる...はず 14日にリリースされることもあります 石の日 肉を食べすぎると尿管結石ができます（実 話） 肉の日から丁度半月 ネタだがネタだけにあらず リリースエンジニアリングが楽になる みんなで肉を食いながら楽しくリリース

デモ

SCIMの基本構造 コアはシンプルなC++クラスライブラリ 徹底したオブジェクト指向／プラグイン構造による柔軟な構成 2つの粒度 プラグインの組合せによって柔軟な対応が可能 FrontEndモジュール: 　各種GUIツールキットとのキー入力の橋渡し IMEngineモジュール: 　言語モジュール Configモジュール: 　設定保存機構の抽象化 Helperモジュール: 　補助ツール （設定ツール／入力パッド等） IMEngine設定用GUIインターフェースモジュール: マルチプラットフォーム化のため、IMEngineからは分離 個々のIMEngine毎に各種GUIツールキット向けの実装が必要 現在はGtk+用 / KDE用の2種 2つの粒度 ローダブルモジュール プロセス Per user daemon / Unix Domain Socketによる通信が基本 ただし接続方法はアプリケーション & デーモンの組み方次第 実際は scim-launcher デーモンを核とする

SCIMの基本構造: 各プロセスの役割 scim-launcher scim-panel-gtk、skim メインとなるデーモン 名前は同じでも単なるブリッジであることも： XIMブリッジ scim-panel-gtk、skim パネル、プリエディットウィンドウ、候補ウィンドウ、システムトレイ を提供するデーモン scim-helper-manager Helperを一元管理するデーモン scim-helper-launcher Helperモジュールを読み込み、Helperを起動 読み込むモジュールによって様々な姿に変化 設定ウィンドウ、記号入力パッド、手書き入力パッド、...

SCIMの基本構造: ４つの通信経路 SocketFrontEnd - SocketIMEngine メインデーモンとアプリケーションとの通信 主にキーイベントと結果文字列の送受信 SocketFrontEnd - SocketConfig 設定値の同期 Panel - FrontEnd GUIツールバープロセスとメインデーモンとの通信 パネル側がサーバ Panel - Helper GUIツールバーとHelperとの通信 Helper – FrontEnd及びHelper - IMEngine通信の仲介

FrontEndモジュール 入力サーバのキー入力元アプリケーションとの通信 を抽象化するモジュール デーモンのメインループをドライブ 現在は2種存在 X11フロントエンド （XIMプロトコル） Socketフロントエンド （独自プロトコル） 通常は２つのデーモンが立ち上がる Socket モジュール を FrontEnd とする scim-launcher X11 モジュールを FrontEnd とする scim-launcher 他プラットフォームへの移植が比較的容易? 新たなモジュールを作成すれば良い 実際は結構大変

FrontEndのアプリケーション側実装 XIMを介さない通信を行うためには、アプリケーション側の実 装も必要 現在は主に2種存在： 現代的なUNIXアプリケーションは網 羅 Gtk+2モジュール Qt用モジュール 通常は SocketIMEngine で キーイベントを scim-launcher デーモンへフォワード 通常のIMEngineでプロセス内直接接続も可能 環境変数 GTK_IM_SCIM_IMENGINE_MODULES 等 FrontEndを介さず、直接IMEngineを読み込みキーイベントを送付 仮想キーイベントの発行も担当 ソフトウェアキーボードの実現 システムネイティブ （X Window System） のイベントではないため、 稀に動作しないキーイベントもある

IMEngineモジュール キー入力を実際に制御するモジュール SocketIMEngine Helperとの高度な連携も可能 キー入力を各国語の文字に変換 Anthy、Canna等の変換エンジンとの通信 GUIツールキット非依存 設定用UIは別モジュールとして提供 個々のGUIツールキットに対するモジュールが必要 SocketIMEngine 特殊なIMEngine: SocketFrontEndへのブリッジ Helperとの高度な連携も可能

SCIMの典型的な構成例 （キーイベントの流れ） ユーザー入力（出発点） Gtk+2アプリ Qtアプリ X Window System アプリ ソフトウェア キーボード Helper Socket IMEngine 仮想キーイベント XIMプロトコル Anthy IMEngine （終着点） Socket FrontEnd Socket IMEngine X11 FrontEnd scim-launcher 1 （メインデーモン） scim-launcher 2 （XIMブリッジ）

SCIMの特殊な構成例 （キーイベントの流れ） Anthy IMEngine （終着点） ユーザー入力 （出発点） Gtk+2アプリ 以下のような環境変数をセット GTK_IM_SCIM_IMENGINE_MODULES=anthy QT_IM_SCIM_IMENGINE_MODULES=anthy アプリケーション内で直接IMEngineに接続 IMEngineのデバッグに便利

Configモジュール SCIMの設定保存機能 ストレージはモジュールにより抽象化 プロセス内への変更通知は独自のシグナル／スロット機構 SimpleConfig (SCIMに同梱) 独自のファイル形式 （/etc/scim/* 及び ~/.scim/*） SocketConfig (SCIMに同梱) ソケット通信による設定値の同期 GConfConfig GNOMEの設定機構であるGConfを利用 現在は「意味がない」として廃止されている KConfigConfig (SKIMに同梱) KDEの設定機構であるKConfigを利用 モジュールを開発すればWindowsのレジストリ等にも対応可能 プロセス内への変更通知は独自のシグナル／スロット機構 コマンドライン用操作ツールが付属 scim-config-agent get ・ set ・ del ・ reloadが可能

SCIMの典型的な構成例 （設定値変更通知の流れ） scim-helper 1 （設定ツール） scim-helper 2 （入力パッド等） Gtk2アプリ Qtアプリ Scoket Config Socket Config Socket Config Socket Config Socket FrontEnd Socket Config scim-launcher 2 （XIMブリッジ） scim-panel-gtk Simple Config 設定ファイル scim-launcher 1 （メインデーモン）

SCIMの特殊な構成例 （設定値変更通知の流れ with KConfig） scim-helper 2 （入力パッド等） Gtk2アプリ Qtアプリ scim-helper 1 （設定ツール） Socket Config Scoket Config Socket Config Socket Config Socket FrontEnd Socket Config scim-launcher 2 （XIMブリッジ） scim-panel-gtk KConfig Config KDE KDEアプリ scim-launcher 1 （メインデーモン） 設定ファイル

Helperモジュール 設定用ウィンドウ、手書き入力パッド等の補助ツール を提供するモジュール Helperプロセスのメインループをドライブ 実装者の好みのツールキットを利用可能 以下の処理が可能 仮想キーイベントの発行 文字列のコミット ツールバーへのボタン追加 設定再読み込み指令の発行 IMEngine との高度な連携

Panelプロセス ツールバー、プリエディットウィンドウ、候補ウィンドウ、システ ムトレイを提供するデーモン 現在は scim-panel-gtk と skim の2種 依存性分離のため、scim-launcher とは別プロセス IMEngineやHelperからの制御はProperty経由で Helper（入力パッド等）と メインデモーンとの通信を仲介 Helper と IMEngine の通信を仲介 プロトコルは双方を繋ぐ開発者が定義 独自Panelへの差し替えも可能 PanelAgentクラスを利用

SCIMの典型的な構成例 （GUI関連イベントの流れ） 仮想キーボード 押下 マウスによる候補選択 ツールバーボタン押下 XIMブリッジ X11 FrontEnd パネル Socket IMEngine HelperAgent PanelAgent scim-helper （仮想キーボード） Socket FrontEnd PanelClient Anthy IMEngine Socket IMEngine Gtk+2アプリ Qtアプリ メインデーモン

SCIMの今後 大枠の機能はほぼ実装済み ABI問題の解決の必要性 入力開始用ホットキーの扱いの改善 各国の慣習に沿える形に 設定用UI及びHelper用のGUIフレームワーク 一本のコードで全てのGUIツールキットへ対応 柔軟性と開発効率の両立が課題 モジュールのオンデマンドローディング （起動の高速化） コンソール用フロントエンド 仮想キーボード 他プラットフォームへの移植 Windows Mac OS X マルチユーザー? 2.0では大幅な構造改革? （別図）

ScimBridge Fedora開発者の大力亮さんが鋭意開発中 SCIMのABI問題に対する一つの解答 通信を仲立ちするデーモン ABI互換性の問題が出る部分はC言語で記述

SCIMを育てる意義 既に普及している にもかかわらず日本人が開発に参加していない 日本語特有の機能が不足 実質的な日中韓の協力体制確立 商用IM / OSS IM同居の可能性 現状では困難 しかし、IIIMF、uimでは更に困難

日本語IMEngineの今後 scim-prime、scim-canna 基本的な機能は実装済み scim-anthy、scim-wnn 2006年3月29日に1.0リリース予定 以後、当面は開発凍結 scim-prime、scim-canna 1.0リリース済み 当面は開発凍結 ほのかたん、scim-skk 当面は開発継続? 商用IMの機能・性能には及んでいない 及ばなくて良い

scim-tomoeの今後 国際化 Tomoe 及び scim-tomoe を汎用的な単漢字データベース & 検索エンジンとして進化させる 当面、最も開発リソースが投入されるべきモジュール 現代的OSS日本語IMにおいて決定的に欠落している機能 現在エンドユーザーから最も要求の多い機能 手書きデータの収集が課題 第2水準、第3水準、第4水準漢字 精度を上げるためには複数のデータが必要 nnmnd: 手書きデータをインターネットで収集するシステム http://www.sikigami.com/~fuku/nnmnd/ Ajaxを使った手書き文字認識 http://chasen.org/~taku/software/ajax/hwr/

まとめ 基本機能は実装済み – 成熟期間への移行段階 SCIMは柔軟であり、またデスクトップとの統一感も 高い IMEngineの開発コストは低いが、FrontEndの開発 は大変 単漢字検索機能の実装が急務 開発者は常に募集中 日中韓の実務レベルでの協力体制の確立が必要 SCIMには拘らないが、現時点ではSCIMが最も現実的?

最後に... SCIMの開発者、各種変換エンジンの開発者、 開発を支えてくださる皆様に感謝

IMEngineの開発 （１） 前提知識 scim.h を include モジュールインターフェースを実装 ２つの抽象クラスを実装 オブジェクト指向 Autotools gettext scim.h を include モジュールインターフェースを実装 初期化と終了、Factoryの生成 ２つの抽象クラスを実装 IMEngineFactoryBase IMEngineInstanceBase 内部文字コードはUNICODEで正規化

IMEngineの開発 （２） IMEngineInstance生成までの流れ IMEngineFactoryBaseの以下の関数を実装 FactoryでのIM情報の提供 FactoryでのIMEngineインスタンス生成 IMEngineFactoryBaseの以下の関数を実装 get_name (): IM名 （Anthy、PRIME等） get_uuid (): uuid は uuidgenコマンドで生成 get_icon_file () get_authors (), get_credit, get_help () create_instance (): IMEngineInstanceを生成

IMEngineの開発 （３） IMEngineInstanceの実装 基本はキーイベントハンドル用関数 process_key_event キーイベントの詳細は scim_event.h 以下の関数で出力文字列を制御 commit_string update_preedit_string update_preedit_caret reset でプリエディット文字列をクリア フォーカス制御 focus_in (), focust_out () 挙動はIMEngineの実装者次第 詳細は scim_imengine.h

IMEngineの開発 （4） 必要に応じて使用するクラス scim::Attribute クラス 文字列の装飾を制御 プリエディット文字列、AUX文字列、候補文字列に適用可 能 scim::CommonLookupTable クラス 候補ウィンドウの制御 scim::Property クラス 主にパネルの制御 scim::IConvert クラス 文字コード変換 String → WideString： 内部エンコード（UCS-4）への変換 WideString → String： 指定エンコードへの変換

脱線 - surrounding textの是非 IMEngineからカーソル周辺文字列を取得するAPI タイ語等のサポートに必要とされている タイ語は一文字が子音記号・母音記号・声調記号の3つの記号の組み合わ せによって構成される 一回のキー入力に対して一個の記号が入力される キー入力毎に逐次コミットし、後置で文字を置き換える実装 実際はプリエディットでも対応可能 コミット後の修正はユーザーが手動削除 日本語の濁点・半濁点も同様の扱い カーソル周辺文字列の取得は フロントエンド側にAPIが存在するとは限らない APIが存在しても、バギーな場合もある その様な現状で、無理にsurrounding textを使用する必要がある のか？という議論がある 日本語の再変換に利用可能？ 取得できる情報が足りないため、現在は非実用的 選択範囲の情報が、SCIMによる抽象化の結果として欠如している

レイヤ分断：OpenOffice.org 2.0 with scim-uimの場合 VCL (Visual Class Library) SAL (System Abstraction Layer) UNIX Windows hoge-system Xlib VCL plugin Gtk+/GNOME Qt/KDE uim SCIM hoge-im Gtk+ immodule scim-chinese scim-uim scim-hoge SCIM IMEngine uim-anthy uim-prime uim-hoge uim バックエンド

IMフレームワークに対する私見 多様な価値観に対する包容力が決め手 プリエディット制御は別ライブラリ化 各種自然言語・プログラミング言語への対応 オープンソース・クローズドソース双方への配慮 投入可能な開発リソースに見合った開発スタイル GUI環境、非GUI環境双方への十分な配慮 プリエディット制御は別ライブラリ化 IM HUBとの分離 開発責任の分離／明確化 API／ABI安定性の問題 SCIM と uim or m17n-lib の関係が一つの解答 デスクトップインテグレーションの重要性 コアは徹底的に依存性を排除した上で、逆に末端機能は徹底 的なデスクトップ環境への依存が必要 ユーザーインターフェースの統一感 モジュール間通信の統一感 プログラミングインターフェースの統一感