Comments on Club Contexte : Communications Papier (ou pensées en vrac sur les lettres et leur forme)

@JML:

C'est vrai, j'ai excessivement simplifié. D'ailleurs, Unicode définit toutes sortes de relations d'équivalence entre suites de caractères (codepoints) Unicode, par exemple U+00E9 LATIN SMALL LETTER E WITH ACUTE (é) devrait être dans un certain sens équivalent à la succession U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT (é) (je ne sais pas comment j'ai réussi à pondre un rant aussi long sans mentionner les combinants) et dans certains contextes, d'ailleurs pas complètement clairs, il est autorisé de transformer l'un en l'autre, d'utiliser l'un pour afficher l'autre, de matcher l'un quand on recherche l'autre, ce genre de choses.

N'empêche qu'on sait très bien que ça va causer des emmerdes de toutes sortes : à moins qu'on normalise les équivalences et les contextes dans lesquels elles doivent servir, on va se retrouver avec un système de recherche qui considère que <foo> et <bar> sont pareil et un autre qui ne le considère pas, un OS qui considère qu'on peut avoir deux fichiers nommés <foo> et <bar> dans le même répertoire et un autre qui ne le considère pas (d'où toutes sortes d'emmerdes quand on échange des fichiers de l'un à l'autre…), ou pire, une situation où on dit à un utilisateur qu'il ne peut pas créer un fichier <foo> parce qu'il y en a déjà un mais où ce fichier n'apparaît pas quand il le recherche — ou bien le contraire.

@DH: Aaaaaaahhh… Je n'avais même pas imaginé une seule seconde que ça devait être autre chose que /gora/…

@Typhon:

Ce que je crois avoir illustré dans mon rant, c'est qu'à la fois l'amalgamation et la désunification peuvent poser des problèmes, et parfois on n'a que le choix entre Charybde et Scylla, donc d'un côté comme de l'autre les gens vont se plaindre. Quand on râle que des caractères « différents » ont été amalgamés, on oublie que, dans le cas contraire, la recherche dans un texte serait rendue excessivement merdique et les problèmes de sécurité se multiplient. Réclamer « le plus de distinctions possibles » n'est clairement pas une bonne solution ; je le sais notamment parce que j'avais utilisé Emacs pré-Unicode, son principe à lui était de faire la réunion de tous les jeux de caractères existants (en n'unifiant qu'ASCII stricto sensu), alors on avait un ‘à’ latin-1 et un ‘à’ latin-3 et même un ‘à’ latin-15 tous distincts, et sans doute plein d'autres, c'était un cauchemar. À un certain moment, aussi, je passais mon temps à corriger sur Wikipédia les ‘µ’ (U+00B5 MICRO SIGN) qui auraient dû être des ‘μ’ (U+03BC GREEK SMALL LETTER MU) ou vice versa — tiens, j'aurais dû en parler, de ça — et à maudire cette désunification. (Pourquoi est-ce que le ‘k’ de « km » est un ‘k’ tout ce qu'il y a de plus normal alors que le ‘µ’ de « µm » est un truc complètement spécial qui ne sert que pour ça ?)

Et spécifiquement, s'agissant de l'unification Han, j'ai entendu plein de gens râler, mais je n'ai jamais entendu qui que ce soit expliquer ce qu'on aurait dû faire au juste. Notamment, il faut se souvenir qu'avant même qu'Unicode n'existe, les dessins de caractères (voire des polices complètes) avaient déjà commencé à s'échanger librement entre langues asiatiques, conduisant à l'apparition de glyphes passés d'une langue à une autre où ils étaient censément « incorrects » (whatever that means) : la mondialisation n'a pas attendu Unicode, et le phénomène n'est pas spécialement de la faute des « occidentaux ».

Décider de désunifier complètement les idéogrammes japonais, chinois traditionnels, chinois simplifiés, coréens aurait fatalement conduit à des textes hybrides à la frankenstein parce que les gens auraient pris les caractères là où ils étaient en cas de lacunes, la recherche aurait été rendue impossible par la multiplicité des variantes, l'encodage de textes anciens aurait été un casse-tête supplémentaire, et pour les caractères très rares on se serait rendu compte que ça n'a plus aucun sens d'essayer de savoir de quelle langue ils sont (ou alors on aurait fini par encoder N fois 10^5 caractères)… En comparaison, le problème du ‘µ’ versus ‘μ’, ce serait de la gnognote. Et il n'est même pas clair que ça aurait résolu le problème parce que les variations de glyphes existent aussi au sein d'une même langue et qu'un moment ou un autre il faut bien décider ce qu'on considère comme digne d'être encodé et ce qu'on ne considère pas comme digne d'être encodé.

