Troika: Prise en charge de la disposition du texte de droite à gauche

Créé le 5 avr. 2021  ·  11Commentaires  ·  Source: protectwise/troika

Au lieu d'une solution de mise en forme de texte avancée complète (par exemple, harfbuzz.wasm), j'aimerais un support de base prêt à l'emploi pour la mise en page RTL. Typr inclut déjà un certain niveau de prise en charge des substitutions de glyphes arabes, bien que je ne sache pas à quel point cela est complet.

J'ai déjà ajouté une logique de mise en page/emballage RTL très basique. Utilisons ce problème pour suivre les bogues avec cela et d'autres lacunes dans le support.

Page de test temporaire : https://troika-examples.netlify.app/#text -rtl

Commentaire le plus utile

J'ai poussé une implémentation plus complète de la détection de type de jointure ; la logique que j'avais adaptée d'Opentype.js s'est avérée incomplète. La nouvelle implémentation intègre en fait une version hautement compressée des définitions de type de jointure unicode , elle devrait donc désormais gérer tous les caractères joignables en arabe et autres. Il donne également un ralentisseur décent sur le code Typr.

@MichaelHazani puisque vous vous êtes porté volontaire pour tester l'hébreu, je pense que c'est prêt pour vous maintenant. Vous pouvez utiliser cette page de test où j'ai ajouté quelques polices hébraïques à la liste déroulante "police", et vous pouvez taper votre propre texte. Merci!

Tous les 11 commentaires

Tout d'abord, je tiens à vous remercier beaucoup d'avoir travaillé là-dessus. La prise en charge des mises en page arabes et RTL sera utile pour de nombreuses personnes.
J'ai fait quelques premiers tests, le texte arabe standard est généralement bien supporté dans les polices cairo, Lemonada, Scheherazade (sans Tachkil).

Je testais ces 2 règles pour l'arabe :

  1. Si les 3 formes d'écriture des caractères sont fines (une au début, au milieu, à la fin) et les liaisons (ligature).
  2. Tachkil qui est l'ensemble des indications de prononciation ُ َ ً ٌ (non utilisé dans la plupart des textes que vous trouvez sur internet sauf dans de rares cas)

Dans mirza, certaines lettres internes ne sont pas liées (la forme finale de la lettre est mise à la place de la forme interne ou autre)
arabicTachkil

Avec tachkil, certaines polices fonctionnaient bien tandis que d'autres modifiaient la forme du caractère à côté. Certains ont travaillé avec un texte que j'ai écrit dans la boîte alors que je ne l'ai pas fait avec un texte copié.

Si j'utilise des lettres non arabes comme des parenthèses "(", ")", elles sont inversées (doit être inversée).

C'est un test rapide que j'ai fait, j'ai besoin de vérifier plus et de vous donner plus de détails là où les choses deviennent bizarres. (Je dois aussi vérifier les polices, certaines polices ne fournissent pas les caractères nécessaires)

Grand merci! Je suis heureux d'apprendre qu'il a un bon départ.

Il est intéressant de noter que le résultat des substitutions de position de mot varie selon la police. La logique de détection de la position des mots dans Typr est toujours la même, il doit donc y avoir quelque chose de différent dans la façon dont ces polices encodent leurs substitutions que Typr ne gère pas. Je vais examiner Mirza spécifiquement pour voir si je peux déterminer une différence.

Étant donné que je ne connais pas ces caractères et que je ne peux donc pas déterminer moi-même ce qui est correct ou incorrect, il serait extrêmement utile si vous pouviez me donner des cas de test ciblés avec les résultats attendus, peut-être juste des mots simples, quelque chose comme :

Texte saisi : xxx
Devrait ressembler à : [image]
Semble correct dans la police A : [image]
Semble incorrect dans la police B : [image]

Quant aux parenthèses, je pense que c'est la partie Paired Brackets de l'algorithme Bidi. Je ne sais pas encore si c'est quelque chose que je vais aborder moi-même, mais je vais certainement l'examiner.

J'ai poussé le code avec un support de mise en page bidirectionnel approximatif. À l'heure actuelle, c'est purement manuel en utilisant les caractères de contrôle LRO/RLO/PDF pour définir les plages directionnelles. Le bidi entièrement automatique est beaucoup plus compliqué et je ne comprends toujours pas sa portée, mais être capable de disposer les plages (avec retour à la ligne et sélection !) Est un début important.

image

Je suis vraiment désolé de ne pas avoir posté de commentaire hier. J'ai pensé à faire un test complet le week-end, mais je pense qu'il vaut mieux faire les choses par étapes.
Commençons par des polices qui fonctionnent très bien (il peut y avoir des problèmes dans certaines polices) J'ai utilisé la police Scheherazade, mais Cairo et Lemonada donnent le même résultat.
Les polices Mirza et Amiri affichent toujours des lettres déconnectées.
Les polices Noto Sans, Roboto ne fonctionnent pas du tout.

Dans l'image ci-dessous, j'ai utilisé le rouge pour signifier la mauvaise forme de la lettre, et le vert est la bonne forme.
Le problème n'apparaît que lorsque nous avons des Tachkil (notes vocales) ou un caractère latin ou numérique.

  1. Au lieu du formulaire final, nous avons un formulaire interne.
  2. À l'intérieur du mot, au lieu de la forme initiale, nous avons la forme interne. (à l'intérieur du mot certaines lettres n'ont pas de ligature)
  3. Lorsque nous avons un nombre juste après le mot, (كم2) nous gardons la forme finale.
  4. les nombres sont inversés.

arabThree

