ICU布局引擎

Question

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

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

这对我来说非常令人沮丧，因为我认为众所周知的字体格式和系统字体表的使用应该被合并到这样的库中，否则我作为用户必须实现字体读取和选择的所有功能。之后，布局引擎可以处理字形。

是否值得使用ICU进行复杂脚本的布局（如SDK和Windows为系统字体表中的字体提供了足够的支持）？
如果我使用ICU布局引擎，涉及哪些工作？ （我可以看到我必须自己处理所有的字体格式。）

还有什么我在这里失踪？

Answer 1

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

他们说：

的ICU LayoutEngine本身，但是，没有提供访问字体文件所需的布局表的接口。根据访问字体的方式，该接口必须由客户端（开发人员）编写。换句话说，开发者负责打开，关闭和管理实际的字体（例如来自文件或内存），访问并可选择地缓存其布局表，并在请求时将这些表提供给ICU LayoutEngine。过去，这是软件开发人员将ICU LayoutEngine与D-Type字体引擎结合使用的唯一方法。

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

Answer 2

我在这里添加一个更新的答案，我们（ICU）现在推荐使用HarfBuzz代替ICU的布局引擎。有一个桥梁可以让你仍然对HB使用ICU API，但是你应该使用HarfBuzz而不是ICU。

Answer 3

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