再谈 Web 字体的现状与未来

Date:2009-08-05 10:13:12| Industry|Browse: 149|Source: cnBeta.COM|Author:

Follow FontKe on Wechat to get Zcode
Scan the Qrcode to participate in the SVIP lottery

Introduction感谢COMSHARP CMS的投递新闻来源:arstechnica.com随着 CSS3 渐入人心，Web 字体逐渐成为话题，这种

感谢COMSHARP CMS的投递新闻来源:arstechnica.com随着 CSS3 渐入人心，Web 字体逐渐成为话题，这种即将让未来的 Web 更加丰富多彩的技术（或者说标准）拥有多种可能，虽然 .webfont 即将提交 W3C，然而它的实现仍然遥遥无期，等待是痛苦的，因此，一些公司联合字体设计推出兼容 @font-face 标准的技术，鉴于主流的浏览器都支持 @font-face，这种技术在 .webfont 实现之前不失为一种不错的替代品，参阅关于 Web 字体：现状与未来。

上图是 Typotheque 公司提供的兼容 @font-face 标准的 Web 字体技术示例。

作为 CSS3 的一项改进，尤其是 @font-face 标准的对手，.webfont 技术为 Web 设计师提供了更丰富的字体选项。尽管 Firefox 个 Safari 一直积极地推动 Web 中的 TrueType 和 OpenType 技术，然而将商业字体放到服务器供调用会侵犯到字体商的权益，鉴于此，至少有三家公司寻求使用特殊技术，在兼容 @font-face 的前提下，实现对授权字体的访问，多家字体商有意支持该技术，同时，一些大的字体商表示支持 .webfont。

为什么要费这番周折？

几年前，微软购买了10款字体的版权供 Web使用，就是所谓的 Web 字体，我们的 Web 就活在这 10 款字体下，不过老实讲，尽管有10款，但接近98.7% 的 Web 事实上只用其中的4款，Times, Arial, Verdata, 以及 Georgia。其中的原因正象 Web 设计师 Richard Rutter 所说的那样，设计与可访问性问题。

尽管这些字体设计优良，尤其在目前普遍存在的低分辨率显示器上，然而，这些有限的字体显得千篇一律，尤其是公司网站用户，他们更希望实现差异性，比如，他们希望通过定制的字体表达公司的识别信息。Rutter 解释道，最起码，更多字体选项可以能让网站看上去更有个性。

除了美学上的考量，还有一些实践上的考虑，尤其是可访问性。一些 Web 设计师将个性字体转换成 Flash 或图片，这样做有很多问题。真实的字体意味着更少的数据量，尽管对多数宽带用户来说算不上什么，但对一些使用移动设备的用户来说却十分重要，真实的字体还有更多好处，比如可以缩放，翻译，索引，可以使用读屏软件朗读。另外，诸如希腊文，泰文，中文一类的语言目前没有很好的通用 Web 安全字体，如果能实现自定义字体，将是一种福音。（译者注：作者显然忘记了中文字库庞大的文件尺寸问题）

现状：TypeKit, Fontdeck, 以及 Typotheque 的 Web 字体服务

如今，已经有不少服务商提供基于 @font-face 标准的 Web 字体服务，然而在字体盗用异常简单的今天，如何说服字体商提供在线许可？于是便有了 TypeKit，Fontdeck 一类的服务，他们拥有合法授权的在线字体，通过向 Web 设计与开发者提供一段 CSS 和 JavaScript 代码实现对这些在线字体的访问，除此之外，一些字体商也推出一些类似服务。

Typotheque 的 Peter Bilak 说，我们的服务使用 TTF 字体，但隐藏了这些字体的真实的地址，因此它们不会被非法复制，我们对字体进行了处理，去掉了浏览器无法识别的部分，然后向用户提供一段代码，这样文件尺寸只有原始文件的10%到20%大小。

以上是 Typekit 的编辑界面

Typekit 和 Fontdeck 的工作方式和 Typotheque 类似，他们按域名签发字体许可，因此别的网站即使得到了这段代码，也无法使用，他们通过使用字体片段来降低数据量。Fontdeck 由 Rutter Clearleft 设计公司开发，可以针对不同浏览器推出不同字体格式，比如 IE 支持 @font-face，但只限于微软自己的 EOT 格式。对于那些不支持 @font-face 的浏览器，他们也有不同的应对措施，比如 Typekit 会使用 sIFR or Cufón 替代方案。

不过他们也受到了一些质疑，比如，这样的机制依赖第三方服务，受限于他们的在线时间，另外一个问题就是费用，字体许可加上带宽的占用不是一个小费用，另外，还有人指出，这些方案并不能真正阻止字体盗用，仅仅是让盗用更难了一些。

针对这些质疑，Rutter 表示，依赖第三方服务的系统到处都是，想想 Google 地图或 Amazon S3，人们没必要担心其可靠性。而价格问题不同服务商各不相同，不过让更多的公司参与进来会让价格降低到市场能够接受的水平，关于字体盗用，字体商们并不喜欢 DRM，他们希望字体很容易部署使用。Typekit 的 Jeffery Veen 在其公司博客中解释道，我们的目的是消除通常意义上的滥用。

未来：我们自己的 Web 字体

虽然上面说的这些 Web 字体方案有诸多缺陷，他们在目前至少是已经可以使用了的。不过人们还是提出了一些专门的 Web 字体提议，微软最近再次向 W3C 提交 EOT 提案，不被仍被拒绝，这次提交的 EOT 方案命名为 EOT Lite，似乎意味着一种妥协，不过 Readable Web 的 Richard Fink 解释到，EOT Lite 比 TTF 文件略有不同，包含调整过的文件头以及不同的文件后缀。Font Bureau 的 David Berlow 则提议在标准 OpenType 字体中加入一个许可表，以便浏览器查验某个字体是否允许用于某个网站。

而由字体设计师 Tal Leming 与 Erik van Blokland 提议的 .webfont 方案则受到了多数字体商乃至 W3C 的关注。.webfont 是一种经过 Zip 打包压缩的文件包，包含两个文件，info.xml 以及真正的字体文件，前者包含了 XML 格式的许可信息，受益于其 Zip 压缩格式，这种字体文件尺寸至少减少了40%，不过字体公司应该提供转换工具，实现字体片段机制，这样，文件尺寸还会降低。（译者注：这或许会解决中文字体文件尺寸庞大的问题）

目前，支持这一提议的字体公司包括 House Industries, FontShop, Hoefler & Frere-Jones 等，甚至 Typotheque 自己也支持这一提议，Bilak 说，这不是一个非常理想的方案，是一种妥协，虽然仍不能消除字体商的所有疑虑。

而浏览器设计商似乎也愿意参与到这个技术中，尤其当 W3C 接纳该技术成为标准时，不过浏览器设计商至少要等待 W3C 完成系列工作才能提供支持。.webfont 是一种未来的方案，也许要两年或四年，Bilak 说，也有人认为这一过程需要五年或更长时间。