长话短说，我在不使用 FreeType 或 HarfBuzz（出于各种原因）的情况下渲染字体，通过手动解析 TrueType 和衍生格式以提取元数据和字形信息，然后在运行时从其轮廓构建位图和距离字段。我关心的是必要的可靠字形替换，即必须根据语言规则将某些序列替换为另一个。
我不清楚的是通常可以假设 GSUB 表有多可靠。换句话说，例如，期望阿拉伯字体应该提供一个填充的 GSUB 表，其中包含阿拉伯文字所需的替换，这是否合理？或者，鉴于这是每个脚本，是否通常假设字体只会提供特殊的每个字体替换，而假设整形引擎将任何每个脚本替换作为全局规则处理？我不担心替换的字形可能不可用，因为在这种情况下系统会搜索回退，否则会恢复到原始序列。
显然，为每个脚本设置一个全局规则集作为后备是完全可靠的，但我希望尽可能地减少这一点。很抱歉，这不完全是一个经验性问题，但我很难找到有关这方面的大量信息，而不必实际检查各种字体的大量样本。该概述似乎表明将定义每个脚本的替换，但鉴于表是模块化的，当然不能保证甚至会有一个表，更不用说所需的定义了。如果做不到这一点，是否有任何已知的各种脚本替换数据库？
说 OpenType 字体是一个完全独立的排版程序是不准确的，并且“文本整形器只能‘按照字体的指示去做’”。特别是对于像阿拉伯语或梵文这样的脚本，在文本整形器中实现的字体之间存在非常基本的通用逻辑。
这意味着支持阿拉伯语之类的东西根本不像实现逻辑来解析“GSUB”和“GPOS”表并在其中应用查找（操作）那么简单。这绝对不是一件小事，我肯定会寻找现有的实现来重用。
您提到您选择不使用 Harfbuzz。我建议你重新考虑一下。
我不清楚的是通常可以假设 GSUB 表有多可靠。换句话说，例如，期望阿拉伯字体应该提供一个填充的 GSUB 表，其中包含阿拉伯文字所需的替换，这是否合理？
绝对地！阿拉伯字体必须具有“GSUB”、“GPOS”和“GDEF”表才能正确显示阿拉伯文本。每个脚本/跨字体替换是不可能的，原则上更不用说在实践中了。
您可能会发现一些有用的资源——有些是旧的（MS Typography 网站已重新发布，因此日期页面并不总是反映原始发布日期），但内容仍然相关。虽然可能会引用 Windows，但它适用于任何 OpenType 布局引擎。
现代的 OpenType 字体文件实际上是一个完全独立的排版程序，文本整形器只能“按照字体的指示去做”（即使这需要整形器方面的一大堆复杂性），所以有GSUB 规则的预烘焙列表，这些规则与在字体指定之外咨询的整形器捆绑在一起。
将字体视为游戏 rom：虽然您需要一个好的模拟器（文本整形器）来正确运行游戏（字体），但模拟器的工作是确保执行所有复杂的位，如 blitting、内存交换等。在正确的时间，游戏指定会发生什么。同样，一个好的文本整形器将具有所有（复杂的）逻辑，用于解释 OpenType 数据，以及如何处理它、以何种顺序、经过多少次传递等，但该数据仅来自字体，无处可去别的。
当然，这并不意味着这些列表不存在：它们只是不存在于 shapers 中。它们绝对存在于字体构建工具中，因为没有它们，设计字体的工作会非常乏味，但是每个工具都有自己的列表和预设，当它们生成字体时，所有这些规则都被编码到字体文件本身中：字体在排版方面成为事实的来源。
如果你有一个字体文件，那么你就拥有了塑造文本所需的所有信息，前提是你的塑造器代码按照 OpenType 规范解析字体，并且这种合规性的一部分是塑造器只允许应用字体中的内容。
（当然，有一些可配置性，因为 OpenType 功能是明确设计的，允许整形器跳过应用它们中的任何一个或全部，但不允许添加自己的任何一个）