跳到主要内容

字体基础知识

待办事项（面向维护者）
  • 添加图片；
  • 添加更多字体的示例；
  • 考虑将部分选用字体相关的内容迁移到「样式设定」篇章。
本节学习目标
  1. 掌握字体基础知识，知晓如何获取字体；
  2. 获取字体并安装需要使用的字体；
引用声明

本篇章部分内容引用自 VCB-Studio 论坛的文章《超级字体整合包 XZ —— 字体从此不再是问题》。

字体获取​

成为一名合格时轴的第一步，便是学会获取、识别并灵活使用字体。
感谢 VCB-Studio 为我们提供了一个「超级字体整合包 XZ」（后文简称「整合包」），该字体包收录了众多种类的字体，可以供我们制作字幕和观众观看使用。
字体包详情（后文简称「帖子」）可以参见这里，并可以从这里下载到（如无法访问，可通过帖子中其他链接下载），在此向整理者表达感谢。
帖子中也提供了一些字体知识，请务必仔细阅读。

字体更新

由于整合包已发布很长时间，部分字体（常用的如方正准圆、兰亭黑、兰亭圆、雅宋、（锐）正黑及汉仪部分字体）版本较老，正式使用时应注意更新到新版本（进组获取）；其中，方正雅宋、（锐）正黑系列由于新版字体更改了字体基线或修复了字体名称错误，若和后期使用的不是同一版本，将导致显示差异；

安装字体
  1. 由于整合包字体较多，通常不建议全部安装，而是只安装部分常用字体，其他字体在用到的时候再安装；
    • 安装过多字体会导致系统及部分软件（如 Office）开启速度变慢，也会占用较多系统盘空间；
  2. 相同字体具有多种字符集标准版本时，通常只需要安装最高规格的版本；
  3. 在 Windows 系列系统上安装字体时，应在字体文件上单击右键，选择 为所有用户安装；这样才会将字体安装到 C:\Windows\Fonts 目录下，否则部分工具链无法识别到已安装的字体。

此外，不时也会有新的可用字体放出，而整合包由于不会定期更新，所以只能获取到整理当时的字体。
如果你在平时遇到了整合包所没有收录的字体，应养成随手收藏的好习惯。

禁止商业使用

整合包中许多字体为商用字体，仅供学习参考和非商业使用，商业使用请购买正版授权。

字符处理基本原理​

提示

字符编码和字体原理内容非常多而且非常复杂，由于本篇章主题为「字体基础知识」，因此只讲解和字幕制作相关的最基本的部分字体和编码概念。

字

开始之前，需要先区分以下几个概念。

  • 字 / 字符（character）：语言学中语意的最基本单位，一个完整的汉字和一个英文字母都可以是一个字；
    • 例如：「明」是一个字（符），「A」也是一个字（符）；
    • 前文说到的是狭义上的字，通常 UTF‑16 编码的 1 个代码单元（code unit）可以描述，广义上的字 / 字符应该是字形簇（Grapheme Cluster），对应 1 个甚至多个 Unicode 标量值（Unicode Scalar Value），1 个 Unicode 标量值通常由 1 个代码单元或 1 个代理对（surrogate pair）来描述。比如一个简单的 emoji 😀或生僻汉字 𠀀 对应的就是 1 个 Unicode 标量值，需要用到 1 个代理对，也就是 2 个代码单元来描述；
  • 字形（glyph）：一个抽象的图形符号，不依赖于特定设计；
    • 例如：我们每个人手写同一个汉字的样子都会有些许出入，也许「永」字我喜欢捺稍微写长一点，你喜欢稍微写短一点，但是我们都能认出它是同一个汉字；
    • 汉语中，当同一个字的简体和繁体写法不同时，我们认为是不同的字形，例如简体的「门」和繁体的「門」是不同字形；
    • 汉字文化圈内，不同地区对同一字的写法不同是否为同一字形涉及到「中日韩统一表意文字」的问题，篇章内会具体介绍；
  • 字型（font）：在印刷行业中，传统的意义上（铅字时代）指某一整套具有同样样式、字重和尺码的字模，现代意义上因为可以排版印刷随意改变字体大小则不再把尺码作为必备属性；
    • 例如：一整套用于铅字印刷的宋一、一套方正兰亭黑的 Regular 就叫一套字型；
    • 在本篇章内，我们认为同一字形的不同写法就是不同的字型；
  • 字体（typeface）：是由一个或多个字型组成的集合，每个字型由具有共同设计特征的字形组成；
    • 每一个字型都有特定的字重（weight）、风格（style）、宽度（width）、倾斜度（slant）、斜体（italicization）、装饰（ornamentation）、设计师或铸字厂。
    • 具体实现上，一个字体就是一个字体家族（font family），其下的不同字型会放在的不同的字体文件中，例如方正兰亭黑的不同字重「方正兰亭细黑」和「方正兰亭粗黑」就是两个独立的字体文件。

