cahier lukhnos

是的，Leopard 上的輸入法架構確實有了新局面，星期四和星期五還另外有針對 TextService 的 session 和 lab.

More update on that later. :)

lukhnos :: Aug.09.2006 :: tekhnologia 技術或者藝術 :: Comments Off

今天的確是相當漫長的一天。Steve Jobs今年的Keynote Speech內容以及評價，我想網路上已經貼了許多，我在此就不再添足。今天除了上午的Keynote Speech外，下午連續參加了三場講座：OS X State of the Union, Development Tools State of the Union, Graphics and Media State of the Union, 都是屬於宣示性、策略性的演說。事實上，後面三場的重要性，我現在認為，其實遠比Keynote來得重要。

當然，會議的Keynote不外乎是替大方向定調。今年的WWDC Keynote很意外的都是Apple自家員工上陣，並沒有Intel、MS或Adobe的人出來講話。對Apple來說，Intel transition也許已經完成，但是有在看MS Mac BU的人都知道，事情絕非如此單純。另一方面，Steve Jobs的Keynote似乎已經變成了一種煙火秀，在這樣的情況下。可是要年年有驚喜，其實並不容易。

就目前我所看來，上午Keynote的「平淡無奇」，其實都是在為下午每一項技術的深化定調。例如Time Machine其實是Journaled file system的延伸，要真能發揮功能，最終仍要靠應用程式的配合。Spotlight, universal access也一樣。

對我來說，有兩個我所關心的主題，Keynote上沒提到，反倒是在下午的講座上漸次被提及。一個是Objective-C 終於有了正式的garbage collection的機制（將在Leopard中支援），另一個則是終於有了resolution-independent UI──意思是說，從此使用大螢幕時，UI的尺寸（其實是DPI數）也會跟著增加，終於讓眼睛不會太傷。

很顯然，Apple 仍把主要技術的實作，押寶在 Objective-C 這套語言上。負責 Objective-C 講題的人甚至開玩笑說，他會吹管樂，而升do（C#）的調子 “get you nowhere”。話雖如此，增加諸如 setter/getter 自動生成的關鍵詞，增加 “foreach” 的語法，以及早在前一版 gcc 就已經出現、但 Apple 並無在 Cocoa 層次支援的 garbage collection 等等，這些只能說是 Apple 終於跟上了現代語言發展的腳步。同樣的道理也出在 Xcode 3.0 的眾多「新功能」上，例如區塊收攏（folding）、refactoring、更好的除錯訊息支援等等，這些早就是各種現代編輯器以及IDE環境就該有的功能，Xcode只能說是早該如此。不過，那套竟然跟GarageBand介面有異曲同功之妙的除錯工具，倒是很令人眼睛一亮。

整體說來，今天一整天所提及的技術，主要還是以媒體及呈現（media and representation）為主，舉凡CoreAnimation, QuartzComposer等等，顯然Apple仍然專注於桌面軟體，並且針對的都是高階、高單價／高成本、大量圖形或媒介處理的應用。而，當 Steve Jobs 在 Keynote 講到 iChat 的新功能時，很多朋友（就我所知）的第一個反應是：這有什麼好拿來講的。然而，在下午的 session 中便不難發現，此次 SJ Keynote 的重點都在於：這每一項「平淡無奇」的「新功能」，都有一套 API ，而且顯然做為 OS X 的應用程式，都該儘可能善用這些功能。

也就是說，OS X 的應用程式將越來越難寫。應用程式底層必須有可程式化的 scriptability，UI 基礎要能有 accessibility （這一點在美國相信會益發受到重視），程式要好用、要提供 “wow factor”，必須善用各種的媒介資源──聲音、圖片、影像、攝影機、H.264格式、HTML+CSS+Javascript──這一些都建立在一個又一個的 “framework kit” 上面：PDF Kit, CoreAnimation, ImageKit, QT Kit, Web Kit, etc. etc. （是的，這些程式庫初期都會只有 Objective-C 寫的 API）有一點跟 MS 哲學很不一樣的是：OS X 的程式庫，似乎都直接反應在 Apple 自家的應用程式上，也就是說 Apple 自家的應用程式就是那些程式庫的精緻應用。例如用 PDF Kit 配合 Interface Builder 就可以拉出一個簡易版的 Preview，Web Kit 拉一拉就有個陽春版的 Safari 等等。而如此的挑戰變成了，當這些事 Apple 都已經幫你做好時，你到底能發展出什麼新的東西出來。

