web-dev-qa-db-ja.com

4.2より前のバージョンのAndroidでRTL言語を処理する方法は？

バックグラウンド

TextViewには、RTL（右から左）言語で常に問題がありました。私は（英語に加えて）ヘブライ語の読み方しか知らないので、その問題について話します：

  • テキストの配置（そして私は重力について話していません）。 RTL言語として、ヘブライ語は単語を右から左に配置します（英語とは逆です）。

    それがどれほど迷惑であるかを示すために、「Helloworld」を表示する代わりにそれを想像してください。通常は「.Helloworld」を取得します。これは、1つの文に含めると簡単に修正できますが、句読文字が複数ある場合は難しくなります。

  • 母音の位置。ヘブライ語はテキストを読むために母音を必要としませんが、母音なしでは読むのが非常に難しい場合があります（特に聖書）。母音の場合、ヘブライ語には「NIKUD」と呼ばれるものがあります。これは実際には文字内のドットのようなものです。 Androidの問題は、通常、間違った場所に配置されていたことです。

    それがどれほど迷惑であるかを示すために、「Helloworld」を表示する代わりにそれを想像してください。通常、「。eHlolowrld」を取得します。それを修正しようとしても（母音を常に現在の母音の1文字後に配置する）、文字の位置が正しくありませんでした（「Hello」の「e」が「H」の上にあると想像してください。例）。

バージョン4.2でのみ（ ここ 、「ネイティブRTLサポート」の下で）、Googleはヘブライ語に関連するすべての問題を修正しました（または少なくともそう思われます）。

問題

ヘブライ語の問題により、各イスラエルの通信事業者と各カスタムROMメーカーは、さまざまな問題を修正する方法について独自のソリューションを持っているため、4.2より前のデバイスでRTLテキストを処理することは事実上不可能です。

テキストにヘブライ語と英語の両方の文字が含まれている場合、事態はさらに苛立たしいものになる可能性があります。

私が試したこと

私はそれらの問題について話している多くのウェブサイトを読みました、そして私は解決策の多くの変形を試しました、どれもすべてのデバイスで問題を解決しませんでした：

  • テキストの最後/開始/両方に文字「\ u200F」（または「\ u202D」）を配置することを提案する人もいます。

  • Html.fromHtml（） メソッドを使用して、そこに何か特別なものを置くことを提案する人もいます。

  • 代わりにWebViewを使用することを提案する人もいます（そして多分 WebSettings.setDefaultTextEncodingName（） を使用します）。

質問

この問題の明確な解決策はありますか？

Android 4.2はこれを解決し、Androidはオープンソースなので、TextViewをライブラリにインポートする必要があるので、最良のことだと思います。使用しますが、Googleはまだそのようなライブラリを提供していません。

androidandroid-webviewtextviewhebrewright-to-left
28
android developer

悲しいことに、私は良い解決策があるとは思いません（「良い」は「仕事をしてすぐに利用できる」という意味です）。ヘブライ語をサポートする独自のAndroidアプリでは、長年にわたって開発したカスタムレンダリングメカニズムを使用します。レンダリングメカニズムは、独自のフォント、双方向（bidi）分析、グリフ配置、線など、すべてを実行します。ブレーク分析、テキストフローなど。ネイティブAndroidテキスト処理機能（特に4.2より前）を使用しようとする際の問題のいくつかは次のとおりです。

  1. 本当にくだらないフォント。ただし、 DejaV のようなかなり優れたサードパーティフォントをパッケージ化することはできます。適切なフォントは、nekudotとte'amimの配置に驚異的な効果をもたらします。1、必要な場合。 （正しいポインティング配置がいかに重要であるかについては同意します。間違って配置されたネクドットでヘブライ語のテキストを読むことは、画面いっぱいの CAPTCHA を読むようなものです。）

  2. バギービディ分析。さらに悪いことに、Androidのバージョンによってバグが異なるように見えます。戦略的に配置されたbidiフォーマットコード（RTLマーク、LTRマークなど）を含むようにテキストを変更すると、これらのバグの多くを克服できます（Androidに固有ではない説明 ここ を参照）。ただし、これを行うのは面倒であり、Androidバージョン間の不整合のため、フレームワークが必要とするヘルプを事前に予測することは困難です。

  3. 右から左への問題に対するフレームワークレベルの認識がない（またはよく考えられていない）。たとえば、ヘブライ語のTextViewの左側にスクロールバーを表示できるように頑張ってください。私たちのアプリでは、これを希望どおりに機能させるために、スクロールバーシステム全体を構築する必要がありました。 （良い考えAndroidはオープンソースです！）

  4. 貧弱な行とワードブレーク分析。テストしたAndroidの初期バージョンの少なくとも1つは、各nikudマークが単語の境界であると考えていました。改行に関しては、システムはヘブライ語の句読点の処理方法を知らないことがよくあります。 maqaf、gershayim、またはsofpasuk。

  5. 一部の新しいUnicode文字（HOLAM HASER FOR VAV-U + 05BA-Unicode 5.0の新機能など）は、システムによってヘブライ文字として認識されません。

上から下へのテキスト処理システムを自分で構築する準備ができていない限り、特にnekudotとte'amimをサポートする必要がある場合は、4.2より前のバージョンのAndroidでの高品質のテキスト表示をあきらめることをお勧めします。 。また、上記の最初の2つのポイントで述べた手法を使用することを計画します。

1 聖書の詠唱マーク

13
Ted Hopp

2013年8月の時点で、Androidは、ニーズに合う可能性のある双方向フォーマッターのAPIドキュメントを投稿しています。これはAndroidサポートv4ライブラリに含まれています。 Android 4.2より前のバージョンで実行する必要があると考えています。

参照： http://developer.Android.com/reference/Android/support/v4/text/BidiFormatter.html

2
user2082922