现代计算机系统处理文本显示时，通常采用字符编码记录和文件存储字形图像数据相结合的形式。

通常在记录和传输字符本身时只使用字符编码，只有当需要将字符展现出来时，才会从字库提取相应字形的图像数据并使用相应方式渲染成可以看见的图像。
一个最常见的例子是我们在互联网上发送文字时，通常会发送字符的编码而不是发送字符的图像数据。
当接收者接收到字符编码后，接收者的设备会根据字符编码从设备存储中提取相应字形的图像数据并通过排版引擎展现，这样做大大减少了直接传输字形带来的额外通信开销。
如果不同设备针对同一字符所存储的图像数据不同，那么同样的字符编码在这些设备上展现时，会根据该设备所存储的字形图像数据将字符展现出来。因此，当字形图像数据不统一和使用的排版引擎不同时，同样的字符在不同设备上的显示效果可能是不同的。

假设我们希望接收者看到的字符图像和发送者看到的字符图像尽可能是相同的，又该怎么办呢？
答案非常简单，我们只需要命令接收者的设备采用相同的图像数据将字符展现出来，这个问题便迎刃而解。
要让接收者使用指定的字符图像渲染，接收者就需要知道以下几个信息：

  • 要显示的是什么字符（字符编码）；
  • 要用哪一套字型显示（字体名称）；
  • 这个字符是什么样子（字形数据）。

现代计算机系统所使用的字体文件便是以上三者的结合体，下图很好地展示出了字体文件是如何存储字形图像数据，又是如何通过字符编码与字形联系起来的。
该截图来自字体工具 fontforge，若有兴趣详细了解，可参考本篇末尾的字体工具（进阶）。

Aegisub 主界面

图 - 一个字体的例子

排版引擎​

现阶段没有完美的跨平台像素一致排版引擎，也没有任何排版引擎能保证和其他排版引擎可以达成完全一致的排版效果。常见的排版引擎有：

  • GDI / GDI+ 和 Uniscribe：Windows 的传统排版引擎，一些古老的软件如 Aegisub 和 VSFilter 就在使用；
  • DirectWrite：Windows 7 开始提供的现代化排版引擎，相对于 GDI 路径可以提供更多的 OpenType 特性支持和更好的渲染质量，而且与 GDI 有优秀的互操作性，libass 在 Windows 上就默认使用它；
  • DWriteCore：目前通过 Windows App SDK 提供，最低运行系统版本是 Windows 10 1809。DirectWrite 的重新实现，而且有跨平台计划，大部分与 DirectWrite 相同；
  • Core Text：Apple 系的系统排版引擎；
  • HarfBuzz：跨平台排版引擎，但一般只在 Linux 上默认使用

字符编码​

上一小节中，我们多次提到了字符编码这个概念，对应于 Unicode 标量值。
从上图中我们可以看到，每个字符编码在字体文件中均对应一个具体的字形数据。若某个字符编码在某种字体的文件的相应位置（码位）上没有对应的字形数据，则称该字符在该字体中缺字。
此时若要求系统展现该字符，系统则会遵从一定规则找到已安装的拥有该码位字形图像数据的字体，并从中提取字形数据替代并展现出来，这个过程叫做回滚（fallback）。 如果系统中所有字体都不含有这个码位的字形数据，则通常会根据不同排版引擎处理为不显示或展现一个「叉」的符号。
在任何时候都应避免出现缺字导致回滚的情况。 不仅限于字幕，在任何场合缺字导致回滚通常都是不美观的。

最简单的编码——ASCII 编码​

提示

计算机的世界是基于二进制的，因此我们通常用 0x?? 作为一个字节（8 位）的十六进制表示，每个「?」代表 4 位二进制数。

ASCII 编码（American Standard Code for Information Interchange，美国信息交换标准代码）是基于拉丁字母的一套电脑字符编码标准。它主要用于显示现代英语，而其扩展版本延伸美国标准信息交换码则可以部分支持其他西欧语言。
ASCII 编码的每个字符均为一个字节（8 位）长度，其包含的字符和编码的对应关系可参考这里，本文不再赘述。

