ICU布局引擎

Question

我正在尝试使用 ICU 进行复杂脚本的布局。它在布局引擎用户指南 (http://userguide.icu-project.org/layoutengine) 中有一个示例。看起来很简单，但是当我开始在示例代码中对其进行测试时，我卡在了 LEFontInstance 创建。

它没有任何东西可以满足特定的字体类型（ttf/otf 等）。他们在letest.cpp 文件中的PortableFontInstance 中给出了定义和使用ttf 字体的示例。我从所有这些信息中收集到的是，例如，如果我们想通过名称选择特定字体，我们必须编写一个继承自 LEFontInstance 的新类并自己实现字体选择。

这让我很沮丧，因为我认为众所周知的字体格式和系统字体表的使用应该包含在这样的库中，否则我作为用户必须实现字体读取和选择的所有功能。之后布局引擎可以处理字形。

是否值得将 ICU 用于复杂脚本的布局（因为 SDK 的 windows 和苹果对系统字体表中的字体提供了充足的支持）？
如果我使用 ICU 布局引擎，需要付出什么努力？ （我可以看到我必须自己处理所有字体格式。）

我还有什么遗漏的吗？

Answer 1

我将在这里添加一个更新的答案，我们 (ICU) 现在建议使用 HarfBuzz 而不是 ICU 的布局引擎。仍然有一个桥可以让您使用 ICU API 来对抗 HB，但您应该使用 HarfBuzz 而不是 ICU。

Answer 2

您应该查看内部使用 ICU LayoutEngine 的 D-Type 字体引擎和 D-Type 文本扩展。见http://d-type.com/page/text_layout

他们说：

但是，ICU LayoutEngine 本身不提供访问字体文件中必要的布局表的接口。根据访问字体的方式，此接口必须由客户端（开发人员）编写。换句话说，开发人员负责打开、关闭和管理实际字体（例如，从文件或内存中），访问和（可选）缓存它们的布局表，并在请求时将这些表提供给 ICU LayoutEngine。过去，这是软件开发人员将 ICU LayoutEngine 与 D-Type Font Engine 结合使用的唯一方法。

幸运的是，有了 D-Type 文本布局扩展，这不再是必需的了。 D-Type Text Layout Extension 负责所有特定于字体的任务以及与 ICU LayoutEngine 的交互。软件开发人员现在可以使用一个简单的扩展来显示所有受支持的复杂脚本，而无需编写自己的字体访问界面。 D-Type Text Layout Extension 是 D-Type Font Engine 的扩展，可以轻松渲染复杂的脚本，向开发人员隐藏与此过程相关的所有复杂性以及直接与 ICU LayoutEngine 交互的需要。

Answer 3

最好透露一下您为什么推荐使用 HarfBuzz 而不是 ICU 布局引擎。 HarfBuzz 仍然是一个非常新的库（甚至还没有达到 1.0 版本），几乎没有它的文档，它的可靠性、稳定性和安全性仍然未知，也没有经过很好的测试。在 HarfBuzz 成熟之前，您是否只是决定放弃/弃用 ICU 布局引擎？如果是这样，那听起来有点不专业。我知道 ICU 布局引擎最初设计时并没有考虑到安全性，并且有很多未完成和未完善的部分（更不用说多年来没有更新任何重要的新功能），但肯定比 HarfBuzz 更成熟。我认为你应该用一些可靠的技术论据和/或测试数据来支持你的建议，解释为什么人们应该现在改用 HarfBuzz。当推荐来自 ICU 时，情况更是如此。是的，HarfBuzz 肯定会在未来让 ICU LayoutEngine 过时，但同样，为什么您现有的 ICU Layout Engine 用户应该在这个时间点切换到新的库？