雖然WWDC做為每年Apple的兩大盛事（另一是MacWorld）之一，總有許多花絮和trivia可講，不過我想最終還是要回到技術的主題來。接下來四天會參加的活動，也會循著這個方向來走。

今天先到這邊，要去補充五點起床苦撐透支的體力啦。

lukhnos :: Aug.08.2006 :: tekhnologia 技術或者藝術 :: 5 Comments »

所以，今天早上應該算 Day 0 ，到今天結束，才應該叫 Day 1 ？(See, I solved the day numbering fence-post problem!)

幾個 quick updates:

• 早上5:15 AM起來實在令人腦袋一片空白, but it pays.
• 遇到 WebObjects evangelist 然後被傳了十分鐘的 WO 之道。
• 據說到時會場會強力干擾wireless access points, 所以非常好奇之前的文字現場轉播是怎麼做的。
• 承上，「全文轉播」的網站應該已經滿天飛了，這裡就不轉載了吧……
• 很明顯的有些人已經來很多次了，所以跟著他們走準沒錯。除此之外老經驗的人也會傳授一些例如「何時要去參加Apple campus bash」或是「要提早到Company store買紀念品，不然人會爆滿」這樣的tips and tricks.
• 會場偶爾還是有一些 non Apple machines, but they are the minority (well, unless, of course, they’re running You-Know-What…
• 還沒有看到人拿出 bingo sheet，不過也許是因為還沒進會場。
• 現場的一些照片可以看這裡。
• Right… I’m thrilled about it

lukhnos :: Aug.07.2006 :: tekhnologia 技術或者藝術 :: Comments Off

今天有點晚了，先轉來今天 (“Day -1″) 的英文版 WWDC 見聞錄，以上。:)

附註：”OV @ WWDC” 開頭的文章，均以 Creative Commons Attribution-Non-Commercial-NoDerivs 2.5 License (英文版 / 繁體中文版 / 簡體中文版) 公開。這個 blog 上的其他文章除非特別標明，否則（仍）不是使用 CC 授權發表的。

lukhnos :: Aug.07.2006 :: tekhnologia 技術或者藝術 :: Comments Off

(But then, is tomorrow WWDC Day 0 or Day 1?)

昨天下午睡了一下午覺，起來的時候，大約花了一分鐘的時間，才真的醒過來，確定自己到舊金山啦。

簡短快速 update 一下現況：

• 去 Moscone Center 拿到了入場用的名牌。舊金山市區看得到不少拿著 WWDC 2006 包包（與會贈品）的人走來走去。去買東西的時候，還被店員問到明天會有什麼好料，我當然只能說請他也來玩keynote賓果遊戲啦。
• 去了一趟 Apple Store ，事實上就在 Moscone 兩個 block 之遙的步程內。修好了我的電源供應器（其實就是換掉了），我的 AppleCare 資料又再度消失在資料庫中… orz. 最後東西修好沒錯，不過，這已經不是第一次我的「阿婆不care」出狀況了。這這，不太對吧。
• orcas 又找出了好幾個 OS X 奇怪的地方，像是 QuickSilver + 改過的US keyboard layout + OV 會搞怪。Matlab 還是無法用 OV。呃，看起來都不是 OV 的錯。
• 明天應該會很早起來排隊吧，上午似乎會很漫長……

lukhnos :: Aug.07.2006 :: tekhnologia 技術或者藝術 :: 2 Comments »

晚上利用時間重新啟動了一個去年就進行過的實驗：使用WebKit來製作OpenVanilla的選字窗。翻譯成白話就是：「用web browser來做為輸入法的選字界面」。

