Note : on a un même bogue similaire aussi dans JOSM (mais là c'est un défaut du rendu de texte dans les bibliothèques Java, dont la solution nécessite la prise en charge du nouvel algorithme BiDi d'Unicode).
- Un libellé "ARABE (1)" qui devrait apparaître comme "EBARA (1)" apparaît comme "((1 EBARA" - mais "ARABE (1) " (avec une espace à la fin) qui devrait être indentique apparait comme "(1) EBARA " - Un libellé "Latin - ARABE (1)" qui devrait apparaître comme "Latin - EBARA (1)" apparait comme 'Latin - ((1 EBARA" - Un libellé "Latin - ARABE (1)" qui devrait apparaître comme "Latin - EBARA (1)" apparait comme 'Latin - (1) EBARA" D'une façon générale aussi, JOSM compose des chaines par concaténation sans s'inquiéter de la direction : le " (1)" ajouté à la fin n'en tient pas compte. Comme il crée des chaines en texte simple et non des chaines en format enrichi (type HTML ou RTF), il devrait utiliser des caractètes de contrôle directionnel. Mais les anciens contrôles directionnels codés dans Unicode (et les styles CSS2 ou CSS correspondant) ne permettent pas une encapsulation correcte des niveaux directionnels. Le seul moyen est d'utiliser les nouveaux controles directionnels (l'équivalent dans CSS2 utilisant "unicode-bidi: embed" ne fonctionne pas correctement, une nouvelle valeur est proposée dans Unicode 6 et CSS3 et devrait être ajoutée aussi dans HTML5 , mais rien envue pour l'instant du côté du codage texte seul pour son rendu correct dans Java ; cela ne marche pas mieux non plus dans la CLR de .Net, ni dans WebGL, GDI-Plus, et avec les moteurs de layout texte standards actuels). L'algo BiDi d'Unicode est en cours d'évolution et doit aussi modifier la prise en charge des ponctuations fonctionnant par paire (les parenthèses), l'encapsulation. Les nouveaux contrôles directionnels (pour le support en texte seul) ne sont pas encore reconnus. Dans JOSM la saisie bidirectionnelle est toujours aussi difficile : impossible de sélectionner correctement les espaces qui sont en frontière entre deux directions, malgré la présence du "caret" orienté supposé aider à savoir la direction de ce qu'on écrit, et gestion incorrecte des touches de flèches droite et gauche, et ambiguité entre les touches SUPPR et BACKSPACE, et impossibilité de savoir si on a sélectionné un caractère ou pas en frontière de changement de direction (par exemple si on a sélectionné ou pas un espace séparateur de mots, ou quelle ponctuation est utilisée lorsqu'elle est en affichée en miroir). Il est de même impossible d'y saisir un contrôle directionnel ou de savoir si on en a un dans le texte. Et on n'a toujours pas d'option "contrôles visibles" ni d'option permettant de passer dans une vue avec désactivation du réordonnancement BiDi et des caractères présentés en miroir. On ne sait pas visuellement ce qui est saisi pour pouvoir le corriger. Le problème affecte aussi le rendu sur le web (consultation des historiques de changesets par exemple). Note: tous les anciens contrôles directionnels d'Unicode sont dépréciés, SAUF les nouveaux (ceux qui permettent une encapsulation complète où ce qui suit l'encapsulation ne dépend pas de la direction de ce qui est encapulé avant mais doit reprendre la direction du texte placé avant le texte encapsulé). Mais tant qu'on ne les verra pas mieux supportés, on aura des problèmes à gérer les langues écrites de droite à gauche, dès qu'on combine les textes avec des caractères à direction ou rendu contextuel (ponctuations en miroir, présentation des chiffres, ponctuations de séparation pour la présentation de listes d'items...). La dernière version de l'algo BiDi est toujours en discussion et pas finalisée. De fait JOSM devrait éviter de concaténer des chaînes dont il ne sait pas quelle est la direction de lecture ou si elles contiennent déjà plusieurs directions. Pour s'en sortir, la seule façon est de sélectionner tout le champ pour le copier vers le presse-papier et le coller dans un éditeur de texte externe permettant de voir réellement "ce qui est dedans". Mais peu d'éditeurs externes en sont en fait capables (sous Windows, ne fonctionnent pas Notepad, WordPad, NotePad++; il n'y a que Vim ou Emacs, sous Windows ou Linux, qui ont le supporte adapté où le WYSIWYG n'est pas le seul mode de saisie ou d'affichage ; aucun navigateur Web n'a ce support nativement) J'utilise un plugin Javascript "fait maison" (pas beau mais fonctionnel) dans mon navigateur Chrome pour afficher une vue complémentaire sous un champ de saisie de texte). Mais rien que je puisse faire pour corriger les rendus incorrects. Mapnik a encore d'autres anomalies BiDi où il inverse les mots arabes même dans un libellé tenant sur une seule ligne. Son algo Bidi est carrément bogué et ne correspond même pas à sa version actuelle stabilisée pourtant il y a plusieurs années. Pour ces raisons il est quaiment impossible d'obtenir une carte correcte affichant les toponymes arabes, hébreux. Enfin toujours pas de support de l'écriture tiginaghe pour le Maghreb dans JOSM (le choix de polices est trop restreint). Pas plus non plus pour les écritures birmane, syriaque, éthiopienne, khmère, laotienne ; le rendu des écritures brahmiques indiennes est tout aussi bogué. Le rendu arabo-persan (pour le farsi et l'ourdou) est tout aussi incorrect (ligatures complètement fausses, diacritiques mal placés). Ce n'est pas un gros problème pourle tendu Web, sauf dans un éditeur en ligne basé sur Flash (lui aussi largement bogué, mais Adobe ne veut plus rien faire pour maintenir Flash, il n'investit plus que dans HTML5 et CSS, et porte son ancienne bibliothèque ActiveScript vers Javascript). Malgré tout c'est le rendu BiDi qui pose les plus grosses difficultés. Espérons que tout le monde se mette au rendu compatible HTML5+CSS3, même les OS y compris dans les bibliothèques graphiques accélérées pour la 3D ou l'animation 2D, et que la nouvelle norme Unicode 6+son nouvel algo BiDi (pratiquement finalisé) soit pris en charge et qu'enfin se développe une méthode de saisie BiDi pratique et stable (actuellement c'est encore infernal). Le 19 août 2013 09:23, Bruno Cortial <bruno.cort...@laposte.net> a écrit : > > Le 18 août 2013 21:40, Philippe Verdy <verd...@wanadoo.fr> a écrit : > > http://www.openstreetmap.org/#map=19/36.25233/1.97501 >> >> On constate ici dans TOUS les rendus Mapnik un bogue pour l'affichage des >> textes bidirectionnels : l'affichage n'est correct QUE s'il n'y a pas de >> saut de ligne au milieu du libellé >> >> Ainsi un libellé bilingue comme: >> "Nom latin - NOM ARABE" >> devient bien après réordonnancement linéaire des glyphes (sur une seule >> ligne): >> "Nom latin - EBARA MON" >> >> Mais ça se complique en cas de saut de ligne (pour des libellés trop >> longs, ou contenant des espaces): >> "Nom latin" >> "- EBARA" >> "MON" >> est complètement faux, alors que la solution correcte serait plutôt: >> "Nom latin" >> "- MON" >> "EBARA" >> >> Autrement dit ce n'est pas parce que la partie écrite en arabe se lit de >> droite à gauche qu'il faut couper la partie coupée à droite et la placer >> SOUS la partie conservée à gauche. >> >> Mapnik ne respecte donc pas l'ordre des mots car même en arabe les lignes >> se lisent du haut vers le bas et nom du bas vers le haut. >> >> Le rendu bidirectionnel Mapnik (nécessaire pour l'arabe, l'hébreu) est >> faux partout aussi bien sur le site .org que sur les rendus français et >> même d'autres (OpenCycleMap, etc.). >> >> A qui renvoyer l'anomalie? >> >> > Bonjour, > C'est par là: https://github.com/mapnik/mapnik/issues > Il faut regarder les bugs existants tagués text-symboliser et/ou > harfbuzz (bib de gestion des caractères UTF). > > Il y a eu un travail réalisé l'année dernière sur les placements de texte, > mais ton cas ne semble pas évoqué : > http://mapnik.org/news/2012/08/04/gsoc2012-status7/ > http://mapnik.org/news/2012/07/22/gsoc2012-status5/ > > A+ > Bruno >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
