9.1 casse les lignes au milieu des mots en écriture khmère - correction ?

Question

J'ai récemment signalé aux développeurs que la version 9.1 (contrairement à la 8 ou à la 9.0) casse régulièrement les lignes au milieu des mots (et nous avons des espaces entre les mots !). Notre projet utilise une écriture non occidentale (khmère). Je me demande si d'autres personnes travaillant avec des écritures non occidentales ont maintenant ce problème ? Si c'est le cas, veuillez signaler le bug et aider à en faire une priorité.

Aussi, si vous connaissez un moyen de contourner ce problème pour le corriger, veuillez le partager.

Au fait, à cet égard, PT 9.1 se comporte maintenant comme Microsoft Word, qui depuis des années casse les lignes au milieu des mots en écriture khmère, même lorsque les mots sont séparés par des espaces. (Notre langue est fortement isolante, donc nous ne parlons pas de mots longs !) Je me demande si PT 9.1 a changé la façon dont il affiche le texte et utilise une technologie similaire à celle de Microsoft ? Si c'est le cas, j'espère que les développeurs réexamineront ce choix.

Traduit automatiquement depuis English Afficher l'original

Answer 1

Il semble que cela ait déjà été signalé sous le numéro PTX-20833

Harfbuzz délègue les décisions de coupure de ligne. Précédemment, la coupure de liens complexes (nécessaire pour le khmer et 3 autres langues) était déterminée en interrogeant uniscribe. Cela est maintenant fait en interrogeant icu, ce qui a corrigé la coupure de ligne pour certaines langues. C'est probablement la cause du changement.

Traduit automatiquement depuis English Afficher l'original

Comments

hindlemail, il y a quelques années, Martin Hosken a fait des travaux pour corriger la coupure de ligne en khmer dans LibreOffice. Je pensais que sa correction avait été faite dans ICU, mais peut-être que la correction consistait à faire la coupure de ligne dans LO au lieu de dans ICU.

Traduit automatiquement depuis English Afficher l'original

---

J'ai vérifié avec Martin au sujet de sa correction dans LibreOffice. Il a dit qu'ICU n'a pas accepté ses corrections parce qu'il n'a implémenté que le C++ et qu'ils voulaient aussi que ce soit fait en Java.

Traduit automatiquement depuis English Afficher l'original

---