由於OpenVanilla從0.7.0開始，選字窗的顯示是由另外一個process負責，也就是所謂的OVDisplayServer。Display server是透過Objective-C RPC來聯繫，因此我們只要kill掉display server的process，換上有相同RPC註冊名的process，就可以達到替換UI的功能。

目前這個實驗真的還在無比alpha的階段，以下步驟僅供the truly adventurous使用：

1. 從svn取得OV最新原始碼
2. 使用Xcode編製在trunk/Experiment/WebKitServer的project file (WebKitServer.xcodeproj)
3. 在shell底下執行 “killall OVDisplayServer”，把原先的 OVDisplayServer process 殺掉
4. 執行編好的WebKitServer.app
5. 開啟新的應用程式（此時最好關閉舊的應用程式，不然切至OV時會發生問題）
6. 切至OV，就會看到使用WebKit的選字窗
7. 如果不喜歡default style，可以到 ~/Sites/ 建立一個名叫 WebKitServer 的目錄，然後在裡面建立一個 style.css
8. 換上自己喜歡的body style

注意事項及現有問題：

• style.css更新後，WebKitServer 不會即刻更新，得重新啟動（如何refresh WebKit中的stylesheet，得要研究一下）
• 重新啟動 WebKitServer 代表先前啟動的應用程式也得關掉重新啟動，不然會當掉
• 不能調整選字窗的大小和位置，不然OV會在選字窗內啟動，然後就陷入永劫回歸，orz
• 選字窗目前是用default window style，這個得調
• 選字窗內文目前是用重新載入HTML page source的方式做的，這個將來應該要改成用JavaScript來做：反正WebKit很邪惡嘛……

不能免俗，有圖有真相：

lukhnos :: Jul.14.2006 :: tekhnologia 技術或者藝術 :: 2 Comments »

在先前兩篇準備工作，我們做了幾件事：需求分析、可行性分析、原始資料的分析與準備，並且建立了一個計劃所需的「周邊」（periphery）。我們這次要開始動手了。

Introducing… OpenVanilla

我們終於可以開始一展 OV 發展的初衷：簡化輸入法的開發工作。這一篇blog會比前兩篇都短得多。我希望我們利用這一篇做為 OV 的某種 crash course ，讓大家馬上就編出一套簡單的輸入法──換個方式說，先做出一套「輸入法的 “Hello, world!”」，再慢慢細述一個輸入法有哪些構成。

所以今天的內容會相當簡單。I promise.

輸入法的 “Hello, world!”

什麼是輸入法的 “Hello, world!” 呢？最簡單最簡單的輸入法，其實就是：鍵盤打了什麼，就直接輸出什麼。用網路的術語，這叫 “echo back”，或者叫回送。把使用者打的鍵、也就是餵進輸入法的鍵碼，再原封不動地送回去。事實上，在輸入法上，這也可以稱為 “pass thru”，也就是不做任何處理。

不過，在以下的範例中，我們還是會在這 pass thru 的過程中，再多動一點手腳。

以下就是今天的程式範例，我稱為 FoobarIM.cpp （「foobar 輸入法」）：

#include <stdio.h>
#include <Openvanilla/OpenVanilla.h>
#include <Openvanilla/OVLibrary.h>

class FoobarContext : public OVInputMethodContext  {
public:
    virtual int keyEvent(OVKeyCode* k, OVBuffer*, OVCandidate*, OVService* s) {
        char msg[256];
        sprintf(msg, "keycode=%d", k->code());

        s->notify(msg);
        return 0;
    }
};

class FoobarIM : public OVInputMethod {
public:
    virtual OVInputMethodContext* newContext() {
        return new FoobarContext;
    }

    virtual const char *identifier() {
        return "FoobarIM";
    }
};

OV_SINGLE_MODULE_WRAPPER(FoobarIM);

請將以上的程式碼範例，存檔成 FoobarIM.cpp 。然後，進到 shell ，利用下面這行指令編譯：

g++ -bundle -o FoobarIM.dylib FoobarIM.cpp

