纵向量度值

教程
量度
作者：Rainer Erich Scheichelbauer
en fr zh

18 二月 2020 发布日期： 10 七月 2012

竖排量度决定文本首行基线位置、行间距，以及在末行基线的下边距。

出于历史原因，至少有3组数值用于处理纵向量度。分别为 hhea、typo（或 sTypo / OS/2）和 win（或 usWin）。根据您的操作系统及应用程序的不同，在屏幕上渲染字体时会使用不同参数进行配置。

不幸的是，这些数值以一种复杂的方式相互关联。但幸运的是，Glyphs 会尽力根据你为每个母版配置的纵向量度值来计算上升部、大写字高、x 字高和下降部的具体数值。然而，当这些值在不同的母版之间发生了变化，可能会产生问题。

自定义参数

因此，为了避免你在同一字体家族间切换字体时出现纵向跳动，最好在所有母版中同步量度值。为此，您可在 “文件 > 字体信息 > 母版“（Cmd-I）中用使用自定义参数。在一个母版中配置完成量度值后，便可轻松将这些参数复制粘贴到其他所有母版的 “自定义参数“ 区域。

但这些数值都是什么意思？以下将为您快速介绍。

hhea

hhea 指 OpenType 规范中的 hhea 参数表。“hhea” 为 “horizontal typesetting header”（纵向排印标头）的缩写。在 Mac、iPhone、 iPad 等 Apple 设备中均使用其中的数值执行渲染。hhea 表记录有三个纵向量度值。为了方便，我以 Glyphs 的自定义参数名称列出：

  1. hheaAscender：上升部高度，以基础网格单位配置
  2. hheaDescender：下降部高度，以基础网格单位配置（负值）
  3. hheaLineGap：建议的行间空隙

OS/2 sTypo (typo) 系列

此类数值记录于 OpenType 规范中的 OS/2 参数表。有人还记得 OS/2 操作系统么？因为这一系列纵向量度值，字体人每天都在纪念它。有时它们被简称为 sTypo 或 typo 系列量度值。我知道部分设计师还会将它们简称为 OS/2 值，但这有待斟酌，因为 win 系列量度值事实上也被保存于 OS/2 参数表中。

  1. typoAscender：上升部高度，以基础网格单位配置
  2. typoDescender：下降部高度，以基础网格单位配置（负值）
  3. typoLineGap：建议的行间空隙

Yannis Haralambous (p.724)曾表示，typo 系列量度值“与 hhea 表中的上升/下降部/行间空隙以奇怪的方式映射，随着字形轮廓的复杂变化，它们并不保持精确的对等关系。据称，Windows 同样会使用这些值来确定理想的布局参数；因此我们还是有一定程度的艺术自由。”。

专业排版软件 XPress 与 InDesign 使用 typoAscender 与 typoDescender 的值来决定文本框中首条基线的偏移量以及文本框的初始尺寸。小于这个尺寸时，字体显示会发生裁切。由于在数字化排版软件中，行距本就是由用户设置的，因此 typoLineGap 将被忽略。

若启用了自定义参数 “使用 Typo 系列量度值”，常见办公软件与浏览器会更倾向于优先使用 typo 系列值，win 系列次之。这种情况下，typoLineGap 建议值将被采纳。

UPM 教条

不过，有一件事你需要注意：“UPM 教条”。在数字化排版的黑暗时期，TrueType/OpenType 规范曾经规定，从 typoAscender 到 typoDescender 的幅面跨度，应该和字体的 UPM 数值一致（通常为 1000 或 2048）。它曾让事情变得非常复杂。

几年前，“UPM 教条”受到了抨击，因为在部分依赖多量度系统的非拉丁文种设计中，根本就无法适配数值。放弃 UPM 教条的支持者之一是 SIL 的Victor Gaultney，他专门为此编写了 最佳实践：设计量度 以及 最佳实践：行量度值。

与此同时，该教条终于完全从 OpenType 规范中删除：

并不强制要求“sTypoAscender - sTypoDescender = unitsPerEm”。但这些数值应当在该字体设计的主要语种环境下，提供恰当的默认行距。


(来源：微软字体排印文档中的 OS/2 sTypoAscender 规格说明)

