不拘小节的中文字体设计（2）

问题顿时有了突破性的进展，比较 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 之类的字体软件，也能方便快速地调校从而满足自己的需要。中文字体的设计，离开这个标准还很远很远，有很长一段路要走。