Je viens de recevoir la mise à jour vers 9.1.104.39. Pas de changement pour l'instant – je suppose que la correction n'était pas prévue pour cette mise à jour ? (J'avais précédemment vu une note disant que la correction de ce problème était une priorité pour la prochaine mise à jour.)

Traduit automatiquement depuis English Afficher l'original

---

Le changement a bien été inclus dans la mise à jour 9.1.104.39, mais ce n'est pas l'option par défaut, car changer le comportement par défaut causerait des problèmes pour d'autres.

Si vous ouvrez les paramètres de Paratext, il y a une nouvelle option pour les coupures de mots en khmer (c'est la seule langue que nous connaissons qui voudrait cette option). Cocher cette option et redémarrer Paratext devrait vous donner le comportement souhaité.

John+Wickberg
Support Paratext

Traduit automatiquement depuis English Afficher l'original

---

J'utilise la version 9.1.104.39, j'ai coché la case dans les paramètres et redémarré Paratext, mais je vois encore certains mots cassés, comme dans la mise en évidence ici :

PastedGraphic-3.png1779×753 150 KB

Traduit automatiquement depuis English Afficher l'original

---

À titre d'information : les langues utilisant des écritures basées sur le thaï ont aussi des problèmes avec la division des mots, mais c'est toujours été le cas dans Paratext (apparemment contrairement aux écritures basées sur le khmer, et je pense aussi celles basées sur le lao, qui semblaient être corrigées pendant un certain temps pour ne pas casser). Pour Print Draft, c'était corrigé l'année dernière, mais à l'écran, les mots se divisent incorrectement aux retours à la ligne. Je pense qu'avec les écritures basées sur le thaï, il y avait des problèmes de police qui ne permettaient pas de corriger la coupure (sauf dans Print Draft et dans ptxprint), donc je doute que cette correction khmère nous aide. Mais nous aimerions vraiment que ce soit le cas !!
Linda119

Traduit automatiquement depuis English Afficher l'original

---

Le fait de cocher la case a-t-il un effet ? (c'est-à-dire, corrige-t-elle certaines choses mais pas tout ?)
L'exemple utilisé lors de la correction de ce problème était :

យេហូវ៉ា
(1799,17c1,17a0,17bc,179c,17c9,17b6)

Si la case à cocher ne corrige pas cela, pourriez-vous essayer ceci :

Créer le fichier C:\Users\$USER\AppData\Local\ParatextGeckoPreferencesOverrides.txt
(avec $USER remplacé par le nom d'utilisateur approprié)

et coller cette ligne dans le fichier :

b intl.complexLineBreaking.uniscribe true

et enregistrer.

Maintenant, si vous redémarrez Paratext, cela fait-il une différence ?

Traduit automatiquement depuis English Afficher l'original

---

Les modifications du code Paratext étaient incluses dans le correctif, mais la version mise à jour du moteur Firefox ne l'était pas.

Nos tests utilisent normalement des versions de compilation différentes de celle du correctif et ces versions avaient la bonne version de Firefox.

Je vais travailler pour inclure la version de Firefox dans notre prochain correctif qui sera envoyé la semaine prochaine.

John+Wickberg

Traduit automatiquement depuis English Afficher l'original

---

	hindlemail Développeur 12 février

Le fait de cocher la case a-t-il un effet ? (c'est-à-dire, corrige-t-elle certaines choses mais pas tout ?)

Je ne suis pas sûr, mais étant donné l'e-mail de John+Wickberg W, je suppose qu'il n'est pas important de chercher plus loin.

L'exemple utilisé lors de la correction de ce problème était :

យេហូវ៉ា
(1799,17c1,17a0,17bc,179c,17c9,17b6)

Si la case à cocher ne corrige pas cela, pourriez-vous essayer ceci :

Créer le fichier C:\Users$USER\AppData\Local\ParatextGeckoPreferencesOverrides.txt
(avec $USER remplacé par le nom d'utilisateur approprié)

et coller cette ligne dans le fichier :

b intl.complexLineBreaking.uniscribe true

et enregistrer.

Maintenant, si vous redémarrez Paratext, cela fait-il une différence ?

Coller « b intl.complexLineBreaking.uniscribe true »
dans "C:\Users\LivingField\AppData\Local\ParatextGeckoPreferencesOverrides.txt”
n'a pas corrigé la coupure du mot យេហូវ៉ា
Nous attendrons la version de compilation de la semaine prochaine avec Gecko mis à jour.

Traduit automatiquement depuis English Afficher l'original

---

Hier, mon PT s'est mis à jour vers 9.1.104.59. Après la mise à jour, la coupure de ligne est toujours cassée.

image1171×602 203 KB

Dans la version 1.104.39, j'avais déjà sélectionné « Khmer uniquement : Prendre en charge les coupures de ligne complexes. » Après la mise à jour vers 104.59, j'ai désélectionné cette option, redémarré PT, l'ai sélectionnée à nouveau et redémarré à nouveau – tout pour m'assurer que l'option était « prise en compte ». Mais rien à faire.

Merci pour votre attention à ce sujet ! Ce serait bien d'avoir une correction.

Traduit automatiquement depuis English Afficher l'original

---

J'ai essayé avec votre projet et 9.1.104.59, et cela semble fonctionner de mon côté :

Avec l'option activée :

1162×173

et :

1091×169

Avec l'option désactivée :

1095×143

Je sais que j'utilise une police différente de la vôtre, mais je n'ai pas réussi à localiser la police Khmer Barkaew. Je ne pense pas que cela fasse une différence, mais il vaut peut-être la peine de l'exclure. (Si vous pouvez facilement me fournir la police, je testerai avec celle-ci).

Donc, si vous êtes d'accord pour dire que mes captures d'écran montrent le comportement attendu (et que je ne mal interprète pas le problème), et que la police ne fait pas de différence, je pense qu'il vaut la peine de vérifier que le processus de mise à jour de Paratext a fonctionné comme prévu.

Dans l'Explorateur Windows, pourriez-vous naviguer vers C:\Program Files\Paratext 9\Firefox64 et faire un clic droit → propriétés sur xul.dll. Le champ Taille : devrait être « 75,891,200 bytes ». S'il ne l'est pas, c'est probablement la cause de ce problème.

Si la taille ne correspond pas, vous pouvez corriger cela manuellement en effectuant les étapes suivantes :

télécharger :
https://www.nuget.org/api/v2/package/Geckofx60.64.Windows/0.18.0
renommer l'extension du téléchargement en .zip

Extraire le fichier : content/Firefox64/xul.dll

1. arrêter Paratext.
2. renommer C:\Program Files\Paratext 9\Firefox64\xul.dll en xul.dll_original
3. copier xul.dll depuis le fichier zip dans C:\Program Files\Paratext 9\Firefox64\
4. redémarrer Paratext

Traduit automatiquement depuis English Afficher l'original

---

Les fichiers du téléchargement l'ont corrigé pour moi.

Traduit automatiquement depuis English Afficher l'original

---

Y a-t-il une chance que cela puisse aussi être fait pour les langues à écriture thaïe ? J'ai essayé de remplacer xul.dll en suivant ces instructions, mais cela n'a pas fait de différence, les mots à l'écran dans Paratext pour notre langue basée sur le thaï se divisent toujours sur plusieurs lignes, donc je suppose que cela ne s'applique qu'au khmer ?

Linda119

Traduit automatiquement depuis English Afficher l'original

---

Cela l'a aussi corrigé pour moi. Merci !

Traduit automatiquement depuis English Afficher l'original

---

Bonjour Linda119,

Les langues auxquelles cette option s'applique sont les suivantes :
thaï, lao, tibétain, khmer
(Le libellé de cette option n'est peut-être pas le plus approprié. En effet, en plus de concerner d'autres langues, le fait de ne pas cocher cette option permet bien de gérer les retours à la ligne complexes. À ma connaissance, l'option décochée est plus conforme à la norme Unicode en ce qui concerne la gestion des retours à la ligne, ce qui peut différer du fonctionnement antérieur.)

Le seul effet de cette option est de revenir au comportement précédent de Paratext en matière de retours à la ligne complexes.
Ainsi, si vous avez constaté un changement de comportement souhaité lors du passage de la version 9.0 à la 9.1, cette option vous permet de retrouver l'ancien comportement.

Traduit automatiquement depuis English Afficher l'original

Answer 2

Ce changement était certainement involontaire. Paratext utilise le moteur de mise en page Harfbuzz de Firefox, il est donc possible qu'une mise à jour de ce système ait provoqué ce dysfonctionnement.

Veuillez utiliser Aide > Donner un retour afin que nous puissions examiner ce problème de plus près.

Traduit automatiquement depuis English Afficher l'original