@Ryekee：最近在看关于字体渲染技术的时候在SmashingMagazine上看到了这篇文章，觉得算是对 Windows、MacOS 以及 iOS上渲染技术说的比较详细的了，就翻译成了中文，同步更新于Ryekee_Blog和localhost/Ryekee。有任何错误或者不当的翻译欢迎指出。:-)
在Mac OS的Finder下或者网页（随便什么浏览器）中对文本截屏，之后对图片放大放大不断放大，就可以看到下图所示这样奇怪的东西了。为什么纯黑圆滑优美可爱的字体放大之后会有奇怪的颜色出现呢？这背后又有什么神奇的奥秘呢？欢迎来到本期「走进科学」之字体渲染的奥秘。
引言
两年多（原文写于2012年）以前开始的Web字体革命，引出了一个我们忽视了多年的问题：字体渲染，新被发明出来的Web字体给我们带来了新的挑战。选择使用一个字体不再仅仅涉及到样式的问题，它更值得我们去探寻技术上是如何实现的了。
虽然我们无法改变网站访客的浏览器和操作系统，但了解字体渲染的原理，有助于我们搭建一个对所有人都友好易读的网站。直到最近，我们可以使用的「Web零风险」字体屈指可数。但这些字体都为屏幕显示进行了精心的设计以及优化，因此你大可以放心它们的显示效果。
如今，当我们为网站选择字体时，有了更大的灵活性。可以清楚的看到，字体设计的渲染技术已经悄然发生了改变。操作系统厂商正在采用不同的字体渲染策略，而这一情况还将随时间继续演化。随着对屏幕上的字体更加深入的了解，我们已经意识到，这些字体的渲染会因为操作系统和字体格式而存在着明显的差异。蛋疼的是，即便是精心设计的字体可能看上去都不适合Windows，只因为它们缺少了很重要的要素：字体微调（hinting）。
本文将介绍字体渲染的原理，它们被开发出来的历程，以及它们是怎么被应用在不同的操作系统和浏览器中的。因此当你为你下一个项目挑选字体时，你就知道要怎么样才可以确保排版的效果了。
渲染策略
理想的形状（左），黑白渲染（中），灰度渲染（右）
栅格化（Rasterization）
在数字形态（digital type）中，字体被设计成矢量的图像。当文本在屏幕上显示时，需要将图形栅格化，理想的显示效果是需要不同的大小的一个个像素网格来共同组成字体的。你可以看到理想的形状中e的边缘并没有占满整个像素，但由于我们所能控制的最小元素就是像素了，也就造成了现实与理想的差距。
因此，工业界发明出了越来越先进的渲染策略，以确保屏幕显示的字体友好易读。
黑白渲染（Black and white rendering）
最早的字体渲染技术是使用黑白两色来填充像素，有时这种方法也被称作二值渲染（bi-level rendering）。目前打印机仍在使用这种方法，但由于打印机的高分辨率，打印的效果可以很好地还原原始的设计。
然而当这一技术应用于屏幕时，早期屏幕的低分辨率的局限性使得字体的呈现效果并不好。虽然肉眼无法分辨每个像素，但是难看的锯齿边缘却很明显。
灰度渲染（Grayscale rendering）
从上世纪九十年代中期开始，我们的前人开始采用了一种很聪明方式，虽然当时的分辨率依旧很低，但可以控制每个像素的灰度，这就可以在栅格化的图像中存储更多的信息，以使字体边缘变得更加平滑。这就是灰度渲染。
在灰度渲染中，边缘的像素不再是纯黑的，它的灰度值取决于理想的字型在此像素所覆盖的面积比例。这样，字体的轮廓看起来更加平滑，设计的细节也更加丰富。屏幕上的字体不再仅仅满足于清晰可辨，它们甚至还可以体现字体本身的特征和风格。
这一方法也被称作抗锯齿渲染，与照片重新采样（resampled）到一个较低分辨率时的原理是相同的。我们的眼睛和大脑在理解灰色像素所包含的信息时，会将它转换为字型的轮廓，这就让我们可以获得与原始设计极为接近的渲染效果。
类似的效果出现在当我们离报纸上糟糕的图片保持足够远的距离时（Chuck Close艺术）。最近，Gary Andrew Clarke就在他的「Art Remixed」系列作品中将这一原理运用到了极致。
亚像素渲染（Subpixel rendering）
彩色像素提高了分辨率
第三代渲染技术的特点是加入了颜色信息，如果我们把屏幕截图不断放大，可以看到字体边缘有红蓝两色出现，这就是亚像素渲染了。
在LCD屏中，一个像素是由红绿蓝三个紧密排列的亚像素构成的，它们决定了这一像素的颜色和亮度。由于它们是如此之小，以至于肉眼不会把它们看作是一个个独立的色点。如果我们仔细看看上图中被白点标记的「红色」像素，就可以发现它所采用的渲染策略：所有的亚像素都可以单独控制开或关的；若「空白」像素最右侧的亚像素是红色的话，则此像素都将填满红色。
LCD屏中的亚像素渲染
如果我们需要降低图片的饱和度，采用该技术的好处就显而易见了。相比于单纯的灰度渲染，水平方向的分辨率是其三倍。垂直方向的位置和粗细也更加的精确，文本也呈现得更加清晰。
当前的应用情况
浏览器中文本的显示完全依赖于系统的渲染技术，因此当我们讨论Web字体渲染时，关键还是操作系统所采用的渲染技术。然而，由于每个浏览器所采用的技术都不相同，字间距（kerning）、连字（ligatures）、下划线位置甚至它们的粗细都不一样，因此我们无法在这些不同的浏览器中获得完全相同的渲染 效果（即便是在同一个操作系统下）。
更蛋疼的是，在Windows下还可能采用两种技术来渲染——GDI或者DirectWrite。
在我们探寻背后的细节之前，让我们先了解一下每个浏览器所采用的渲染技术：
各种Windows浏览器所采用渲染模型
Windows
在Windows系统下，字体格式对其渲染效果有很显著的影响，比如PostScript字体和TrueType字体之间就存在着巨大的差别。但这种差别并不是由浏览器所引起的，只要底层的字体一样，我们就可以看到完全相同的渲染效果。
尽管这种方法并不十分可靠，但从字体的命名中我们可以大致推断该字体所采用的渲染技术，比如，EOT和.ttf格式一定是TrueType技术，反之.otf通常是PostScript技术。但是还有一中封装的字体格式WOFF，它可以包含其中任意一种字体格式。因此光看文件名是不可能清楚它所采用的渲染技术的。除了EOT和.ttf格式文件可以断定是TrueType渲染技术外，其他文件格式所包含的是哪种字体都无法确定。因此在你购买字体时，你最好对想要购买的字体做一番了解。（@Ryekee: 我觉得这一句根本不用翻译，中国还有人会买字体么？）
TrueType和PostScript的区别在于描绘曲线时所采用的数学方法不同，但这一差异对栅格器并不会造成太大的影响，只有字型设计人员才需要考虑着两者的差别。另一个重要的区别就是所采用的字体微调的方法。PostScript只包含了组成字体的各种元素的抽象位置信息，而TrueType则包含了非常详细的底层命令，直接接管了渲染的进程。然而造成两种渲染技术的差异并不是它们的设计理念上的差别，而是源于Micro$oft采对TrueType采用了新的渲染引擎。
Windows: TrueType字体
Windows灰度渲染下的TrueType字体渲染效果
在Windows XP中，许多浏览器都是采用灰度渲染来渲染文本的。尽管效果比不上Mac OS所采用的亚像素渲染，但字体在大尺寸下的效果依旧出众，字体的边缘很平滑。
Windows GDI ClearType渲染下的TrueType字体渲染效果
ClearType渲染技术是Micro$oft对亚像素渲染的「借鉴」。它最早供GDI使用——经典的Windows API。尽管从Windows XP系统开始就可以使用该技术，但是所有的浏览器都并没有采用该技术。在Windows 7和Vista中，ClearType是默认开启的，从而使得其成为了应用最广泛的渲染技术（如果算上所有的互联网用户的话）。但需要注意的是，ClearType只适用于TrueType类Web字体，并不适用于PostScript类字体。
奇怪的是，Micro$oft吸纳了水平方向上亚像素渲染技术的优点，却全然抛弃了垂直方向上平滑度的改进。因此ClearType实际上是亚像素渲染和黑白渲染的杂交，结果使得字体在轮廓线上出现了锯齿，在大尺寸字体下更扎眼。即便是最精细的字体微调也无法消除曲线上难看的锯齿。
对于大尺寸的字体，ClearType表现得十分糟糕，水平方向上精确度带来的好处非但并不明显，粗糙的轮廓甚至毁了整体的渲染效果，技术仿佛退回了解放前。
DirectWrite模式下的TrueType字体渲染效果
至少对Windows字体渲染技术来说，未来是光明的。在GDI的接班人DirectWrite中，Micro$oft为ClearType增加了垂直方向上的平滑度。新的渲染模型（目前应用于IE9）在所有尺寸下都提供了平滑而精确的渲染效果。与Mac OS不同的是，Micro$oft仍试图将轮廓与全像素高度（full pixel heights）对齐，如果字体微调得当的话，此举将可以获得更好的渲染效果。更牛逼的是，DirectWrite可以进行亚像素定位（subpixel positioning），让字符间的间隙与设计的完全相同，还改善了字体纹理的匀称度。
Windows: PostScript字体
GDI灰度渲染模式下的PostScript字体渲染效果
在使用GDI渲染模式的浏览器中，PostScript类型的字体是通过灰度渲染呈现的。不同于流行的GDI-ClearType渲染模式，这种渲染模式可以使得字体轮廓更加平滑；与TrueType字体微调不同，PostScript字体微调更为简单，甚至可以自动完成。
DirectWrite下的PostScript字体渲染效果
DirectWrite不仅可以使字体的边缘更加平滑，它也可以运用亚像素渲染技术来渲染PostScript类字体。但与TrueType渲染不同的是，为了能够更加真实的反应笔画的粗细，它使用了更多的灰色像素。经过优化的渲染效果更加接近Mac OS的渲染了。
未来的某个时候（浏览器厂商并不会像我们期望的那样快的采用新技术），DirectWrite将取代Windows过时的渲染技术，到那时我们就不必再纠结于选择TrueType类字体还是PostScript类字体了。
Windows: 无微调字体
灰度渲染下的无微调字体渲染效果
在Windows老式的灰度渲染模式下，无微调字体的渲染效果出奇的好。因为字体并没有通过微调与全像素对齐，栅格器也没有对其进行强制处理，其效果很接近iOS上的字体渲染。遗憾的是，目前来看，无微调字体还不适合使用，我们可以看看下图：
GDI-ClearType下的无微调TrueType字体的渲染效果
在许多有关Web字体渲染的讨论文章中都指出，GDI-ClearType极度依赖良好的字体微调。水平方向上的笔画需要通过微调来精确定义，否则笔画的粗细可能会不恰当。在大尺寸字体下，微调也极为重要。无微调字体在轮廓线在没有对齐像素网格的地方会出现一些「疤」，正如上图所示。
DirectWrite下的无微调字体的渲染效果
在DirectWrite模式下，无微调的PostScript和TrueType两种Web字体的渲染效果几乎完全相同。这两种格式的文本字体仍需要良好的微调才可以保证笔画的清晰度和一致性。屏幕显示的字体可能可以侥幸避免无微调带来的不良效果，因为在大尺寸下，微调与否区别并不大。
Mac OS X
Mac OS X下的字体渲染
在Mac OS中，所有的浏览器都使用Quartz渲染引擎。TrueType和PostScript字体采用完全一样的渲染方式，所以字体微调可以完全无视了卧槽，这正是两种字体的核心区别啊！所以Mac OS的亚像素渲染简直是屌爆了，我们可以放一百万个心。栅格器不会试图解读构成字体的笔画和特征，因为所有东西都可以通过暗像素来呈现。字体形状不会被解读，因此也就不会被曲解。Quartz渲染引擎十分可靠，因为它不会自作聪明瞎搞瞎弄。另外，Apple似乎也会采用一些很美妙的智能方案去增强渲染效果，但是这种技术没有说明文档，也完全超出我们的控制范围。
不过在某些情况下，这种技术也会导致一些不理想的效果。比如在上图所示的例子中，由于大「T」的高度不是全像素值，而Mac OS不会强制字母对齐，因此在字母的顶端会有一条灰线。可惜这个蛋疼的情况不是设计者所能改变的。不过，这种模糊的现象只有在特定的字号下才会出现，因此一般只需要改一改字号就可以解决这一问题。体会一下修改字号带来的阵痛，我们就可以获得一个非常棒的渲染效果啦。
在Mac上另一个比较蛋疼的是，字体会渲染得更重一些。在文本字体的大小下会更明显，同样地字体在Mac OS下会「黏乎」一些，而在Windows下则比较清淡。
iOS
iOS上的字体渲染
iOS上的渲染遵循与Mac OS一样的原理，两者主要的区别就是iOS不采用亚像素渲染。主要的原因就是当设备旋转之后，系统需要重新计算并更新渲染，因为亚像素的排列方向发生了变化。Apple竭尽全力想要减少CPU的使用。
结论
网站访客所使用的浏览器和操作系统差异很大，有些是没有及时更新，有些是公司的政策所规定，不是用户的错。我个人的建议是尽可能的为用户提供最佳的渲染效果，而不是指责操作系统厂商，或者要求用户更换更好的操作系统（@Ryekee：比如Mac OS？:-P）。
在Mac OS和iOS上，我们对渲染没有控制权，但这完全可以接受，因为渲染引擎简直太棒了。除了字体渲染得太过黏乎之外。或许有一天，Web字体服务可以根据不同的平台提供稍浓或稍淡的字体来改善字体的一致性。
在Windows上，字体微调极为重要，尤其是对TrueType类字体而言（这是万恶的IE6到IE8唯一接受的Web字体格式）。除此之外，选择TrueType还是PostScript字体格式也会对渲染的结果造成重大的影响。除了小号字体的微调外，PostScript的渲染效果完全不逊色于TrueType。尽管 DirectWrite为Windows提供了令人身心愉快的渲染效果，但是良好的字体微调依旧很重要。
实际应用：改善屏显字体的渲染效果
一些Web字体的提供商，比如Typekit和Just Another Foundry，已经开始提供PostScript类字体了。
JAF Domus Titling字体在不同的环境下的渲染效果
在IE6到IE8中，GDI ClearType渲染效果的锯齿无法避免，但在其他环境下都可以得到平滑的渲染效果。这就意味着我们还是需要使用带有微调的TrueType字体，因为操蛋的IE6 - 8还是有着巨大的市场份额。
Typekit上的Underware设计室设计的Bello字体就是PostScript格式的Web字体（右侧），它比左边的TrueType字体轮廓要更顺滑一些
Typekit也开始采用混合策略，提供PostScript格式的屏显字体，为Windows GDI提供更平滑的渲染效果。但这需要为制定一些视觉效果的评判标准。
你们可能会问我，「你大爷的究竟要如何定义屏显字体（display font）啊？」
事实上确实很难画一条清晰的线来定义屏显字体。有些字体供应商提供人工微调的TrueType字体，用作正文显示非常不错（可惜的是转换成PostScript格式可能会丢失微调信息）。一些文本字体在大尺寸的情况下表现也相当不俗，因此理想的情况是同一字体提供两套不同的格式。不过这会增加UI以及后端的复杂度，目前来看并不现实。
未来发展
越来越多的字体设计师都开始注意到Web字体所带来的技术问题，尤其是TrueType字体的微调。随着Web字体产业的崛起，他们愿意付出精力为屏幕显示而优化字体。在不远的将来，我们将看到大量精心设计的字体问世（或者至少是对现有字体的更新）。
随着屏幕分辨率的增加（以及对栅格器的重大改进），我们慢慢地不再担心字体渲染的技术细节。采用GDI渲染模式的浏览器必将拖后腿，正因为此，未来数年内，我们都还无法放心的使用无微调的TrueType字体。只有当这一类浏览器用户比例降到足够低的程度的时候，TrueType字体微调（耗时又需要高超的技巧）才可以被扔到一边。尽管目前市面上几乎所有Web字体都是TrueType格式的，我仍希望字体行业能够大规模转向PostScript格式，因为这种字体能为设计师减少绝大部分的工作。
相关资源
- 《Firefox6 中的 DirectWrite 字体渲染》，Mozilla官方博客
- 《JAF Domus Titling 字体》，Just Another Foundry
- 《Typekit 更新：为 Windows 改善字体渲染》，Typekit 官方博客
- 《OpenType/CFF 相对于 TrueType 的优势》，Typblography
