programar - ¿Cómo se manejan los lenguajes RTL en versiones pre 4.2 de Android?

programacion de celulares android

Question

Fondo

TextView siempre tuvo problemas con los idiomas RTL (de derecha a izquierda). Como solo sé leer hebreo (además del inglés), hablaré sobre sus problemas:

• Alineación de texto (y no estoy hablando de gravedad). Como un lenguaje RTL, el hebreo pone las palabras de derecha a izquierda (en comparación con el inglés, que es lo contrario).

  Para demostrar lo molesto que es, imagina que en lugar de mostrar "Hola mundo". usualmente obtienes ".Hola mundo". Esto podría arreglarse fácilmente si lo tiene en una sola oración, pero es más difícil cuando hay múltiples caracteres de puntuación.

• Posiciones de vocales. El hebreo no requiere vocales para leer el texto, pero a veces es muy difícil leer sin ellas (especialmente la Biblia). Para las vocales, el hebreo tiene lo que se llama "NIKUD", que en realidad son como puntos dentro de las letras. El problema en Android era que generalmente se ubicaban en la ubicación incorrecta.

  Para demostrar lo molesto que es, imagina que en lugar de mostrar "Hola mundo". generalmente obtienes ".Holol owrld". Incluso si intentas arreglarlo (pon las vocales siempre un carácter después del actual), la posición en la letra no era correcta (imagina que la "e" en "Hola" sería como arriba de la "H", para ejemplo).

Solo en la versión 4.2 (lea here , bajo "Soporte de RTL nativo"), Google ha corregido todos los problemas relacionados con hebreo (o al menos eso parece).

El problema

los problemas con el hebreo han causado que cada operador israelí y cada creador de ROM personalizado tengan su propia solución de cómo solucionar los diferentes problemas, lo que hace que sea prácticamente imposible manejar el texto RTL en dispositivos pre 4.2.

Las cosas pueden ser incluso más frustrantes en caso de que el texto incluya tanto letras hebreas como inglesas.

Lo que he intentado

He leído muchos sitios web que hablan de esos problemas, y he probado muchas variantes de las soluciones, ninguno ha resuelto el problema en todos los dispositivos:

• Algunos sugieren poner el carácter ''/ u200F'' (o ''/ u202D'') al final / inicio / ambos del texto.

• Algunos sugieren usar el método Html.fromHtml() y poner algo especial allí.

• Algunos incluso sugieren usar el WebView en su lugar (y tal vez usar WebSettings.setDefaultTextEncodingName() ).

La pregunta

¿Hay una solución definitiva para este problema?

Supongo que lo mejor es que, debido a que Android 4.2 resuelve esto, y Android es de código abierto, deberíamos importar su TextView a una biblioteca que podamos usar, pero Google aún no ha proporcionado esa biblioteca.

Answer 1

A partir de agosto de 2013, Android ha publicado la documentación de la API para un formateador bidireccional que podría adaptarse a sus necesidades. Esto está contenido en la biblioteca Android Support v4, que creo que debería ejecutarse en versiones anteriores a Android 4.2.

Consulte: http://developer.android.com/reference/android/support/v4/text/BidiFormatter.html

Answer 2

Tristemente, no creo que haya una buena solución ("bueno" significa "hace el trabajo y está disponible"). Para nuestras propias aplicaciones de Android que admiten hebreo, utilizamos un mecanismo de renderizado personalizado que desarrollamos durante muchos años. El mecanismo de render hace todo: fuentes propietarias; análisis bidireccional (bidi); colocación del glifo; análisis de ruptura de línea; flujo de texto; etc. Algunos de los problemas que intentan utilizar las capacidades nativas de manejo de texto de Android (especialmente pre-4.2) son:

1. Fuentes realmente cutre. Sin embargo, puede empaquetar fuentes de terceros como DejaVu que son bastante buenas. La fuente correcta puede hacer maravillas con el posicionamiento de nekudot-y te''amim ¹ , si es necesario. (Estoy de acuerdo con usted acerca de cuán importante es la colocación correcta de puntos, leer un texto hebreo con nekudot fuera de lugar es como leer una pantalla llena de CAPTCHAs ).

2. Buggy bidi analysis. Lo que lo empeora es que los errores parecen ser diferentes para las diferentes versiones de Android. Modificar el texto para incluir códigos de formato bidi estratégicamente colocados (marca RTL, marca LTR, etc.) puede superar muchos de estos errores (consulte la discusión here , que no es específica de Android). Sin embargo, es una molestia hacer esto y, debido a las incoherencias entre las versiones de Android, es difícil predecir de antemano qué ayuda va a necesitar el marco.

3. Sin conocimiento de nivel de marco (o poco pensado) de problemas de derecha a izquierda. Por ejemplo, buena suerte haciendo que la barra de desplazamiento se muestre en el lado izquierdo de una TextView en hebreo. Para nuestras aplicaciones, tuvimos que construir un sistema completo de barras de desplazamiento solo para hacer que funcionara como queríamos. (¡Bien, creo que Android es de código abierto!)

4. Pobre análisis de líneas y palabras. Al menos una versión anterior de Android en la que probamos pensó que cada marca nikud era un límite de palabras. Cuando se trata de saltos de línea, el sistema a menudo no sabe cómo manejar la puntuación hebrea como maqaf, gershayim o sof pasuk.

5. Algunos de los caracteres Unicode más nuevos (como HOLAM HASER FOR VAV-U + 05BA-nuevo en Unicode 5.0) no son reconocidos como script hebreo por el sistema.

Mi recomendación es que, a menos que esté preparado para construir un sistema de manejo de texto de arriba a abajo, abandone la visualización de texto de alta calidad en las versiones anteriores a la 4.2 de Android, particularmente si necesita admitir nekudot y te''amim. . Además, planee usar las técnicas que mencioné en los primeros dos puntos anteriores.

¹ cantillation bíblica