從Chrasis談手寫辨識引擎在移動裝置的機會

Gentoo Taiwan的Palatis日前公開他發展中的手寫辨識引擎與訓練程式，可參考blog文章「Chrasis 0.1.0 alpha!」，專案發展紀錄可參考「 Chrasis - Chinese Handwriting Recognition As-Is」，正如版本號所宣示的，現在還有很大的改進空間，不過已經初步可運作，以下是其訓練手寫辨識程式的執行畫面：
程式碼可透過Subversion存取：

# svn co svn://svn.berlios.de/chrasis/Engine/libchrasis/trunk libchrasis
# svn co svn://svn.berlios.de/chrasis/Linux/ChrasisTrainer/trunk ChrasisTrainer

libchrasis為手寫辨識引擎，其相依性有： (以Ubuntu 7.04為例)

• libxml++2.6-dev
• libsqlite3-dev
• sqlite3
• libboost-dev

ChrasisTrainer顧名思義就是訓練程式，以Gtk+打造，其相依性如下：

• libgtkmm-2.4-dev
• llibxml++-2.6-dev

測試了幾個簡單的中文字，都能正確辨識，算是不錯了。當然，手寫辨識的議題很複雜，以下是筆者在wiki - ChineseInformationProcessing的「手寫輸入」段落紀錄的部份資訊l：

• Kanji Pad - Japanese Handwriting recognition http://www.gtk.org/~otaylor/kanjipad/
• Kanji Pad 的新網頁 (演算法不變，新增 GTK2 的移植) http://fishsoup.net/software/kanjipad/

以下為 rabit 的個人見解 (Modified by User:jserv)：

• KanjiPad 本身使用的辨識方法是很簡單的字典法，當使用者透過手寫版或滑鼠寫出字時，程式辨識出筆劃種類，並紀錄每個筆劃的順序，然後根據字典查出候選字。也因此，KanjiPad 根本不考慮寫出來的字形貌是否相似，只求筆劃順序相符。

• 以 Cinput (修改自 Kanji Pad) 的圖為例，「林」這個字辨識出來的候選字有「林、杯、枝、板、茂」，這幾個字右半邊的「木、不、支、反」筆劃順序都是跟「木」是相似的。這樣的演算法辨識 率是不高的，一但筆順不對，就很難辨識出來，不過話說回來，也不能太苛求 KanjiPad，因為它原本的用途就是日本人寫來學習漢字用的，可以說本來就是當作字典使用。
• 中文手寫辨識是難度相當高的, 困難的地方有二：
  • 就技術而言，在辨識方面會用到許多數學模型，如 Baysian Decision Theory hidden Markov models、類神經網路等，而辨識中文還必須對中文字作分析，找出每個中文字的特徵 (筆形、筆順等)，若要更精準，需拆解中文字成基本的部件，來作分析 (有點像漢字跡因工程)，這時就要處理寫字上連筆的問題，技術上有實現的複雜度，但或許還不是最困難的。
  • 必須對每一個字的分析，建立資料庫，這是需要大量的成本 (包含時間、人力等)，中文字尤其複雜，除了大量的漢字，還有異體字、罕用字等，我想這對 open source 是最困難之處，這跟 open source license 中文字型的狀況有些類似。

看似這是NP-Hard的問題，但如果我們思考Mobile 2.0對我們的衝擊，可以發現，大多數的手持裝置都需要手寫、筆跡、觸碰軌跡辨識的技術，而且也依賴原本在桌面系統的軟體元件與操作習慣，此時，危機反而就是轉機。具體來說，我們可思考「新酷音」一類智慧型輸入法如何移植到手持式裝置如PDA或SmartPhone一類的裝置，基本上，運算速度與儲存裝置都不是大問題 (早在兩年前，「新酷音」輸入法系統就證明在某隻SmartPhone上正確運作)，真正的難題反而是輸入法的「輸入」本身。是的，以「新酷音」來說，支援兩種基本符號：

• 注音符號
• 拼音字母

這兩者背後也有學問，光是注音符號對照的鍵盤排列就可玩許多花樣，諸如許氏注音、倚天26鍵等等，拼音系統就不必多說，在台灣根本就是多頭馬車。以往，「新酷音」的開發者花了很大的心力去維護這些子系統的可用性與正確度，整合到libchewing (核心函式) 中，但如今要整合到手持式裝置，就面臨新問題：

「如何將傳統鍵盤的行為導入輸入法系統？」