編完之後，我們就會得到一個 FoobarIM.dylib 。再將完成品用下面的指令，拷到自己的 OV 模組目錄裡：

cp FoobarIM.dylib ~/Library/OpenVanilla/0.7.2/Modules/

好了，大功告成。請隨便新開一個應用程式（例如 TextEdit.app）──請注意，要是新開啟的應用程式才行──然後，拉下你的 OV 選單，你應該會看到如下例的圖片：

FoobarIM 輸入法正式進入選單中！

你可以選用這個輸入法，在 TextEdit.app 中隨便打幾個字，看看會有什麼東西。

So, 這就是最簡單的 OV 輸入法了。我們會在下一篇中慢慢解釋，上面看似怪異的程式碼，到底做了哪些事情。

使用 svn 取出範例

事實上，我們先前建立版本管理倉庫，有一個好處是：我們完全可以用版號來分辨目前進行到哪一個階段。例如，如果你想知道今天之前我們放進了哪些東西，你可以用 svn co -r 2 http://svn.openfoundry.org/ovgeoinfo 這個指令，來取得「revision 2」的所有程式碼。

今天送進去 svn repo 裡的東西為 revision 3。我們之後還會繼續送新的東西進去。用 svn 的好處已經很明顯：我們不再需要開啟例如 step1/ step2/ step3/ … 等等目錄。我們直接用 svn 的 co 指令，就可以取得某一個特定版號的所有程式碼。

lukhnos :: Jul.05.2006 :: tekhnologia 技術或者藝術 :: 2 Comments »

上一篇文章裡提到，我們想開發一個「（以任何現有輸入法）打完地名，輸出與地名相關之地理資訊」的新「輸入法」──或者是「超輸入法」（meta input method）。我們在上一篇文章針對了需求做過了分析，並評估了一下OpenVanilla能派上什麼用場。我們拿到了一份「生」的XML的原始資料，將它煮成了SQLite資料庫所需的SQL指令檔。

我們針對功能核心（functional core）的準備工作差不多到此。在今天這一篇，我打算從另一個方向來進行準備。這些事項通常被認為只是一個計劃的「邊緣」（periphery），或者用不那麼哲學的說法，叫做「支援／支持性結構」（supportive structure）。然而我們可以從任何一個初具規模的open source計劃中發現，這些「邊緣」與「支援／支持性結構」的重要性，絕不亞於功能核心。

好的，那麼今天的準備工作，將包括有：

• 在OpenFoundry上開設一個計劃
• 利用OpenFoundry所提供的原始碼倉庫（source repository），將我們目前為止準備的材料送進去（commit）。
• 為我們的計劃選一套open source的授權條款。

準備好了？我們開始。

為程式碼找一個家

剛開始的時候，一切都很單純：你把程式碼編好，把東西包裝起來，上傳到自己的homepage所在地，修改index.html（或其他網頁檔案），然後昭告親友，你寫了一套新軟體。

然而軟體會長大，計劃也會成長。你可能開始想找人參與，或是有人主動想開發新的功能。你開始有共同工作（collaboration）的需要。另一方面，你也可能開始有各種不同的版本要發布。你想要使用subversion一類的工具來管理程式碼，可是又不想或無法自己架subversion在server端所需的各種工具。然後你還需要有bug tracker、mailing list，你發現你開始分心去做這些「務虛」但必要的管理工作……

許多龐大的open source計劃，因為資源較為足夠，得以發展出一套完整的分工體系，讓其中一部份參與者擔負各種管理及「顧家」（housekeeping）的工作。這些大型計劃像是自給自足或自成體系的大企業。然而我們只是個剛開始的計劃，我們不可能花費這些心神來處理這些「顧家」的工作。

像SourceForge、OpenFoundry一類的服務，所幫你分擔的，就是這種「安家」（hosting）的憂愁。它們為你的計劃提供一個家、一個發布的空間、一套具有版本管理功能的原始碼倉庫，並提供一些基本的計劃管理工具，供你的計劃公開給世人使用。

