Wiktionnaire : dictionnaire libre et universel

Discussion utilisateur:Verdy p/Codage Unicode de la liaison

< Discussion utilisateur:Verdy p
Dernier commentaire : il y a 14 ans par Verdy p dans le sujet retour à U+203F

liaison, diacritique double brève souscrit modifier

Dernier commentaire : il y a 14 ans46 commentaires4 participants à la discussion

Bonjour. Le modèle:liaison utilise le signe diacritique brève souscrit U+035C entre deux espaces insécables. Pourquoi ne pas simplement utiliser le tirant souscrit U+203F comme nous en avons l’habitude pour les liaisons en API ?

U+035C est sensé être souscrit sous deux lettres.

Ce n'est pas vrai, Unicode n'écrit pas seulement ça. Regarde la descriptions des diacritiques combinants dans la norme Unicode (consulte le chapitre 3, consacré à la conformité, et lis le modèle de codage des caractères, Unicode Character Encoding Model), il ne les restreint pas aux seules lettres. verdy_p (d) 6 novembre 2009 à 12:58 (UTC)Répondre

U+203F est entre deux caractères. Il n’y pas de composition créant une équivalence entre les deux dans Unicode.

Il y a-t-il une source qu’on peut utiliser comme référence pour justifier l’usage de trois caractères U+0020 U+035C U+0020 au lieu d’un U+203F ? --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 30 octobre 2009 à 17:33 (UTC)Répondre

Corrections :
  1. le caractère U+035C n'est pas la brève souscrite comme tu l'écris, mais la double brève souscrite.
  2. le modèle:liaison n'utilise pas une espace normale (U+0020) mais une espace insécable (U+00A0), comme le recommande Unicode pour créer des versions à espacement de tout diacritique (les anciennes équivalences de compatibilité des symboles de diacritiques avec chasse ne sont plus recommandés, et n'ont jamais été des équivalences canoniques de toute façon.
Justement la liaison API ne se met pas sous les deux lettres, mais sous une espace. Et U+203F a été mal utilisé car on l'a mis directement entre les deux phonèmes alors que sa largeur est nulle, ce qui accole les deux caractères. Mais on peut aussi remplacer dans le modèle U+035C par U+203F (à condition de garder les espaces insécables de chaque côté) si ce caractère est plus approprié, afin de s'assurer qu'il ne sera PAS sous les deux phonèmes liés.
verdy_p (d) 5 novembre 2009 à 22:04 (UTC)Répondre
J'ajoute aussi que le symbole U+203F n'a pas été codé dans Unicode en tant que tel, mais y a été ajouté en 1993 lors de la fusion avec ISO/IEC 10646, où il ne codait pas la liaison (malgré son nouveau nom normalisé "UNDERTIE", traduit de façon non normative en français « tirant souscrit ») car dans ISO/IEC 10646 il représentait la ponctuation grecque énotikon.
Cela est confirmé d'ailleurs par les références normatives de l'API et de SAMPA (qui nomment ce symbole phonologique "tie bar below", représenté par le soulignement "_" en X-SAMPA) :
voir par exemple http://www.phon.ucl.ac.uk/home/wells/ipa-unicode.htm
où clairement ce n'est pas l'énotikon grec (U+203F) qui est utilisé, mais bien la double brève souscrite (U+035C).
Le même symbole API (ou SAMPA) est un diacritique double dont l'effet porte sur les deux caractères avant et après. Pour la liaison, cela impose de coder une espace avant et après, le même symbole API/SAMPA pouvant aussi se placer entre deux phonèmes pour former les diphtongues, les consonnes affriquées (codage recommandé au lieu des ligatures obsolètes) ou encore pour lier les consonnes de pré- ou post nasalisation et les glides consonnantiques ou vocaliques.
Et c'est cohérent avec ce que produisent les polices qui montrent correctement la liaison en utilisant la double brève, mais pas bien du tout avec l'énotikon grec qui est une ponctuation diacritique combinante.
Et je n'ai jamais écrit qu'il y avait une équivalence entre les deux codages dans Unicode (c'est toi qui interprète). verdy_p (d) 6 novembre 2009 à 10:36 (UTC)Répondre
Salut, juste pour dire, j'utilise SCIM sous linux pour écrire en API en tapant en X-SAMPA. Or, la liaison en X-SAMPA y est écrite /-\/ (et non /_/), et elle donne bien le caractère /‿/ (~espace insécable avec trait dessous). De manière générale, autant que j'ai pu en juger, c'est toujours ce caractère qui est utilisé pour les liaisons. En outre, le site que tu indiques ne précise pas que c'est utilisé pour les liaisons (juste tie bar below), il est même placé dans la section des diacritiques, et la liaison n'en est pas un, il me semble. N'aurais-tu pas une autre source qui indique spécifiquement que quel caractère est utilisé pour les liaisons ? — Dakdada (discuter) 6 novembre 2009 à 11:10 (UTC)Répondre
Le codage X-SAMPA "-\" est tout à ait correct, mais la référence SAMPA ne mentionne pas comment il se transcrit en Unicode.
Noter que quand X-SAMPA a ajouté "-\" en 1993, il faisait pourtant référence à ISO 10646 où pourtant U+203F était déjà présent (mais pas encore dans Unicode): demandez-vous pourquoi alors SAMPA n'a pas référencé ce caractère déjà existant depuis longtemps dans ISO/IEC 10646 ?
Hors dans Unicode U+203F n'a pas été codé pour la liaison (et il n'a été ajouté que parce qu'il représentait l'énotikon grec dans ISO 10646 avant la fusion).
Le caractère U+035C en revanche existait déjà dans les deux normes Unicode et ISO 10646 en 1993.
U+035C est unifié (et Unicode permet et recommande d'ailleurs l'utilisation de l'espace insécable U+00A0 pour créer des versions avec chasse des diacritiques simples ou doubles).
Cela devrait s'imposer au codage utilisé pour transcrire X-SAMPA en Unicode. Il n'y a aucune référence dans SAMPA pour dire qu'il devrait utiliser U+203F en API.
Alors je veux bien que SCIM sous Linux fasse ce qu'il veut, mais c'est son implémentation et pas une norme.
verdy_p (d) 6 novembre 2009 à 11:27 (UTC)Répondre
encore d'autres arguments:
  • Les deux sites de référence pour l'API et SAMPA sont bien connus, il n'y en a pas d'autres. Ils sont d'accord sur le glyphe à utiliser pour la liaison, mais ni l'un ni l'autre ne mentionne comment ce symbole de l'API se code en Unicode.
  • La dernière et seule référence reste alors la norme Unicode. Hors justement Unicode ne mentionne pas U+203F comme faisant partie des symboles pour l'API (en revanche il mentionne bien le bloc des diacritiques U+0300..U+03FF pour cet usage. Cela s'applique donc aussi bien à l'API que X-SAMPA (l'extension de SAMPA qui a ajouté le symbole de liaison en 1993).
