Troika: Soporte de diseño de texto de derecha a izquierda

Creado en 5 abr. 2021  ·  11Comentarios  ·  Fuente: protectwise/troika

En lugar de una solución completa y avanzada de modelado de texto (por ejemplo, harfbuzz.wasm), me gustaría tener un soporte básico listo para usar para el diseño RTL. Typr ya incluye cierto nivel de soporte para sustituciones de glifos árabes, aunque no sé qué tan completo es.

Ya he agregado una lógica de diseño/envoltura RTL muy básica. Usemos este problema para rastrear errores con esa y otras brechas en el soporte.

Página de prueba temporal: https://troika-examples.netlify.app/#text -rtl

Comentario más útil

Impulsé una implementación más completa de detección de tipo de unión; la lógica que adapté de Opentype.js resultó ser incompleta. La nueva implementación en realidad incorpora una versión altamente comprimida de las definiciones de tipo de unión Unicode, por lo que ahora debería manejar todos los caracteres que se pueden unir en árabe y otros. También da un aumento de velocidad decente sobre el código Typr.

@MichaelHazani ya que te ofreciste como voluntario para probar el hebreo, creo que ya está listo para ti. Puede usar esta página de prueba donde he agregado un par de fuentes hebreas al menú desplegable "fuente", y puede escribir su propio texto. ¡Gracias!

Todos 11 comentarios

Primero quiero agradecerles mucho por trabajar en esto. La compatibilidad con diseños árabes y RTL será útil para muchas personas.
Hice algunas primeras pruebas, el texto árabe estándar está bien soportado en su mayoría en las fuentes cairo, Lemonada, Scheherazade (sin Tachkil).

Estaba probando estas 2 reglas para el árabe:

  1. Si las 3 formas de escribir caracteres están bien (uno al principio, en el medio, al final) y las conexiones (ligadura).
  2. Tachkil, que es el conjunto de indicaciones para la pronunciación ُ َ ً ٌ (no se usa en la mayoría del texto que encuentra en Internet, excepto en casos excepcionales)

En mirza, algunas letras internas no están conectadas (la forma final de la letra se coloca en lugar de la interna o de otra manera)
arabicTachkil

Con tachkil, algunas fuentes funcionaron bien mientras que otras cambiaron la forma del carácter al lado. Algunos trabajaron con un texto que escribí en el cuadro mientras que no lo hicieron con un texto copiado.

Si uso letras no árabes como paréntesis "(", ")", se cambian (debe invertirse).

Esta es una prueba rápida que hice, necesito verificar más y darle más detalles donde las cosas se ponen raras. (También necesito verificar las fuentes, algunas fuentes no proporcionan los caracteres necesarios)

¡Muchas gracias! Me alegra saber que tiene un comienzo decente.

Es interesante que el resultado de las sustituciones de posición de palabra varíe según la fuente. La lógica de detección de posición de palabra en Typr es siempre la misma, por lo que debe haber algo diferente en la forma en que esas fuentes codifican sus sustituciones que Typr no maneja. Estudiaré a Mirza específicamente para ver si puedo determinar una diferencia.

Dado que no conozco estos caracteres y, por lo tanto, no puedo determinar si es correcto o incorrecto, sería de gran ayuda si pudiera proporcionarme algunos casos de prueba específicos con los resultados esperados, tal vez solo palabras sueltas, algo como:

Texto de entrada: xxx
Debería verse como: [imagen]
Se ve correcto en la fuente A: [imagen]
Se ve incorrecta en la fuente B: [imagen]

En cuanto a los paréntesis, creo que es la parte de paréntesis emparejados del algoritmo Bidi. Todavía no estoy seguro de si eso es algo que abordaré por mi cuenta, pero definitivamente lo investigaré.

He empujado el código con un poco de soporte de diseño bidireccional aproximado. En este momento es puramente manual usando caracteres de control LRO/RLO/PDF para definir rangos direccionales. El bidi completamente automático es mucho más complicado y todavía estoy enfrascado en su alcance, pero poder diseñar los rangos (¡con ajuste de línea y selección!) es un comienzo importante.

image

Siento mucho no haber publicado un comentario ayer. Pensé en hacer una prueba completa el fin de semana, pero creo que mejor hacer las cosas por pasos.
Comencemos con fuentes que funcionan muy bien (puede haber algunos problemas en algunas fuentes) He usado la fuente Scheherazade, pero Cairo y Lemonada dan el mismo resultado.
Las fuentes Mirza y ​​Amiri siempre muestran letras desconectadas.
Las fuentes Noto Sans, Roboto no funcionan en absoluto.

En la imagen de abajo, he usado el rojo para indicar la forma incorrecta de la letra, y el verde es la forma correcta.
El problema aparece solo cuando tenemos Tachkil (notas vocales) o un carácter latino o numérico.

  1. En lugar de la forma final, tenemos una forma interna.
  2. Dentro de la palabra, en lugar de la forma inicial tenemos la forma interna. (dentro de la palabra algunas letras no tienen ligadura)
  3. Cuando tenemos un número justo después de la palabra, (كم2) mantenemos la forma final.
  4. los números están invertidos.