可以說SourceForge、OpenFoundry是一種公共服務，我們可以把各種顧家、安家的工作「外包」出去，利用它們來節省我們的管理時間。

到OpenFoundry上開一個計劃

在這個時點上選擇OpenFoundry的理由，不外是它有中文介面，又不像SourceForge那麼複雜。

要在OpenFoundry上開一個新計劃的方法很簡單。首先，你要先成為註冊使用者，然後就可以開設新計劃。

我們在計劃資料上填上以下的內容：

• 計劃名稱：地理資訊輸入法
• 計劃的id：ovgeoinfo （我們將來以此名稱來存取原始碼倉庫）
• 版本管理工作：使用預設的 subversion

然後，在選擇授權的時候，我們使用 BSD License ，文件的授權則使用Creative Commons的Attribution-NonCommercial-NoDerivs。

稍後我會說明（在此時點）做這個選擇的理由。

將原始碼送進原始碼倉庫中

嗯，到此為止，我已經用了兩個我實在用不慣的中文詞，幾乎快到爆炸的程度。以後我會只講check in、check out跟source repository（簡稱repo）。

在OpenFoundry上把計劃開設好後，我們就可以透過這個URL來存取和計劃相關的資訊。同時，OpenFoundry也會幫我們設定好計劃要用的subversion repo：http://svn.openfoundry.org/ovgeoinfo

接著，我們利用subversion這套工具，把先前寫的Perl煮XML工具，以及範例的資料檔，check in（或說commit）進入我們的repo中。

使用subversion

Subversion屬於UNIX「一脈相承」的的版本管理系統，它的使用方式和命令語法都承襲自CVS，而CVS又是承襲自RCS。目前Subversion的中文文件，最重要的，當然要屬plasmaball翻譯的手冊全文。不過，subversion雖然功能強大複雜，對於我們來說，日常的工作，其實只有以下四種：

1. 用svn checkout指令取得原始碼
2. 用svn update指令將放在我們自家硬碟裡的拷貝，更新到最新版本
3. 用svn commit指令將我們做過的修改，送進repo裡
4. 用svn log瞭解最近的更動記錄
5. 萬一在svn update時遇到衝突，做衝突的修正

其實 (1.) 只有第一次工作時會需要用到。一般對只需要取得程式碼、或僅有唯讀（read-only）權限的人，也只會用到 (2.) 和 (3.)，只有真正在修改程式的人會需要碰到 (4.) 和 (5.) ，而且 (5.) 的情況不多見。

將repo目錄checkout到自己硬碟上

Ok, 我們可以把repo給checkout出來了：

svn co http://svn.openfoundry.org/ovgeoinfo

事實上，當你看到這篇文章的時候，我已經把上一篇文章提到的幾份東西，都一一送了進去，除此之外還有很多別的東西。為了說明方便，我想先「還原現場」，向你說明我在第一次checkin時，到底送進去了哪些東西。

我送進去了哪些東西

如果你觀察一下 checkout 出的 ovgeoinfo/ 目錄，你會發現如下的結構：

ovgeoinfo/
  trunk/
    License/
    Mk/
    Module/
        OVGeoInfo/
    SharedHeaders/

之所以會有這樣的安排有有原因的。

許多subversion的使用者承襲了CVS的習慣，把repo最頂層區分為以下兩種目錄：

• trunk/: 字面意思是「樹幹」，意思是程式碼的主支幹，也就是現行的最新版本（latest version）
• branches/: 意思是「支幹」，也就是程式碼的分支。

事實上，許多計劃承繼自CVS的習慣，還有一個名叫 tags/ 的目錄，用來標示各種已經推出的版本。但是由於 subversion 不再依靠這種方式，有一些計劃（例如 OpenVanilla）把各固定的版本放在 releases/ 目錄中。

這些習慣雖然在計劃初期看不出好處，儼然只是增加麻煩，但是隨著計劃成長，這些過去open source計劃所慢慢累積出來的經驗法則，就會顯露出其效用。

放在 trunk/ 裡的東西

至於，trunk/ 裡的四個目錄，功能是這樣的：

