28

背景

TextView 总是遇到 RTL（从右到左）语言的问题。由于我只知道如何阅读希伯来语（除了英语），我将谈谈它的问题：

  • 文本对齐（我不是在谈论重力）。作为一种 RTL 语言，希伯来语将单词从右到左排列（与英语相反）。

    为了演示它有多烦人，想象一下，而不是显示“Hello world”。你通常会得到 ".Hello world" 。如果您将它放在一个句子中，这可以很容易地解决，但是当有多个标点符号时就更难了。

  • 元音位置。希伯来语不需要元音来阅读文本，但有时没有它们很难阅读（尤其是圣经）。对于元音，希伯来语有所谓的“NIKUD”，实际上就像字母中的点。Android 中的问题是它们通常被放置在错误的位置。

    为了演示它有多烦人，想象一下，而不是显示“Hello world”。你通常会得到 ".eHlol owrld" 。即使您尝试修复它（将元音始终放在当前字符后一个字符），字母中的位置也不正确（想象“Hello”中的“e”会像“H”一样，因为例子） 。

仅在 4.2 版（阅读此处，在“Native RTL support”下），Google 已修复所有与希伯来语相关的问题（或至少看起来如此）。

问题

希伯来语的问题导致每个以色列运营商和每个定制 ROM 制造商都有自己的解决方案来解决不同的问题，这使得在 4.2 之前的设备上处理 RTL 文本几乎是不可能的。

如果文本同时包含希伯来语和英语字母，事情会变得更加令人沮丧。

我试过的

我已经阅读了许多谈论这些问题的网站，并且我尝试了许多解决方案的变体，但没有一个解决了所有设备上的问题：

问题

这个问题有明确的解决方案吗？

我认为最好的事情是因为 Android 4.2 解决了这个问题，而且 Android 是开源的，我们应该将它的 TextView 导入我们可以使用的库中，但谷歌还没有提供这样的库。

4

2 回答 2

13

可悲的是，我不认为有一个好的解决方案（“好”的意思是“完成工作并且随时可用”）。对于我们自己的支持希伯来语的 Android 应用程序，我们使用了我们多年来开发的自定义渲染机制。渲染机制无所不能：专有字体；双向 (bidi) 分析；字形放置；换行分析；文本流；等等。尝试使用原生 Android 文本处理功能（尤其是 4.2 之前）的一些问题是：

  1. 真的很垃圾的字体。但是，您可以将DejaVu之类的第三方字体打包，效果还不错。正确的字体可以为 nekudot 和 te'amim 1的定位创造奇迹，如果你需要的话。（我同意你关于正确指向位置的重要性；阅读带有错位nekudot的希伯来语文本就像阅读满屏的验证码。）

  2. 越野车比迪烟分析。更糟糕的是，对于不同版本的 Android，这些错误似乎有所不同。修改文本以包含策略性放置的双向格式代码（RTL 标记；LTR 标记等）可以克服许多这些错误（请参阅此处的讨论，这不是特定于 Android 的）。然而，这样做很麻烦，而且由于 Android 版本之间的不一致，很难提前预测框架需要什么帮助。

  3. 对从右到左的问题没有（或考虑不周）框架级别的意识。例如，祝滚动条显示在希伯来文 TextView 的左侧。对于我们的应用程序，我们必须构建一个完整的滚动条系统才能让它按照我们的意愿工作。（好想 Android 是开源的！）

  4. 换行和断字分析不佳。我们测试的至少一个早期版本的 Android 认为每个 nikud 标记都是一个单词边界。当涉及换行时，系统通常不知道如何处理希伯来语标点符号，如 maqaf、gershayim 或 sof pasuk。

  5. 系统无法将一些较新的 Unicode 字符（如 HOLAM HASER FOR VAV-U+05BA-Unicode 5.0 的新字符）识别为希伯来语脚本。

我的建议是，除非你准备自己构建一个从上到下的文本处理系统，否则你放弃在 4.2 之前版本的 Android 上的高质量文本显示，特别是如果你需要支持 nekudot 和 te'amim . 另外，计划使用我在上面前两点中提到的技术。

1圣经的音符

于 2013-04-03T19:51:35.707 回答
2

截至 2013 年 8 月，Android 已发布可能适合您需求的双向格式化程序的 API 文档。这包含在 Android Support v4 库中，我认为它应该在 Android 4.2 之前的版本中运行。

参考：http: //developer.android.com/reference/android/support/v4/text/BidiFormatter.html

于 2013-08-09T22:37:35.103 回答