然而，UPM 教条依然在 Adobe 和微软（针对旧式软件的）兼容策略中维持着影响力，下文将有所讨论。

OS/2 usWin（win）

win（或 usWin）值也是 OS/2 表的一部分。

  1. winAscent：字体渲染框的最顶端
  2. winDescent：字体渲染框的最底端（正值）

注意：超出这两个值的部分，很可能在由 Windows 文本引擎渲染时被切掉。因此，最简单的方法，应该就是确保让字体中的全部内容都处于 win 范围中。所以，通常情况下，win 的范围会包含超过 1000 个单位（或者你设置的其他 UPM 值）。现在，我想你已经猜到问题是什么了。

专业提示：要想找到字体中的最高点和最低点，试用一下 mekkablue 脚本 “Test > Report Highest and Lowest Glyphs”（汇报最高和最低的字符形）。该脚本会列出每个母版中全部字符形的最高点和最低点。

使用 Typo 量度

还有一件事。如果你可以安全地无视早期的 MS Office 版本（2006 年之前），你应该在 “文件 > 字体信息 > 字体” 中添加 Use Typo Metrics 参数。引用 Glyphs 手册中的内容：

Use Typo Metrics（布尔值）如果勾选，支持这一设置的应用程序（特别是 2006 年之后的 Microsoft Office 版本）会偏好使用 “typoAscender”、“typoDescender” 和 “typoLineGap” 来决定竖向位置，而非 “winAscent” 和 “winDescent”。默认关闭。和 OS/2 表中 “fsSelection” 域的第 7 位（“不使用 Win 行量度”）一致。根据 MakeOTF 用户指南，这一位的引入 “比起 Microsoft 直接改变所有字体的行为，所引发的文档文本重排更少。”

所有现代字体都需要拥有这一参数。它告知 Office 应用程序采用 OS/2 值而非 win 量度。所以如果你没有一个很好的理由，就把它添加到字体里吧。

啊对，“一个很好的理由” 可能是，有了这个参数，旧版的 Office 软件（即 2006 年之前的）可能会应用 OS/2 值来裁切，而非 win 值。如果你发现自己的处境是需要支持古早软件的话：嗨。其他的所有人都有权认为这是一个过去的问题。

另一个问题是，在 Microsoft Office 软件中，当 “Use Typo Metrics” 打开时，underlinePosition 和 underlineThickness 的值会被忽略。即使它是关闭的，当下划线不在 winDescent 之上时，会相应地升高。换言之，underlinePosition 加上 underlineThickness 之和必须小于 winDescent。如果 “Use Typo Metrics” 开启，则使用默认的下划线值。如果你觉得在 Microsoft Word 中正确显示下划线比正确的行距更重要，那么禁用 Use Typo Metrics，并遵循一种旧版策略。Microsoft 策略很可能会是个好主意。

策略

不同的字体设计师使用不同策略来找到最佳的竖向量度值。但请当心：在字体迷中，关于哪种才是最好的策略，存在着激烈的争论。

作为示例，在 Vertical Metrics How-to 帖子中，John Hudson 对于在 Microsoft Word 的特殊状况下优化竖向量度给出了他自己的建议 。备注：他所说的 fsSelection 一位，就是 “Use Typo Metrics” 的技术用语。

在任何情况下，使用上面列出的自定义参数，你都可以使用手动设置的值来覆盖自动计算。我来给你展示一下用来手动设置竖向量度最流行的策略。首先，是两种历史上的方法：Adobe 和 Microsoft 策略。它们很容易确定，因为你可能需要为特定的受众设计字体——要么是使用 Adobe 的桌面出版从业者，要么是普通的 Office 用户。这两类人都会期待他们（预先安装的）字体能够产生某种行为。如果你供这些受众使用，最好的办法可能就是让你的字体适应他们。然而，这两种策略都有点过时，因为它们都遵循 UPM 教条。因此，特别是如果你供网页使用，并且/或者如果你需要全面照顾桌面出版和 Office 用户，我建议采用下述的 Webfont 策略。

Adobe 策略