• License/: 這是屬於服務性質的目錄，主要將放進我們的 BSD License 全文。
• Mk/: 這是 OpenVanilla 模組共用的 Makefile
• Module/: OpenVanilla 的模組會放在這個目錄裡，裡面的 OVGeoInfo/ 是我們真正要開發的模組。
• SharedHeaders/: OpenVanilla 的一些供模組使用的程式庫標頭檔。我們在此將只用到 OVSQLite3.h 這個 sqlite3 程式庫的包裝紙（wrapper）。

OpenVanilla 之所以會這樣安排目錄結構，當然也是有原因的，我們會慢慢解釋。至於為何目錄名一反 UNIX 的慣例，首字都是以大寫開頭？那是因為 OpenVanilla 受到了 Mac OS X 的目錄命名習慣影響所致。

我們可以從命名看出一個計劃的文化背景。:)

然後，我們把上一篇文章所提到的內容，都放到了 OVGeoInfo/ 這個目錄中了。

選擇 BSD 授權

大抵說來 free/open source 軟體的授權只有兩種：GPL 系的跟 BSD 系的。我選擇所謂的「三條文式BSD授權條款」有以下幾個理由：

• 它很短
• 比較起來算是好懂
• 它的限制少
• 我翻譯了一個中文版本

當然，這兩種軟體授權代表了兩種哲學差異，在此無法一一細述。

我們 reuse 了一下 OpenVanilla 的 trunk/License/ 目錄裡的授權條款文字，將之放進了地理資訊輸入法的 trunk/License 中

到此…

到此，我們完成了這些「邊緣」或「支持性結構」的準備工作了。我們可以試一下先前提過的煮XML的程式碼：

cd ovgeoinfo/trunk/Modules
./gendb.pl example.xml

你也可以用svn log指令閱讀最近的修訂記錄，了解這個實驗的最新進度。

lukhnos :: Jul.01.2006 :: tekhnologia 技術或者藝術 :: 1 Comment »

（註：其實這應該要畫很多圖來說明的，在此先略）

ilya先前和我討論到：有沒有可能拿OpenVanilla來做地理資訊的輸入工具？他的需求，簡單說來，有以下兩類：

• 輸入中文地名，出一地的英文地名或古地名
• 輸入中文地名，出一地的經緯度或其他座標資料

在和ilya以及中研院OpenGIS Lab的張欽隆討論後，我們決定將這個輸入法的開發，變成一種公開的實驗。

這篇文章便是這一系列實驗的第一篇。我的初步構想是：藉這個機會，來實現OpenVanilla最初設計的其中一個理想──簡化輸入法的開發過程，讓開發者能專心於輸入法的邏輯和演算法，而不需煩心於各種作業系統平台的實作細節。

同時，我也希望藉由這個實驗，來說明OpenVanilla晚近加入的一個新設計──所謂的「詞彙管理架構」，以及為什麼詞彙管理架構能夠填補現有輸入法設計的不足。

最後，也希望藉由這個實驗，來走一遍一個 open source project 的開發流程，包括了建立程式碼的版本管理倉庫、選擇版本授權等等雖然屬於「周邊」（peripheral）、但對於計劃延續不可或缺的部份。

問題分析

地理資訊的輸入是一件麻煩的事。由於與一個地名相關的資訊種類繁多，如果能以「地名」為中心，也就是拿地名來當key，便能輸入各種資料，對於地理相關工作應該是很有幫助的。Ilya的需求是由此出發的。

同時，地名也是一種有歷史性（historicity）的東西。地名不只是現時、此刻的存在，也代表了歷史的累積。打當今地名而能出古地名的需求，也是由此而衍生出來的。

輸入法所可能提供的協助

輸入法在軟體工程上是一種奇特的存在。雖然輸入法最早是輸入亞洲語文所不可或缺的工具（sine qua non）^[1]，但是本質上輸入法是一種變換（transform）：輸入一串組字鍵碼，得出組字結果。嚴格說來輸入法其實就是一種索引鍵─鍵值（key-value）的查找關係。

