GSUB Table 是否在 TrueType 字体中广泛使用?

Is The GSUB Table Widely Populated In TrueType Fonts?

长话短说,我在不使用 FreeType 或 HarfBuzz(出于各种原因)的情况下渲染字体,通过手动解析 TrueType 和派生格式来提取元数据和字形信息,以便稍后从它们构建位图和距离场运行时的轮廓。我担心的是必要时可靠的字形替换,即某些序列必须根据语言规则由另一个替换。

我不清楚的是 GSUB table 通常可以假设有多可靠。换句话说,例如,期望阿拉伯字体应该提供包含阿拉伯文字所需替换的填充 GSUB table 是否合理?或者,鉴于这是每个脚本,是否通常假设字体只会提供特殊的、每个字体的替换,而假定整形引擎将任何每个脚本的替换作为全局规则处理?我不担心被替换的字形可能不可用,因为系统会在这种情况下搜索回退,否则会恢复到原始序列。

显然,每个脚本都有一个全局规则集作为后备方案是完全可靠的,但我想尽可能减少它。抱歉,这不完全是一个经验性问题,但我很难找到这方面的很多信息,而不必实际检查各种字体的大量样本。 This overview 似乎暗示将定义每个脚本的替换,但鉴于 table 是模块化的,当然不能保证甚至会有 table,更不用说了所需的定义。如果做不到这一点,是否有任何已知的各种脚本替换数据库?

现代 OpenType 字体文件实际上是一个完全独立的排版程序,文本整形器只能“按照字体的指示进行操作”(即使这需要整形器方面的一大堆复杂性) ,因此有预制的 GSUB 规则列表,这些规则与在字体指定范围之外咨询的整形器捆绑在一起。

将字体视为游戏 rom:虽然您需要一个好的模拟器(文本整形器)来正确 运行 游戏(字体),但模拟器的工作是确保所有复杂的位,例如blitting、内存交换等在正确的时间执行,game 指定会发生什么。类似地,一个好的文本整形器将具有所有(复杂的)逻辑,用于解释如何解释 OpenType 数据,以及如何处理它、以何种顺序、通过多少次等,但数据仅 来自字体,无处可去。

当然,这并不意味着这些类型的列表不存在:它们只是不存在 整形器 中。它们绝对存在于字体构建工具中,因为没有它们设计字体的工作将非常乏味,但每个工具都有自己的列表和预设,当它们生成字体时,所有这些规则都被编码到字体文件本身:字体成为排版的真实来源。

如果你有一个字体文件,你就有了塑造文本所需的所有信息,前提是你的整形器代码按照 OpenType 规范解析字体,并且部分符合性是整形器只允许应用字体是什么。

(当然,有一些可配置性,因为 OpenType 功能是明确设计的,允许整形器 跳过 应用任何或所有功能,但它是不允许 添加 任何它自己的)

说 OpenType 字体是一个完全独立的排版程序是不准确的,"text shaper only gets to 'do as instructed by the font'"。特别是对于像阿拉伯语或梵文这样的脚本,在文本整形器中实现了跨字体的非常基本的通用逻辑。

这意味着支持像阿拉伯语这样的东西并不像实现逻辑来解析 'GSUB' 和 'GPOS' 表并在其中应用查找(操作)那么简单。这绝对不是一件小事,我当然会寻找现有的实现来重用。

您提到您已选择不使用 Harfbuzz。我建议你重新考虑一下。

What I'm unclear about is how reliable the GSUB table can generally be assumed to be. In other words, is it reasonable to expect that an Arabic font, for example, should provide a populated GSUB table containing the substitutions required for an Arabic script?

当然!阿拉伯语字体必须具有 'GSUB'、'GPOS' 和 'GDEF' 表才能正确显示阿拉伯语文本。按脚本/跨字体替换是不可能的,原则上更不用说实践了。

您可能会发现一些有用的资源——有些是旧的(MS Typography 网站已重新发布,因此页面的日期并不总是反映原始发布日期),但内容仍然相关。虽然可以引用 Windows,但它适用于任何 OpenType 布局引擎。