摘要

  • W3C 于 2010 年 7 月 27 日发布 WOFF 1.0 首份公开工作草案，提出把已有表格式字体封装为面向网页的文件，可压缩字体表并附带独立元数据。2012 年 12 月 13 日，WOFF 1.0 成为正式建议。
  • WOFF2 的首份公开草案发表于 2014 年 5 月 8 日，正式建议发表于 2018 年 3 月 1 日。它通过理解字体结构的预处理和 Brotli 压缩，让同样的字体数据更便于运输。

刊头在编辑电脑上排得漂亮，到了另一台机器却像换了副嗓子。替代字体的字母宽一点，标题就换行；曲线稍有不同，品牌气质也跟着变。网页可以用 CSS @font-face 请求指定字体，问题是文件该怎么寄。没有共同认可的包装，发件人、运输方和收件人各自理解一套，精心设计的字形仍可能到不了读者眼前。

W3C 当年的 WOFF 常见问题说明点出了缺口：链接字体的 CSS 机制已经存在多年，能在各方之间通用的字体文件格式却迟迟未定。浏览器开发者、字体设计者、字厂和网页设计者都要参与这次交接。字体本身可以千姿百态，交货用的箱子却要有共同尺寸。刊头需要的不是浏览器临时重画一个字母，而是把原来那个字母送过来。

2010 年 7 月 27 日的 WOFF 1.0 首份公开工作草案选择了务实的做法。TrueType、OpenType 和 Open Font Format 的字体以一张张数据表组织；WOFF 把这些表放进面向网页的容器，允许压缩，并给元数据、私有数据留出独立位置。浏览器取到文件后再解包用于渲染。删去不用的字形、修改字体轮廓、增加功能，属于打包前对源字体的加工，不是 WOFF 箱子在路上顺手做的事。

分清这两道工序，才能知道设计控制权在哪里。字体设计者决定字形长相，出版者挑选刊头的声音，WOFF 负责运送已有材料。可选的元数据能随包裹写明字体资料，甚至与使用许可有关的信息，却不会改变页面上那个字的轮廓。标签和衣服各有工作；读者看见的字形仍来自箱子里的字体。

2012 年 12 月 13 日的 WOFF 1.0 正式建议把第一代格式定成可引用的标准。它还划清了使用范围：通过 @font-face 链接来的字体供引用它的网页使用，不是自动装进整台电脑供每个程序调用。把一只行李箱送到客房，和在整栋楼里分发里面的衣物，是两个动作。规范要的是前者。

第一代箱子能用，网络上的重量仍值得计算。2014 年 5 月 8 日的 WOFF2 首份公开草案开始更精细地整理内部空间：先针对字体数据结构做预处理，再用改进的熵编码和 Brotli 压缩。它收拾的是表示字形的数据，不是把字母本身压扁给读者看。行李叠得更好，刊头仍按自己的样子出现。

2018 年 3 月 1 日的 WOFF 2.0 正式建议确认了这套方法，并与 WOFF 1.0 使用的 Flate 压缩作了比较。浏览器解包后能重建可用字体；有些表的顺序或变换方式会让重建后的二进制字节与输入文件并非逐位相同。判断刊头有没有正确呈现，要看字形的功能与显示；如果要比文件指纹，必须另行处理字节层面的差别。

第二代格式也保留了网页链接的边界。网站选择把哪款字带到自己的页面，浏览器为这个页面拆包使用。别的应用不会因此获得一套全局安装的新字体。这个限制让字体设计、网页编辑和浏览器实现各做各的事，不把一次下载误当成设备级改造。

2010、2012 年解决的是共同包装；2014、2018 年解决的是更高效的包装。W3C 文件写的是字体怎样旅行，刊头最终长什么样，仍取决于设计者装入箱子的内容。读者看到熟悉的字形时，行李箱已经完成了自己的工作。