IT中文環境的血淚史(2)中文字型的檔案體積與美觀

字型檔體積
解決了中文編碼，至於中文字型又是一個問題。在Windows上，一個不算美觀的中文TrueType字型需要約4 MB，像「隸書」這種每個筆畫「要斷不斷」的字型，檔案就更大一些，接近10 MB，而專業印刷（而非螢幕顯示）所使用的字型，由於相當細緻，字型檔案也就更大得多。

中文字型檔案內有大量重複的資訊，相當浪費。例如以「木」為左邊部首的中文字，恐怕不下一百個，每個字的glyph資料都重複描述「木」的外框，這是相當大的浪費。我粗估，如果壓縮得當，搭配自動調整筆畫寬鬆的演算法，原本13,000字的5~10MB字型檔，可以壓縮到100 kB。甚至可以讓演算法搭配各種參數組合，只需要少數參數資料，就可以產生不同的字體。我估計，多一個字型可能只需要多10kB，而不是多100kB（因為字的組成資料可以重複運用）。

目前，只有嵌入式系統會注意到中文字型檔案的大小，而在一般PC上我們不會把這當一回事。事實上，為了保持文件顯示效果的一致，有時候我們會嵌入字型。如果字型太大，或者使用太多字型，可能也會造成文件檔案變大。大多數允許嵌入字型的檔案格式（例如：PDF），都只允許嵌入文件中有真正使用到的文字。但盡管如此，只要有嵌入字型的檔案，多個幾MB是免不了的。

把形音義同時納入考量，可以解決中文字型太大，以及輸入法的一些問題。有一些單位在做這樣的研究，我也有看到不錯的產品，但似乎還有相當大的改進空間。

發明倉頡輸入法，人稱中文電腦之父的朱邦復，似乎也有做過相關的研究。只可惜他最近沈迷於「中文詩詞動畫」的研究，請恕我無知，我不知道以目前來說，中文詩詞動畫的重要性何在？

我之所以對中文字型的壓縮這麼執著，其實是有原因的。我在清華大學資訊工程研究所就讀時，我們實驗室是「視訊通訊實驗室」。對於視訊通訊來說，壓縮（compression）相當重要。每天看學長埋首在資料的壓縮上，只要比別人的方法節省幾個bit，就可以樂翻天，準備寫論文發表。有一天，我跟教授說：「我們每天在實驗室為這些bit斤斤計較，以後進入社會，一定會成為很節儉的人。」

字型美觀
如果你研究一下TrueType字型的glyph，你會發現，大多數的中文是以「筆畫外框」來描述，但英文字型是以「視覺外框」來描述。例如，英文字型對加號（＋）的外框描述是一氣呵成，只需要一個figure；但是大多數中文字型的「十」卻是兩個figure，一個描述「豎」、一個描述「橫」，在豎與橫的交界處，可能會發生問題。許多軟體在顯示中文字時，沒有處理填色的問題，所以常常會造成兩個筆畫交錯的地方反倒沒有上色，那是因為預定的Fill Rule採用Even-Odd，沒有改成Non-Zero。除非是繪圖軟體，否則一般的軟體不會允許我們更改字型的Fill Rule。我常常在夜市之類的地方，看到攤販自己用Office軟體和印表機做出來的簡易海報，「珍珠奶茶買二送一」上面大大的中文字，每個筆畫交錯的地方都沒有上色，整張海報怪異到不行，這都要怪軟體。

中英文字夾雜出現時，許多軟體並沒有注意到兩者之間要有空格才美觀。Microsoft Word有注意到這一點，但是許多排版軟體沒有注意到這一點。所以我之前在出版社工作時，我們必須先把稿件中，英文和中文的交界處加上空白，然後才排版。幸好我們不必手動加空格，而是寫了一個簡單的程式來作這件事。

有一些軟體（包括Acrobat Reader和早期的Java），不是使用OS的API來繪製中文，而是取出字型檔案中的glyph資料自行繪製（附帶一提，這些程式由於沒有使用Windows顯示文字的API，所以像譯點通這類API hook的程式就會無法偵測出游標位置的文字）。這個時候，很容易就會忽略了每個字的「hint」，當字體很小時，有些筆畫可能會消失（比方說Times New Roman字型的e，中間的橫線會消失，看起來很像c）。不過這不是中文字型的問題，這是所有字型都會遇到的問題。

正體中文字的筆畫可能相當多，如果字體很小，筆畫又不適當縮減，在螢幕上很可能會呈現一團黑，比方說，在Big-5字集中，筆畫最多的一個字是「龘」，也就是將「品」這個字的每個「口」都用「龍」取代。

有些西方的字型變化，套用到中文是不恰當的，最明顯的例子是：中文字不該出現斜體字。英文字加上斜體，可以吸引注意，但中文字加上斜體，只會變得相當難以辨識，但許多人似乎都沒有意識到這一點。

蔡學鏞－專職作家
清華大學資訊工程碩士，曾任華碩集團軟體工程師、元智大學資訊系講師、美商歐萊禮出版社技術編輯、臺灣微軟特約專欄作家。