如何在 4.2 之前的 Android 版本上处理 RTL 语言? [英] How to handle RTL languages on pre 4.2 versions of Android?

查看:19
本文介绍了如何在 4.2 之前的 Android 版本上处理 RTL 语言?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

TextView 在使用 RTL(从右到左)语言时总是有问题.由于我只知道如何阅读希伯来语(除了英语),我将谈谈它的问题:

TextView always had issues with RTL (Right-To-Left) languages. Since I know only how to read Hebrew (in addition to English), I will talk about its issues:

  • 文本对齐(我不是在谈论重力).作为 RTL 语言,希伯来语从右到左放置单词(与英语相反).

  • Text alignment (and I'm not talking about gravity) . As an RTL language, Hebrew puts words from right to left (compared to English which is the opposite).

为了演示它有多烦人,想象一下,而不是显示Hello world".你通常会得到 ".Hello world" .如果你把它放在一个句子里,这个问题很容易解决,但是当有多个标点字符时就更难了.

For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".Hello world" . This could be easily fixed if you had it in a single sentence, but it's harder when there are multiple punctuations characters.

元音位置.希伯来语不需要元音来阅读文本,但有时没有元音就很难阅读(尤其是圣经).对于元音,希伯来语有所谓的NIKUD",它实际上就像字母内部的点.Android 中的问题是它们通常位于错误的位置.

Vowels positions. Hebrew doesn't require vowels in order to read text, but sometimes it's very hard to read without them (especially the bible). For vowels, Hebrew has what is called "NIKUD", which are actually like dots inside the letters. The problem in Android was that they were usually positioned in the wrong location .

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

For demonstrating how annoying it is, imagine that instead of showing "Hello world." you usually get ".eHlol owrld" . Even if you try to fix it (put the vowels always one character after the current one), the position in the letter wasn't correct (imagine that the "e" in "Hello" would be like above the "H", for example) .

仅适用于 4.2 版(阅读此处,在本机 RTL 支持"下)、Google已解决所有与希伯来语相关的问题(或至少看起来如此).

Only on version 4.2 (read here, under "Native RTL support") , Google has fixed all of the Hebrew related issues (or at least it seems so).

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

the problems with Hebrew has caused each Israeli carrier and each custom ROM maker have its own solution of how to fix the different issues, which makes it practically impossible to handle RTL text on pre 4.2 devices.

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

Things can get even more frustrating in case the text include both Hebrew and English letters.

我已经阅读了许多讨论这些问题的网站,并且我尝试了许多解决方案的变体,但没有一个能够在所有设备上解决问题:

I've read many websites talking about those problems, and I've tried many variants of the solutions, none has solved the problem on all devices:

  • 有些人建议将字符u200F"(或u202D")放在文本的末尾/开头/两者.

  • Some suggest to put the character 'u200F' (or 'u202D') at the end/start/both of the text.

有些人建议使用 Html.fromHtml() 方法并在那里放一些特别的东西.

Some suggest using Html.fromHtml() method and put something special there.

有些人甚至建议改用 WebView(也可能使用 WebSettings.setDefaultTextEncodingName() ).

Some even suggest to use the WebView instead (and maybe use WebSettings.setDefaultTextEncodingName() ).

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

Is there a definite solution for this problem?

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

I would assume the best thing is that because Android 4.2 solves this, and Android is open source, we should have its TextView imported into a library that we can use, but Google hasn't provided such a library yet.

推荐答案

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

Sadly, I don't think there's a good solution ("good" meaning "does the job and is readily available"). For our own Android apps that support Hebrew, we use a custom rendering mechanism that we developed over many years. The rendering mechanism does everything: proprietary fonts; bidirectional (bidi) analysis; glyph placement; line break analysis; text flow; etc. Some of the problems trying to use native Android text handling capabilities (especially pre-4.2) are:

  1. 字体真的很烂.但是,您可以打包诸如 DejaVu 之类的非常不错的第三方字体.如果需要,正确的字体可以为 nekudot—和 te'amim1 的定位创造奇迹.(我同意您关于正确的指向位置的重要性;阅读带有错位的 nekudot 的希伯来语文本就像阅读一整屏的 CAPTCHA.)

  1. Really crappy fonts. However, you can package third-party fonts like DejaVu that are pretty good. The right font can do wonders with positioning of nekudot—and te'amim1, if you need that. (I agree with you about how important correct pointing placement is; reading Hebrew text with misplaced nekudot is like reading a screen-full of CAPTCHAs.)

越野车比迪分析.更糟糕的是,不同版本的 Android 的错误似乎不同.修改文本以包含战略性放置的双向格式代码(RTL 标记;LTR 标记;等等)可以克服许多这些错误(参见讨论 此处,并非特定于 Android).但是,这样做很麻烦,而且由于 Android 版本之间存在不一致,因此很难提前预测该框架将需要哪些帮助.

Buggy bidi analysis. What makes it worse is that the bugs seem to be different for different versions of Android. Modifying the text to include strategically placed bidi formatting codes (RTL mark; LTR mark; etc.) can overcome many of these bugs (see the discussion here, which isn't specific to Android). However, it's a nuisance to do this and, because of the inconsistencies among Android versions, it is difficult to predict in advance what help the framework is going to need.

对从右到左的问题没有(或经过深思熟虑的)框架级意识.例如,祝你好运滚动条显示在 Hebrew TextView 的左侧.对于我们的应用程序,我们必须构建一个完整的滚动条系统才能让它按照我们想要的方式工作.(很好,Android 是开源的!)

No (or poorly thought out) framework-level awareness of right-to-left issues. For instance, good luck getting the scroll bar to display on the left side of a Hebrew TextView. For our apps, we had to build an entire scroll-bar system just to get this to work how we wanted. (Good think Android is open source!)

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

Poor line and word break analysis. At least one early version of Android on which we tested thought that each nikud mark was a word boundary. When it comes to line breaks, the system often doesn't know how to handle Hebrew punctuation like maqaf, gershayim, or sof pasuk.

某些较新的 Unicode 字符(例如 HOLAM HASER FOR VAV—U+05BA—新到 Unicode 5.0)未被系统识别为希伯来语脚本.

Some of the newer Unicode characters (like HOLAM HASER FOR VAV—U+05BA—new to Unicode 5.0) are not recognized as Hebrew script by the system.

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

My recommendation is that, unless you are prepared to build a top-to-bottom text handling system yourself, you give up on high-quality text display on pre-4.2 versions of Android, particularly if you need to support nekudot and te'amim. Also, plan to use the techniques I mentioned in the first two points above.

1 圣经微调标记

这篇关于如何在 4.2 之前的 Android 版本上处理 RTL 语言?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