我正在尝试使用ICU来布局复杂的脚本 . 它在布局引擎用户指南（http://userguide.icu-project.org/layoutengine）中有一个示例 . 看起来它很简单，但是当我开始在示例代码中测试它时，我被困在 LEFontInstance 创建 .
它没有任何东西可以满足特定的字体类型（ttf / otf等） . 他们给出了在 letest.cpp 文件中 PortableFontInstance 中定义和使用ttf字体的示例 . 我从所有这些信息中收集到的是，如果我们想要按名称选择特定字体，我们必须编写一个新类，继承自 LEFontInstance 并自己实现字体选择 .
这对我来说非常令人沮丧，因为我认为众所周知的字体格式和系统字体表的使用应该包含在这样的库中，否则我作为用户必须实现字体读取和选择的所有功能 . 布局引擎可以在此之后处理字形 .
是否值得使用ICU来布局复杂的脚本（因为SDKs窗口和苹果提供了对系统字体表中字体的充分支持）？
如果我使用ICU布局引擎需要付出多少努力？ （我可以看到我必须自己处理所有字体格式 . ）
还有什么我在这里失踪的吗？
3 回答
我将在这里添加一个更新的答案，我们（ICU）现在建议使用HarfBuzz而不是ICU 's layout engine. There' s桥接器，允许你使用ICU API来对抗HB，但你应该使用HarfBuzz而不是ICU .
您应该查看内部使用ICU LayoutEngine的D-Type字体引擎和D-Type文本扩展 . 见http://d-type.com/page/text_layout
他们说：
但是，ICU LayoutEngine本身不提供访问字体文件中必要布局表的接口 . 根据字体的访问方式，此接口必须由客户端（开发人员）编写 . 换句话说，开发人员负责打开，关闭和管理实际字体（例如，从文件或内存），访问和（可选）缓存其布局表，并在请求时将这些表提供给ICU LayoutEngine . 过去，这是软件开发人员将ICU LayoutEngine与D-Type字体引擎结合使用的唯一方法 .
有了D-Type Text Layout Extension，幸运的是，这已经不再需要了 . D-Type Text Layout Extension负责处理所有字体特定任务以及与ICU LayoutEngine的交互 . 软件开发人员现在可以使用一个简单的扩展来显示所有支持的复杂脚本，而无需编写自己的字体访问接口 . D-Type Text Layout Extension是D-Type字体引擎的扩展，可以轻松呈现复杂的脚本，从开发人员那里隐藏与此过程相关的所有复杂性以及直接与ICU LayoutEngine连接的需要 .
最好披露为什么建议使用HarfBuzz而不是ICU Layout Engine . HarfBuzz仍然是一个非常新的库（甚至没有达到1.0版本），几乎没有文档，它的可靠性，稳定性和安全性仍然未知，并且没有经过充分测试 . 在HarfBuzz成熟之前，您是否已经决定放弃/弃用ICU布局引擎？如果是这样，那听起来有点不专业 . 我知道ICU布局引擎最初并没有考虑到安全性，并且有许多未完成和未完成的部分（更不用说多年来没有更新任何重要的新功能），但肯定比HarfBuzz更成熟 . 我认为你应该用一些可靠的技术论证和/或测试数据来回复你的建议，解释为什么人们应该切换到HarfBuzz now . 当推荐来自ICU时更是如此 . 是的，HarfBuzz肯定会在未来使ICU LayoutEngine过时，但是，为什么现有的ICU Layout Engine用户此时会切换到新的库？