OpenVanilla的捐款贊助活動，從2005年十月開始，也已經經歷快半年了。這半年來我們持續收到許多朋友的支持。本來我一直提醒自己一個月一定要更新一次捐款名單的，這兩個月先是因為工作，又有一些個人的事，竟然被擱到了一邊。跟大家說聲抱歉。
我們二月和三月都各收到一筆贊助款，在此再次謝謝大家的支持。捐款名單已經更新於OV的捐款贊助者名單，另外如果你有訂閱ov-develoepr這個mailing list，也會收到這份更新的名單。
lukhnos :: Mar.19.2006 :: tekhnologia 技術或者藝術 :: Comments Off
好幾年沒去參觀台北書展了。今年因為朋友邀約去晃了一圈，第一次有種感覺：書展不是為了大書商賣便宜書而存在的，而是為了那些平常在書店的地平面上不易看到的小出版社、另類出版社，或者是一些平常不在認知範圍外的知識領域。收獲：一本安德烈．布列東（André Breton，《超現實主義宣言》作者）的名作《娜嘉》（Nadja）中譯本（台北：行人，2003），還有認識一家名叫「集合」，專出女同志相關書籍的出版社（她們攤位掛滿彩虹旗，大概是整個書展最好認的攤位吧）。
這幾年因為有網路書店，再加上在書店買外文書的選擇也多，就沒有必要把書展當作是解決書渴的出口了（在很多很多年前的確是一個很重要的出口）。但是我慢慢相信，不管亞馬遜或阿嬤爽介面做得再好，仍然取代不了我們在實體空間跟書「遭遇」（encounter）的經驗──好比不管amazon.de做得再好，要對德文書有個全貌式（holistic）的感覺，還是應該要走進德國任何一家書店才行。那是一種整體感，而不只是早年電子商務流行時議者所談的「觸感」而已──當時很多人認為觸感是可以在技術進步下被取代的。
亞馬遜的介面及促銷話術確實越來越進步，「觸感」的替代方案也越來越多。當然更不用提諸於one-click buying這種技術，在消減、解決經濟學上所謂交易摩擦（transaction friction）、減少中介人轉手所做的貢獻。但是「空間」和「遭遇」是取代不了的。我們就算有30吋螢幕，我們仍然只是透過「窗口」在看世界。那和你走進一家有著挑高五層中庭的大書店，或是有著善本書香的小書店，所得到的全貌式感官經驗，還是有很大的不同。色聲香味觸法，眼耳鼻舌身意，加上走動的肢體經驗（甚至是疲倦），這些東西都得要走出窗口才能得到。或許要到了虛擬實境和可複製氣味的世界才可能解決「窗口」的問題，但到那時虛擬實境就不是虛擬的了。
「遭遇」又是另一回事。「遭遇」意味著見到自己喜歡的也見到自己不喜歡的，遇見自己想找的與自己意料之外從來沒想找過的，碰觸到自己熟悉的與自己完全陌生的。「遭遇」毋寧說是一種空間經驗，需要在空間當中才可能發生的事件。就這個意義上，書店與展場都是一種公共領域：一種各方折衝、碰撞的地方。
網路書店的問題是為了在最小的窗口上達到最大的銷售作用，必須要迎合購買人的喜好一路追下去，亞馬遜的資料海撈（data mining）技術是這種「在小窗口上只呈現你喜歡的東西」的代表。網路媒體這種「黨同伐異」的潛在問題很多年前也有無數人提過了。簡言之：網路是一種極化性（polarizing）的媒介，愛者更愛，恨者更恨，悲觀者認為網路很難真的擴展我們的視野或想像力，因為我們都只是被亞馬遜式的話術（在跨國資本主義的層次上）或「鄉民」的推文（在草根的層次上）不停地正增強我們的偏好而已。政治機能的網路化，或許很諷刺的代表現代性（公共空間）的結束，世界於是就再被「部落化」了（re-tribalize，麥克魯漢早在還沒有部落格的1960年代便如是說）。真實世界（有血有肉有同有異的世界）說不定還是得要從走出窗口才能開始。
還有一個關於展場的聯想（聯想──這或許也是遭遇性空間的質性之一）：
關於「市集」（bazaar）與「商展」（trade fair）的關係。如今想來這似乎是一個批評Eric S. Raymond（此處批評不是負面表述的批評而是作為一種重省式的critical thinking）不錯的起點？例如，他所採取的兩個意象（市集與大教堂），毋寧是相當中世紀、前現代的意象（以及關於俗民世界〔vernacular〕與階層的、菁英的、封閉的宗教體系的對比）。如果市集是前現代的「市場」典型（市集的確也是一種遭遇他者／異種／異地／異議／意想不到的地方），那麼，現代的「市集」對映物，又是什麼呢？會不會是「商展」、「交易所」（exchange）以及全景敞視的議院（panoptic council）？ESR的書成於1998年，以技術變革而論已經有如盤古時代的事了，我們對於open source的想像與隱喻，是否也需要升級了？
lukhnos :: Feb.09.2006 :: tekhnologia 技術或者藝術 :: 10 Comments »
外表上的變動不大：程式核心不變，架構上也沒有什麼革命，不若0.6到0.7時，API翻天覆地，加入了「輸出模組」這種新想法等等（API更動是OV是否能進一個大版本的依據）。不過，我自己覺得，就版本發表所做準備工作的份量，這可以算一個主要版本了。
先說功能上的變化好了，OpenVanilla從0.7.2版開始列名在「Unicode輸入法」中，在系統表列中再也不是歸類在「繁體中文輸入法」。這個變化的意義，既是象徵性的，也是實質上的：OpenVanilla有一定數量的簡體中文使用者，說不定還有其他語言的使用者（例如藏文、閩南語白話字等等），這一版也正式將UIM-Anthy日文輸入法支援給包裝進去了，再怎麼說來，OpenVanilla都不該只是「繁體中文」的輸入法架構。改列Unicode名下，既爭得面子，也有裡子：用Microsoft Word等會接收語系訊息的文書處理軟體，終於不會有字型亂換的情況了。
另一個重要的功能，自然是實驗性的「詞彙管理模組」。簡單說呢，這是一個「超越輸入法」或者「跨在輸入法上」的新模組。我們把這一類模組取了個抽象名詞，叫「鍵碼前置處理器」（key preprocessors）──是的，繼「輸出轉換模組」（output filter）之後，我們又在「輸入法」的設計理念上搞怪了。目前詞彙管理模組能做的事很簡單：記錄你打出的詞，將之存入資料庫。等你下次要用的時候，只要按下啟動模組的快鍵，敲進當時存入時聯結上的關鍵詞，噹噹，就可以叫出一大串字。這東西不依存在任何輸入法裡面，因此不管你打倉頡還是注音、五筆還是雙拼，都可以叫出這個管理模組來。更棒的是底層的資料庫是SQLite，因此你儘可對這資料庫做任何增刪動作，不一會兒轉到別的視窗，又可以輕鬆劈哩趴啦打出一串新加入的詞。詳細的使用方法，唔…… 我還要再找時間發表到#osxchat blog上。不過，有圖有真相，hlb已經幫我把想說的話給說了，大家就先去那邊看兩張圖（順便再幫他升升page rank？）吧。
其他像是修正錯誤、增加效能等等。不過，真正讓我覺得這陣子的工作，有如準備一個主要版本（major release），還是因為許多內在的工作。
像是重新整理程式碼、網站搬家、寫新文件、做軟體包裝等等。
本來兩週前，想趁每天工作的空檔，一一完成上面那些工作的。結果哪想得到竟然一做就是兩週，而且每一天都在跟做「工作」之間掙扎（就不說我還有兩個deadline要趕了）。實情是，每一件「重整」工作都龐大得不得了。
例如重新整理程式碼這事，先從為每個程式碼加上版權宣告的檔頭，還要問每個模組的作者要不要用這個或那個授權──是的，這實在是很「務虛」而不「務實」的事，可是我總認為這種抽象制度面層次的整理，畢竟還是有必要的。
又好比，OV的”build system”──也就是大家說的那個”make ; make install”的部份──也因為有一段時間了，需要加以整理和更新。有些目錄配置不太合宜的也該大幅搬動。目前的問題是因為檔案搬家幅度太大，Linux/FreeBSD/Windows版本想必是編不出來了。這一點可能要由關心以上兩種版本發展的朋友來接手了。
至於網站搬家和寫新文件，也同樣是龐大得不得了的事。從評估要用哪一套網站系統、測試安裝、熟悉、點點點（剛裝起來MediaWiki的繁體中文翻譯檔時，實在是…… 只能用「點點點」來形容），到後來的建置內容、搬家、比對，也都是相當花時間的事。
最後當然是「包裝」這件事最花時間。因為OS X的輸入法很特殊，每一次改完新版本、做好安裝包，就得先清掉自己系統內原來裝好的程式，重開機，然後測試安裝、重開機、測試結果…… 如果一切順利，那就可以轉到第二階段，用另一顆硬碟上裝的「空白」OS X開機、安裝、重開機、測試結果…… 其中免不了要看看檔案是不是裝對了，顯示的說明有沒有錯字（還得看英文、繁體中文、簡體中文三個版本）。
於是，因為這樣的過程，讓我開始對那些寫手冊、作網站、作包裝（installer）的人，開始佩服起來。我猜這些功夫大體上不脫一個「磨」字，不是主角，可是卻是把主角（軟體）推上桌面的重要陪襯或過場。
到最後呢，覺得每一件事情都有其收獲，像是網站搬家的事讓我對MediaWiki有多一些認識，至於包裝過程則是讓我發現原來OS X的磁碟映象檔（.dmg）裡還有這麼多花招或包裝時要注意的地方。
就這樣，這一階段的「新版發表工作」終於完成。其實我們2005年11月17日的時候，在mailing list上就覺得可以開始進行0.7.2版的工作了。實際情形是…… 兩者之間，有整整八週的距離啊。
我們網頁的家也搬完／「重新裝潢」好了，英文版網頁也有了個簡單的概要說明，捐款贊助活動也持續進行。希望大家都能繼續有好用的輸入法能用囉。
最後，最後：照過去的習慣，每次一有版本發佈，我都會有好幾天時間，不時盯一下OV新版有多少人download。不過讓我好奇的是，自從去年八月發佈0.7.1後，那個安裝套件竟然有超過6,400次下載…… 讓我非常好奇：到底有哪些人在用OpenVanilla呢？如果你有在用OpenVanilla、有在看我的blog，先前沒有在我的blog上留過言，又有興趣浮上水面的話，就，出個聲吧！
lukhnos :: Jan.19.2006 :: tekhnologia 技術或者藝術 :: 4 Comments »
近來為了在重整openvanilla.org wiki的內容，也同時順便survey了一下通行的幾套wiki系統。MediaWiki是Wikipedia的核心系統，最大的好處是具有相當成熟的多語系支援，包括了多語系的介面，以及許多配合多語系網站所需的功能（例如：在頁面左側，顯示這篇文章還有哪幾種語言的版本）。
我認為openvanilla.org至少必須要有三種語言版本：繁體中文、簡體中文，以及英文。事實上繁體中文又可分為台灣繁體中文及香港繁體中文，簡體中文以中國大陸為主，新加坡也有一些特殊用語。但以openvanilla.org的詞彙使用範圍，有繁體中文及簡體中文，應該就相當合用，英文版當然是為了非中文使用者的需要（例如不會講中文的藏文使用者、希望拿OpenVanilla拿協助歐語輸入的西方使用者，或是看英文較快的中文使用者等等）。延伸來看，做為一個從中文世界起源、而服務性質不限於中文使用者（也許姑且套用中國大陸的構句法，叫「具有面向世界的服務性質」），這樣一個網站，的確應該要至少有中文及英文兩種版本，而中文如果能支援繁體及簡體，自然是更貼心的。
如果我們暫且忽略Wikipedia過去在中文議題上採取的官方立場[1]，純粹就MediaWiki這套軟體而論，有很多技術上的設計的確有可取之處，例如自動詞彙轉換可以節省不少文章寫作及編輯校對的力氣。
但是，如果直接拿MediaWiki的正式安裝套件來用，就會發現，簡繁轉換功能，包括了在版面的導覽列上顯示「繁體版」與「簡體版」兩個tab，必須要在語系設為「中文」（zh）的情形下才能使用。而這裡的「中文」，hélas! 指的是「簡體中文」。再仔細往裡面的程式碼探，才更可以發現在物件組織上，程式也都是繞著簡體中文組織的，甚至包括內文以及搜尋的內部工作碼，也都是先轉成簡體中文進行的。
就我來看，這是個「程式碼反應組織意識型態」的案例研究。
回到務實層面，openvanilla.org的服務對象，最大宗者仍是繁體中文使用者，就比例原則而論，預設（而非「默認」或「缺省」）的語系設定及工作語言，包括內部資料編碼及搜尋，自然應該以繁體中文為主。而，就組織層面而論，MediaWiki的多語網站，是以「一個主要工作語言建一個網站」為原則來鋪設的。就此兩者，我們應該建立的是一個「具有繁簡轉換功能、但以繁體中文為主的中文網站」以及一個英文網站。就此目標來說，MediaWiki是令人稍微傷了點心。
當然幸好多拜MediaWiki有開放的程式碼，我們在此針對MediaWiki的繁體中文語系物件（定義於LanguageZh_tw.php）做修正，依循簡體版的作法，開啟語言轉換功能，並且將預設的內部工作語言改為繁體中文。為了方便，這次的修正暫時省去了香港與新加坡的體例（variants）。如果使用者選用了簡體中文作為預設顯示介面及工作介面，簡體中文也一樣具有繁簡轉換功能，這點是沒有改變的。
我們順便修正了MediaWiki繁體中文語系檔中，一些與台灣使用習慣差異過大的詞，例如「登錄、退出」改為「登入（或註冊）、登出」，「文件、文檔」一律改為「檔案」，「電郵」展開為「電子郵件」等等。更進一步的修正有賴大家共同雞蛋裡挑骨，至於程式碼的部份則也許有必要再多修正（主要是更改物件繼承及原始碼相依賴結構）──原先的程式碼中，LanguageZh.php（繼承自LanguageZh_cn.php）將LanguageZh_tw.php視為下屬（subordinate）、被引入（include）的對象，我們這版修正中則讓LanguageZh_tw.php引入LanguageZh.php，使得LanguageZh_tw.php成為繼承結構的終端點。
以上所提及的種種修正，都可以從從這裡取得。安裝方法是：
以上的修正檔會不定時更新。我們已在諸如OpenFoundry開設計劃網頁，以來公開發佈這份修正檔（可用svn取得所有修正檔原始碼）。我們也針對詞彙的部份，到MediaWiki的Bugzilla回報系統裡，做了初步的修正建議。
至於新版的openvanilla.org，將在裝潢階段告一段落後開張。:)
本地化工作（localization; l10n）沒有許多眼珠盯著，就不可能有所做為。感謝以下朋友：pcchen (for MediaWiki), hlb (for terms and testing), Jedi (terms), mjhsieh (for his hawk eyes)。
lukhnos :: Jan.15.2006 :: tekhnologia 技術或者藝術 :: 2 Comments »
2005/12/31舉行的FSCI 2在跨年聲中圓滿結束。OpenVanilla這次出了四個講題。我負責的兩個講題，投影片可由這裡取得：如何應用及部署 OpenVanilla 個別的輸入法模組以及 OpenVanilla Linux Loader移植過程簡介，都是PDF格式。要說明的是，這兩份投影片都是以配合講者口白而做的，平均播放速度是3-5秒一張，所以其實並不是給人看來得到資訊的啦。
三句話的心得報告：(1) gcin某種近似monolithic的架構，在快速增加core feature上有優勢（plug-in架構是增加模組有優勢，但core feature就不見得了）；(2) 試用了Arne Götje（高盛華）製作的台灣閩南語（Holo）字型及他帶的台語注音輸入法計劃，相當有意思──我們當天將資料轉成了OV能用的.cin格式，但因為該輸入法有特殊需要，所以還是得找個時間來寫點code；(3) bluebat講倉頡輸入法演變，投影片上的「倉頡」拼成 CangJei，讓我有一種所謂什麼不孤必有什麼鄰的感覺。XD
lukhnos :: Jan.05.2006 :: tekhnologia 技術或者藝術 :: 9 Comments »
TOSSUG（台北開放原始碼軟體使用者社群，a.k.a. 「土虱」）在今年（2005）年末，要舉辦「第二次中文輸入自由軟體工作坊」（連結），OpenVanilla團隊也有成員應邀出席，主要有移植OV-IME（Windows版的OV）kanru及pcman（同時也是Windows版酷音輸入法的移植者）以及我。pcman將講解「Windows IME簡介」一題，kanru則講述「OpenVanilla 的 win32 移植」。
除此之外FSCI 2還有許多中文處理相關的講題。歡迎對此一議題有興趣（在這裡，尤其是對 OV/中文輸入法開發有興趣）的朋友共襄盛舉。
我將要講的兩個講題如下，一場主打，一場代打：
OpenVanilla自2004年年底推出以來，已經成為許多Mac OS X使用者不可或缺的套件──包括台灣、香港，甚至中國大陸都有使用者。2005年OV也推出了與SCIM的橋接套件，讓OV許多輸入法模組也能初步在SCIM上使用。另外OV也有了 Windows上的初步移植，這部份會由kanru來為我們介紹。
目前看來，OV對Linux/FreeBSD使用者的最大價值，其實不在於做為一個取代 xcin/gcin/SCIM等「輸入法框架」的計劃（這不是OV的priority），反而是希望能提供一些xcin/gcin/SCIM支援未臻理想的輸入法，例如：行列、POJ，或是SQLite-based的泛用輸入法模組等等。
其實，因為OV的設計，個別輸入法模組的獨立性相當高，也可以個別拿出來部署（deploy）使用──OV的Windows實驗，也是在這樣易於部署的設計下誕生的。也就是說，OV的價值毋寧是，提供了一些經過使用者測試、完整度相當高的個別輸入法模組。
因此，這一次的講題，我將主要介紹「怎麼去使用單一的輸入法模組」：使用模組的人需要提供或實作哪些介面──其實說穿了就是如何實作OpenVanilla.h裡定義的抽象類別（abstract classes）──以及有哪些需要注意的地方。希望經由這次的介紹，能讓更多好用的輸入法模組，普及於更多平台或框架上。
這是我代打的講題。OV 的 Linux Loader 其實嚴格說來是一個 SCIM 的輸入法模組，這個輸入法模組負責去載入 OV 的其他輸入法模組。最早的 OV-SCIM bridge 是從 scim-chewing 「借殼上市」而來的，後來經過 vgod 的努力研究 autotools，而後有了初步可用的 OV-SCIM，後來更有 Debian package 跟 RPM 的出現。
這次講題我會簡單介紹這個「借殼上市」的過程，為何挑選 SCIM 當 bridge 對象，以及 vgod 設計的 OV-SCIM bridge 是怎麼構成的。我會同時利用這個講題，來介紹組成 OV 兩大部份的另一部份──platform-dependent loader（另一部份是上一個講題的 platform-independent modules/IM algorithms）。由於 OV-SCIM 只算是初步的版本，還有兩個很大的部份未實作出來（configuration management以及encoding conversion service），因此 OV-SCIM 目前只能滿足諸如行列及 POJ 使用者的需求。OV 是否能在Linux/FreeBSD 上有後續的發展，端看是否有朋友願意從事這三個領域的工作：(1) 繼續開發 OV-SCIM 或是 (2) 為 OV 尋找新的 bridge 對象，以及 (3) 根基於 (1) 或 (2) 的結果去維護 package（這其實是件相當花時間、相當重要、貢獻絕不亞於程式源頭開發者的工作──deployment）
（P.S. 如果 OV 講題還有時間，lukhnos 會示範〔可能會〕在 OV 0.7.2 出現的「詞彙管理模組」第一版──一個跨越輸入法的詞彙輸入模組。Well, it’s NewYearsEvesEasterEgg. :p）
lukhnos :: Dec.29.2005 :: tekhnologia 技術或者藝術 :: Comments Off
才正好在整裡家裡的時候，就看到了 tseching 的這篇文章。說來很感慨，當年為了追隨別人的流行，為了一個 “me too”，先是幫家人買了 MD，隔了一年又終於有了自己的 CD player。我其實已經距離這樣的流行很遙遠很遙遠──所有 Sony 早幾代的播放器，我全沒趕上也全不在乎，怎麼會後來竟變成了一個盲目追隨那 “me too” 「我也想要」這樣的人呢？
總之當時也花了一些錢，買了一個完全是封閉標準的東西（MD，以及 Sony 的 CD-MD player 的資料傳輸光纖）。我從來都不是把音樂帶著走的人，更不用說工作時其實很習慣於完全的安靜。因此到了研究所還模仿別人的街頭風，只招得不倫不類的自我評價。更何況機器一下就壞了，維修費貴得嚇人。兩台 player 都壞了之後，那些當初辛苦轉錄的 MD 片有如廢物，封閉標準為害至深，莫此為甚。雖然，我看看家裡還有更多 Betamax 時代的東西，更是只能苦笑。
都說時代浪潮不留情，但是至少在 MP3 的大浪這件事，我還是很盲目地附和商業雜誌的說法：Sony 沒有擁抱開放標準，大概是這十年來最致命的策略錯誤了。
lukhnos :: Oct.25.2005 :: tekhnologia 技術或者藝術 :: 2 Comments »
2004年10月23日是 OpenVanilla 的誕生日。那一天傍晚，gugod 和 zonble 問我，要不要把當時還在改寫中的 CarbonInputMethod 帶去多鬆裡看看狀況。我大約是晚餐時間過去的。大約在那之前兩週，我給 gugod 還有 zonble 看了那時在進行的改寫計劃。那是自我開始做「香草輸入法」後便一直覺得要完成的：把 Mac OS X 輸入法元件底層的程式碼給整理起來，變成一個獨立的底層元件，好在上面建立一個通用的框架，可以容納其他的輸入法。
之所以會有這個想法，一開始是因為酷音輸入法的 OS X 版以及香草輸入法的注音、倉頡及簡易模組，這三者間都共同用到同一份程式碼──也就是從 Apple 的 BasicInputMethod (BIM) 所改寫成的輸入法底層──因此我總覺得，應該有一個方法，可以把這幾個輸入法整合起來。
那時候也因為工作的關係，開始接觸 UNIX 界的亞洲文字輸入問題。當時稍稍對大家都在討論的 IIIMF 做了點瞭解，發現相當難以上手──當時我對 X-Window 瞭解有限，而且覺得 IIIMF 網站和文件都沒有一個很清楚的起點。而且以「跨平台」、「寫一次可以在所有平台上執行」為設計目的的 IIIMF，終究說來，仍然是一個以 X-Window 為起點所設計出來的架構。我當時單純地覺得，做為 OS X 的使用者，我比較急切想要看到的，是一個為 OS X 快速增添新輸入法的管道。因為 OS X 的架構和 X-Window 差很多，走「把 IIIMF 移植到 OS X」上這條路，遠遠超過我的能力範圍，於是打算從我已知的輸入法需求出發，設計一套自己需要的架構。
於是從「香草輸入法」於八月底加入倉頡、簡易兩個模組之後，中間有快兩個月的時間，都在構思這樣的一套架構，也就是後來的 OpenVanilla.h 。同一時間在進行的就是上面說的 CarbonInputMethod ，也就是 OS X 的輸入法底層。我很久沒寫程式，很多新的、或是早成慣例的程式寫作方式，都不是很熟悉。像是 OV 的關鍵之一，也就是要能動態載入程式庫，這樣一件事，我在八月底時還完全沒有概念，不知道該怎麼做、該叫用哪些程式庫，OS X 又會以什麼方式載入這些程式庫、怎麼配置程式庫的程式及資料段空間等等。又因為那時有了新工作，有很多事務要處理，這兩個部份的工作就緩步進行。偶爾，我在和 Autrijus 或 gugod 喝咖啡時，會提起最近的狀況（那時 Autrijus 非常關心這件事的進度，因為 OS X 上一直沒有他合用的大易輸入法），他們也看過幾次進行中的 OpenVanilla.h：九月底有一天 Autrijus 還在新生南路的星巴克咖啡裡大砍其中的贅碼。OpenVanilla 一直到 0.6.x 之前的 API 幾乎就是在那一天確立的。
然後到了把 OpenVanilla.h 以及 CarbonInputMethod 組合在一起的時候。這就是2004年10月23日那天晚上發生的事情。gugod那一天就開始了酷音輸入法的移植工作，zonble開始找「香草」的icon，而我則一直在實驗能否真的藉由dyld程式庫把輸入法模組動態載進來。晚上九點，第一個「測試輸入法」能動了：一個按a鍵出a字，按b鍵出選字窗的「無用」輸入法。gugod立刻叫我把現有的程式通通儲放進version control system中──而我當時連svn都還不會使用！就這樣，我上了一個晚上的subversion crash course，gugod 建立了 OV 的標準組立（build）程序。OpenVanilla 於當天誕生。
2004年10月25日，我們在 OpenFoundry 上丟出第一個 OV 的載入器及輸入法模組：大易輸入法。一開始因為我們沒有人知道 Objective-C 寫成的程式庫，在動態載入時有一些細節要處理，所以花了將近兩週的時間在研究各種除錯的方法。那是段臭蟲抓不完的時間。OpenVanilla.h 很多小地方要更動。我因為不熟悉版本管理，經常忘記送出某個檔案…… 混亂的時期一直到了十一月中，那時我們已經有了第二套輸入法：POJ。然後是一段密集的工作時期，開始做泛用輸入法（當時還稱作 “Xcin 模組”），我們開始有了可以真正載入多套輸入法的 Loader ，開始陸續有朋友開始試用下載這套軟體，然後有更多的 bug report 進來……
以後的故事，大家都知道了。我們在 ICOS 2004 上有了一次很漂亮的 demo，我們在 2005 年的 1 月 19 日推出了當時最穩定的 0.6.3 版，這個版本一直到 0.7.0rc3 出來前，只經歷過少數的錯誤修正。我們有了完整的使用手冊，那時的成員有我、gugod、zonble、b6s、pcchen 還有 mjhsieh。
後來我辭掉了工作，在家當起 freelancer。一段相當疑惑和混亂的日子。OV 好像已經很不錯了，但還可以更好些。CarbonInputMethod 一直有一些沒有解決的老問題。OpenVanilla.h 還可以設計得再精簡些。但是沒想到開始做 freelancing 之後反而更沒有時間去照顧程式。我心裡面總是想著：一定要把 OV 再往前推一個主要版本的。一定要讓 OV 有自己的生命…… 讓更多人可以瞭解、維護這些程式碼。
OV 0.7.0rc3 是在2005年5月19日推出的，與 0.6.3 整整相隔了四個月。0.7.0rc3 到 0.7.0rc5 是一段相當痛苦的歷程：因為 Loader 改用了 Cocoa 程式庫撰寫，初期穩定度相當差。那時每天醒來都擔心會不會有可怕的 bug report 跑進來，尤其正好那時同時遇到 OS X 從 10.3 過渡到 10.4，libchewing（酷音輸入法模組的主程式庫）也從 0.2.5 過渡到 0.2.6 。因為有太多不穩定的狀況，我曾經有很長一段時間覺得：OV 往前推進到 0.7.x 是一大錯誤。也許我早早就應該停止再繼續做任何事情的。
一直到 2005 年 8 月 12 日，也就是 0.7.0rc5 推出兩個半月後，我們才終於有了 OV 0.7.1。至此算是擺脫了 “rc = repeated crash” 的惡夢。在這段期間裡，vgod 加入了 committer 的行列（而且他主要做的真的是 OV 的行列模組），
vgod 的另一個貢獻，是做到了 OV 與 SCIM 這個輸入法框架上的橋接（bridging）。 我曾經認為 OV 與 SCIM 之間應該有一個還不錯的合作的可能，但是中間有蠻多複雜的議題，我發現我的時間不足，無法一一深入去瞭解。另一方面，SCIM 的成員可能也一直誤解了 OS X 的特殊性：確實 OS X 上面可以執行 X-Window 環境，那麼將 SCIM 「移植」到 OS X 的 X-Window 上，所涉及的主要是如何滿足 SCIM 的編譯依賴套件（dependency）──一個需要佈建（deployment）高手來解決的問題，因為 SCIM 依賴數量龐大、以 gtk 為主的模組。至於，在 OS X 的原生環境上製作輸入法，那就完全跟 X-Window 是兩回事。曾經有一回，SCIM mailing list 上有成員用英文問我：「等你們完成 OV 與 SCIM 的橋接，你們何時會把 OV 改用 SCIM 的核心？」瞠目結舌之餘，我想這中間大概是出了什麼誤會吧。
後來隨著 kanru 和 pcman 的加入，先前一直在討論的一個議題──關於 OV 有沒有可能移植到 Windows 上──也出現了曙光。或者，客觀地說，挑戰毋寧在「有沒有可能讓 Windows 上的輸入法開發變得更容易」上面。OVIME（Windows 版的 OV）開發速度之快令人驚訝。我在這一段時間正好在外到處旅行，手邊沒有任何 Windows 機器可供測試。看著 OV version control repository 每天都有新的進展，感覺還是蠻特別的：this is an on-going project with a new direction.
其實，從當初只是為了「抓自己的癢」（scratching my own itch），到後來起心動念，想弄一個「可容納多種輸入法的架構」，有時候還是會自問：這其中是不是有任何浮華的意念在推使著？雖然中文輸入法（或輸入法本身）似乎總還有很多很多問題要解決，但大家日常生活不也已經還算使用得平順了？
或者就只是，我已經抓了太多超過自己的癢：OV 帶給我私人的便利，還是那當初寫「香草注音」時的倚天排列選字注音輸入法──一個讓我至今仍然能平順地在 OS X 上從事日常工作的重要基礎。我從開發 OV 的過程中學到非常、非常多，甚至毋寧說所有我「補修」的軟體開發知識，都是因為有了 OV 這樣的計劃才學到的。寫程式畢竟還是一件很快樂的事。而跟一大堆人一起 hack 的經驗：無價。
這一年來我寫了很多很多的 release notes 和一些這樣的心得感想。Autrijus 有一次曾經笑我：「lukhnos 寫一行程式，可以寫兩行感想」。我覺得對於 OV ，我已經開始在重覆老套，越來越像一個喜歡憶往事、卻還想為之決定方向的囉唆的人了。我想我該寫到這裡。It’s the time to pass the baton.
lukhnos :: Oct.05.2005 :: tekhnologia 技術或者藝術 :: 1 Comment »
417 is the number of the distictive syllables, discouting tonal differences, in the Mandarin spoken in Taiwan. 1323 if tones are counted.
What is with these two numbers?
I learned how to use Hanyu Pinyin many years ago. Way before Taiwan got trapped in the Romanization polemics. Since then I have been aware of the influences of Romanization systems upon the language we speak and write. On the other hand, Hanyu Pinyu has many upsides. Once mastered, reference books by Hong Kong and Mainland Chinese editors become instantly accessible: idiom dictionary, Chinese-English, Chinois-français, Chinesisch-Deutsch… all indexed with Pinyin. I also got the idea how I should index my Chinese documents, and even my address book got sorted that way.
lukhnos :: May.24.2005 :: tekhnologia 技術或者藝術 :: 2 Comments »
在台灣講的國語，如果不計聲調，一共有417種音節組合。如果計聲調的話，則一共有1323種。
為什麼會突然提到這兩個數字？
我在很多年前就學會了漢語拼音，那是早在台灣大開拼音論戰之前的事了。我從那時候就意識到了拼音的模樣對於語言的影響，卻也同時知道學會漢語拼音的好處：許多香港及中國大陸編的工具書，成語詞典、漢英、漢法、漢德詞典…… 一瞬間變得好用起來。自己的中文資料需要編目的時候也馬上有了現成的索引依據，甚至連地址簿要怎麼排序都有了解法。
也許因為自己很早學會漢語拼音，我對於台灣的拼音論戰，其實是很早就選邊站的（雖然因為當局者的關係，通用拼音似乎是贏得實質勝利了）。唯一一次被動搖，是台大的江文瑜老師說：拼音就跟文字一樣，看拼音的長相就知道這是哪個地方。我忘了她確實怎麼講，也忘了出處。但這句話確實是打動我的。只是，hélas，對我來說，真正能代表台灣，讓人一眼就看得出來你是台灣來的拼音名，既不是通用，更不是亂七八糟的國語羅馬字、注音二式，而是，洋人發明的、從來沒有人搞得清楚 t t’ 差別的，威妥瑪……
（請比較唐太宗：T’ang T’ai-tsung 跟當歸湯 Tang-kuei soup 的 T 的差別。）
拼音論戰討厭的地方是會被跟政治立場劃上關係。當然我完全可以理解「通用派」或至少是「反漢語派」（如果這個集合減去通用派，還不是空集合的話）的專家學者們，以文化論述或「拼音也是一種表意文字／圖象符號」的觀點，佐以身份主體性與差異性等論述，來強調台灣要有自己拼音系統的理由。不過，就像大家都認識的積丹尼（Dan Jacobson），說過一句大家都聽過的話：「我支持台灣獨立，但拜託請用漢語拼音」（引他的話並不代表我支持或不支持「苔灣都立」）。可惜漢語拼音已經貼滿了顏色，有時我也覺得好端端的 Chien-kuo South Road （或是某個同名中學）如果改成了 Jianguo South Road ，怎麼感覺就是怪怪的，更不用說 Zhongshan South Road 或 Zhongxiao East Road 了（至於那種「半漢語、半通用」──據說主要是通用，讓通用在我心中扣了相當多分──類似 Microsoft Windows API 或 Wiki/CamelCase 命名式的拼法，像是 ZhongXiao East Road 或 ZhongShan North Road ，則是愚蠢至極點──這些學者教授都不知道漢語拼音有斷字規則，對於 Xi’an 這樣可能造成模糊的字也有斷點的嗎？！）。可能只是因為從小看慣了，鄉愁使然吧。如果萬一哪天台北變成了 Taibei ，高雄變成了 Gaoxiong ，我一定會有那種亞爾薩斯人一夕之間變成得講德語的恥辱和憎惡感。那麼威妥瑪到底招誰惹誰了（Taipei和Kaohsiung都是威妥瑪式拼法）？神奇的是，「漢語派」和「通用派」竟然有共同的敵人，那就是這個由清末洋使節和語言學家（「漢學家」）所設計的拼音系統。我還記得同樣是台大老師的廖咸浩曾經在《中國時報》論壇上寫說，威妥瑪太浪費字母了，擺著 b, d, g 不用，而且許多音律不合中文習慣。威妥瑪浪費字母的問題是大家都知道的，但是廖老師大概把外文系的語言學概論給忘了，其實中文的「得」的確不是歐語的 d ，再說那堆 apostrophe 並沒那麼礙眼，說不定還蠻有異國或甚至「東方（主義）」情調的（例如荷蘭文以 apostrophe 開頭的地名，或是希伯來文／阿拉伯文的拉丁轉寫等等）。
我扯遠了。在守著不合時宜的威妥瑪，以及使用著政治不正確的漢語拼音的同時，我其實是有機會就跟人家傳傳教，說這兩種拼音的優點各是如何等等。「漢語拼音的好處之一，」我常說，「就是它幾乎和注音符號一對一對應」。
說是這樣說，但我其實從來沒有真的驗證過這個說法。我只知道除了把ㄅ換成b、ㄆ換成p，然後有少數的規則要記（例如 liou → liu）。由於每次「傳教」的時間都不長（通常旁人只是希望你趕快幫她／他把名字或地址翻成拼音，然後就去忙別的事了），我也從來沒機會窮舉這些規則。這其實不是一件好事：傳教的人怎麼可以不對自己的信仰，做一番徹頭徹尾的檢驗呢？這種東西就跟沒有自己做過一遍證明，就把命題當定理，一樣是很危險的事。
於是，心血來潮，來寫個「注音符號轉漢語拼音」的程式。
軟體工程這一門，其實是很忌諱「重新發明輪子」這回事的。當然，換個方式想，「重新發明輪子」或許是把事情搞懂、搞通、搞爛最好的方式之一。通常做過幾次之後，就會對造輪子的人充滿敬意（我因此對設計 GUI、開發文書處理軟體、草擬程式語言文法以及會做日式蛋包飯的人充滿敬意，這些當然是我以血淚換來的教訓）。當然也有像 Hacker’s Dictionary 說所謂 “toolsmith” 之流的人，專門以重新發明輪子為樂，而且「要重新發明就發明個最棒」的。兩個月前我參加了某場程式設計的集會，就聽過這樣一個強者如是說。這個人叫 Brian Ingerson (Ingy) ，Kwiki 的發明人。他自我剖析說：”My weakness? … I reinvent everything. My strength? … I reinvent everything.”
不過我的「注音符號轉漢語拼音」純粹只是個像學生做證明題般的必經之路而已。網路上能夠查的表一大堆（據說）。幹嘛花這個力氣？
還是那句老話：為了檢驗自己所說「漢語拼音和ㄅㄆㄇㄈ幾乎是一對一對應」的命題。
經過了一陣子（reads: 一個不眠的晚上）的努力，發現事實沒那麼單純，先說結論好了。如果你要把注音符號轉成漢語拼音，請照以下的步驟進行：
首先，請先將每一個注音符號，直接依下列對照表一一代換：
（ㄜ跟ㄝ竟然都轉成 e ？沒錯，由於ㄜ跟ㄝ是互斥對──沒有ㄧㄜ，ㄝ只出現在ㄧㄝ的組合──因此沒有衝突的可能。）
接著，有一些縮寫規則：
最後是在上述規則轉換後，剩下來的特例：
最後，漢語拼音對於ㄩ這個音，其實是設計了 “ü” 的寫法（想來應該是從德文的 ü ─ “u umlaut” 來的）。然而會衝突的只有兩個組合，nu 和 nü（努和女）、lu 和 lü （盧和呂）。因此在最後一個階段，我們把所有剩下除了 nü 和 lü 之外的 ü 換成 u 。如果是做輸入法，則 nü 和 lü 有各種處理方法，例如 Mac 和 Windows 的簡體中文是用 v （一個漢語拼音沒用到的字母）這個鍵來輸入 ü。理論上，依照簡體中文多半是以智慧選字的拼音輸入方式，在有上下文的情況下，打 nu/lu 應該還是可以分辨這是 u 還是 ü 的。例如 nuxing→女性，luren→路人（而不是「綠人」）等。
以上的規則都寫在這個目錄裡所附的 bpmf-to-pinyin.pl 裡了。有興趣一試的朋友，可以把 bpmf-list.txt 倒進這個程式裡（perl bpmf-to-pinyin.pl < bpmf-list.txt），這個程式便會產生一列三行的輸出：第一行是拼音、第二行是注音符號、第三行則是所謂「標準排列鍵盤」的鍵碼。最後這東西對做輸入法是很有用的，有在台灣打過注音的朋友應該一看就知道我在說什麼，例如「ㄓㄨˋ」的鍵碼是 5j4 ，這樣的東西。
上面便是注音符號轉拼音的規則。至於拼音能不能利用規則倒施，來轉回注音符號，我就沒試過了。
可是，這跟一開頭說的 417 個音節組合，有什麼關係？
這個數字，是在驗證以上轉換規則的過程中，意外得到的。
為了要驗證以上規則是否正確（更誠實地說，其實是為了看看還漏了哪些規則，邊驗證邊補齊），我找來了台灣通行的「注音輸入法」的 Xcin 資料表格：phone.cin （下載 OpenVanilla 傳統注音輸入法模組所使用的 UTF-8 版，改名為 bpmf.cin），以及同樣屬 Xcin 計劃的「簡體拼音輸入法」資料表格 pinyin.cin （下載 OpenVanilla 計劃收錄的、含五萬條詞庫的 UTF-8 版），看看把 phone.cin 所有的注音符號轉過去拼音，是否能對應到 pinyin.cin 的拼音表列中。
這樣的工作，要是以前對我來說，是完全不能想像的苦工。現在有了 Perl 跟 SQLite 等工具，計算是否有漏字，是否正確一對一對映、是否有重覆衝碼等問題，就變成只是動動手寫一兩行程式或一兩句 SQL 指令的事情了。經過一些驗證，以上的規則，確實可以正確地把注音符號，轉成漢語拼音，完全不需要查表。有趣的是，phone.cin 當中，這些國語裡有的字和音，是 pinyin.cin 檔案所沒有的，這並不代表這些字不在台灣不是這樣唸，僅僅代表 pinyin.cin 沒有而已：
繁體中文的 phone.cin 一共有 14143 條目，扣除重覆字（破音字）則一共有 13097 字，再扣除三十七個注音符號仍有 13060 字。最早的 Big-5 內碼中文一共造 13053 字，也就是說 phone.cin 一共多了七個字，果不其然：「碁、銹、裏、墻、恒、粧、嫺」，全都是最早的 Big-5 裡所沒有的字（想來真是不可思議）。
至於 pinyin.cin 部份，扣除雙字（含）以上的詞，一共有 7300 條，6769 個字，397 種不同的音節組合。扣掉 pinyin.cin 的兩個快鍵，總共是 395 個組合。而 phone.cin 扣除 22 個 phone.cin 裡才有的字音（以上的例外，加上幾個注音符號──漢語拼音是沒有注音符號的音碼的），正好也是 395 個組合。再作兩個集合的比對，果然證實了這個轉換規則是有效且正確的。
一路做下來，算是解答了許多自己多年來的疑惑（「注音輸入法所涵括的台灣用國語裡，到底有多少個 distinctive syllable」是其中之一」）。說真的，這些都要拜工具之賜，還有最重要的，是公開的資料表格。
說來有點荒唐也有點慚愧。我竟然是大約到去年快當完兵，有一次意外地在 google 上搜忘記跟什麼有關的東西，才知道原來 Xcin 計劃一直一直是有公開的資料表格，而且排列順序和我所熟悉的倚天中文及 Windows 注音輸入法是一致的（在此之前，我對於 X-Window 上的中文輸入法，印象僅僅及於大學時代計算機中心 Sun 工作站上的 cxterm）。我的浦島太郎時代大抵如是。
倒是，還記得更早之前，MS-DOS 的時代，寫個「不進中文系統也能顯示中文」的程式，好像挺厲害的。這件事後來變得誰都會做，也就不足為奇，於是難度提高為「不進中文系統也能輸入中文」，這就有點看頭了。我還記得那個時候有一位高中學長弄了一套很炫的 GUI ，連繪圖驅動程式都是自己用組合語言寫的。尤其是「能夠輸入中文」這件事，很是令人稱奇。我記得我曾經問他，能不能跟他要這一份程式碼（後來則是問能不能要驅動程式）。或許因為是學長要拿來賺錢的程式，或者是因為學長認為我從來都沒懂過組合語言（也沒表現過「想學組合語言」所必要的虛心或誠意）吧，這件事情從來就沒有下文。那時還不時興 open source ，少數像《倚天中文技術手冊》又寫得語焉不詳（可能是我那時沒學過資料結構，當然於我讀來如希臘文──it’s all Greek to me）。早年的羨慕只能歸羨慕。
沒想到，好死不死，後來換到了 Mac OS X 上工作，竟然又被我撞上一個同樣是超過十年的想望：想要在 Mac 上用倚天排列的注音輸入法來輸入中文。我差不多同樣在那個羨慕學長的年紀就知道 Mac 的中文不會合我用，沒想到多年後竟然還是回到了這個點上。不過這一次，我知道了 Xcin 有資料表格（多虧退伍前某次放假的 google 意外）、有 gugod, zonble 那時在天天討論的 OS X 版酷音，還有 Apple 自己提供的輸入法範例──更不用說 OS X 買來就附開發工具、開發手冊這種事了。雖然 Mac 剛入手時中文輸入不太順，感覺很幹，但是想想似乎能夠靠著這些公開的資料和公開的程式碼，自己動動手來「重新發明輪子」，這樣的感覺還是蠻幸福的。若是在 Windows 上，我大概就完全無法想像要怎麼辦了（雖然幸虧 Windows 自始至終都有倚天排列的傳統注音）。
如果沒有 open source ，就是此路不通，有緣再相會了。
後來竟然就這樣一路跟朋友們做了下去，變出了一個規模不算小、有正式包裝、有 build scripts 、有 .PDF 文件、有朋友繪製的美美的 icon 、有偏好設定程式的計劃。倒是當我用程式求出 417 這個數字的那一片刻，我突然有種感覺：這陣子的狂寫程式，無非不是在把自己那段浦島太郎歲月所該寫而沒寫、該求知而未求知、該解決而沒解決的問題，給一一償還付清。原來當時的許多疑惑以及起心動念，竟然可以延續如此長長久久的一段時間，一直到現在才有那樣的時間、精力（讓我好奇過去的時間是被用到哪去了），還有勉強算是終於學會的一些能力，而得以如願。於是繞了那麼一大圈之後，我又回到了當初起了好奇心時的那個原點。T. S. 艾略特的詩：「我的開始中有我的終點」（In my beginning is my end），我突然想到那樣的一句話。
如此說起來，似乎也挺不錯的。至於這之後又能夠做些什麼，那都是好好睡一覺然後再說的事了。
lukhnos :: May.24.2005 :: tekhnologia 技術或者藝術 :: 17 Comments »