hhea 值和 OS/2 值同步。

  1. hheaAscender = typoAscender
  2. hheaDescender = typoDescender
  3. hheaLineGap = winAscent + winDescent – UPM
  4. typoLineGap = hheaLineGap
  5. “字体信息 > 字体 > 自定义参数”：Use Typo Metrics = yes

通过这种策略，行间距倾向于范围内的最小端。因此，如果你的字体 x 高度较小（小于 UPM 的一半），使用这个策略是一个好主意。优点：字体在 Mac 应用程序和排版应用程序（XPress、InDesign）中的一致性更佳，通常会缩短默认的行距。缺点：Mac 和 Windows 中的显示不同；大写字母上的变音符在 Office 应用程序中可能会被切掉。

Microsoft 策略

hhea 值和 win 值同步，因此是到边界框的最大值。

  1. hheaAscender = winAscent
  2. hheaDescender = −winDescent
  3. hheaLineGap = 0
  4. typoLineGap = winAscent + winDescent – UPM
  5. “字体信息 > 字体 > 自定义参数”：Use Typo Metrics = yes

其他的，如前所述，typoAscender 到 typoDescender 之间的跨度必须加起来等于 UPM 值（通常是 1000）。你可以将下降部深度放入 typoDescender（比如 -200），其余的（800）放入 typoAscender。在这种策略中，hhea 和 win 的上升部和下降部之和最有可能大于 1000（或者其他你设置的 UPM 值）。用这个和减去 UPM 值，将所得的差放入 typoLineGap。

使用这种策略，行距倾向于范围内的最大端。所以，如果你的字体 x 高度较大（超过 UPM 的一半），使用这种方式是个好主意。优点：Windows 和 Mac 应用程序中的显示更一致；变音符在 Mac 应用程序中不会被切掉，因为winAscent 会比 typoAscender. 更高一些。缺点：Mac 应用程序和排版应用程序（XPress、InDesign）中不同，且默认行距可能显得太大了。

Webfont 策略（2019）

在这里，你要先设置 winAscent 和 winDescent 值，因为在 Windows 机器上，“哪些要被切掉、哪些不被切掉” 是最重要的事情。

在 Mac 上，Safari 和 Chrome 使用 hhea 值来定位文本，无视 Use Typo Metrics 设置。当文本被放在 HTML 元素（比如 <div> 或 <p>）中时，浏览器会使用 hheaAscender 加上半个 hheaLineGap，以此计算第一行的基线相对于 HTML 元素上边缘的位置。类似地，HTML 元素中最后一行到该元素下边缘的距离由 hheaDescender 加上半个 hheaLineGap 确定。没错，行间距被均匀分配到一行的上下两边。

需要注意的 Mac 上的例外：Firefox 遵循 Use Typo Metrics 设置，如果设置了 OS/2 typo metrics 也会同样处理，即：首行基线会放在 typoAscender 加半个 typoLineGap，末行基线下面的空间等于 typoDescender 加半个 typoLineGap。不过，如果 Use Typo Metrics 没有设置，它就会表现得和 Mac 上其他浏览器一样，应用 hhea 值。

在 Windows 上，所有浏览器遵循 Use Typo Metrics 参数。如果设置了这个参数，首行基线会位于 typoAscender 加上半个 typoLineGap，末行基线到下边缘的距离会是 typoDescender 加半个 typoLineGap。不过，如果 Use Typo Metrics 没有设置，那么所有 Windows 浏览器都会默认为 win 值。在这种情况下，首行基线会放在从上边缘开始 winAscent 的位置上，下边缘到末行基线的距离则会是 winDescent。

