有些角色的方向性不明确,如空格和标点符号。这可能导致文本布局情况,其中似乎没有单一正确的布局而无法访问其他数据来解决模糊性。请考虑以下文字:
\u05e9\u05e0\u05d1\u05d2abcd!
这四个希伯来字符(明确地从右到左),四个英文字符(明确地从左到右)和一个标点符号(模糊)。如果我使用IDWriteTextLayout
在DWRITE_READING_DIRECTION_RIGHT_TO_LEFT
中布置该字符串,我会得到以下内容:
标点符号似乎被视为从右到左的字符,它在英语的左边开始一个新的从右到左的块,这似乎是完全合理的,特别是考虑到从右到左是指定的阅读方向。然而,期望将标点符号视为与嵌入的从左到右的英文文本相关联的从左到右的字符也是完全合理的,这意味着它应该出现在&的右侧。 #39; d'
我的应用确切地知道应该如何对待这个角色。如何将该数据传递给IDWriteTextLayout
以解决这种歧义?
我找到了SetLocaleName
方法并且认为它必须是答案,但我似乎无法让它影响结果。我在创建localeName
时也找到了IDWriteTextFormat
参数(然后用于创建IDWriteTextLayout
)。
如果我的目标通常是带有一串嵌入式美国英语的希伯来语文本,我认为我想在he
上使用语言环境IDWriteTextFormat
,然后使用{ {1}}在字符范围[4-9]上覆盖区域设置SetLocaleName
。但是,这样做没有任何效果。事实上,我无法在这些地方使用任何语言环境组合对布局产生任何影响,无论是将它们限制在子范围内还是将它们应用于整个字符串。
我认为这些API应该用于此目的是错误的吗?如果是这样,我应该使用哪些API?或者,真的没有办法告诉en-US
以不同的方式解决这种歧义吗?我可能使用API错了吗?以下是我用来创建此IDWriteTextLayout
:
IDWriteTextLayout
答案 0 :(得分:3)
我不认为从Unicode BiDi算法的角度来看有任何不明确之处。设置为IDWriteTextFormat
或IDWriteTextLayout
的初始方向至关重要,但在此之后,运行方向将严格地从代码点派生。
设置区域设置不会改变方向,但它可能会影响整形,最终结果取决于运行字体所具有的特定功能。
我认为你可以在文本的这一部分使用LRE / PDF控件完成 abcd!... 输出。