cf. http://unicode.org/charts/ (sous l'entrée "Phonetic symbols") et noter que dans les tableaux il est fait référence aussi aux diacritiques génériques.
Le document informatif d'Unicode (note technique) UTN#29 contient des précisions sur l'emploi des caractères Unicode comme symboles dans les dictionnaires. Il fait référence au diacritique U+035C dans plusieurs exemples concernant les transcriptions phonétiques (malheureusement pas dans le cas de la liaison API/X-SAMPA).
verdy_p (d) 6 novembre 2009 à 11:56 (UTC)Répondre
# U+035C double brève souscrit, oui, mea culpa.
# espaces insécables, comme je l’avait remarqué.
Tu ne l'avais pas remarqué, c'est pour ça que j'ai corrigé (tu as bien écrit U+0020 plus haut, de même que dans le commentaire incorrect de ta modification du modèle). verdy_p (d) 6 novembre 2009 à 12:41 (UTC)Répondre
La liste Phonetic symbols des tables Unicode ne contient pas les symboles API comme a U+0061, etc. Doit-on appliquer le raisonnement qui exclu U+203F à ces symboles API ? Clairement, non, ce raisonnement est sans aucun doute trompeur. Unicode ne dicte pas que seul les caractères des blocs de Phonetic symbols sont des symboles API et pas les autres.
Je repose ma question : Où est-il indiqué que la liaison s’écrit à l’aide de deux espaces autour d’un signe diacritique au lieu d’un caractère unique ? --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 12:13 (UTC)Répondre
Unicode écrit clairement que l'API s'écrit avec les caractères latins (c'est pour ça qu'il a réencodé distinctement dans l'écriture latine des symboles API issus de l'alphabet grec). Il décrit explicitement l'API comme l'extension de cette écriture (de même que les promoteurs de l'API), et les diacritiques combinants de l'alphabet latin sont donc inclus (en témoigne la propriété "Script=Latn" codée dans Unicode pour tous ces symboles API).
Et l'énotikon grec est clairement un caractère grec depuis le début (alors seulement dans ISO 10646, même avant 1993 quand l'ISO a rééncodé ses anciens jeux de caractères 7 et 8 bits en 16 bits, et codé depuis 1993 dans Unicode 1.1 comme la même ponctuation grecque), ce qui explique les gros défauts d'affichage de U+203F quand il est utilisé avec la plupart des polices courantes latines supportant aussi l'alphabet grec (Arial, Verdana, Courrier New, Times New Roman, etc.) où U+203F mange les caractères voisins qui disparaissent (certes ce sont des bogues de ne rien afficher, mais U+203F n'a pas été fait pour être utilisé avec l'écriture latine, contrairement à U+035C apparu dans Unicode 4.1 et très bien supporté dans de très nombreuses polices latines).
Ni SAMPA (dans sa révision X-SAMPA de 1993, pas remise à jour depuis), ni l’API n'indiquent dans leurs normes le caractère Unicode ou ISO 10646 à utiliser. Seul Unicode le fait explicitement dans le corps du texte de la norme (et dans les références incluses dans ses charts où l'API est clairement mentionné comme une extension de l'alphabet latin, et d'ailleurs codé comme tel pusique les mêmes symboles sont maintenant utilisés aussi comme lettres normales dans des langues à écriture latine, Unicode ayant ajouté depuis des capitales pour certaines lettres).
Unicode indique l'utilisation de l'espace insécable avec les diacritiques dans le corps du texte de la norme. Il faut le lire, c'est pas compliqué quand même (ce sont des PDF, je ne peux pas te donner de lien direct dans un paragraphe de ces fichiers PDF).
De plus, l'API proscrit l’utilisation des ponctuations génériques pour les transcriptions phonétiques. Pour les transcriptions phonologiques et/ou morphologiques (dont fait partie la liaison), il admet l'espace ou le point bas comme séparateur de segmentation, mais cela ne va guère plus loin (ce qui exclue d'inclure la plupart des ponctuations générales de l'Unicode, sauf mention explicite). verdy_p (d) 6 novembre 2009 à 12:27 (UTC)Répondre
Vous dites que l’API n’admet que l’espace et le point. Pourquoi admet-il donc l’espace insécable, un diacritique, et un autre espace insécable ?
Relis s'il te plait ce que j'ai écrit : j'ai marqué « pour les transcriptions phonétiques » et j'ai fait explicitement l'opposition avec « les transcriptions phonologiques ». Il faut comprendre évidemment que les deux concepts (phonétique et phonologie) sont différents, d’usage distinct, et notés distinctement entre [] ou //.
Le point-virgule ';' U+003B est un symbole utilisé dans l’écriture latine, mais aussi dans l’écriture grecque, même si l’érotimatikon ';' U+037E est codé. Idem pour le point '.' U+002E, aussi utilisé en API.
Même remarque. De plus l'éromatikon grec est unifié avec le point-virgule (par une équivalent canonique de type singleton, donc non inversible, ce qui fait de l'éromatikon un caractère de compatibilité non recommandé, comme le sont aussi les accents grecs).
Le tirant souscrit '‿' U+203F n’est pas catégorisé dans un système d’écriture spécifique non plus. Rien ne l’empêche d’être utilisé en API.
Regarde la propriété de ce caractère : c'est vrai que techniquement on pourrait l'utiliser dans d'autres écritures, mais depuis le début c'est le codage de la ponctuation grecque (comme l'indique la note d'usage dans les charts, qui reprend le nom qui existait dans ISO 10646 avant sa fusion dans Unicode). Si on va plus loin, l'IPA permet aussi de modifier dans certains cas les diacritiques souscrits en diacritiques en chef, s'ils portent sur des symboles avec jambes (descenders), ce qui ne donne pas un codage unique de la fonction, mais deux versions possibles à la fois du glyphe et du caractère utilisé pour ces diacritiques. Comme ici il n'y a pas de jambage, cette tolérance n'est pas possible, il n'y a qu'un seul glyphe possible.
Bien que l’API soit une extension de l’écriture latine, on y retrouve le béta grec β U+03B2, le theta U+03B8 et le chi grec χ U+03C7.
Faux ! Ce sont les versions latines de ces caractères qui sont utilisées, comme je l'ai écrit plus haut, relis !). On n'a pas toujours pu le faire, mais Unicode les a explicitement codés comme caractères latins à la demande de l'IPA (association), le codage complet de l'API (version 1996) dans Unicode ne s'étant terminé que depuis Unicode 5 (et la version correspondante de ISO/IEC 10646). Ce qu'on faisant avant n'était qu'une approximation pour les caractères manquants. Ces approximations n'ont jamais été recommandées mais seulement admises en attendant mieux (y compris pour les extensions plus récentes de l’API qui ne sont toujours pas codées, comme les caractères de « contours » de ton (tonalités multiples) pour lesquels on devrait les décomposer en mores (avec le symbole API vide [ø] sur lesquels on peut appliquer les diacritiques de ton simple successifs ; il y a donc encore des caractères manquants). verdy_p (d) 6 novembre 2009 à 13:52 (UTC)Répondre
«ce qui explique les gros défauts d'affichage de U+203F » De quel défaut d’affichage parlez-vous ?
Le chapitre 7 du livre Unicode indique bien l’usage de l’espace insécable avec un signe diacritique mais pour l’isoler, hors de texte habituel, ç-à-d. quand le caractère est cité (cf. Marks as Spacing Characters dans la section 7.9 du livre). --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾
Oui car il faut bien dans ce cas qu'il ne s'attache pas aux caractères voisins, ni qu'il se détachent de l'espace normale (par l'effet de la gestion et la compression des espaces normales dans HTML ou XML). Unicode a du mentionner cela parce qu'avant on pouvait utiliser aussi l'espace normale (ce qui posait des problèmes avec HTML, SGML et XML), et d'autre part parce que les équivalences de compatibilité mentionnent l'espace normale pour décomposer les diacritiques avec chasse (ces équivalences de compatibilité ne sont pas recommandées, elles ne sont dans la norme que pour compatibilité avec des normes plus anciennes). Cette note n'a pas toujours été là, mais la décision a été prise de cet ajout il y a maintenant plus de 5 ans (elle est mentionnée aussi dans les normes HTML, XML et SGML, et sans doûte d'autres, pour ne plus utiliser l'espace U+0020, quoi que contienne la base de données UCD au sujet des décompositions de compatibilité des diacritiques avec chasse, pour lesquels il n'y aura plus aucun autre codage, puisque tous ceux qui manqueraient DOIVENT être codés avec U+00A0 et le diacritique combinant existant). verdy_p (d) 6 novembre 2009 à 13:52 (UTC)Répondre
Où est-il donc justifier que U+203F n’est pas à utiliser en API ? Pour l’instant vous ne justifier cela qu’avec vos raisonnements. Je ne suis pas convaincu et qui devrait l’être ? --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 13:55 (UTC)Répondre
Pour l'instant, il n'y a pas de recommandation de codage Unicode. Le caractère U+203F posant des problèmes sérieux, tant que l’« IPA Handbook » ne recommandera pas un codage (comme il le fait pour la plupart des symboles phonétiques, mais pas les symboles phonologiques), ni Unicode lui-même (dans une révision de UTN#29), on doit vivre avec ces problèmes. Et on doit simplement constater que le diacritique double remplit très bien sa fonction pour représenter le glyphe prescrit avec de très nombreuses polices parmi les plus courantes. On doit aussi constater que les navigateurs et éditeurs de texte traitent incorrectement la sélection du caractère U+203F, car ils l'interprètent comme un diacritique, ou cherchent des ligatures inexistantes (puisqu'ils ne supporte vraiment ce caractère que pour lier deux morphèmes grecs. De nombreuses polices (parmi les plus courantes et même dans leur version récente) le traitent comme un diacritique combinant sans chasse, ou calculent mal sa largeur (ce qui provoque l'effacement des caractères voisins).
On verra plus tard si on peut utiliser U+203F, mais pour l'instant ça ne marche pas (et ça casse complètement l'affichage de la phonétique avec les polices par défaut, même celles théoriquement conçues pour supporter l'API) : ne plus voir les caractères qui suivent (et ne pas voir non plus le caractère de liaison, ni même un carré blanc s'il manque dans une police) est un bogue sérieux à prendre en compte. C'est à cause de ces problèmes qu'un modèle simple (sans paramètre pour qu'il n'y ait aucun problème de performance sur le serveur) est utile (d'autant qu'il facilite énormément les modifs de modèles complexes, où des caractères U+203F avaient été utilisés n'importe où, ou laissés par erreur au mauvais endroit, et étaient difficiles à corriger avec l'éditeur web). verdy_p (d) 6 novembre 2009 à 14:07 (UTC)Répondre
L’API pourrait effectivement clarifier le problème. À ma connaissance il n’y a jamais eu de plainte d’affichage de U+203F avec les polices par défaut. Avez-vous des captures d’écran ou des liens vers de plaintes ? Si des applications manipulent ce caractère incorrectement c’est un problème, mais quelles applications ? Je n’ai jamais eu de problème sous Linux ou Windows. --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 14:24 (UTC)Répondre
Tous les navigateurs existants sous Windows (IE, Firefox, Safari, Chrome), même dans leur dernière version, par exemple en affichant cette page-ci. Si tu ne vois pas le problème, c'est que tu es sans doûte sous Linux/Unix avec un moteur de rendu du texte sous X11 qui lui est propre. verdy_p (d) 6 novembre 2009 à 14:33 (UTC)Répondre
Et ne me dis pas que ça marche avec les polices par défaut sous Windows (ce n'est pas vrai même sous Windows Seven), regarde comment s'affiche ta propre phrase citée plus haut:
« Le tirant souscrit '‿' U+203F... » (inacceptable, le tirant dépasse le caractère suivant et peut même effacer la suite si ce n'est pas une espace).
Le même exemple avec cette fois U+035C entre espaces insécables :
« Le tirant souscrit ' ͜ ' U+00A0 U+035F U+00A0... » (OK dans tous les cas)
Et regarde aussi avec les polices sélectionnées par le modèle:pron: Erreur sur la langue !. On n'a pas du tout la liaison attendue, mais un tirant souscrit sous le z et éventuellement le e, voire seulement le z, le e étant mangé comme on le voit encore dans certains tableaux de conjugaisons composées par les liaisons entre l'auxiliaire et le participe passé).
De même en édition,
  • la police à chasse fixe par défaut (monospace) : z‿e (caractère absent, carré blanc)
  • Courier New : z‿e (caractère absent, carré blanc)
ou en visualisation, avec
  • Arial : z‿e (caractère absent, carré blanc)
  • Arial Unicode MS (inclus dans MS Office) : z‿e (caractère absent, carré blanc)
  • Code2000 (libre) : z‿e (caractère absent, carré blanc)
  • Verdana : z‿e (caractère absent, carré blanc)
  • Times New Roman : z‿e (caractère absent, carré blanc)
  • Segoe UI (par défaut sous Windows 7) : z‿e (caractère absent, carré blanc)
  • Tahoma : z‿e (caractère absent, carré blanc)
  • DejaVu Sans (libre) : z‿e (c'est le seul cas où l'affichage est correct, mais ce n'est une police par défaut sur aucun système)
En revanche avec U+035C et l'espace insécable, et :
  • la police à chasse fixe par défaut (monospace) : z ͜ z (passable mais lisible sans ambiguïté)
  • Courier New : z ͜ z (passable mais lisible sans ambiguïté)
  • Arial : z ͜ e (passable mais lisible sans ambiguïté)
  • Arial Unicode MS (inclus dans MS Office) : z ͜ e (passable mais lisible sans ambiguïté)
  • Code2000 (libre) : z ͜ e (passable mais lisible sans ambiguïté)
  • Verdana : z ͜ e (passable ou OK suivant la version)
  • Times New Roman : z ͜ e (passable ou OK suivant la version)
  • Segoe UI (par défaut sous Windows 7) : z ͜ e (OK)
  • Tahoma : z ͜ e (OK)
  • DejaVu Sans (libre) : z ͜ e (OK)
verdy_p (d) 6 novembre 2009 à 14:38 (UTC)Répondre

Voici mes captures d’écran sous Windows XP.

C’est plutôt U+00A0 U+035C U+00A0 qui pose un problème. ---moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 15:11 (UTC)Répondre

J'ai tout le contraire sous XP aussi, ainsi que Vista et Seven (et aussi sous Linux avec Firefox, je viens de le tester, j'essayera bien KHTML si je pouvais l'installer facilement sans passer trop de temps à reconfigurer le reste et le maintenir). A mon avis ton système est configuré pour forcer certaines polices (dont une à problème qui ne supporte pas U+035C) car je ne vois pas dans tes captures chez toi les différences de polices telles qu'elles sont sélectionnées. verdy_p (d) 6 novembre 2009 à 15:17 (UTC)Répondre
Oui, certaines polices ne sont pas installer, il y a donc parfois une substitution par défaut. Courier New, Arial, Arial Unicode MS, Verdana, Times New Roman, Segoe UI, Tahoma sont installées. Tu vera la différence si tu regardes bien. Je ne me suis pas amuser à configurer tout mes navigateurs pour utiliser une police unique. DejaVu Sans que tu as rajouté après mes captures d’écran ne pose aucun problème dans chaque navigateur. --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 15:25 (UTC)Répondre
C'est la guerre de celui qui aura l'affichage le plus pourri   ? NB : perso chaque fois que je suis allé voir le Wiktionnaire sous XP, que ce soit IE ou Firefox, je n'ai jamais eu de problème d'affichage (et encore moins de carré blanc) au niveau de la liaison. À vérifier. Je ne parle même pas de Linux où je n'ai aucun problème. — Dakdada (discuter) 6 novembre 2009 à 15:27 (UTC)Répondre
Au moins ça confirme une chose, chez Moyogo, sa police par défaut de substitution (DejaVu Sans) est celle qu'il a configurée manuellement pour avoir un affichage qui semble fonctionner dans certains cas. Les navigateurs toutefois se comportent de façon aléatoire/incohérente et non compatible avec ce que font les autres, quand ils comptent sur ces substitutions. C'est pour ça qu'il ne faut pas compter dessus, et qu'on a des polices ordonnées explicitement dans les pages, si on a besoin de certains caractères. verdy_p (d) 6 novembre 2009 à 15:37 (UTC)Répondre
Note: je fais tous mes tests sur une machine virtuelle propre sans ajout supplémentaire (avec MS VirtualPC ou Sun Virtual Box, cela ne change rien les mêmes images système fonctionnant dans les deux, mais un peu plus rapidement dans VirtualBox), telle qu'elle est installée par défaut avec aussi les mises à jour automatiques. Pour tester je copie l'image et j'installe le navigateur, sans outil complémentaire optionnel (pas de barres d'outils, pas de thèmes, seulement les fonctions de base...), car hors des machines virtuelles (plus lentes), mes systèmes de base ont souvent plein d'extensions.
Ceci dit sur une autre machine que j'ai qui fonctionne sous XP avec peu d'extensions, j'ai les mêmes résultats que dans les machines virtuelles (en 32-bit) comme aussi une autre sous Windows Server 64-bit. Je n'utilise Linux que dans une machine virtuelle, pas comme système de base. verdy_p (d) 6 novembre 2009 à 15:31 (UTC)Répondre

Voici mes captures d’écran sous Vista depuis l'ordinateur de quelqu’un d’autre:

--moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 15:55 (UTC)Répondre

Contre l’argument que le bloc U+2000 n’est pas utilisable pour l’API : U+2016 ‖ est utilisé pour Major (intonation) group. (cf références ci-dessous) --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 16:34 (UTC)Répondre

Ok mais je n'ai pas parlé de bloc, juste d'un caractère (dont on connait un nom et un glyphe, mais pas le point de code recommandé) pour lequel il n'y a aucune recommandation officielle que ce soit par SAMPA, IPA (association), ou Unicode.
On a des noms similaires, mais pas identiques (le seul nom normalisé dans Unicode et ISO/IEC 10646 sont les noms anglais en capitales, même s'ils sont trompeurs et induisent en erreur pour certaines utilisations, mais que ni Unicode, ni l'ISO ne peuvent modifier, dès que le principe de leur codage a été accepté lors des dernières étapes de validation, et avant même que le point de code qui leur soit finalement assigné soit définitif et publié ne serait-ce que dans une version bêta. Les changements de noms sont impossibles ensuite, même si Unicode admet que ces noms peuvent être trompeurs, et dans ce cas il ne peut qu’ajouter une note informative dans ses charts, ou publier des notes techniques annexes, ou définir un comportement dans une mise à jour de ses annexes standardisées UAX, sauf si cela doit changer des propriétés stabilisées et normatives, telles que les décompositions canoniques et de compatibilité; il peut aussi réviser les glyphes de référence pour faire des distinctions nécessaires car ces glyphes ne sont pas complètement normatifs et ne servent qu'à identifier distinctement les caractères entre eux quand les différences sont pertinentes dans une même écriture donnée).
En attendant une clarification d'API ou d'Unicode, gardons le status quo avec l’habitude des linguistes, cf les références ci-dessous, et utilisons U+203F. --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 7 novembre 2009 à 09:35 (UTC)Répondre

Salut à tous, j'ai presque tout lu de votre petite discussion... J'n'y connais pas grand chose, je suis en codage UTF8. Moi j'ai toujours eu ça : Fichier:Modèle-liaison-Firefox-XP.png.PNG. C'est grave docteurs ? Stephane8888 Discuter 6 novembre 2009 à 16:56 (UTC)Répondre

Tiens, je n'ai pas la police Arial Unicode MS, c'est peut-être pour ça que ça s'affiche mal chez moi... Stephane8888 Discuter 6 novembre 2009 à 17:08 (UTC)Répondre

Fichier:Modèle-liaison-Firefox-WinXP-2.png Autre capture d'écran, Firefox, Windows XP tout neuf, sans modification à part Firefox. Sans DejaVu Sans, Arial MS Unicode fait l'affaire dans ce cas. --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 7 novembre 2009 à 08:45 (UTC)Répondre

références modifier

En attendant une référence de l’API. Il y a quelques autres références utilisés par les linguistes :

--moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 16:34 (UTC)Répondre

--moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 7 novembre 2009 à 10:25 (UTC)Répondre

Note que toutes ces sources ne lèvent pas l'ambiguïté d'utilisation (au passage, certaines oublient aussi de mentionner que ie bar souscrite ou en chef sont allographes dans la notation de 1996, alors qu'elles sont distinguées dans Unicode). D'ailleurs aux dates où elles ont été publiées, le diacritique double (qui lève totalement ces ambiguïtés) n'existait pas encore dans Unicode (version 4.1) et ISO/CEI 10646. Comment auraient-ils pu mentionner autre chose ?
On n'a toujours rien d'officiel concernant tous les ajouts ultérieurs à 1996 et leur codage dans Unicode/ISO/CEI 10646. verdy_p (d) 13 novembre 2009 à 02:07 (UTC)Répondre
On aura toujours le problème tant que l'API ou l'Unicode ne fournira pas un codage explicite ou une référence avec le même nom pour l'usage dans l'API. Tant que cela n'aura pas eu lieu, il y a peu de chances de voir les moteurs de rendus ou les polices mises à jour pour donner un comportement correct (pourquoi corriger ce qui marche dans l'état, alors que ça peut encore changer?).
Ceci dit, tes sources sont intéressantes, et pourraient motiver les normalisateurs à faire ce choix, et les auteurs de polices et moteurs de rendus à adapter leur support (Microsoft, par sa politique de stabilité, se refuse à le faire lors de mises à jour simples, en dehors de la création de nouvelles polices pour ses logiciels, ou de mises à jour majeurs de Windows ou d'Office dans lesquels ses polices sont distribuées : il ne corrige que les problèmes liés à la sécurité).
Si on regarde le support actuel, il n'y a que la police DejaVu Sans qui fonctionne avec linking codé en U+203F, mais elle ne figure dans aucune installation par défaut des systèmes (et l'installer n'est pas non plus sans problèmes à cause du comportement instable et imprévisible des fallbacks des navigateurs). Les autres polices par défaut sur les systèmes usuels ne fonctionnent pas correctement avec ce codage. Doit-on imposer aux utilisateurs d'avoir installé DejaVu Sans, même ceux qui aujourd'hui passent à Windows Seven ?
Note aussi que je n'ai pas de système MacOSX pour tester (ne serait-ce que dans une machine virtuelle, car les Mac sont chers et Apple ne fournit pas de licence MacOX sans avoir d'abord un PC ou un serveur d'Apple avec, et MacOSX ne peut pas fonctionner légalement sur autre chose qu'un matériel certifié par Apple). verdy_p (d) 6 novembre 2009 à 17:00 (UTC)Répondre
Ceci dit, le monde Windows n'est toujours pas rose, face à MacOSX: http://manas.tungare.name/blog/wp-content/uploads/2007/09/which_vista.gif (ça parle de Vista mais c'est encore pareil avec Seven).  ;-)
Mais MacOSX n'est dispo qu'en mise à jour (pas cher à 29€, mais jamais sans un Mac avec MacOSX déjà dedans). L'un vend et promeut du logiciel, l'autre du matériel et ne fait pas ses marges commerciales sur la même chose. Le tout est garanti par des accords commerciaux entre les deux sociétés (qui ne se concurrencent que sur d'autres produits que les systèmes d'exploitation, Apple et Microsoft acceptant parfaitement de faire tourner Windows ou Linux sur un Mac : Apple vend aussi des droits sur les médias, que Microsoft ne vend pas, bien qu'ils se concurrencent sur les serveurs de médias et les players) verdy_p (d) 6 novembre 2009 à 17:20 (UTC)Répondre
U+203F est dispo aves les systèmes qui ont Arial Unicode MS aussi (qui n’est pas installé par défaut sans Office). U+035C n’est pas disponible sur les Windows plus anciens que Vista par défaut. --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 6 novembre 2009 à 17:29 (UTC)Répondre
Oui mais Arial Unicode MS est plutôt merdique et plus génant qu'utile sur le web (vu qu'il n'existe qu'en caractères droits, non gras et non italiques) et qu'il cohabite très mal avec les Fallbacks de Windows pour plein d'écritures.
Je l'ai carrément enlevée, elle n'est pas nécessaire à Office, largement boguée (elle ne peut servir que comme police de Fallback, et encore c'est pas évident de bien régler les paramètres de navigateur avec)
Il y a mieux, même sous Windows avec des polices mieux conçues (même si elles sont séparées par type d'écriture) ou avec la nouvelle Segoe UI qui est très bien pour lire le web comme pour l'interface utilisateur (tout en étant compatible avec les polices pour écritures non latines), ou encore Cambria qui est vraiment magnifique et d'une grande lisibilité pour les styles avec sérifs et les textes anciens (à voir sur Wikisource).
De plus l'API demande normalement une police avec sérifs, ce qui fait que cette variante un peu plus complète de la police Arial n'est pas adaptée.
Ceci dit, je vais très vite abandonner aussi Vista (en tant que système hôte) et le remplacer par Seven au vu des performances (quitte à passer Vista en système hébergé dans une machine virtuelle). Il faut juste que je prépare le backup de Vista en VHD, puis que je refasse après l'opération une image propre.
De plus j'ai des licences pour Seven (depuis la version Final Release for OEM) et tous les systèmes de Microsoft, dans toutes les versions (même Ultimate et les versions Server, toutes les langues et toutes variantes 32 ou 64 bits), même les versions historiques (MS-DOS 6 et Windows 3 inclus dont je ne me sers pas, mais sait-on jamais...), pour un nombre illimité d'installations (tant qu'elles sont personnelles car ce n'est pas une licence de distribution). J'ai fait ce choix plutôt que d'acquérir une série de licences individuelles de mise à jour (c'était plus économique et c'est aussi nettement plus pratique à l'usage que les mises à jour chiantes de Windows), et de toutes versions des produits Systèmes et Office que Microsoft sortira pendant un an (jusqu'en fin août prochain) ; la différence c'est que je n'ai pas de CD, tout est en ligne, et pas de support personnalisé de la part de Microsoft (totalement inutile).
Je ne sais plus trop de quelles versions de polices dispose XP, puisque je l'utilise généralement dans une machine avec les polices dans leur version Vista puis maintenant de Seven (c'est légal sur la même machine hôte, vu que je suis le seul utilisateur et j'ai une licence légale sur cette machine, tout le reste de ce qu'essaye d'imposer Microsoft est illégal car Microsoft tente illégalement de limiter les autres logiciels qu'on peut installer sur une installation légale du système qu'il a lui même approuvée, et vu que le système hébergé a aussi sa propre licence, de même que la machine virtuelle de Sun qui la fait tourner et n'est qu'un logiciel compatible comme un autre sur le système hôte, comparable à VirtualPC que Microsoft distribue d'ailleurs gratuitement aux détenteurs de licences Windows pour le système hôte). verdy_p (d) 6 novembre 2009 à 18:15 (UTC)Répondre
Tu as mal lu : le même document mentionne justement que U+203F est bel et bien aussi utilisé comme un diacritique combinant sous les caractères. Bref que U+203F pose problème pour son emploi en tant que liaison. Un problème que règle le codage proposé dans N2594 qui permet les deux usages de façon clairement non ambigüe.
Note que les documents du WG2 sont des ébauches, pas des normes, elles servent seulement à donner justification des propositions de nouveauc codages (ils cessent de devenir des références une fois le codage établi, car ces documents ne sont jamais approvués en tant que tels).
Pourtant ici, ce document recommande bel et bien l'emploi du caractère proposé et pas de U+203F qui est reconnu comme faisant problème (donc pas seulement par moi !). verdy_p (d) 11 novembre 2009 à 21:48 (UTC)Répondre
Et je cite ce document que tu ne veux pas lire correctement :
In the Handbook of the IPA (1999), the character is actually misidentified.
Page 173 shows "Top tie bar", IPA #433, which is a diacritic to indicate various kinds of coarticulation (affricate or double articulation). This is a nonspacing double diacritic, = U+0361.
Page 174 shows "Bottom tie bar", IPA #509, which is an indication of linking. That is a spacing extender, equivalent to U+203F UNDERTIE.
(But the example shown on p. 203 is not this; instead p. 203 shows the nonspacing double diacritic in question, displaying *below* two characters.)
The IPA documentation does not properly distinguish between "tie bars" that behave this way and U+203F UNDERTIE.
Unicode has to make this distinction, because nonspacing and spacing things are quite different in implementation and properties.
In concept, the nonspacing tie bar below is simply an allograph of the nonspacing tie bar above. It is like the cedilla below the g (Figure 7-1, p. 162, The Unicode Standard 3.0) that jumps to an inverted comma above the g, because of the presence of a descender.
However, because of properties and because of the nature of our encoding of nonspacing combining marks in particular, it makes sense to encode a separate character for this allograph.
Ce qui clairement dit que IPA ne fait pas correctement la distinction entre les utilisations avec chasse et sans chasse du même symbole, et que normalement la liaison est avec chasse, mais que la documentation API de référence (IPA Handbook) mentionne aussi le contraire page 203 où il apparait comme diacritique combinant sans chasse.
Bref, si tu cites une source, lis la complètement et pas à moitié en la survolant (tu n'as pas été loin, tu as lu une seule ligne et pas la ligne suivante !). Et évalue la portée aussi du document (normative ou informative).
En clair, puisque que l'API ne fait pas la distinction les polices n'ont aucune chance d'être corrigées, tant que l'API n'aura pas été révisée (ce document parle de l'API 1999) et que les polices qui emploient U+203F comme diacritiques ne sont pas fautives au sens de l'API. Comme il est impossible de prédire le comportement de U+203F, et comme toutes les polices usuelles ont inclu U+203F de la façon ambigüe où l'IPA les définissait, ces polices (dont toutes les polices par défaut présinstallées sur les systèmes) posent problème ! Pour afficher aussi bien une liaison que pour afficher des coarticulations et affriquées. Un problème qui est totalement résolu par U+035C dont l'emploi correct a été précisé dans Unicode dans les deux cas (liaison ou coarticulation).
verdy_p (d) 11 novembre 2009 à 21:56 (UTC)Répondre
J’ai lu le document, et pas juste une ligne. C’est toi qui le comprends mal. Il confirme que U+203F est utilisé pour la liaison et la ligature, mais qu’il ne devrait pas être utilisé pour la ligature, d’où la création de U+035C. Si des polices ont un U+203F corrompu (sans chasse), c’est une erreur dans ces polices. ---moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 12 novembre 2009 à 13:24 (UTC)Répondre

retour à U+203F modifier

Dernier commentaire : il y a 14 ans10 commentaires2 participants à la discussion

Salut,
J’ai remplacé les modèles liaisons avec U+203F là où je l’ai trouvé.

  • Status quo, _aucune_ référence ne mentione le besoin de proscrire l’usage du U+203F pour les notations API.
  • Plusieurs références donnent et utilisent U+203F, notamment celle de l’UVic et Linguist List à défaut d’avoir une directement d’IPA.
  • Unicode ne présice pas quel est le rôle de la liste Phonetic Symbols sur http://unicode.org/charts/, celle-ci contient de l’API, mais aussi d’autres notations phonétiques. De plus le caractère '‖' U+2016 est dans le même cas que U+203F
    Aucun rapport. Car U+2016 n'a pas d'usage en tant que diacritique et n'intervient dans aucune ligature. Et tu as tord, il mentionne bien ce caractère explicitement comme entrant dans les notations phonétiques. Ce que tu ne veux pas admettre c'est que l'argument que j'avais utilisé inclut bel et bien U+035C parmi les caractères phonétiques (sans en exclure pour autant U+203F pour des raisons historiques, même s'il est ambigu ce qui n'est pas le cas de U+2016.); d'ailleurs Unicode ne code pas seulement l'API mais aussi les symboles UPA (alphabet phonétique ouralien, basé sur une extension de l'aphabet cyrillique, au lieu d'une extension de l'alphabet latin dans le cas de l'API). verdy_p (d) 13 novembre 2009 à 02:39 (UTC)Répondre
  • S’il y a un problème d’affichage à cause d’une police, c’est un problème de police et non un problème de code Unicode.
    Encore une fois tu te trompes, ces polices ne sont pas fautives (hormi le fait qu'elles devraient au minimum afficher quelque chose et ne pas laisser un blanc ni omettre toute la ligature entièrement quand elles pourraient afficher aussi les caractères séparément). Et Unicode non plus, qui référence l'IPA pour lequel il n'y a pas d'erreur dans ces polices d'usage très courant (et préinstallées par défaut sur nombre de systèmes, dont tous les systèmes Windows, Mac, et X11). Moralité : on se traine le problème depuis 15 ans, et on a une solution propre depuis Unicode 4.1 depuis près de 7 ans, et toujours aucune correction de ces polices. On ne verra pas de changement de ces polices pour encore au minimum 6 ou 7 ans (3 ans pour attendre un éventuel changement dans une version future de Windows 8, ou d'autres systèmes qui suivent les mêmes évolutions, puis encore 3 ans ou plus pour avoir les mises à jours, dans 15 ans on y sera encore. Pourquoi trainer ce problème derrière nous quand on a une solution qui fonctionne bien et est déjà bien supportée (et même de mieux en mieux, en utilisant le diacritique double) ??? J'ai envie de faire un parallèle avec l'ASCII qui comporte aussi des caractères d'usage ambigu (comme le tiret-moins ou l'apostrophe droite, qui resteront sans doûte toujours ambigus mais qu'il est hors de question de changer maintenant, les ambiguités pouvant être résolues avec d'autres caractères sans corriger aucune des polices existantes qui ne sont pas fautives non plus). verdy_p (d) 13 novembre 2009 à 02:51 (UTC)Répondre
  • U+203F est nommé Undertie, son alias est Greek enotikon. U+035C est nommé Combining double breve below, ses alias sont : ligature tie below, papyrological hyphen. L’hyphen papyrologique est utilisé en grec ancien, et semble être la même chose que l’énotikon grec. Ceci explique sans doute la confusion possible ou les erreurs dans certaines polices, due à l’histoire des codes Unicode en question.
    En fait non. Ce ne sont pas des erreurs, mais l'interprétation directe de ce que l'API recommandait depuis l'origine, quand il a recommandé l'utilisation de tirants souscrits ou suscrits diacritiques à la place des anciennes ligatures pour les coarticulations (comme la ligature 'ts'). Les coarticulations existant dans presque toutes les langues, il est normal qu'ils aient alors utilisé le seul caractère à leur disposition à l'époque, U+203F comme l'indiquait déjà l'IPA Handbook de 1993 ! Ils ont omis le cas de la liaison française car ils ne l'avaient pas rencontrée, mais surtout parce que le symbole de liaison n'est pas à proprement parler un symbole phonétique (mais une extension de l'API pour une utilisation non phonétique), d'autant que les dictionnaires ou traités de français la notait aussi de différentes façons sans recourir à ce symbole, dans leurs diverses notation phonologiques ou morphologiques (comme c'est encore le cas aujourd'hui). Le symbole de liaison est en fait moins fortement recommandé que l'utilisation en tant que diacritique qui elle est fortement normalisée depuis plus de 15 ans. verdy_p (d) 13 novembre 2009 à 02:46 (UTC)Répondre

--moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 9 novembre 2009 à 15:36 (UTC)Répondre

Tu noteras que 203F ne marche toujours pas correctement après le caractère /ʁ/ de l’API (les exemples que j'avais donnés après le caractère /z/ ne sont pas les plus sérieux, alors que c'est la même lettre latine z normal non réservée à l'API et que la liaison n'est nécessaire en tant que telle que dans le contexte après un symbole de l'API... Bizarre quand même qu'un caractère fait pour l'API ne fonctionne correctement qu'après les lettres latines ou grecques, mais pas après les symboles spécifiques parmi les plus courants pour les consonnes de l'API; il semble donc que les testeurs des polices ont oublié que la liaison française peut aussi intervenir après autre chose que des consonnes latines, ils ont du croire qu'on notait /r/ en français et non /ʁ/ ou que de telles liaisons étaient inexistantes en français). Je ne m'explique pas de toute façon pourquoi U+203F est traité comme un diacritique dans certaines polices en dépit de son origine indiscutable pour noter l'énotikon grec...
Et j'ai toutes les polices nécessaires et les plus à jour qui soient. Ca ne marche correctement QUE avec la police DejaVu Sans, jamais installée par défaut. verdy_p (d) 11 novembre 2009 à 21:41 (UTC)Répondre
Note sur le titre que tu as donné à ce message : cela n'est certainement pas un « retour » à 203F, c'est bien un « changement ». Car le modèle dès le début a utilisé U+035C depuis le début qu'il a été créé et dans les quelques endroits où il a été utilisé pour résoudre un problème bel et bien existant (faut de mieux mais aussi de spécification réelle sur le codage de la liaison, car tes sources ne sont pas normatives même si elles sont intéressantes), que visiblement tu sembles vouloir ignorer totalement (ce qui me choqe alors est de voir comment un /ʁ/ en fin de mot suivi d’une liaison avec le mot commençant par une voyelle, se voit supprimé totalemnt à l'affichage, de même que la voyelle qui suit !).
Ce qui me choque aussi c'est de voir que le caractère de liaison U+035C s'il est rentré directement, reste totalement invisible dans l'éditeur, et qu'il se retrouve régulièrement mal ordonné (un problème que résoud très facilement un modèle simple et très lisible, quel que soit ce qu'il génère.
Ton titre laisse croire que c'est moi qui ait changé les choses, ce qui n'est absolument pas vrai, le changement ne venant pas de moi mais m'étant imposé uniquement par toi.
Ce problème existe depuis longtemps et la sortie finale de Windows 7 (qui n'y change rien) fait qu'il va persister maintenant pendant des années (au strict minimum 3 ans, plus encore si on tient compte du temps des mises à jour et d'adoption des nouveaux systèmes, je dirais plutôt un minimum de 6 à 10 ans!), sans jamais permettre une solution alternative pendant tout ce temps là (un problème facile à régler même si à terme U+203F est mieux supporté qu'il ne l'est actuellement de façon incorrecte). verdy_p (d) 11 novembre 2009 à 21:41 (UTC)Répondre
Bref je demande que tu révertes les remplacements d'appel du modèle (quoi que contienne le modèle) par le caractère seul. C'est arbitraire et tu ne prends pas en comptes les difficultés rencontrées et bien avérées. verdy_p (d) 11 novembre 2009 à 21:42 (UTC)Répondre
  • C’est bien un retour, les linguistes utilisent U+203F depuis qu’il existe dans Unicode, le Wiktionnaire l’utilse depuis ses débuts. Un jour tu ajoutes le modèle liaison et l’ajoutes au modèle de conjugaison. Ce modèle de conjugaison utilisait U+203F, tu l’as modifier pour utiliser U+035C à l’aide du modèle liaison. J’ai donc bien fait un retour à U+203F.
  • Mes références ne sont pas directement de l’IPA mais elles font parties des références utilisées par la communauté linguistique dont l’IPA fait partie. L’IPA n’a émi aucune interdiction d’utiliser U+203F. Si l’a communauté se trompe, que fait l’IPA ?
  • Tu ne donnes aucune référence normative proscrivant l’usage de U+203F pour la liaison.
  • S’il y a un problème de police, c’est au niveau des polices qu’il faut le résoudre. D’autres polices que DejaVu Sans affiches U+203F correctement voir Fichier:Modèle-liaison-Firefox-Vista-2.png.
  • Si tu veux, lance un vote. Si les contributeurs du Wiktionnaire sont d’accord avec toi, tant mieux pour tes polices. En attendant, utilisons ce que les linguistes utilisent. ---moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 12 novembre 2009 à 13:40 (UTC)Répondre

U+203F est dans plusieurs polices de Seven : Microsoft PhagsPa et SegoeUISymbol ; et ce, à chasse. Il semble donc que l’avenir est plus prometteur que tu ne sembles l’observer. --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾ 12 novembre 2009 à 15:52 (UTC)Répondre

La police PhagsPa n'est pas une police latine. Il apparait que ce signe est aussi une ponctuation en PhagsPa, raison de son placement là (et en PhagsPa il n'y a pas l'ambiguïté de son interprétation. Mais tu ne pourras pas transcrire de l'API avec cette police. Et pas non plus avec l'autre. U+203F est codé deplus plus de 16 ans sans chasse dans des polices qui ne sont pas prêtes d'être corrigées (d'autant que les initiateurs d'Unicode et ISO/CEI 10646 ont reconnu eux-mêmes l'ambiguïté de ce symbole, qui dès lors à les 2 fonctions et continuera de poser les problèmes d'ambiguïté et de sa dépendance des polices utilisées qui ne peuvent certainement pas changer sans une redéfinition claire par l'IPA Association).
Tout ce qu'on peut dire c'est que bien que 203F ne soit pas codé comme diacritique, il est malgré tout légal qu'il soit traité ainsi dans des ligatures (et l'API lui-même en a fait usage en autorisant des ligatures plutôt que l'emploi du signe, mais une position révisée depuis où les ligatures ne sont plus recommandées du tout, ce qui a encore accru le problème du symbole qui a été utilisé depuis maintenant plus de 10 ans pour former les coarticulations...)
On pourrait se dire qu'Unicode ferait mieux d'employer un code distinctif pour l'emploi sans chasse là où il existe l'ambiguïté. Mais ce n'est pas du tout nécessaire car la solution avec le diacritique double et l'espace insécable est parfaitement décrite dans Unicode (et aussi implémentée maintenant dans de plus en plus nombreuses polices) sans soulever aucun problème de compatibilité (et d'autre part Unicode a établi une politique de ne pas encoder de caractères supplémentaires pour lesquels il existe déjà une solution de codage non ambigüe.)
J'ai écrit à Unicode et à l'IPA mais je n'ai toujours aucune réponse. Ce que je peux en dire c'est que cette question a déjà été longuement discutée dans les listes de diffusion Unicode et divers ateliers. Et à chaque fois la solution avec NBSP et le diacritique double résolvait simplement le problème évoqué par ceux qui posaient la question...
Je n'ai cependant pas le détail de la suite qui a été donnée au document provisoire de la proposition de codage du diacritique double. Malheureusement, une fois le caractère approuvé, on n'a pas le détail des motivations (sans doûte pour ne pas fermer non plus d'autres usages légaux futurs qui ne posent pas de problèmes de compatibilité ascendante. Les seules descriptions normalisées sont celles des propriétés assignées aux caractères codés, et l'indication informative d'un glyphe représentatif possible, insuffisant dans le cas de U+203F qui autorise déjà son utilisation dans les ligatures optionnelles, comme tous les autres caractères d'ailleurs, qu'ils soient avec ou sans chasse).
Le mieux serait qu'Unicode discute d'une note technique (UTN) révisée pour l'API (telle qu'une révision de UTN#29 portant sur les symboles utilisés dans les dictionnaires). verdy_p (d) 13 novembre 2009 à 02:01 (UTC)Répondre
Ajouter un sujet
Récupérée de « https://fr.wiktionary.org/w/index.php?title=Discussion_utilisateur:Verdy_p/Codage_Unicode_de_la_liaison&oldid=6548750 »
Retour à la page de l’utilisateur « Verdy p/Codage Unicode de la liaison ».