总之，如果我们按照建议来使用 Use Typo Metrics，那么 win 就完全独立于 hhea 以及 typo 值。所以我们可以将 hhea 和 typo 值用于它们本身的目的，包括行距。只需将 win 值设为你字体家族中竖向上最大和最小的值，并且像在 Adobe 策略中一样，确保同步 typo 和 hhea 值。所以我们得到这样的：

  1. winAscent = 竖向最大值 ，向上取整数
  2. winDescent = 竖向最小值（取正值），向上取整数
  3. typoAscender = hheaAscender = 包含重要的大写变音字母（例如 É、Å、Ñ、Ő 等，或者你最在意的、达到基线上很高位置的字母）取整数
  4. typoDescender = hheaDescender = 完整包含下降部（j、g、p、q、y 的最低点，或者你最在意的、达到基线下很低位置的字母）向下取整数
  5. typoLineGap = hheaLineGap = 合理的行间距：约 typoAscender 和 typoDescender 之和的 10–20%，如果（在浏览器和 Office 软件中）行之间的上升部和下降部彼此相碰，则考虑设置得大些；如果你的上升部和下降部的数值很大，则考虑设置得小些
  6. “字体信息 > 字体 > 自定义参数”： Use Typo Metrics = yes

关于找到合适的行距值（第 5 点）：只需设想网页中一个文本框或按钮中的单词。（OS/2 和 hhea）上升部位置上方，和下降部下方的边距各将会是行间距量的一半。

另外，如果不论出于什么原因，你不能或不想启用 “Use Typo Metrics”，可以尝试：

  • typoLineGap = hheaLineGap = (winAscent − typoAscender) × 2

首行基线的偏移量会保持一致，即便没有 Use Typo Metrics 参数。如果你想要支持上述的旧版软件，这样做就合理。然而，行距可能还是会变化，除非 winDescent 与 typoDescender 之差恰好和 winAscent 与 typoAscender 之差完全相同。

注意：Webfont 策略假定你拥有相当规则的量度，即，字体中所有重要的部分都或多或少地符合你的 UPM，有一点点偏差。如果还是看到很多裁切，请考虑调整 UPM。

类似地，如果计算结果导致了过大的间距值（大于 UPM 五分之一的任何值），考虑减小行距，并以同样数值增大 hhea 和 typo 上升部。

应用程序中的首行基线位置

你可能什么都做对了，却还是收到来自用户的抱怨，特别是关于文本框中第一行的位置。在 InDesign 和 Illustrator 中，首行基线位置取决于相应文档中的设置。

不过，最奇怪的事情是默认设置 “字母上缘” 测量的是小写拉丁字母  d。所以，如果你需要保证你的字体和其他字体完美对齐，并且不想耗费大量宝贵的生命来向你的 Adobe 用户解释下面的两个对话框，请考虑同步小写  d 的高度。

译者注：此处指国际版 InDesign 和 Illustrator。东亚版中，下述 “基线选项” 的默认设置均为 “全角字框高度”。
另注：本节采用中文版 Adobe 软件中的界面翻译。“字母上缘” 在英文版中为 Ascent，即字体设计中的 “上升部高度”。

特别是当你制作一款分层字体时，各层形状必须对齐，你可能会用到小写  d 的邪门技巧。查看分层彩色字体教程了解详情。

InDesign：

在 InDesign 中，选择一个文本框，并选择 “对象 > 文本框架选项…”（Cmd-B），在对话框中，选择顶部的 “基线选项” 选项卡，在 “首行基线” 处，你有以下 “位移” 选项：

  • 字母上缘：字体中 d 字符的高度落在文本框的上边缘下面。
  • 大写字母高度：大写字母的顶端和文本框上边缘相碰。
  • 行距：使用文本行距值作为首行基线和文本框上边缘之间的距离。
  • x 高度：字体中 x 字符的高度落在文本框的上边缘下面。
  • 固定：指定首行基线和文本框上边缘之间的距离。
  • 最小值：选取基线位移的最小值。例如，如果选择了 “行距”，且指定了最小值为 1p，那么只有当行距值大于 1 派卡时，InDesign 才会应用这个值。

在 Adobe 帮助页面中寻找更多关于 InDesign 文本框的信息。

Illustrator：

在 Adobe Illustrator 中，选择一个文本框并选择 “文字 > 区域文字选项…”，在随后弹出的对话框中，为 “位移 > 首行基线” 选择一个选项：

  • 字母上缘：字体中 d 字符的高度落在文本对象顶端之下。
  • 大写字母高度：大写字母的顶端和文本对象顶端相碰。
  • 行距：使用文本行距值作为首行基线和文本对象顶端之间的距离。
  • x 高度：字体中 x 字符的高度落在文本对象顶端下面。
  • 全角字框高度：东亚字体全角字框的顶端和文本对象顶端相碰。无论首选项中 “显示东亚文字选项” 是否打开，这一选项都可以使用。
  • 固定：在 “最小值” 框中指定首行基线和文本对象顶端之间的距离。
  • 旧版：使用 Illustrator 10 或更早版本中默认使用的首行基线。