以 ASCII 可显示字符表为例，字符「A」的编码为 0x65（十六进制），存储它需要 1 个字节，而存储单词「duck」则需要 4 个字节。
假设现在我们有两个基于 ASCII 编码的字体 sky font（天空体） 和 sea font（海洋体），字符「A」在它们各自的 0x65 码位上将显示出不同的字型。

注意要和 Windows 的当前代码页（ACP, Active Code Page）结合，在不同的区域设置下默认使用不同的字符编码，如英文系统下就一般使用 ASCII 编码，简体中文系统就一般使用后文会提到的 GB2312 / GBK 编码。

统一码（Unicode）​

上述的 ASCII 编码只使用一个字节长度编码字符，因此它最大能编码的字符数量为 256。 这显然不能满足字形众多的汉字及其他多字形语言编码。

要解决这个问题，只能用更多的字节来编码一个字符，此时统一码（Unicode）便于 1980 年代末期应运而生了。
Unicode 的编码范围为 0x000000 到 0x10ffff，被划分为 17 个平面（plane），第一个字节表示字符所处的平面（0x00～0x10），后两个字节表示字符在该平面中的码点，每个平面有 65536 个码点（0x??0000～0x??ffff）。
Unicode 的具体平面的划分可参考这里。

中日韩统一表意文字​

提示

本部分大量引用了维基百科相关页面的内容。

在 1970～1980 年代，许多东亚国家和地区都制定了自己的语言文字所使用的编码，如中国大陆的 GB2312、台湾地区的中文信息交换码及中文标准交换码、日本的 JIS C 6226、韩国的 KS C 5601 等。 然而，每个国家和地区采取自己的编码会使信息交换中因编码转换产生诸多不便。
为了解决这个问题，中日韩组成了联合研究小组。经过各方协商一致，决定将中、日、韩、越、壮、琉球文中起源相同、本义相通、形状一样或稍异的表意文字，在 ISO 10646 及统一码标准赋予相同编码，形成中日韩统一表意文字（CJK Unified Ideographs）。这一作业也被称为汉字等同、汉字认同。
中日韩统一表意文字有两个非常重要的原则，即表意文字认同原则与原字集分离原则。它们是两项对立原则，是统一码整理中日韩统一表意文字的基础。

由于文化发展的差异，同一个汉字可能在不同国家和地区写作不同的字形，如「房」字的第一笔（「户」部的第一笔）在中国大陆写作「点」，在韩国和台湾地区写作「撇」，而在日本标准中写作「横」。
类似地，「冫」「辶」部的汉字也有微小的差异，另外台湾地区还习惯将标点符号写于汉字格正中央。

相同编码的字写法不同的例子（示例通过设置字体实现，纯文本复制无效）

中国大陆写作：房、次、迷。
台湾地区写作：房、次、迷。
日本标准写作：
韩国标准写作：房、次、迷。

在这个例子中，由于几种「房」「次」「迷」字的差异较小，不适合分别作为多个字形，于是按照「表意文字认同原则」，统一码只对「字（character）」而不对「字形（glyph）」编码，会把同一字的不同字形（即异体字）合并。
合并后，几种不同的写法位于同一个点位，拥有相同的 Unicode 编码，具体的字形则交给字体处理。

字形差异与字体选用

因此，同一个字在使用不同国家和地区厂商制作的字体时便会出现字形上的差异，所以一定要使用与要展现的文字所属语言相同的字体，即：中文一定要使用中文字体，日文一定要使用日文字体。
其中一个特例是，当中文字体缺少繁体字形又不得不用时，可以为繁体字使用匹配的日文字体（字体匹配后文讨论）。

与「表意文字认同原则」相对的是「原字集分离原则」，即在各种收字来源中，若有任何字集同时收了两种以上文字字形，中日韩统一表意文字也会临时放弃认同原则，同时收录这些字。
比较具有代表性的是日本 JIS 编码所同时收录的日文汉字「剣」与「劍」。 由于该字的两种字形可能在该国家或地区同时使用，若强行合并会导致读者不习惯没有见过的字形，因此决定均予以保留。

在 Unicode 中，中日韩汉字和部首大多位于 0 号～2 号平面，3 号平面目前已有提案放置甲骨文等古代文字，但和实际应用关系较小。

