|
問題頓時(shí)有了突破性的進(jìn)展，比較 LuaTeX 產(chǎn)生的 pdf 和 dvipdfmx 產(chǎn)生的 pdf，發(fā)現(xiàn) LuaTeX 的 StemV 數(shù)值大得多，不久 Taco 就發(fā)現(xiàn)，這是 LuaTeX 的某個(gè) bug 導(dǎo)致的。該 bug 當(dāng)天就得到了修正，這樣產(chǎn)生的 pdf 就和 dvipdfmx 一樣了。但是修正以后事實(shí)上得到的 pdf 依然很細(xì)。cairo 產(chǎn)生的 pdf 文件，一律取成了相同的默認(rèn)數(shù)值，所以看上去宋體表現(xiàn)還不錯(cuò)。而 dvipdfmx 的 TrueType 字體的 StemV 數(shù)值到底是怎么產(chǎn)生的呢？它經(jīng)驗(yàn)性地依賴于一個(gè)擬合公式：
stemv = (os2->usWeightClass/65)*(os2->usWeightClass/65) 50
其中，os2->usWeightClass 是字體中 pfmtable 中的信息，是一個(gè)數(shù)值。這個(gè)數(shù)值在字體設(shè)計(jì)的時(shí)候就被定了下來，一般和字體的 weight 有關(guān)：比如 Light 就是 300，500 表示 Medium，而 800 則表示 Extra Bold。該數(shù)值決定了 StemV 的數(shù)值，也就是說，如果這個(gè)字體越粗，那么 StemV 數(shù)值就越大，在閱覽器中渲染，就會越虛，合情合理。但是當(dāng)我們打開中易公司的中文字體，方正公司的字體，還有華文字體，我們失望地發(fā)現(xiàn)，他們都取了同樣的數(shù)值：400。
于是這個(gè)問題，如果扯開擬合公式本來結(jié)果就偏大不說，其他的就應(yīng)該怪罪到中文字體設(shè)計(jì)上來了。像 Simsun 字體，并不比 AdobeSongStd-Light 粗多少，甚至更細(xì)，取一個(gè) 400 的值本來就不合理。其次，中易字體不管黑體還是宋體，都取相同的數(shù)值，怎么都說不過去。相同的也發(fā)生在方正字體上，方正宋黑，方正書宋，小標(biāo)宋，也都取相同的數(shù)值。這個(gè)基本上是不可能讓軟件來自動判斷的問題，本該是字體公司仔細(xì)勘酌的，現(xiàn)在卻被信手賦值。按照現(xiàn)在的狀況，軟件不可能自動判斷這個(gè)值，使得黑體就是比宋體取值大。
解決這個(gè)問題，也只能讓用戶自己設(shè)定了，不久以后 LuaTeX 用戶可以通過修改 Fonttable 來實(shí)現(xiàn)，dvipdfmx 開發(fā)者稱，今后會在 map 文件中，讓用戶指定數(shù)值。 XeTeX 開發(fā)者估計(jì)可能會像先前指定偽粗，偽斜一樣的語法來定義這個(gè)數(shù)值，不過目前沒有收到任何他的計(jì)劃。這個(gè)估計(jì)就是我們能采用的唯一不是辦法的辦法，不過終歸而言，這個(gè)問題被解決了，今后只要仔細(xì)調(diào)整參數(shù)，就能得到渲染效果得當(dāng)?shù)?pdf 文件。
類似的中文字體亂設(shè)參數(shù)的例子還有很多，此前 yindian 同學(xué)，提到了XeTeX 的一個(gè) bug，導(dǎo)致沒有辦法產(chǎn)生正確的 pdf，后來發(fā)現(xiàn)這個(gè)根本不是 bug，完全也是由于字體設(shè)計(jì)公司亂設(shè)字體參數(shù)導(dǎo)致的。后來 jjgod 同學(xué) hack 了一下 xdvipdfmx 總算差不多解決該問題。該問題的詳細(xì)信息，請參考 XeTeX 的郵件列表，該主題內(nèi)容在http://tug.org/pipermail/xetex/2007-October/007536.html，和后續(xù)的討論。
中文字體設(shè)計(jì)不拘小節(jié)也讓我也想到了另一個(gè)問題，用先前，中文用戶使用 XeTeX，需要頻繁地切換中英文字體，后來 XeTeX 開發(fā)者不得不提供了一個(gè)機(jī)制來讓字體切換變得不那么折騰。而我和 ConTeXt 開發(fā)者交流中文排版問題，還要煞費(fèi)苦心地講怎么切換，需要編程實(shí)現(xiàn)復(fù)雜的虛擬字體機(jī)制來實(shí)現(xiàn)。這個(gè)都?xì)w罪于中文字體普遍地缺乏高質(zhì)量的英文部分，仔細(xì)看看 simsun 或者 simhei 的英文部分，就可以看出有多么夸張了。
如果說這個(gè)問題的原因是中國的字體公司，向來沒有很好的英文字體設(shè)計(jì)基礎(chǔ)，同時(shí)對這個(gè)問題也不加以重視，那么中文標(biāo)點(diǎn)的設(shè)計(jì)，就沒有絲毫的可以開罪的地方了，這個(gè)問題直接導(dǎo)致用戶和開發(fā)者都非常為難。我們知道，高質(zhì)量的中文排版，標(biāo)點(diǎn)并不是占據(jù)一個(gè)中文字符的位置，而要比中文字符略小。同時(shí)，標(biāo)點(diǎn)之間需要存在壓縮，比如逗號后緊緊跟隨的關(guān)門引號，需要使用類似 kerning 的特性把兩個(gè) glyph 的距離減小。另外，類似破折號和省略號，其實(shí)應(yīng)該放在一個(gè) glyph 中而不應(yīng)該分開。而現(xiàn)在所有的中文字體的糟糕程度，竟然到所有的標(biāo)點(diǎn)符號都占用一個(gè)中文字符距離的程度。本來這個(gè)問題如果中文字體設(shè)計(jì)得當(dāng)，使用默認(rèn)的排版算法，就基本上能夠解決一般的中文的排版問題，而現(xiàn)在糟糕的設(shè)計(jì)就使得排版軟件的設(shè)計(jì)難上加難。首先我們需要重新定義一系列的新算法和新規(guī)則，然后需要手工賦值去確定標(biāo)點(diǎn)的大小和兩個(gè)標(biāo)點(diǎn)連在一起時(shí)候的壓縮程度。更麻煩的是，不同字體中的相同的 glyph，比如逗號或者句號，往往會在這個(gè) box 的不同的位置，大小也會千差萬別。調(diào)好了中易宋體的冒號和開門引號，把相同的數(shù)值使用到中易的隸書中，頓時(shí)兩個(gè)符號就會擠在一起，這就使得如果不針對每一個(gè)字體仔細(xì)調(diào)整，高質(zhì)量的中文排版就幾乎不可能。我寒假和 ConTeXt 的開發(fā)者交流中文排版問題時(shí)，這個(gè)麻煩搞得頭都大了，而這個(gè)問題本來就是該在字體公司設(shè)計(jì)字體時(shí)就解決的。
排版軟件的開發(fā)，永遠(yuǎn)不是一個(gè)軟件的事情，它牽扯到政府規(guī)范，字體設(shè)計(jì)，文檔標(biāo)準(zhǔn)和字體標(biāo)準(zhǔn)的制定。往往如果排版軟件不能做出令人滿意的結(jié)果，很可能是由于其他非排版軟件的因素造成的。Adobe 或者 LinoType 大公司出品的英文字體，往往都會有較高的水準(zhǔn)，正是因?yàn)樵O(shè)計(jì)者已經(jīng)仔細(xì)調(diào)整好字體中的各項(xiàng)參數(shù)，使得用戶使用排版軟件默認(rèn)的方案，就能夠做出很好的作品，偶爾遇到需要的 glyph 找不到，或者某個(gè) kerning 長度不理想，打開 fontforge 之類的字體軟件，也能方便快速地調(diào)校從而滿足自己的需要。中文字體的設(shè)計(jì)，離開這個(gè)標(biāo)準(zhǔn)還很遠(yuǎn)很遠(yuǎn)，有很長一段路要走。
本文鏈接：http://m.95time.cn/design/doc/2009/6719.asp 
出處：live <-> evil
責(zé)任編輯：bluehearts
上一頁 不拘小節(jié)的中文字體設(shè)計(jì) [1] 下一頁
|
第 1 頁 
第 2 頁 不拘小節(jié)的中文字體設(shè)計(jì) [2]