在 Adobe 帮助页面中寻找更多关于 Illustrator 文本框的信息。

TT 对齐区域

如果你以 TTF 格式导出，还是会在 Microsoft Word 之类的应用程序中遇到被切掉的情况，尤其是带有两层变音符的字母（比如越南文或汉语拼音中的那些），那么试试这个：首先确保你的 winAscent 和 winDescent 正确设置，即，它们覆盖了你所希望保留而不被切掉的、最高和最低的字符形。然后，你需在要在 winAscent 和 winDescent 处有 TT 对齐区域。这两个额外的对齐区域，使得渲染器将其位置之内的全部内容包含在内。

如果你手动进行 TrueType 渲染提示，你可以在 “文件 > 字体信息 > 母版”（Cmd-I）中使用 “TTF Zones” 参数添加 winAscent 和 winDescent 区域。

不过，如果你依赖 ttf 自动渲染提示，就还有一个更简便的方法。你只需要前往 “文件 > 字体信息 > 子样 > 自定义参数” 在 “TTFAutohint options” 参数中启用 “Windows Compatibility” 选项。在每个 TTF 子样中都这样做，然后就完成了：

可视化竖向量度

有两种方式来可视化竖向量度：Jan Janeček 的 Vertical Metrics Tool，以及一个名为 “Show Vertical Metrics” 的 Glyphs 插件。你可以在 “窗口 > 插件管理器” 中找到它。

实用脚本

在 mekkablue 脚本中，你可以找到 “Font Info > Vertical Metrics Manager” 和 “Test > Report Highest and Lowest Glyphs”。

“Vertical Metrics Manager” 会尝试尽量应用 Webfont 策略。它可以测量任何一组字符形，并在一定程度上确定可行的值。在将值应用于字体之前，你可以自己编辑这些值。工具提示中提供了大量的说明：如果有什么不明白的东西，只需将鼠标悬停在它上面一两秒钟。运行脚本功能后，脚本会在 “窗口 >宏窗口” 中记录其过程。

“Report Highest and Lowest Glyphs” 仅指出在竖向上最极端的字符形，并在宏窗口中写下简短的汇报。这有助于找到合适的 sTypo 值。

喔啊。现在，喝杯咖啡休息一下。或是来点冰淇淋。或是两个一起来。


2013-05-25 更新：更新为新的参数命名法，改正了几处措辞。
2015-07-17 更新：更正一处错误（typoDescender 必须为负值），删掉了 Typophile 链接以及到 1.3 版的引用，添加了 Webfont 策略。
2016-12-02 更新：添加了关于 TT 区域的一节。
2017-04-25 更新：添加了备注，更正了 Webfont 策略中的录入错误，添加了拓展阅读。
2017-11-30 更新：添加了关于 “使用 Typo 量度” 的备注。
2018-07-04 更新：添加了 John Hudson 竖向量度教程的链接。
2018-10-11 更新：修改了 Wayback Machine 过时的 Wideman 链接。
2019-05-16 更新：添加了 Webfont 策略的更多一般变体，使 “使用 Typo 量度” 更加突出。
2019-08-20 更新：更正了录入错误（感谢 Nathalie）。
2019-09-12 更新：重做了 “Webfont 策略”（2019），在拓展阅读中更新了 UPM 教条的技术信息；更新了截屏；部分重写。
2019-10-30 更新：添加了关于 Adobe 首行基线位移的章节。
2020-02-18 更新：添加了 “实用脚本”，以及个关于 underlineThickness 和 underlinePosition 的段落（感谢 Henrique Beier）。
2020-03-02 更新：澄清了关于 Mac 浏览器如何使用 hhea 值的措辞（感谢 Nathalie）。
2020-03-05 更新：将 defer 改为 differ（英文原文）。

中文翻译及维护：3type (三言)。