UTF-8​

Unicode 拥有包括 UTF-8、UTF-16 及 UTF-32 在内的若干种编码格式，我们主要使用 UTF-8 来保存文件。 相比于 UTF-16 及 UTF-32，UTF-8 具有可变长度节省空间、不存在字节序（大小端）问题等优点，被广泛采用。 虽然 UTF-8 没有字节序概念，但也存在可选添加的字节顺序标记（BOM, Byte Order Mark），常见系统中通常 Windows 会在文件开头添加。 UTF-8 是一种可变长度的前缀编码，具体的编码方法并非本文重点，可参考这里的介绍。

文件编码

在现代计算机系统中存储纯文本数据时，通常会将文本以一定方式编码后存储到文件中。
在制作字幕的全流程（翻译、时轴、繁化等）中，都应该使用 UTF-8 编码存储所有中间纯文本文件（.ass 文件也是纯文本文件，而且最好使用 UTF-8 with BOM 编码），以免造成乱码。

字符集标准​

如果把字符编码解决的问题看做是如何给字符「编号」，那么字符集标准所解决的问题则是规定字体中应该含有多少个字符。

注意
  1. 字符编码和字符集标准是两个不同的概念，应注意区分，避免混淆；
  2. 字符集标准不是强制标准，只是规定了满足该标准应有多少个字符，部分字体可能没有足够的字符数却声称自己是某个标准，也有字体达到了更高标准却声称自己满足相对较低的标准。使用时应以实际情况为准。

常见简体中文字符集标准​

以下各标准按收录汉字数量由少到多排序。

  • GB 2312—80：信息交换用汉字编码字符集 基本集，收录 6763 个汉字；
  • GB 12345—90：信息交换用汉字编码字符集 第一辅助集，是 GB 2312 的繁体版（输简得繁），增补103字，共收录 6866 个汉字。
  • GBK：汉字扩展内码规范，收录 21003 个汉字；
    • 伪 GBK：个别字体声称或后缀为 GBK，实则远远达不到 GBK 标准要求的字符数量；
    • 简繁中文：现在一些字体厂商如方正、汉仪不会做 GBK 和 GB 2312 字符集标准的字体，而是在 GB 2312 字符集的基础上多做了一些厂商自己判断的常用繁体字符和生僻字符，通常比伪 GBK 多一点也更能区分出
  • GB 18030：信息技术 中文编码字符集，GB 18030—2000 收录 27533 个汉字，GB 18030—2005 收录 70244 个汉字并替代前者，GB 18030—2022 收录 87887 个汉字并替代前者。
注意
  1. 一般认为符合 GBK 及以上标准的字体均可简繁两用，实践中一般也仅选用 GBK 及以上标准的字体；
  2. 虽然符合 GB 18030 标准的中文字体所包含的字形数更多，但部分字体的 GB 18030 存在一定 bug，实践中不能盲目使用 GB 18030 版本。

常见繁体中文字符集标准​

  • Big5：大五码，收录 13060 个汉字。
    • 不同设计师对于同一字符的字形有不同理解，通常与台湾教育部规定的标准字形不同，而且字体上通常不会标注
  • HKSCS：香港增补字符集，以 Big5 为基础进行扩展的增补字符集，但是本身不包含 Big5 的内容，字体厂商的字体常用的标准有 2004、2008 等。

常见日文字符集（文字セット）标准​

Adobe-Japan1 是 Adobe 公司定义的日语文字字符集标准，并拥有 -1 至 -7 等 7 个追加字符版本，现被广泛使用。
同时，日语字符有两种字形标准 JIS90 字形（旧字形）和 JIS2004 字形（新字形）。字体后缀末尾没有 N 的为 JIS90 标准字形，有 N 的为 JIS2004 标准字形。
字体后缀与字符集标准的对应关系如下。

  • Adobe-Japan1-0：收录 8284 个假名及日文汉字字形；
  • Adobe-Japan1-1：收录 8359 个假名及日文汉字字形；
  • Adobe-Japan1-2：收录 8720 个假名及日文汉字字形；
  • Adobe-Japan1-3：字体名后缀 Std(N)，收录 9354 个假名及日文汉字字形；
  • Adobe-Japan1-4：字体名后缀 Pro(N)，收录 15444 个假名及日文汉字字形；
  • Adobe-Japan1-5：字体名后缀 Pr5(N) / Pro-5(N) ，收录 20317 个假名及日文汉字字形；
  • Adobe-Japan1-6：字体名后缀 Pr6(N) / Pro-6(N)，收录 23058 个假名及日文汉字字形；
  • Adobe-Japan1-7：字体名后缀 Pr6(N) / Pro-6(N)，收录 23060 个假名及日文汉字字形；
