Jserv's blog

新酷音進度報告2

其實不算是「報告」，因為最近沒有大的進展，但是卻有許多重要的新想法值得紀錄，所以在此 blog 備忘。

[新酷音] 事實上不只是個輸入法，嚴格來說，這是一系列的輸入法實做，有個重要的指導原則就是 "Chewing Anywhere"，讓繁體中文使用者能夠在許多不同的平台能享有同樣的輸入法習慣。上個月 blog [新酷音進度報告] 所提到的部份大致在二月底時釋出新版本實做出來，如果可以的話，我試著保持一個月更新這樣的紀錄。

Sun Microsystems 的 Ervin Yan 在他的 blog [A great story for IIIMF and chewing for Taiwan CTS project] 提到新酷音與 IIIMF 的商業應用，這的確是讓人很開心的事情，像 JDS (Java Desktop System) 這樣成熟的商業產品竟然願意採納新酷音的成果，實在是一種高度的肯定，而這跟華視又有什麼關係呢？請參閱新聞報導 [昇陽Java桌上軟體簽下首家客戶]，所以，這世界實在奇妙，雖然我很少看電視，但是華視大概是電視頻道中，我看最多的，這問每個服過兵役的台灣男子都知道，因為每週四都要看在華視放映的《莒光園地》節目。 (我對華視直接的聯想)

然而，正如之前在 Tsung 的 blog [銘言啟示錄] 所看到劉燈前輩的一席話：

「當百分之90的code做完的時候，表示百分之90的事情還沒有做完」

現在有極深刻的感觸。整整十一個月前，我在 tw.bbs.comp.linux newsgroup 貼了我對於當時 xcin-cvs + Chewing support 的 patch，因為一直聯絡不到原始酷音輸入法的作者，只好暫時弄個 fork 出來，但是沒有想過維護，畢竟這與我過去所作的軟體項目落差實在太大。然而，無心插柳柳成蔭，雖然進度不怎麼樣，但是這個計畫就在各地的同好協助下，透過網路聯繫與分享，成就 [新酷音] 這個計畫，爾後原始酷音的設計者也給予頗多鼓勵，這實在是很有趣的經驗。現在回頭看當時的動機，現在的完成度有一定的水準，但是過去的包袱也帶來諸多限制，這些的確是完成 90% code 時才發現的。

libchewing 與 SCIM-chewing 的維護人 Kanru Chen 在 blog [UTF-8 vs. UTF-16] 提到在 libchewing kanru-0.3 branch 開始 Sqlite3 backend 與 Unicode 支援，這方面的議題頗複雜，因為過去太多基於 Big5 的假設，從使用者的 feedback 與自身的需求來說，已經面臨太多缺字與重複轉碼的困擾。說到這，補充一個注意事項，上個月釋出的 libchewing 0.2.6 在漢語拼音的支援部份出了些問題，在 svn repository 已經有所修正。

上個月舉行的 [中文輸入自由軟體工作坊] 有許多新想法，而我也決定加強新酷音在 IIIMF 上的實做。im-sdk 12.2 的 Namespace I/O 會固定 API/ABI，是個很讓人高興的消息，因為這樣一來，Language Engine 的開發者可以減少許多額外的 I/O routines，不過，這又暴露酷音設計的另一個缺陷 -- 內部做了太多 I/O 操作，最顯著的問題就是，現行的 IIIMF-Chewing 與 tch_le_sun/Chewing 處理使用者手動加詞的功能很糟糕，無法針對特定使用者套用不同的詞庫，何也？光看 ReadHash() 實做就可以發現許多問題了，在 Ervin Yan 的協助下，邀請了他的同事 Phill Zhang 針對這個議題，在 #iiimf 討論，這是他的自我介紹：

13:45 < phill> hi, jserv,
13:46 < phill> I am phill, from SUN, working together with eyan
13:46 < eyan> hi, jim, I just ask Phill to attend this irc channel, he will help to enhance the user data loading/saving for chewing.
13:46 < phill> on Tch_LE
13:47 < eyan> phill is the designer of tch_le_sun's API/SPI.

經過討論後，我知道 libchewing 要如何在 tch_le_sun 發揮出應有的功能，看樣子必須再行設計新的 I/O wrapper bound to Namespace I/O，必須承認的是，我對於 Namespace I/O in IIIMF 的認知也侷限於閱讀過 im-sdk/doc/ns/README 的描述，至於其設計動機為：

IIIMF Namespace based file I/O API provides a set of functions which have the same semantics as the POSIX file I/O functions.

This document briefly describes how LEs (Language Engine) can use the IIIMF Namespace based FILE I/O APIs. LEs may access their own configuration files, per user data, and such. If LEs use this set of APIs to access these files, input method users can control where those files will be located.

The purpose of these APIs is to provide better I/O implementation for LEs.

有趣的是，libchewing 內部設計也有這樣的概念，差別在於後者具體而微罷了，現在要將兩者建立關聯，就是一個需要處理的議題。在我的 local repository 已經設計出一個 prototype，等我想好細節的部份應該就可以 check-in。

先提到這，因為太多細節我不能參透，那麼，聊些比較有趣的項目吧，在 SCIM 平台上，新酷音有不錯的展現，可參考 [SCIM/新酷音 + scim-input-pad]，記得我去年才在蘇哲抵達台北時，在某個聚會跟蘇哲說我需要這樣符號輸入的功能，沒想到好快就有這樣完整的實做，看來我以後不能說「這些符號我打不出來」了 :-)

SuSE 9.3 已經釋出，正如之前 blog [最近幾個跟新酷音有關的消息] 提到的，SuSE 9.3 繁體中文內建新酷音，讓人真想玩看看。上個月花了一點時間做了有趣的 hack [XFCE 手寫辨識支援] 在 blog 結尾處我提到：

就算不用在 PDA 等 handheld devices，XFCE 的手寫支援還是有其價值在，比方說用在 Kiosk 或者是公用電腦，旁邊放個手寫版，就可以輕鬆的搭配手寫辨識來使用了。完整的手寫筆跡辨識很難，更別說要拿出 Free/Open-Source 的解決方案，但是像是「手寫酷音」或許是個很好的方向，畢竟很多台灣人也寫不出所有的常用字了，寫注音符號輕鬆多了

而前天改了一下 evdev.c，弄了新的 kernel module，部份驅動之前買的極光小蒙恬手寫板，這當然也是個不成熟的 hack，目前只能送 motion 的 raw data，看起來不是很好，但是如果單純的 scratch 或許堪用，所以我又開始思考「手寫酷音」的實做議題了。

總之，寫輸入法一句話就是「送禮自用兩相宜」，可以從中磨練自己的耐心，還可以結交朋友，當然有了好用的輸入法，與 MM 聊天也比較愉快，何樂不為呢？

由 jserv 發表於 March 12, 2005 06:47 AM