而，因為輸入法在現代桌面環境上，可以與任何需要文字輸入的GUI元件共同工作，於是很奇異的，輸入法變成一種增加軟體功能的方法。也就是說，藉由擴充輸入法的功能，我們等於同時也擴充了應用程式的功能（簡繁轉換及標點符號轉換均為其例）。因此，輸入法可以被當成一種「非侵入式的外掛」（non-intrusive plug-in）。

然而，由於主流的輸入法架構，僅僅作到一次性的key-value查找（例如：以倉頡組字碼找中文字），因此就算我們打出了「台北」兩字，我們依然只能把這兩個字剪貼到另一套資料庫程式，藉以檢索與「台北」兩字相關的地理資訊。

OpenVanilla早期設計了所謂的「輸出過濾器」（output filter）的架構，是可以針對「以詞為輸出單元的輸入法」（例如酷音，每一次輸入都是一個詞）做輸出處理。例如，我們可以設計一個「打『台北』出Taipei」filter。然而過濾器的缺點是：在UI邏輯上，filter是一種單向的、多對一的（one-direction, many-to-one）轉換。對於地理資訊來說，我們需要一個反饋的過程，亦即，當打完「台北」之後，我們可能要讓用戶再一次選擇與「台北」相關的地理資訊。

這種類似「二次選字」的事情，用filter是無法做到的。

OpenVanilla的詞彙管理架構

OpenVanilla於2006年初提出了「詞彙管理架構」。事實上一套「詞彙管理架構」是由兩個元件組成的：置如輸入法之前的「鍵碼前置處理器」（Key Preprocessor）跟「詞彙補捉器」（Phrase Catcher）。詞彙補捉器其實是一個filter，只是不停地把使用者輸入的文字給收集進來。

這樣的好處是，讓非以詞彙為輸出單位的輸入法（例如倉頡，一次只輸出一個字），也能夠收集詞彙。而，透過置於輸入法之前的「鍵碼前置處理器」，我們可以在還沒進到輸入法之前，就先對使用者的按鍵做處理：例如，把從「詞彙補捉器」收集來的詞，丟進資料庫裡，或是拿來查找。

也就是說，透過 key preprocessor ，我們可以做到一個「超輸入法」（meta-input method），讓使用者可以用任何一種輸入法打完「台北」兩個字，然後再拿「台北」兩字做一些事。

由於 key processor + phrase catcher 這樣的架構可以做到「再一次的查找與轉換」，我們的地理資訊輸入需求，似乎可以再利用（reuse）這個 pattern 來達成我們的需求。

實作的方法

通常，在原型階段，我們會先用一些 dirty hack 以及 top-down approach ，很快地把程式的功能原型寫出來，來證明概念可行。在此之後，我們再改走 bottom-up approach ，細細烹煮（cook）每個所需的元件，最後再放到一起大火快炒，勾芡上桌。

由於設計樣式已經有了，這個設計也被證明可行，我們要做的是依照需求，重寫一套依地名查找地理資料的輸入法。

在此之前，我們得先把一些材料準備好。

材料：地理資訊的 XML 資料表

我們收到的是一份長相如下的 XML 資料表：

<place id='1'>
    <zh_name>漁人</zh_name>
    <en_name>Yuren</en_name>
    <lon>121˚ 32' 40"</lon>
    <lat>22˚ 1' 5"</lat>
</place>

以上是該 XML 資料表的簡化版，我們先列出中文地名、英文地名與經緯度四項資料。

生的XML資料並不是那麼好利用。OpenVanilla推薦使用SQLite3。因此我們得先把XML煮成SQLite3能用的資料。

最懶的方法：XML::Simple

煮 XML 文件的方法很多，最懶又最快的方法，當然是使用 Perl 的 XML::Simple 模組了。

#!/usr/bin/perl -w
use strict;
use XML::Simple;
my $filename=shift or die "Must specify a filename";
my $data=XMLin($filename);