Texte que j'ai utilisé :
كم2.
كم 2
بِسم اللَّه الرحمن الرحيم
بِسمِ اللَّهِ الرَّحمٰنِ الرَّحيمِ

Cette réponse contient une image sur la façon dont les lettres sont dessinées
https://www.quora.com/How-can-anyone-read-Arabic-as-the-letters-are-all-connected-to-each-other/answer/Hashem-Mohamed-4

Merci beaucoup pour ce cas de test balisé, c'est extrêmement utile !!! Cela m'aide vraiment à comprendre les choses.

La logique de Typr pour détecter la position des mots est définitivement défectueuse ; Je l'ai remplacé par une logique adaptée d' opentype.js et le résultat semble maintenant bien meilleur :

image

Je contribuerai à ce correctif Typr en amont après des tests supplémentaires.

Le problème "les chiffres sont inversés" sera traité avec le travail BiDi que j'ai commencé. Pour l'instant, cela peut être contourné avec des caractères LRO/PDF explicites.

Gardez ce genre de cas de test à venir ! 🤩

C'était rapide.
Eh bien, je n'ai pas trouvé quelque chose qui nécessite plus de correction, sauf ce qui peut être fait en utilisant le travail BiDi que vous avez mentionné (le nombre et les parenthèses peuvent être largement utilisés avec le texte arabe).
Pouvez-vous montrer un exemple sur la façon d'utiliser les caractères LRO/PDF ? Je n'ai pas pu reproduire moi-même l'exemple de texte mixte.

Dernière chose qui n'est pas liée au texte arabe mais peut-être liée au rendu SDF, c'est que certains caractères ont du noir à l'intérieur lorsque 2 caractères sont connectés ensemble comme ici
image
image
et parfois dans le même personnage
image
Ceci n'est visible qu'avec la police Lemonda. Shéhérazade, Le Caire fonctionne bien (peut-être parce que les personnages se connectent au bon endroit).
(Cela ressemble à une opération booléenne dans l'outil de rendu vectoriel.)

Et encore merci pour votre travail.

Merci! Je travaille actuellement sur l'ajout d'une implémentation complète de l'algorithme bidi qui, je pense, devrait résoudre tous les autres problèmes que vous avez décrits jusqu'à présent.

Le texte "BiDi 1" dans la liste déroulante de l'exemple contient un exemple de LRO/PDF, mais ne vous inquiétez pas pour l'instant, c'est juste un pis-aller et ce n'est pas vraiment correct de toute façon. Le vrai bidi sera meilleur.

Le problème de remplissage booléen avec cette police est le même que celui discuté au n ° 57, je pense.

Nous avons maintenant un support bidi complet !

image

Il y a quelques extraits bidi dans la page d'exemple, mais testez-le avec votre propre texte mixte rtl + ltr.

Cela s'est transformé en un exemple classique de moi descendant un terrier de lapin; Je n'ai pas trouvé d'implémentation JS bidi appropriée et je ne voulais pas intégrer fribidi.wasm, j'ai donc décidé de me lancer dans une nouvelle implémentation JS en tant que projet de nuit et de week-end. Voici https://github.com/lojjic/bidi-js ! J'ai besoin d'y ajouter quelques documents, mais il est entièrement conforme selon les tests bidi officiels, assez petit (~ 10 Ko) et assez rapide bien qu'il puisse probablement être optimisé davantage.

Je suis vraiment satisfait de cette solution et du peu qu'elle ajoute à la taille du paquet. Je pense que nous sommes très proches du support RTL complet maintenant. J'ai besoin de revoir la logique des formulaires de jointure, j'ai réalisé que la logique que j'ai adaptée d'opentype.js ne gère que les scripts arabes mais pas les autres qui font aussi la jointure.

J'ai poussé une implémentation plus complète de la détection de type de jointure ; la logique que j'avais adaptée d'Opentype.js s'est avérée incomplète. La nouvelle implémentation intègre en fait une version hautement compressée des définitions de type de jointure unicode , elle devrait donc désormais gérer tous les caractères joignables en arabe et autres. Il donne également un ralentisseur décent sur le code Typr.

@MichaelHazani puisque vous vous êtes porté volontaire pour tester l'hébreu, je pense que c'est prêt pour vous maintenant. Vous pouvez utiliser cette page de test où j'ai ajouté quelques polices hébraïques à la liste déroulante "police", et vous pouvez taper votre propre texte. Merci!

Ça a l'air génial !
("Eh bien, il semble que le test soit un succès. La ponctuation est là où elle devrait être ; l'alignement à droite semble bon. Les deux polices affichent l'hébreu comme il se doit. Passer à l'anglais, c'est-à-dire ce mot, ne rompt pas l'alignement. Bien joué!")
image

J'ai publié la v0.41.0 avec le travail effectué ici jusqu'à présent. Il existe sans aucun doute d'autres scripts RTL qui nécessiteront une gestion spécialisée supplémentaire, mais cela donne une base suffisamment solide pour que je pense que nous puissions les gérer au cas par cas. Et il y a toujours la possibilité d'autoriser un plugin Harfbuzz optionnel (#91) pour certains des cas les plus avancés/obscurs.

Merci encore @boulabiar et @MichaelHazani pour votre aide précieuse ici !!! 🎉

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

asbjornlystrup picture asbjornlystrup  ·  7Commentaires

stephencorwin picture stephencorwin  ·  39Commentaires

Ocelyn picture Ocelyn  ·  13Commentaires

atlmtw picture atlmtw  ·  47Commentaires

natarius picture natarius  ·  14Commentaires