Est-ce que tu suggérerais, par exemple, qu'on dût faire plusieurs ‘G’ différents parce que le ‘G’ majuscule cursif ne s'écrit pas pareil en France et aux États-Unis ? Non, tu vas juste dire à quelqu'un qui cherche une police cursive d'en trouver une qui colle avec l'écriture de son pays.

Bref, il fallait un compromis. Le compromis qui a été trouvé n'était pas parfait, et il y a beaucoup de caractères précis où il est même épouvantable, mais c'est notamment parce que les Japonais, au début, et dans une certaine mesure les Chinois de RPC, ne voulaient pas travailler avec Unicode, parce qu'ils s'estimaient satisfaits de leur standard national, donc ils ont participé aux décisions à reculons, et forcément, elles ont été assez mal prises. Les désunifications excessives l'ont été surtout parce qu'Unicode a eu la main forcé par des standards préexistants (surtout japonais, justement). Les amalgamations excessives l'ont été surtout par manque d'implication des organismes de standards nationaux, mais il y a un point qu'il faut souligner, c'est qu'il est beaucoup plus facile de désunifier sur le tard que de revenir sur une désunification (on ne peut pas réamalgamer deux caractères, au mieux on peut marquer l'un comme déprécié), et Unicode a souvent montré qu'il pouvait revenir sur ses décisions (j'ai donné des exemples).

Le mécanisme des sélecteurs de variations est un excellent moyen de donner plus de flexibilité à Unicode en la matière : cela offre une mesure intermédiaire entre amalgamer complètement et désunifier totalement ; cela permet des variations sans langage de markup mais quand même de ne pas trop casser les recherches. Alors certes, l'implémentation est encore défaillante, mais reprocher à un standard de ne pas être implémenté partout, c'est un peu fallacieux. (Moi aussi ça m'emmerde que mes lecteurs n'aient pas tous le symbole ‘𝔖’ quand je veux parler de maths, mais ce n'est pas la faute d'Unicode, quand même !) En attendant, on peut aussi utiliser des indications explicites de polices ou de langues. La lecture de la page <URL: http://en.wikipedia.org/wiki/Han_unification > me permet de constater que, sur mon navigateur et avec les polices que j'ai installées sur mon ordi, les différences entre glyphes chinois et japonais sont bien réelles.

Et surtout, il faut souligner ceci : UNICODE N'EMPÊCHE RIEN DE CE QUI ÉTAIT POSSIBLE AVANT UNICODE. Tous les encodages de caractères asiatiques sont reflétés fidèlement dans Unicode : si une page Web ou un fichier texte pouvait être écrit en Shift-JIS ou en GB18030, c'est encore possible avec Unicode. Ce n'est pas la faute d'Unicode si le mécanisme de sélection des polices, derrière, se comporte mal. Une fois qu'on a compris ce fait, la grande majorité des critiques contre Unicode en général ou l'unification Han en particulier, apparaissent comme teintées d'une grande mauvaise foi.

Le second lien que tu donnes est très intéressant, mais je ne trouve pas que ce soit une critique du processus d'unification Han, c'est surtout une illustration de l'extrême complexité des choix à faire et de l'impossibilité d'éviter à la fois Charybde et Scylla. Le premier lien… je ne vois vraiment pas ce qu'on peut en tirer quand il ne donne pas le moindre détail technique… il paraît que quelque chose n'est pas encodable en Unicode en bengali, mais quoi ? aucune idée, il ne donne pas une image de ce qu'on devrait pouvoir encoder ni l'approximation que fournit Unicode, ni la moindre précision sur le problème… S'il y a des caractères qui manquent, ils peuvent toujours être ajoutés, mais ce qui est sûr c'est que, une fois de plus, Unicode n'a pas pu empirer la situation par rapport aux standards qui existaient avant (comme ISCII).