我們首先會想到手寫辨識，就目前的系統來說，多半會內建OSK (On-Screen Keyboard)，所以「新酷音」理所當然可架構於OSK之上，不過這與我們中文打字者的思維有很大的落差。何以此說？試想，「新酷音」的中文簡介是什麼？就是「智慧型注音輸入法」，透過統計與預測方式，大幅降低同音字詞的出現率，進而改善注音輸入的速度，使用鍵盤只是一種過度，真正使用者腦海中的思維，仍是「注音」(或拼音）本身，所以，日前筆者也跟Palatis聊到一種新途徑：

「何不直接辨識注音符號，然後導入新酷音輸入法引擎去作猜字處理？」

這種技術難度對於Chrasis一類的簡化手寫辨識引擎來說，算是綽綽有餘，如果不討論太複雜的連寫與草寫議題的話。某種角度來說，這說明了Mobile 2.0的思維方式：「過去的桌面技術有機會走入移動裝置之中」與「打破過去封閉技術的藩籬，個人也得以貢獻新的技術元素到移動裝置設計」，如今，我們有完全開放程式碼並開放手機規格與實做的openmoko、有高效率的動態組字技術，以及最寶貴的資源，也就是富有高度創意的自由軟體開發者，其整體的影響將會很有趣，手持裝置才正要作更有意義的應用，咱們拭目以待。

Xorz/Embedded的動態組字實做

之前的文章「Xorz/Embedded作為Phone UI」與「組字技術與手持式裝置的新機會」提到輕量級視窗圖形系統的實做進度，同時也思考組字技術帶來的新契機，無論是技術與實務規劃面來說，都還有很大的商議空間，但筆者認為這是必要的基礎建設。利用週末，終於在Xorz/Embedded實做出基本的中文動態組字功能，執行畫面如下：

以上展示「黃」(Unicode 0x9EC3)與其搭配不同組件 (部首) 的呈現方式。原本single.fnt (剎那單線體) 定義為：

!009EC300|黃0=0000162E0001F02E00005A1100015A5E0000A8110001A85F0000595F0001AC5F00000A5F0001F55F00003C7300013CCE00003D7B0001CA7B0001CACF00003B9E0001C99E00008066000180C1000062D6000242EB000116FA00009AD00002D0E50001DEF700003CC00001CAC0

又，考慮美觀，我從文鼎楷體轉出了stroked font，從而做了細部的調整，這方面還得與剎那搜尋工坊討論如何整合，但基本上組字的概念是可以延續的。「黈」這字在single.fnt是如此定義：

009EC800|黈0=黃0131272E1主0811078D9

相當明顯就是「黃」與「主」兩部件的左右結合，同理，「黌」則定義如下：

009ECC00|黌0=00D07E66B黃0156AD78A

改為上下部件的結合。當然，目前的實做還很陽春，但已經看得出效益，以目前的stroked font engine來說，只要先描述以上三個組件，如「黃」與「主」：

/* 0x9ec3 (黃) */
3, 66, 56, 0,
'm', 28, -36,
'2', 29, -36, 29, -36,
'2', 33, -37, 39, -37,
...

接著就採用single.fnt所定義的組字表示，去作遞迴表示即可，大幅省下儲存空間，也可避免許多維護成本，更重要的是，這一舉克服以往字型檔與程式碼不對稱的問題。除了中文動態組字外，其實Xorz/Embedded的繪字引擎也允許一些變化，比方說「Q版」的呈現，有點像是塗鴉文字，行文甚至有互相疊合的效果，這是為了配合某些特殊的應用，如廣告文字，所特別設計的系統，畢竟Xorz/Embedded一開始的定位就是針對嵌入式系統的特製輕量級圖形系統。

恰好TOSSUG在本週二也請到國內在動態組字學有專精的前輩，為我們分享中文缺字議題、動態組字技術，以及進行中的變革，詳情可參考「Tossug 2007 年第 7 場心得分享」，如果當天有空檔，或許筆者也可來作些介紹與展示。

組字技術與手持式裝置的新機會

專注於中文技術的剎那搜尋工坊推出新版 (2007.05.26) 的「剎那字引」軟體，其概念相當特別，以「部件」來分析漢字 (泛指中日韓漢字) 進而可做出正向或反向的資訊化操作。就完整的中文處理系統來說，不僅要考慮畫面或裝置輸出，還有繁瑣的輸入法，但受限於異體字、錯別字，或可用性等考量 (特別是手持式裝置來說，得提供一定程度的「漢字容錯」處理)，每每挑戰著設計者的技術水準，但這方面的議題並不是建立大量的state machine就可克服的，我們得從漢字本質去思考。

「剎那字引」的執行畫面如下： (Win32/Delphi Application running via WINE/Linux)
我們可一目了然得知特定部件與其對應的漢字，這可用一致性的數學模式去表示，不過這裡就不贅述了，可參考Foxman前輩發表的一系列文章。對於手持式裝置來說，漢字的輸出與輸入之間即有一定程度的關聯，比方說手寫辨識就與組字在概念上有共通處，而漢字構形資料可作反拆或逆向查詢與推斷，意味著可運用於輸入法的輔助索引處理的機制，是此，即使是手寫辨識的操作，甚至可簡化為只需書寫偏旁，系統反推並決定候選字 (與其組合)，大幅降低辨識的複雜度，或考慮到傳統的輸入法，這就是一個相當有效率的「過濾器」。

再來我們可回頭思考漢字系統長久以來的缺字問題，儘管桌面應用已經逐步改善此議題，對於手持裝置來說，仍是極大的衝擊。當然，國際大廠注意到這類需要對資源錙銖必較的裝置上，做完整中日韓多國語文處理的議題，本身就是兼顧技術、可用性、價格成本，與後端交換碼種種妥協的設計，所以IICore (International Ideograph Core) 標準被提出，預期成為手機、PDA等移動通訊產品的重要規格，原則上不超過一萬字，是Unicode的子集 (碼位大幅調整)。問題是，我們應著眼於深入更多觸角的移動通訊運算，不該僅用常用的表意文字來限制資訊系統的使用。人們都有使用行動通訊裝置的自由，卻往往受限於種種預設立場的桎梏，這是相當不合理的事情，勢必，技術上得有所突破。

基於以上考量，動態組字技術於手持式裝置的需求，越來越顯見其重要性，正如之前文章「紀錄：可攜式造字引擎專利釋放暨成果發表會」所提及的概念，我們可發現運算技術、文化需求，以及M化等因素的交錯即將邁入臨界點，未來將以何種方式呈現？不得而知，但我們實在有必要將基礎建設完善化。

紀錄：可攜式造字引擎專利釋放暨成果發表會

稍早提及可攜式造字引擎專利釋放暨成果發表會，日前已在中研院資訊所圓滿落幕，雖然許多技術性與實用性的議題尚待克服，但剎那搜尋工坊這項釋放專利的創舉，可望驅使漢字與資訊的整合邁入新的契機。OrzLab也順利展示內建動態組字技術的Linux mobile phone概念機，未來將逐步釋出其原始程式碼。

議程方面，自下午三點，由剎那搜尋工坊 (前身為易符智慧科技) 的大家長陳昌江先生在「專利釋放現場公告」揭露「可攜式造字引擎專利公眾授權條款書」，並有存證信函與拍照留影，為漢字資訊處理界劃下新的一頁，自此，此類動態組字技術將不再受限於特定單位，而能以自由軟體之形式，廣泛流通於新的應用中，感謝與會的貴賓與我們見證這一刻。葉健欣先生 (yap，前朱邦復實驗室成員) 則在「組字研究的簡史」給予清晰的介紹，提及何以漢字系統會面臨窘境、古文訓詁的難題、過去幾十年內相關漢字技術的變遷，以及從易符智慧科技至剎那搜尋工坊所面臨的挑戰與技術應用的轉變。

張正一 (魔法設計師) 隨後給予精彩的「組字標準與觀念解說」議程，先由昔日「萬碼奔騰」的時代點題，雖然今日我們已清楚知曉Unicode標準的重要性，但實務應用上難免有所不足，其中以漢字缺字為最，為此，Unicode 3.0以降， 引入新的IDS與IDC機制 (Ideographic Description Sequence/Character)，剎那搜尋工坊則以此為基礎並整合以部件為基礎的動態組字技術，張正一先生則率先撰寫符合自由軟體規範的組字示範程式，在議程中發表與展示，藉此為與會的貴賓建立概念。

由於專利釋放之舉也需要配套的自由軟體社群支援，才得以彰顯價值，所以本會也邀請到來自中研院資訊所的林誠夏與胡崇偉 (marr) 探討授權與專案開發的須知，詳見「公眾授權條款簡介」與「開源計畫要如何參與」。最後是OrzLab的議程「應用動態組字於手持式裝置」，首先分析手機一類的移動裝置在成本與多國語文上面臨的難題，再者是來自裝置端與後端的訊息交換議題，再深入探究系統設計，可發現以往的點陣字系統是一大衝擊，不僅增加成本也造成潛在的裝置壽命問題，同時輸出與輸入系統彼此是獨立的。OrzLab引入全向量繪圖系統，試圖克服上述技術難題，目前已經有高效能且低儲存需求的ASCII字型引擎，正銜接Unicode IDS需求，在議程尾聲，展示了一款內建動態組字技術的Linux mobile phone概念機，得以在QCIF解析度 (176x220) 迅速呈現全螢幕漢字輸出。

由於與會賢達來自古文研究、電子產業、出版業、佛經文化、文書處理等領域，所以議程後的討論時間中，激盪了深入的技術與人文性思考。首先是漢書軟體作者施得勝先生提問：「動態組字美觀度可否精進？」yap的回應是：

• 組字七萬字約佔1MB ，而 TTF 要40~50MB 。美觀是用空間和時間來換取的
• 常用字只有兩三千字，這些字沒有必要動態組出來，使用既有的方式即可
• 動態組字使用的場合為呈現系統不存在的字，此時，組字再醜，也遠比空白或亂碼來得好

另一則是關於自由軟體授權的議題，這由中研院資訊所的葛冬梅小姐給予簡要的分析。臺灣師範大學國文系亓婷婷教授則提出美觀度、手寫辨識與組字的整合等問題，就動態組字本質來說，形同一個可提供無窮字形的字型檔，與輸入法沒有關連，亦即可沿用任何既有的輸入法，來輸入構形部件，當然，對於手寫辨識來說，將會有潛在的優勢，因為已經預先作部件的分析。

東海大學資管系林正偉教授提出澄清專利涵蓋的議題，陳昌江先生則重申專利字號與適用範圍，以茲與眾多漢字學者研究區別，這也引發關於動態組字需要唯一或標準表示的討論，以「好」這個中文字為例，其部件為左邊的「女」與「子」，再行左右組合，但對複雜的字來說，構成方式不唯一，Unicode IDS只是探究其表示法，該如何確認有一致的交換性？多方討論的結果來看，剎那搜尋工坊表示會另行規範，但不在本研討會的議程中。最後是Mat (UCIMF作者) 就實務上詢問動態組字能否與Unicode相容，基本上只要依據Unicode IDS作對應，即可符合相容性，這也意味著，OrzLab未來可能從Unicode console/terminal與FreeType整合的方式，切入動態組字技術的應用。

會後就是BoF時間，也激盪了許多想法，相關的自由軟體實做與部件字庫也會在近日釋出，所以，儘管三十年前謝清俊教授等人就提出構字式的具體研究，但真正能夠讓成果累積並且跨入電腦以外的項目，這是個起點，但我們終於跨出了。

相關資訊：

• 正體中文網
• 剎那搜尋工坊
• 漢字研究 (魔法設計師)

可攜式造字引擎專利釋放暨成果發表會

本週二下午至中研院資訊所，參與「可攜式造字引擎專利釋放既成果發表會」的行前會，確立許多細節，新聞稿已出爐，摘錄如下：

3月17日剎那搜尋工坊將假中央研究院舉行可攜式造字引擎專利釋放暨成果發表會

對於出版、文史研究、教育、甚至科技行業，漢字重重的缺字問題始終是永遠的痛，在經歷30餘年產、官、學的努力下，終於萌生全面性解決方案－部件組字。

部件組字在邁向成熟實用化的道路上，剎那搜尋工坊扮演了相當的角色。過去專注於開發漢字搜尋技術，也鑽研缺字問題的全面解決之道，在吸納中央研究院謝清俊教授、朱邦復先生等等諸前人的成果後，研發出「可攜式造字引擎」。該技術內涵為基於漢字字形本質的動態組字，使跳脫以往人為一字一碼的武斷，回復漢字本有的活性架構。不但解決了缺字困難，也同時相容於unicode標準，為一條無痛的漢字數位進化之路。

剎那搜尋工坊鑑於此重大數位漢字基礎技術，乃「站在巨人肩膀上」的成果，為謀求對社會大眾的最大利益，遂藉此會公示將此專利技術無償開放公眾運用，歡迎各界使用與繼續發揚。

會中將說明本技術的沿革簡史、組字的觀念、以及如何參與發展的作法。

OrzLab也提供了十五分鐘的介紹「應用動態組字於手持式裝置」，延續之前blog「動態組字技術於Embedded領域」的觀點，將以實際的案例探討嵌入式系統領域如何由此受益，相當感謝剎那工作坊釋出專利，經過多次的討論後，也看到許多機會，作為華人的工程背景人員，我們有相當大的伸展舞台，同時開放的胸襟加上open source，所激盪出的變革更值得我們關注。

舉辦單位

• 主辦：剎那搜尋工坊
• 協辦：中央研究院自由軟體鑄造場
• 贊助：資訊工業策進會雜誌社

時間地點

3/17/2007 下午3:00~5:00 中央研究院資訊科學研究所 新館 101會議室

動態組字技術於Embedded領域

在魔法設計師與marr的引見下，去年於COSCUP 2006有幸認識剎那工坊的陳昌江與yap前輩，談到中文組字技術與嵌入式系統的若干細節，給予我很大的鼓舞。本實驗室今年的計畫中，即有Embedded GUI Framework的項目，原本只是因應RT executive或virtualization需要 (如Linux subsystem尚在啟動或者非運作中的情況下，至少可有輕量級的人機介面與使用者互動)，所提出附加性設計，這也就是Xorz/Embedded (展示1/展示2)。但如果能順利整合中文動態組字技術，對於原本即以向量繪圖為核心架構的Xorz/Embedded，是很好的契機，或許可作為低階裝置的UI，同時我們也可以看到，開發中國家如中國大陸，更是需要動態組字技術。

為何我們要重視動態組字技術的原因，除了陳昌江前輩日前發表的大作「等待新漢碼」所提到種種根深蒂固的窘境以及文化傳承的需要，另一個現實的考量是，這類可攜式造字引擎可避免過度的Disk I/O存取，進而大幅提昇儲存裝置的壽命 (NAND/NOR Flash 皆有讀寫次數限制)，所以短期內我們應該要在Embedded平台作技術驗證，中期就是銜接現有mobile標準，克服缺字議題。

魔法設計師貢獻了許多教學文件與參考實做，可參考其 blog 之漢字研究的分類，日前張貼的「組字示範程式釋出！」一文即提供了以Java撰寫的教學程式，內含中華民國發明專利號碼第I254863號「可攜式造字引擎」專利的技術與剎那工坊維護之剎那單線體字形檔，經專利權人陳昌江同意，預先提供執行檔與資料檔供測試評估使用，詳細規格可見正體中文網，附帶一提，相關專利可望於近日釋放，成為公共財。

OrzLab很自然就成為受益者，不過小弟目前仍在規劃階段，只有零星的測試程式碼，不過抽離Xorz/Embedded內部的向量描繪引擎就是相當重要的工作，目前已經有個具體而微的向量字型編輯程式，以下是其運作畫面：

另外，也可試著與對岸許多Embedded GUI開發者打聲招呼，其實已經太多重複的工作了。今年真是刺激的一年 :-)

