ICU布局引擎

Question

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

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

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

是否值得使用ICU来布局复杂的脚本(因为SDKs windows和apple为系统字体表中的字体提供了足够的支持)？

如果我使用ICU布局引擎，需要付出什么努力？(我可以看到，我必须自己处理所有的字体格式。)

我还遗漏了什么吗？

Answer 1

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

Answer 2

你应该看看D型字体引擎和内部使用ICU的D型文本扩展。请参阅http://d-type.com/page/text_layout

他们说：

然而，ICU LayoutEngine本身并不提供访问字体文件中所需布局表格的接口。根据字体的访问方式，此接口必须由客户端(开发人员)编写。换句话说，开发人员负责打开、关闭和管理实际字体(例如，从文件或内存中)，访问并可选地高速缓存其布局表，并在请求时将这些表提供给LayoutEngine。在过去，这是软件开发人员将ICU LayoutEngine与D型字体引擎结合使用的唯一方式。

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

Answer 3

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