注意
  1. 对于同一日文字体，当有更高标准版本字体时，应优先选用更高版本字体；
  2. 对于同时拥有新旧字形版本（N 后缀和无 N 后缀）的同一日文字体，应优先选用新字形（N 后缀）字体。

字体​

我们作为字幕组，通常不关心字体的底层设计，因此本节主要从使用角度出发介绍字体。

字体基本属性​

本节以字体工具 FontExpert 查看到的字体信息为例，介绍字体所拥有的基本属性。 其中比较重要的属性包括：

  • File Name: 字体文件的名称；
  • File Location: 字体文件的位置；
  • Family Name: 家族名称（重要）；
    • 为了字幕文件的兼容性，我们要求在制作字幕时字体名称尽量使用 Family Name，但由于 GDI 的复杂性和黑盒，Full Name 有时也能使用但不推荐；
  • Subfamily Name: 字家族名；
    • 常见的有：Regular、Italic、Bold 和 Bold Italic 等，同一家族下的字体依据这个进行区分。
  • Full Name: 字体全名，理论上是家族名和子家族名的组合，是独一无二的；
  • Version String: 版本字符串（重要）；
    • 大多数情况下，同一字体的新版本可能修复了名称错误、渲染 bug，应尽量选用新版本；
    • 极个别情况下，同一字体的新版本有可能因基线位置改变导致相同参数下显示效果不同，应特别注意；
      • 例如：方正（锐）正黑系列、方正雅宋系列新旧版本；
  • Weight: 字重；
    • 常见的有（以 OpenType 定义为例，由细到粗）：Thin (Hairline)、Extralight (Ultra Light)、Light、Normal (Regular)、Medium、Semibold (Demi Bold)、Bold、Extrabold (Ultra Bold)、Black (Heavy)、Extra Black (Ultra Black) 等；
    • 中文字体可能会用「细」「中」「粗」等字重表述，应注意它们与 OpenType 定义字重的对应关系；
    • 一个字体家族通常只拥有以上列举的其中一种或几种字重，这是由厂商决定的，部分厂商甚至可能有自己定义的字重；
    • 具体到字体的实际实现上，除了可变字体（Variable Fonts）一般只有可以样式链接（Style Linking）的字重才会使用相同的字体家族名（Family Name），不同的字体家族名在设计上可能是同一字体家族
    • 在字体设计时通常会根据线条粗细和位置关系微调笔画，因此字重不是简单的线条粗细区别；
    • 关于字重，我们还会在样式设定篇章中再次讨论；
其他字体基本属性（展开查看）
  • Description: 描述，通常显示字体的格式，如 TrueType、OpenType 等；
    • 当同一个字体拥有 TrueType 和 OpenType 版本时，通常来说应选用 TrueType 字体；
  • Postscript Name: 某种程度上只具有兼容意义；
  • File Size: 文件大小；
  • Copyright: 版权信息；
  • Unique Identifier: 唯一标识符；
  • Opentype: 是否为 Opentype 字体，现代操作系统上大多都已经是 Opentype 字体；
  • Width: 字宽；
    • 常见有：窄体、宽体、正常体；
  • Italic: 斜体；
  • Kerning: 字距（调整字符间距使显示更加美观）；
  • Unicode: 是否为统一码编码；
  • Embedding Rights:
  • Family Style: 家族风格；
  • Vendor ID: 字体厂商代码；
  • Foundry: 字体厂商名称；
  • License Info URL: 版权信息链接；
  • Tables: 字符映射表类型；

字体高级属性（进阶）​

字体设计原理（进阶）​

字体工具​

FontExpert（字体查看）​

待补充

具体使用方式和软件介绍待补充。

FontForge（进阶 / 字体编辑）​

作业​

  1. 获取超级字体整合包 XZ，安装精简包中方正的 GBK 字体和 Fontworks 的日文字体；
  2. 使用合适工具获得汉字「喵」的 UTF-8 编码；
  3. 使用 FontExpert 软件查看字体「方正兰亭准黑_GBK」和「方正兰亭中黑_GBK」的 Family Name。