關於PCF的連結

在網站搜了一下，才發現PCF的資料並不如想像中的那麼多，找到的網站，幾乎都是格式轉換的用法，很少有提到PCF的規格和程式碼，在wikipedia甚至沒有專頁的介紹。

少歸少，還是找到了一些不錯的技術文件如下:

• 「 BDF的規格書」、「 PCF的規格」眼尖的人可以發現這裡可以找到大多數字型檔的規格書: Font File Format，這些資料是FontForge用心整理的, 對字型工作者提供莫大的幫助，而主頁有放正體中文翻譯的文件教學,，內容很棒！
• 「BDF&PCF的深度文件」(日文) 因為是日文，所以從中得到的資訊很有限，不過有介紹到兩個字型的資料結構，內容相當深入，搜一下Google，發現作者多賀奈由太就是寫hexadecimal dump tool(hex)的人，難怪...
• "Unicode fonts and tools for X11" 這篇文章也介紹了不少字型的資訊，尤其在最後兩三章提供了不少關於字型工具的聯結，很有幫助。
• "QPF(QT Preredered Font)" 隨手逛到Qtopia也有自己的字型檔，不過他也支援Freetype的字型引擎，這讓我想到Freetype能否進一步輕量化，提供Embedded System高品質的字型引擎？不過文中也提到Unicode字型最大的弱點：

  All supported fonts use the Unicode character encoding. Most fonts available today do, but they usually don't contain all the Unicode characters. A complete 16-point Unicode font uses over 1 MB of memory.

寫到這裡，沒想到查個文件, 東點點西點點，就花了一個下午的時間。