4.6.2. L'attribut dir

Tandis que la plupart des langues s'inscrivent dans un flux de caractères de gauche à droite, l'hébreu et beaucoup de langues arabes s'écrivent de droite à gauche.

La directionnalité du texte (text directionality) est contrôlée des manières suivantes :

1. 1. La directionnalité définie explicitement sur l'élément racine (via l'attribut dir), ou, si non définie, que suppose l'application de traitement ;
2. 2. L'attribut dir="ltr|rtl" sur un élément qui surclasse la direction héritée. La direction spécifiée n'a priorité sur l'algorithme bidirectionnel Unicode que sur les caractères Unicode neutres (par exemple, les espaces et la ponctuation) dans le contenu de l'élément. Les valeurs "ltr" et "rtl" ne sont pas prioritaires sur les caractères fortement bidirectionnels ;
3. L'attribut dir="lro|rlo" sur un élément. La direction spécifiée a priorité sur l'algorithme bidirectionnel Unicode sur tous les caractères dans le contenu de l'élément ;

Dans la plupart des cas, les auteurs ont besoin d'utiliser dir="rtl|ltr" pour s'assurer que la ponctuation entourant une phrase de droite à gauche ("rtl") dans un élément de gauche à droite ("ltr") soit correctement rendue. Pour passer outre la direction des caractères Unicode fortement typés (c'est-à-dire la plupart des caractères qui s'appliquent à une langue, sauf la ponctuation, les espaces et les chiffres), l'auteur devra utiliser dir="lro|rlo". L'utilisation de l'attribut dir et de l'algorithme Unicodes est clairement expliquée dans l'article Spécifier la direction du texte et des tableaux : l'attribut dir. L'article référencé contient plusieurs exemples d'utilisation de dir="rtl|ltr". Il n'y a pas d'exemple d'utilisation de dir="lro|rlo", quoique que l'on puisse en déduire un de l'exemple utilisant l'élément <bdo> (l'ancienne méthode du W3C pour passer outre l'algorithme bidirectionnel Unicode entier ; la méthode préconisée maintenant utilise des valeurs de priorité (override values) sur l'attribut dir).

Extrait de la spécification HTML 4.0 :

L'attribut dir spécifie la directionnalité du texte : de gauche à droite (dir="ltr", valeur par défaut) ou de droite à gauche (dir="rtl"). Les caractères dans Unicode sont affectés d'une directionnalité, de gauche à droite ou de droite à gauche, afin que le texte puisse être rendu correctement. Par exemple, alors que les caractères anglais sont présentés de gauche à droite, les caractères hébreux le sont de droite à gauche. Unicode définit un algorithme bidirectionnel qui doit s'appliquer à chaque fois qu'un document contient des caractères de droite à gauche. Bien que cet algorithme donne habituellement la bonne resprésentation, certaines situations voient le texte laissé avec une directionnalité neutre et nécessitent une indication de la directionnalité de base avec l'attribut dir. Le texte est souvent de directionnalité neutre lorsqu'il incorpore plusieurs contenus avec une directionnalité différente. Par exemple, une phrase en anglais qui contient une phrase en hébreu, laquelle contient une phrase en anglais, nécessiterait de définir la directionnalité de la phrase en hébreu avec l'attribut dir. La phrase en hébreu, incluant la citation en anglais, serait contenue dans un élément p avec dir="rtl".

Utilisation recommandée

L'algorithme bidirectionnel Unicode pourvoit à divers niveaux de directionnalité, ainsi :

1. 1. La directionnalité est soit spécifiée explicitement via l'attribut dir sur l'élément au niveau supérieur (<topic> ou un pair dérivé pour les thèmes, <map> pour les cartes DITA), soit supposée par l'application de traitement. Il est recommandé de spécifier l'attribut dir sur l'élément au niveau supérieur dans le thème ou l'élément de document de la carte ;
2. 2. Lors de l'incorporation d'un jet de texte de droite à gauche dans un jet de texte de gauche à droite (ou vice versa), la direction par défaut fournit souvent des résultats incorrects, particulièrement si le jet de texte incorporé inclut de la ponctuation située à ses extrêmités. Unicode définit les espaces et la ponctuation comme ayant une diretionnalité neutre, et définit la directionnalité de ces caractères neutres lorsqu'ils apparaissent entre des caractères avec une directionnalité forte (la plupart des caractères qui ne sont ni des espaces ni de la ponctuation). Bien que la direction par défaut soit souvent suffisante pour déterminer la bonne directionnalité de la langue, l'algorithme rend parfois incorrectement les caractères (par exemple, un POINT D'INTERROGATION à la fin d'une question en hébreu peut apparaître au début de la question au lieu de la fin). Pour contrôler ce comportement, l'attribut dir est fixé à "ltr" ou "rtl" au besoin, afin de s'assurer que la direction voulue s'applique aux caractères avec une directionnalité neutre. Les valeurs "ltr" ou "rtl" supplantent seulement les caractères neutres pas tous les caractères Unicode ;
3. 3. On veut parfois passer outre la directionnalité par défaut des caractères fortement bidirectionnels. On le fait en utilisant les valeurs "lro" et "rlo", qui prévalent sur l'algorithme de directionnalité Unicode. Essentiellement, cela force la direction du contenu de l'élément. Ces attributs de forçage (override attributes) donne à l'auteur un moyen brutal de paramétrer la directionnalité indépendamment de l'algorithme bidi Unicode. Les valeurs "ltr" et "rtl" plus légères ont un effet moins radical, en n'affectant que la ponctuation et les autres caractères dits neutres.

Les valeurs "ltr" et "rtl" suffisent pour la majorité des besoins de création. On ne devrait utiliser les valeurs de forçage que si ces valeurs ne permettent pas d'obtenir l'effet désiré.

Bien que le standard Unicode inclut des marqueurs cachés pour la directionnalité sans qu'il y ait besoin de balisage, on ne devrait pas utiliser ces marqueurs. Il est fortement recommandé de baliser le document avec l'attribut dir pour définir la directionnalité. L'utilisation du balisage au lieu des marqueurs Unicode présente les avantages suivants :

• Le document sera aussi portable que possible ;
• Le document peut être traité par des applications qui n'implémentent pas complètement l'algorithme bidi Unicode ;
• Le document balisé peut être lu et compris par des humains ;
• Lors de la mise à jour du document, les frontières de chaque flux de texte sont claires, ce qui facilite beaucoup la mise à jour par l'auteur.

Précautions de mise en œuvre

Les utilisateurs devraient être conscients que le balisage descriptif ne constitue pas nécessairement la fin de leur travail. Chaque restitution de sortie possible ou outil d'affichage peut avoir des exigences différentes pour la gestion du texte bidirectionnel. Tout comme des navigateurs HTML différents offrent des niveaux de prise en charge du style CSS variables, des outils de sortie différents mettent en œuvre l'algorithme bidirectionnel et ses contrôles directionnels différemment. Par exemple, le HTML affiché dans le navigateur Internet Explorer aura des exigences différentes de celui affiché dans Firefox. De la même façon, un contrôle qui fonctionne dans une partie d'un fichier HTML, telle le corps de la page, pourrait ne pas fonctionner ailleurs, telle que dans le titre ou l'index dans une aide HTML compilée. La même incertitude se retrouve dans pratiquement toute sortie. Les outils de rendu PostScript ou PDF traitent le texte bidirectionnel différemment. Les logiciels Microsoft Word et OpenOffice Writer ne traitent pas le RTF bidirectionnel de la même façon. Flash ne se préoccupe d'aucune sorte de balisage directionnel mais formatte les chaînes selon l'algorithme Unicode.

L'entrée dépendant de manière imprévisible de la sortie éventuelle, il ne suffit pas d'appliquer l'attribut dir pour faire apparaître le XML comme il le devrait dans un éditeur. On doit prendre des précautions supplémentaires pour s'assurer que le balisage sera correctement transformé (ou ajouté à la source XML, si nécessaire), à la fois par rapport au format de sortie cible et par rapport à l'outil de sortie cible. Dans le cas de HTML, cela pourrait signifier de créer une sortie ajustée aux capacités du navigateur supposé le plus commun, ou de créer une sortie ajustée pour le navigateur le moins capable et de s'assurer que le balisage fonctionne avec le navigateur censé le plus capable. Par exemple, du HTML bidirectionnel qui s'affiche parfaitement dans Internet Explorer ne s'affichera peut-être pas correctement dans Safari. Par contre, si le HTML s'affiche parfaitement dans Safari, il y a de fortes chances pour qu'il s'affiche aussi correctement dans Internet Explorer. Ce n'est pas une certitude néanmoins. Chaque cas devrait être testé et confirmé par des personnes qualifiées.

Les applications qui traitent les documents DITA, que ce soit lors de la création, de la traduction, de la publication ou tout autre stade, devraient gérer entièrement l'algorithme Unicode pour la mise en œuvre correcte de l'écriture et la directionnalité de chaque langue utilisée dans le document. La pratique recommandée est d'écrire tous les marqueurs de directionnalité via le balisage XML et de ne pas utiliser les marqueurs bidirectionnels Unicode, qui devraient être remplacés par du balisage lors de la sauvegarde du document.

Les applications devraient s'assurer que chaque élément <topic> au niveau supérieur et l'élément racine <map> définissent explicitement l'attribut dir.

OASIS DITA Version 1.1 Architectural Specification — OASIS Standard, 1 August 2007
Copyright © OASIS Open 2005, 2007. All Rights Reserved.