嗯，好像這樣就煮完了，似乎沒什麼挑戰性。當然，如果你只裝 XML::Simple ，在 OS X 上可能會發生一些問題（XML::Simple 預設的 XML parser 是 XML::SAX::PurePerl ，在 UTF-8 判斷上似乎有點 suck），因此建議再安裝 XML::SAX::Expat ，就會順心如意多了：

sudo cpan install XML::SAX::Expat
sudo cpan install XML::Simple

然後是怎麼轉換到 SQLite3 的問題。比較笨的作法是用 Perl 的 DBI 模組，然後實際開啟一個 SQLite3 資料庫，把轉換好的 $data 依欄位一個一個寫進去。

但是，這樣做，就實在太不懶惰了。SQLite3 的好處是，我們完全可以把資料生成另一堆生的 SQL 指令，然後讓 SQLite3 來吃。因為對 SQLite3 來說，一個資料庫就是一個檔案，所以萬一不高興，反正砍掉重練就是了。

所以，我們把煮成了 Perl hash 的資料一個個倒出來：

my $places=$data->{'place'};

for my $x (sort(keys(%$places))) {
    my $d = $places->{$x};

    print "INSERT INTO geoinfo (zh_name, en_name, lon, lat) VALUES (",
        sqlquote($d->{zh_name}), ", ",
        sqlquote($d->{en_name}), ", ",
        sqlquote($d->{lon}), ", ",
        sqlquote($d->{lat}), ");\\n";
}

也就是說呢，我們把資料 dump 成一條又一條的 SQL INSERT 指令。

那個 sqlquote 是一個小的函數，幫忙我們把字串加上 SQL 的 quote：

sub sqlquote {
    my $x=shift;
    $x =~ s/\\'/\\'\\'/g;
    return "'$x'";
}

然後，我們在倒資料前，先加上建立資料庫 schema 和 index 的指令：

print "CREATE TABLE geoinfo (zh_name, en_name, lon, lat);\\n";
print "CREATE INDEX idx_zh_name ON geoinfo (zh_name);\\n";
print "BEGIN;\\n";

並在最後加上

print "COMMIT;\\n";

之所以要用 SQL transaction 來做插入，是因為 SQLite 在 non-transaction insert 的表現慢得嚇死人。用了 BEGIN…COMMIT 之後大體上會瞬間完成所有 insert 的動作。

好了，這樣差不多了，只要再做點水管工（plumbing），我們就可以把 XML 檔案轉成 SQLite3 的 DB 了：

./gendb.pl source.xml | sqlite3 geoinfo.db

從這裡開始……

我們還沒談到去哪找地方放這些程式的問題，因此目前還不會有可以下載的地方。有了資料庫，我們就可以開始想想怎麼設計輸入法了。希望我很快就有時間來寫下一篇。

註解

1. T. C. Chiang, D. Liu, K. M. Liu, W. Z. Yang, P. T. Tan, M. J. Hsieh, T. H. Chang, W. L. Hsu, “OpenVanilla – A Non-Intrusive Plug-In Framework of Text Services”. 2005. (Abstract).

lukhnos :: Jun.29.2006 :: tekhnologia 技術或者藝術 :: 11 Comments »

這應該是 OpenVanilla 誕生到現在，在包裝上最花時間的一次。It’s finally here!

詳細的發布說明、取得方式及安裝說明──這一版請大家至少一定要讀一下「Ok，我到底該安裝哪套variant？」一節──請參考OpenVanilla 0.7.2的版本發布說明。

對了，這一次 0.7.2 正式版的推出，有一個要特別感謝的人：davidyu。因為他的耐心與鍥而不捨──或許也因為他的PowerBook特別搞怪（？）──我們終於得以克服0.7.2-beta以來一直很難再現（reproduce）的一個嚴重bug。雖然這一半是OS X的問題，但至少以這次的修正來說，以後應該不會再發生「需要靠砍神秘的 .plist 才能修復 OV」的奇怪情事了。再次謝謝他的熱心幫忙。

lukhnos :: Jun.25.2006 :: tekhnologia 技術或者藝術 :: Comments Off