arabThree

Texto que usé:
كم2.
2
بِسم اللَّه الرحمن الرحيم
بِسمِ اللَّهِ الرَّحمٰنِ الرَّحيمِ

Esta respuesta contiene una imagen de cómo se dibujan las letras.
https://www.quora.com/How-can-anyone-read-arabic-as-the-letters-are-all-connected-to-each-other/answer/Hashem-Mohamed-4

¡Muchas gracias por este caso de prueba marcado, eso es inmensamente útil! Realmente me ayuda a entender las cosas.

La lógica de Typr para detectar la posición de las palabras es definitivamente defectuosa; Lo anulé con la lógica adaptada de opentype.js y el resultado ahora parece mucho mejor:

image

Contribuiré con la reparación de Typr aguas arriba después de más pruebas.

El problema de "los números están invertidos" se manejará con el trabajo de BiDi que comencé. Por ahora, eso se puede solucionar con caracteres LRO/PDF explícitos.

¡Sigan recibiendo este tipo de casos de prueba! 🤩

Eso fue rápido.
Bueno, no he encontrado nada que necesite más arreglos, excepto lo que se puede hacer usando el trabajo BiDi que mencionaste (los números y los paréntesis se pueden usar ampliamente con el texto en árabe).
¿Puedes mostrar un ejemplo de cómo usar los caracteres LRO/PDF? Yo mismo no pude reproducir el ejemplo de texto mixto.

Lo último que no está relacionado con el texto en árabe, pero tal vez relacionado con la representación SDF, es que algunos caracteres tienen negro en el interior cuando 2 caracteres están conectados entre sí como aquí
image
image
y a veces dentro del mismo personaje
image
Esto solo es visible con la fuente Lemonda. Scheherazade, Cairo funciona bien (tal vez porque los personajes se conectan en el lugar correcto).
(Parece una operación booleana en la herramienta de representación vectorial).

Y gracias de nuevo por tu trabajo.

¡Gracias! Actualmente estoy trabajando para agregar una implementación completa del algoritmo bidi que creo que debería aclarar todos los demás problemas que describiste hasta ahora.

El texto "BiDi 1" en el menú desplegable del ejemplo tiene un ejemplo de LRO/PDF, pero no se preocupe por eso por ahora, es solo un recurso provisional y no es realmente correcto de todos modos. El verdadero bidi será mejor.

Creo que el problema de relleno booleano con esa fuente es el mismo que se discutió en el n. ° 57.

¡Ahora tenemos soporte bidi completo!

image

Hay un par de fragmentos de bidi en la página de ejemplo, pero pruébalo con tu propio texto mixto rtl+ltr.

Esto se convirtió en un ejemplo clásico de mí cayendo por una madriguera de conejo; No encontré una implementación bidi de JS adecuada y no quería incluir fribidi.wasm, así que decidí probar una nueva implementación de JS como un proyecto de noches y fines de semana. ¡Mira https://github.com/lojjic/bidi-js! Necesito agregar algunos documentos allí, pero cumple totalmente con las pruebas bidi oficiales, es bastante pequeño (~ 10 kb) y bastante rápido, aunque probablemente podría optimizarse más.

Me siento muy feliz con esta solución y lo poco que agrega al tamaño del paquete. Creo que ahora estamos muy cerca del soporte completo de RTL. Sin embargo, necesito revisar la lógica de los formularios de unión, me di cuenta de que la lógica que adapté de opentype.js solo maneja scripts árabes pero no otros que también se unen.

Impulsé una implementación más completa de detección de tipo de unión; la lógica que adapté de Opentype.js resultó ser incompleta. La nueva implementación en realidad incorpora una versión altamente comprimida de las definiciones de tipo de unión Unicode, por lo que ahora debería manejar todos los caracteres que se pueden unir en árabe y otros. También da un aumento de velocidad decente sobre el código Typr.

@MichaelHazani ya que te ofreciste como voluntario para probar el hebreo, creo que ya está listo para ti. Puede usar esta página de prueba donde he agregado un par de fuentes hebreas al menú desplegable "fuente", y puede escribir su propio texto. ¡Gracias!

¡Se ve muy bien!
("bueno, parece que la prueba fue un éxito. La puntuación está donde debería estar; la alineación a la derecha se ve bien. Ambas fuentes muestran el hebreo de la forma en que debería mostrarse. Cambiar a inglés, es decir, esta palabra, no rompe la alineación. ¡Bien hecho!")
image

Lancé v0.41.0 con el trabajo realizado aquí hasta ahora. Sin duda, hay otros scripts RTL que necesitarán un manejo especializado adicional, pero esto brinda una línea de base lo suficientemente sólida como para que podamos manejarlos caso por caso. Y siempre existe la posibilidad de permitir un complemento Harfbuzz opcional (#91) para algunos de los casos más avanzados/oscuros.

¡¡¡Gracias de nuevo @boulabiar y @MichaelHazani por su inestimable ayuda aquí!!! 🎉

¿Fue útil esta página
0 / 5 - 0 calificaciones