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化等因素的交錯即將邁入臨界點，未來將以何種方式呈現？不得而知，但我們實在有必要將基礎建設完善化。

UCIMF 2.0預計時程

Mat日前在UCIMF的mailing-list上公告「UCIMF預計時程」，宣告即將在OSDC.tw上釋出UCIMF stable release 2.0.0，以下是訊息摘錄：

目前正在整理UCIMF的程式碼，同時準備4/15的OSDC.TW講稿。
主要修改內容為，加強外觀的調整，和穩定度的提升。
預計在4/15發佈2.0.0的tarball，並希望能邀請社群幫忙打包和開發。

目前希望的功能主要是：

• 字型、顏色，能客製化。
• OpenVanilla、IIIMF的支援

sincerely, Mat.

這個計畫已經進行一段時間，很高興即將邁入新的里程碑，未來也是Embedded i18n (Internationalization) / L10n (Localization)的解決方案之一。嗯，預祝順利！

UCIMF正式成為OrzLab專案項目

日前Mat完成了OrzLab的paper work，自此，UCIMF正式成為OrzLab的專案項目之一。UCIMF是個創新的計畫，引入IIIMF與OpenVanilla輸入法架構 (未來會有SCIM) 的終端機輸入環境，但不受限於輸入法，事實上，在開發的過程中，已經補足Unicode輸出顯示能力、視窗管理，以及多種字型描繪機制。以下是UCIMF的授權宣告：

/*
* UCIMF - Unicode Console InputMethod Framework
*
* Copyright (c) 2006-2007 Open RazzmatazZ Laboratory (OrzLab)
* Maintained by Chun-Yu Lee (Mat)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/

隨著資訊交換的多元化，在我們的觀察，嵌入式系統的多國語文支援有提昇的趨勢，又因為嵌入系統不僅得考慮到效能，也得將成本與穩定性列入考量，所以往往受制於有限的軟體建設。UCIMF則帶來一個新的途徑，得以在低成本需求的Embedded Linux/BSD上，提供豐富的多國語文處理能力，涵蓋顯示、輸入法，未來也會有印表的支援，更重要的是，符合Unicode標準，所以可消除許多相容性議題。

另外，考量到UCIMF應用的多元性，其IMF (Input Method Framework) 的介面部份採用BSD License釋出，這意謂著其上的輸入法引擎不僅可抽換，也可採用非GPL授權，去除商業應用的困擾。

Unicode版のTeX

TeX 是一套重量級的排版軟體，目前在國際流通的論文，大半是以TeX 所製成，其文件品質有目共睹。XeTeX 是Unicode版的TeX，具有功能特色如下：

使用FreeType和Fontconfig的方式讀取系統字型，直接支援True Type和OpenType字型，不用再作繁複的設定。引入ImageMagick支援，可直接套用JPG、PNG、BMP的圖檔，大幅增加引圖的彈性。語法上，繼承TeX和LaTeX的語法，而不再用\usepackage形式上來處理CJK文字，文件相容性高。

目前XeTeX的使用環境以Mac為主，不過目前已有Linux和Windows的支援。圖上所顯示的正是在Gentoo Linux上所製成文件。

大於與小於50000的差異

在zhcon的basefont.cpp中看到這一段程式碼時， 心中突然有了些感觸。

下面所記載的程式碼，主要的目的是判斷在字型檔大於50000Bytes時，就改採用memory mapped的方式來配置，因為CJK所用的字型大部分大於這個容量，所以得另外作一些處理。而這些細心的念頭, 是在FreeType的PCF部分，還有libXFont的PCF中找不到的。想當然爾，國外地區的Hackers只需要用到ASCII的字型，誰會去關心這樣的細節呢？

因此，對於這些CJK的基礎建設，我們更應該主動去作才是。

若我們不作，還有誰會來作？

if (mBufSize > 50000) {
//hzfont use mmap
mpBuf = (char *) mmap((caddr_t) 0, mBufSize, PROT_READ,
MAP_FILE | MAP_SHARED, mFd, (off_t) 0);
if (mpBuf == MAP_FAILED)
throw (runtime_error("error in mmap gbfont!"));
} else {
//ascii font read to buffer
mpBuf = (char *) new char[mBufSize];
unsigned nread = read(mFd, mpBuf, mBufSize);
if (nread != mBufSize)
throw (runtime_error("error in reading asciifont!"));
}

關於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.

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