網頁制作poluoluo文章簡介：不拘小節的中文字體設計.
TeX 排版中文字體嵌入問題，兼談不拘小節的中文字體設計
原文：http://yulewang.spaces.live.com/blog/cns!5C815C994ABB661E!262.entry
低於 18 周歲的小朋友們請不要看此文，會被嚇到的。如果你和中國的字體公司有聯系，請把我所描述的問題轉告給他們。
考完作文後，在上海小歇，除了吃喝玩樂加上逛街還有被導師虐著寫文章，自己看兩眼G詞以外，就是在嘗試解決中文 TeX 用戶幾年來一直抱怨的關於 TeX 產生的 pdf 文檔中文字體看上去太細的問題。
這個問題的來龍去脈是這樣的。很久以前，大家都需要用 dvips 或者 dvipdfm 來轉換 TeX 產生的 dvi 文件為 pdf 文件，這個路徑很麻煩，需要把一個中文 trueype 字體轉為大約一百多個 Type1 字體，然後再把這些字體的 Subfont 給嵌入到文檔中。南韓的一個數學家 Cho，因為不滿意 TeX 的這種狀況，因此寫了一個 dvipdfm 程序的擴展，名為 dvipdfmx。dvipdfmx 可以直接嵌入 CID 的 TrueType 和 OpenType 字體，不需要把字體分割成許多個 subfont，產生的 pdf 文件小巧，而且比原先的方法在閱覽器下渲染速度快，質量比較高。因此得到了中日韓用戶的喜愛。但是許久以來，中文用戶一直抱怨一個問題，就是貌似由 dvipdfmx 產生的文檔，在 Adobe 公司官方的 Acrobat Reader 下，顯得發虛，嚴重地影響閱讀，而相同的字體，如果不用 dvipdfmx，比如使用 cairo、quartz 或者 word2007 進行轉化，產生的 pdf 就沒有這個問題。如果文章中都是中文，那只不過是難以閱讀而已。而如果是中文和英文混排的，而英文部分又比較正常，比如使用了 Times 字體或者 Palatino 字體，則整個 type block 就顯得斑駁，一眼看到的都是突出的英文，所以一直以來，我們都建議用戶使用本來就細得要命的默認的 Computer Modern 字體，以使得文檔不至於失調。
幾年來，從來沒有人認真地研究過這個問題，南韓的用戶都覺得 dvipdfmx 產生的 pdf 質量不錯，因為他們使用的隨 KTUG 定制的發行版發布的字體本來就比較粗，而中國的用戶如果使用 Windows 下的中易公司的宋體，即 simsun，則相當不能忍，方正公司的字體，比如書宋，則稍微好一點，但怎麼也好不過 Adobe 公司的 OpenType 字體 Adobe Songti Std Light。若干年前，jjgod 同學寫過一篇文章比較了幾十個中文字體，他是使用了 dvipdfmx 輸出的結果的視覺效果來評價字體的質量，結果一個相當好的字體，方正博雅宋，由於在閱覽器中顯示過細，被他認為不如方正書宋。而幾年以後，這個問題被泛化，當今，TeX 正在走向國際化，如今的 TeX 已經支持 Unicode 和各種高級的字體格式，也全面從 dvi 時代過渡到 pdf 時代，目前兩大炒作得很熱的 TeX 引擎，都和 dvipdfmx 扯上了關系。 XeTeX 直接使用了 dvipdfmx 的一個變種，xdvipdfmx 來產生 pdf，而 LuaTeX，則用 dvipdfmx 的代碼替換掉部分產原先 pdfTeX 的代碼，來產生 pdf。這就導致，目前所有的先進的 TeX 系統，在 CID 字體嵌入方面的代碼，是近親關系，所有產生的中文 pdf，都虛得離譜，LuaTeX 尤甚。
我在去年和今年，一直使用 LuaTeX 引擎和 ConTeXt 格式，寫各種包括論文以內的文檔，在使用的過程中，發現了不少問題，就開始和開發者交流。幾個月來，報告了不少 bug，其中一些，還給出了補丁。此外，我和 ConTeXt 開發者 Hans 等 TeX 專家討論，試圖讓最新的 ConTeXt 和 LuaTeX 來支持中文排版。其他事情，還包括為ConTeXt 的用戶們提供 FreeBSD 操作系統的 TeX 二進制文件。因此，我和 LuaTeX 與 ConTeXt 的開發者（其實是同一撥人），有很頻繁的聯系，也彼此保持著不錯的關系。開發者們也很勤快地修復著我匯報的各種 bug，這也使我能夠很好地使用這些軟件進行各種文檔（學術論文、技術文檔）的排版。今年考完作文後，我暫時可以小歇一下，同時由於 LuaTeX 的開發者們剛剛搞定了一項新功能，mplib，也有空余的時間。因此，我們就有時間來討論和解決這個由來已久的問題。
我一開始寫信給 LuaTeX 的開發者，Taco Hoekwater，之所以不寫給 dvipdfmx 開發者 Cho 而發給他，因為我和他熟，而且 Taco 這兩年來，勤勤懇懇地寫代碼，我比較相信他解決問題的效率。有時候一個 bug 提交給他他不到幾十分鐘就已經 fix 了。結果 Taco 看了好幾天，一無所獲，於是，Taco 幫助我把信轉給了當今世界上幾個重要的大牛，准備來專家會診。這個會診的醫師陣容龐大，技術高超，隨便舉幾個人：dvipdfmx 開發者 Cho，LuaTeX 開發者 Taco，外加 XeTeX 開發者 Jonathan Kew。不久以後，話說解鈴還需系鈴人，Cho 找到了一個可能的問題。他把 pdf 文件解開，仔細觀察 cairo 輸出了 LuaTeX 輸出中字體嵌入部分的參數，發現某個數值 StemV，相差懸殊。使用編輯器修改解開的 pdf，將 StemV 調整到相同，兩個 pdf 文件頓時就差不多了（雖然還有些許差別，但是這個就是最重要的因素之一）。
網頁制作poluoluo文章簡介：不拘小節的中文字體設計.
問題頓時有了突破性的進展，比較 LuaTeX 產生的 pdf 和 dvipdfmx 產生的 pdf，發現 LuaTeX 的 StemV 數值大得多，不久 Taco 就發現，這是 LuaTeX 的某個 bug 導致的。該 bug 當天就得到了修正，這樣產生的 pdf 就和 dvipdfmx 一樣了。但是修正以後事實上得到的 pdf 依然很細。cairo 產生的 pdf 文件，一律取成了相同的默認數值，所以看上去宋體表現還不錯。而 dvipdfmx 的 TrueType 字體的 StemV 數值到底是怎麼產生的呢？它經驗性地依賴於一個擬合公式：
stemv = (os2->usWeightClass/65)*(os2->usWeightClass/65) 50
其中，os2->usWeightClass 是字體中 pfmtable 中的信息，是一個數值。這個數值在字體設計的時候就被定了下來，一般和字體的 weight 有關：比如 Light 就是 300，500 表示 Medium，而 800 則表示 Extra Bold。該數值決定了 StemV 的數值，也就是說，如果這個字體越粗，那麼 StemV 數值就越大，在閱覽器中渲染，就會越虛，合情合理。但是當我們打開中易公司的中文字體，方正公司的字體，還有華文字體，我們失望地發現，他們都取了同樣的數值：400。
於是這個問題，如果扯開擬合公式本來結果就偏大不說，其他的就應該怪罪到中文字體設計上來了。像 Simsun 字體，並不比 AdobeSongStd-Light 粗多少，甚至更細，取一個 400 的值本來就不合理。其次，中易字體不管黑體還是宋體，都取相同的數值，怎麼都說不過去。相同的也發生在方正字體上，方正宋黑，方正書宋，小標宋，也都取相同的數值。這個基本上是不可能讓軟件來自動判斷的問題，本該是字體公司仔細勘酌的，現在卻被信手賦值。按照現在的狀況，軟件不可能自動判斷這個值，使得黑體就是比宋體取值大。
解決這個問題，也只能讓用戶自己設定了，不久以後 LuaTeX 用戶可以通過修改 Fonttable 來實現，dvipdfmx 開發者稱，今後會在 map 文件中，讓用戶指定數值。 XeTeX 開發者估計可能會像先前指定偽粗，偽斜一樣的語法來定義這個數值，不過目前沒有收到任何他的計劃。這個估計就是我們能采用的唯一不是辦法的辦法，不過終歸而言，這個問題被解決了，今後只要仔細調整參數，就能得到渲染效果得當的 pdf 文件。
類似的中文字體亂設參數的例子還有很多，此前 yindian 同學，提到了XeTeX 的一個 bug，導致沒有辦法產生正確的 pdf，後來發現這個根本不是 bug，完全也是由於字體設計公司亂設字體參數導致的。後來 jjgod 同學 hack 了一下 xdvipdfmx 總算差不多解決該問題。該問題的詳細信息，請參考 XeTeX 的郵件列表，該主題內容在http://tug.org/pipermail/xetex/2007-October/007536.html，和後續的討論。
中文字體設計不拘小節也讓我也想到了另一個問題，用先前，中文用戶使用 XeTeX，需要頻繁地切換中英文字體，後來 XeTeX 開發者不得不提供了一個機制來讓字體切換變得不那麼折騰。而我和 ConTeXt 開發者交流中文排版問題，還要煞費苦心地講怎麼切換，需要編程實現復雜的虛擬字體機制來實現。這個都歸罪於中文字體普遍地缺乏高質量的英文部分，仔細看看 simsun 或者 simhei 的英文部分，就可以看出有多麼誇張了。
如果說這個問題的原因是中國的字體公司，向來沒有很好的英文字體設計基礎，同時對這個問題也不加以重視，那麼中文標點的設計，就沒有絲毫的可以開罪的地方了，這個問題直接導致用戶和開發者都非常為難。我們知道，高質量的中文排版，標點並不是占據一個中文字符的位置，而要比中文字符略小。同時，標點之間需要存在壓縮，比如逗號後緊緊跟隨的關門引號，需要使用類似 kerning 的特性把兩個 glyph 的距離減小。另外，類似破折號和省略號，其實應該放在一個 glyph 中而不應該分開。而現在所有的中文字體的糟糕程度，竟然到所有的標點符號都占用一個中文字符距離的程度。本來這個問題如果中文字體設計得當，使用默認的排版算法，就基本上能夠解決一般的中文的排版問題，而現在糟糕的設計就使得排版軟件的設計難上加難。首先我們需要重新定義一系列的新算法和新規則，然後需要手工賦值去確定標點的大小和兩個標點連在一起時候的壓縮程度。更麻煩的是，不同字體中的相同的 glyph，比如逗號或者句號，往往會在這個 box 的不同的位置，大小也會千差萬別。調好了中易宋體的冒號和開門引號，把相同的數值使用到中易的隸書中，頓時兩個符號就會擠在一起，這就使得如果不針對每一個字體仔細調整，高質量的中文排版就幾乎不可能。我寒假和 ConTeXt 的開發者交流中文排版問題時，這個麻煩搞得頭都大了，而這個問題本來就是該在字體公司設計字體時就解決的。
排版軟件的開發，永遠不是一個軟件的事情，它牽扯到政府規范，字體設計，文檔標准和字體標准的制定。往往如果排版軟件不能做出令人滿意的結果，很可能是由於其他非排版軟件的因素造成的。Adobe 或者 LinoType 大公司出品的英文字體，往往都會有較高的水准，正是因為設計者已經仔細調整好字體中的各項參數，使得用戶使用排版軟件默認的方案，就能夠做出很好的作品，偶爾遇到需要的 glyph 找不到，或者某個 kerning 長度不理想，打開 fontforge 之類的字體軟件，也能方便快速地調校從而滿足自己的需要。中文字體的設計，離開這個標准還很遠很遠，有很長一段路要走。