长话短说，我在不使用FreeType或HarfBuzz的情况下渲染字体(由于各种原因)，通过手动解析TrueType和派生格式来提取元数据和字形信息，以便稍后在运行时从其轮廓构建位图和距离字段。我担心的是可靠的字形替换，在必要的地方，即根据语言规则，某些序列必须被另一个替换。
我不清楚的是，GSUB表通常可以被认为有多可靠。换句话说，例如，期望阿拉伯语字体提供一个包含阿拉伯语脚本所需替换的填充GSUB表是否合理？或者，考虑到这是按脚本的，通常是否假设字体只提供特殊的按字体替换，而成形引擎则假设将任何按脚本替换作为全局规则处理？我并不担心替换的字形可能不可用，因为在这种情况下，系统会搜索回退，否则会恢复到原始序列。
显然，每个脚本都有一个全局规则集作为后备方案是完全可靠的，但我希望尽可能减少这种情况。很抱歉，这不是一个经验问题，但我很难找到很多关于这方面的信息，除了必须实际检查各种字体的大样本之外。这个概述似乎表明将定义每个脚本的替换，但考虑到表是模块化的，当然不能保证会有一个表，更不用说所需的定义了。如果做不到这一点，是否有任何已知的各种脚本的替换数据库？
说OpenType字体是一个完全独立的排版程序，而"文本整形器只能按照字体的指示进行"是不准确的。特别是对于像阿拉伯语或天成文书(Devanagari)这样的脚本，在文本整形器中实现的字体之间有一个非常重要的通用逻辑。
这意味着，支持类似阿拉伯语的东西根本不像实现解析"GSUB"one_answers"GPOS"表并在其中应用查找(操作)的逻辑那么简单。这绝对不是一项小任务，我当然会寻找现有的实现来重用。
你提到你选择不使用Harfbuzz。我建议你重新考虑一下。
我不清楚的是，GSUB表通常可以被认为有多可靠。换句话说，例如，期望阿拉伯语字体提供一个包含阿拉伯语脚本所需替换的填充GSUB表是否合理？
当然！阿拉伯语字体必须具有"GSUB"、"GPOS"one_answers"GDEF"表，才能正确显示阿拉伯语文本。按脚本/跨字体替换在原则上是不可能的，更不用说在实践中了。
有些资源你可能会觉得有用——有些是旧的(MS Typhography网站已经重新发布，所以日期是页面，并不总是反映原始发布日期)，但内容仍然相关。虽然可以引用Windows，但它适用于任何OpenType布局引擎。
- [OpenType字体的Windows字形处理，第1部分](https://learn.microsoft.com/en-us/typography/opentype/processing-part1]
- OpenType字体的Windows字形处理，第2部分
- OpenType规范，高级排版扩展-OpenType布局
- 注意：这(不幸的是)并没有指出塑造引擎的重要作用
- 开发阿拉伯语脚本的OpenType字体
- 这是一个特定于脚本的主题，与阿拉伯语有关。特别要注意的是关于阿拉伯语整形引擎需要做什么的讨论
现代OpenType字体文件实际上是一个完全独立的排版程序，而文本整形器只能获得"按照字体"；(即使这需要整形器的一大堆复杂性)，因此有一个预先制定的GSUB规则列表，这些规则与整形器捆绑在一起，在字体指定之外进行咨询。
把字体想象成一个游戏rom：虽然你需要一个好的模拟器(文本整形器)来正确运行游戏(字体)，并且模拟器的工作是确保所有复杂的部分，如闪电战、内存交换等，都能在正确的时间执行，但游戏指定了将要发生的事情。同样，一个好的文本整形器将拥有如何解释OpenType数据以及如何处理它的所有(复杂)逻辑，以何种顺序，通过多少次，等等，但这些数据仅来自字体，而不是其他地方。
当然，这并不意味着这些列表不存在：它们只是在shapper中不存在。它们绝对存在于字体构建工具中，因为如果没有它们，设计字体的工作将非常乏味，但每个工具都有自己的列表和预设，当它们生成字体时，所有这些规则都会编码到字体文件本身中：字体在排版时成为真理的来源。
如果你有一个字体文件，你就有了塑造文本所需的所有信息，前提是你的整形器代码根据OpenType规范解析字体，而符合性的一部分是整形器只允许应用字体中的内容。
(当然，OpenType功能的可配置性是明确设计的，允许整形器跳过应用其中的任何或全部功能，但不允许添加自己的任何功能)