Re: [EGD-discu] [Vote] Touche morte + espace

[Marcel <bkn.ema@xxxxxxxxx>]

Samedi 21 Janvier 2017 15:10:30, Flamme a écrit :
> 
> > Avant cela, Vendredi 20 Janvier 2017 18:22:26, Flamme avait écrit :
> >> Mais ce qui m’importe vraiment, c’est que les diacritiques combinants ne
> >> se retrouvent pas sur ESPACE. Sur le point, c’est bien.
> >
> > Pourrais-tu s.t.p. détailler les raisons qui t’amènent à cette préférence… troublante ?
> 
> Je n’aime pas la confusion et les incohérences.
> 
> Jusqu’à présent, le bépo a privilégié les touches mortes et les 
> caractères unifiés [1].

Je sais qu’on les trouve meilleurs pour en avoir l’habitude, mais ces caractères 
« unifiés » sont une invention des architectes d’encodages sur 7 ou 8 bit. Déjà 
ISO/IEC 6937 a encodé les diacritiques à part, sauf qu’ils allaient avant, en tant
qu’octet modificateur (de mémoire). Les concepteurs d’Unicode voulaient juste offrir 
la possibilité de faire des allers-retours de conversion avec les anciens encodages. 
Ils appellent ces caractères des « précomposés ». L’unification, c’était entre les 
carctères chinois, japonais et coréens, ça a été un exploit et un succès. 

Avec ce système hérité de caractères précomposés, on a besoin de trop de caractères, 
il paraît que ça ne tiendrait pas dans les 65 000 du plan multilingue de base, car il
y a beaucoup d’autre écritures, dont les écritures complexes, qui utilisent des 
diacritiques elles aussi. Encoder séparément toutes les combinaisons utilisées 
ferait exploser le répertoire, donc il fallait vraiment trouver une solution plus 
intelligente que les caractères précomposés. Pour faire entrer ceux du vietnamien 
dans Unicode, il a fallu un lobbying intense. 

> 
> Quel sens ça aurait de mettre la création de caractères combinants [1] 
> sur la plus grosse touche du clavier?

Ça met en avant la liberté. On n’a plus besoin de faire encoder de longues listes 
et de les faire entrer dans toutes les polices. On peut ajouter les diacritiques 
qu’on veut. Certes il faut que les programmes soient à jour, mais c’est moins lourd 
et plus performant. 

Et c’est un geste en faveur des langues qui se sentent défavorisées du fait de ne 
pas avoir toutes les lettres diacritées en tant que précomposées dans Unicode. 
C’est le cas du bambara avec marques tonales, du ga, pour ne citer que les langues 
que j’ai vues passer à cause des problèmes de clavier. En refusant aux diacritiques 
combinants la barre d’espace et en les reléguant sur le point, on acquiert une 
mauvaise image.

> 
> Quel sens cela a-t-il de promouvoir l’écriture de deux manières différentes?

Pour ce qui est des diacritiques qui se posent à la périphérie des lettres de base, 
la promotion va clairement du côté des diacritiques combinants, car c’est la seule 
manière d’écrire qui couvre toutes les langues à écriture latine, et c’est la méthode 
employée pour d’autres écritures aussi. Il n’y a pas lieu de privilégier les 
utilisateurs de l’écriture latine. Mais personne ne nous empêche ni même nous en 
veut de continuer d’écrire les langues européennes avec les lettres précomposées. 
Quant aux diacritiques traversants, ils restent précomposés parce que ça commence 
à devenir plus difficile au niveau des polices, et avec les crosses c’est carrément 
impossible.

Mais attention, ça ne concerne que le codage, car l’écriture proprement dite peut 
se faire par touches mortes comme avant. Unicode spécifie même que c’est le plus 
évident, de garder les habitudes acquises. Donc on peut mettre dans les touches 
mortes tous les ensembles de lettres composées utilisées dans les différentes 
langues. Apple l’a fait, Microsoft non, mais Keyman peut le faire partout et il est 
devenu gratuit. Je pense que chez Microsoft ils ont dû se dire que ce serait 
dommage de faire double emploi avec un si bon logiciel. Je pense qu’ils ont raison. 

Ça veut dire que le bépo devrait exister aussi en version Keyman. Si en plus, on 
met toutes les listes de lettres des langues africaines et du lituanien dans les 
touches mortes (ce qui sous Linux et macOS est possible nativement), alors, mais 
alors seulement, le projet bépo peut se payer le luxe de reléguer les diacritiques 
combinants sur le point. Or l’Afnor exige que la version Windows tienne dans un 
driver de disposition Windows, donc on n’a pas le choix, ou si ?

Attention encore une fois, là où l’on a piqué ce truc, dans l’ISO/IEC 9995-11, il 
y a un algorithme qui permet de taper tous les diacritiques combinants AVANT la 
lettre de base par les touches “mortes”, et d’avoir le résultat automatiquement 
sous forme NFC, donc avec caractères précomposés autant qu’ils existent, et le reste 
par diacritiques combinants. Or cet algorithme, le bépo ne l’intègre pas ! 
Ceux qui savent le faire peuvent l’ajouter, il est sur Wikipédia. Keyman en tout cas 
ne l’implémente pas. Si je peux donner un conseil : éviter les diacritiques combinants 
comme caractères morts si l’algorithme n’est pas toujours disponible. Choisir plutôt 
des lettres diacritées comme caractères morts, les décomposer et enlever la lettre 
de base, puis procéder comme spécifié. 

> 
> Puisque le bépo a préféré la logique de la touche morte et des 
> caractères unifiés, il semble préférable de laisser les caractères 
> combinants aux experts

Malheureusement, des gens comme toi et moi sont obligés de les utiliser au jour le 
jour, en fonction de la langue qu’on écrit. Ça ne changera plus. On a déjà du mal 
à faire accepter qu’on utilise les lettres en exposant, qui existent pourtant.

> et d’éviter changer le comportement de la barre 
> espace pour produire des caractères selon une méthodologie contraire à 
> tout ce qui a été fait à présent sur le bépo.

Le bépo aurait pu changer la barre d’espace pour les diacritiques combinants dès le 
début. Unicode existait depuis plus de 15 ans en 2008. Mais sans doute on se disait 
que ce serait contraire à tout ce qui avait été fait à l’époque sur l’azerty…

> 
> Puisque les combinants sont quand même utiles par défaut de choix (à 
> cause des déficiences de l’Unicode),

Le terme de déficiences appliqué à la réalité d’Unicode résulte d’une logique en 
trompe-l’œil, tournée vers le passé. Ces caractères précomposés qui sont dans 
Unicode sont juste un geste fait par égard pour les vieux encodages, et pour 
les vieux logiciels et les vieux ordinateurs.

> permettons-les, mais ne les 
> promouvons pas.

Ce n’est pas une promotion que de mettre les diacritiques combinants sur espace, 
puisque les caractères précomposés continuent d’être mieux accessibles :
touche morte, lettre de base — au lieu de :
lettre de base, touche morte, espace.

Mettre les combinants ailleurs que sur espace serait vraiment la double peine.
De l’autre côté, on n’a pas besoin des caractères espaçants sur espace sauf pour 
des documents pédagogiques, pour lesquels les espaces insécables offrent suffisamment 
de places. Je comprends que l’on puisse avoir acquis l’habitude de taper des ^ ou ` 
de manière compliquée faute de les avoir sur de meilleures positions. On aura gagné 
beaucoup plus pour le bépo le jour où tous les caractères informatiques seront bien 
accessibles. (Ce n’est pas parce qu’on n’en parle plus que c’est réglé…)

> 
> Il est triste de constater qu’en 2016, on ne sait toujours pas gérer 
> l’écriture correctement. Unicode a révolutionné le codage des textes en 
> unifiant l’écriture de langues différentes, mais plus je me renseigne, 
> et plus j’y réfléchis, plus je pense que c’est insuffisant, défaillant, 
> bordélique, mal foutu (même si c’est mille fois mieux qu’avant).

Malheureusement il y a des erreurs dans Unicode. Mais les diacritiques combinants 
n’en sont pas. C’est maintenant aux polices, aux moteurs d’affichage et aux autres 
programmes d’implémenter Unicode. C’est dur, mais cela vaut la peine.

> 
> Le fait que les caractères combinés se comportent différemment des 
> caractères unifiés, c’est quand même un problème.

Dès qu’on a ce problème, la solution est la composition canonique. Il y a des 
routines dans les OS que l’on peut appeler dans les langages. Je ne l’ai pas fait 
mais je sais que ça marche.

> 
> Par exemple, la regex "\w+[éèêë]" ne peut reconnaître par exemple le mot 
> "enchanté" si on l’écrit avec un caractère combiné, c’est un problème. 
> Car, en fait, "enchanté" en interne, c’est "enchante´".

En fait, 'enchanté' c’est 'enchant\x{E9}', et 'enchanté' c’est 'enchante\x{301}'.

Pour reconnaître les deux occurrences codées différemment, deux solutions :
1) Normaliser avant, en appliquant string.normalize ou quelque chose comme ça ;
2) En rajouter dans la regex, comme ça il me semble (mais ça peut ne pas être 
disponible dans toutes les implémentations (dans Notepad++ par exemple il paraît 
que ça ne marche pas)) :
\w+(?|[éèêë]|e\p{M}+)

Il me semble avoir vu aussi une manière de noter la classe de toutes les lettre 'e' 
avec ou sans n’importe quel(s) diacritique(s), mais je ne la retrouve pas sur 
internet. Certains des abonné·e·s à cette liste connaissent sûrement tout ça sur le 
bout des doigts.

> 
> Avec des caractères combinés: len("déjà") = 6.
> Avec des caractères unifiés: len("déjà") = 4.
> Si on mélange les deux, ça peut être len("déjà") = 5.

C’est un point important à retenir. Maintenant qu’on a deux formes, il faut toujours 
vérifier ce qu’on traite, et le cas échéant le normaliser en NFD (comme dans ton 
premier exemple) ou NFC (comme dans le second). Quand on a un mélange des deux, 
le mieux c’est de normaliser la chaîne avant.

> 
> On me dira: «Qui mélange des caractères unifiés et combinants? Ça n’a 
> pas de sens!» Oui, ça n’a pas de sens, mais ça arrive déjà, par exemple 
> dans certains articles (sans doute écrits à plusieurs mains). Je suis 
> déjà tombé plusieurs fois dessus.

C’est peut-être que ces articles manquaient de soin. Avant de publier sur internet, 
il paraît qu’il faut normaliser les textes en NFC, avec les caractères précomposés 
autant que possible, car c’est toujours semble-t-il la recommandation du W3C.

> 
> Ce sont deux logiques contraires susceptibles d’engendrer des 
> incohérences. Bref, évitons de compliquer l’écriture et l’analyse des 
> texte autant que possible.

+1

> 
> Je préfère qu’on privilégie une seule méthode d’écriture (sans proscrire 
> l’autre).

Mais j’ai de la peine à voir le rapport avec ce qu’on met sur espace. Mettre autre 
chose sur "touche morte, espace" que les diacritiques combinants, c’est compliquer 
abusivement l’écriture des langues qui en ont besoin. Comme dit plus haut : les 
caractères précomposés sont privilégiés quoi que l’on mette sur espace. Et 
privilégier "touche morte, espace" comme méthode d’entrée pour les caractères ^ 
et `, c’est compliquer l’écriture des programmes informatiques.

> 
> > À mon avis cela vient du fait de ne pas avoir *besoin* des diacritiques combinants
> > parce que l’on ne pratique pas le lituanien, ni le bambara, ni le ga, ni aucune
> > autre langue d’Afrique, au moins de ne pas les écrire avec les marques tonales,
> > autrement on réclamerait certainement (à cor et à cri) que les diacritiques
> > combinants soient sur touches vives, comme sur le clavier unifié français-bambara.
> > http://www.mali-pense.net/IMG/pdf/le-clavier_francais-bambara.pdf
> 
> Je ne parle pas d’interdire, je parle de laisser les combinants sur le 
> point. On pourra quand même taper ce dont tu parles.

Oui mais de façon encore plus compliquée. Si tu étais Malien ou Ghanéen, il serait 
hors de question pour toi de promouvoir le bépo à cette sauce-là. (On est en 2017.)

> 
> Mieux vaut laisser la touche Espace avoir le comportement attendu par la 
> majorité des utilisateurs. Et cette majorité n’a pas besoin des 
> combinants.

C’est d’un côté mal servir la majorité, qui gagnerait à changer pour un mode de 
saisie plus simple du ^ et de l’`, et de l’autre côté c’est de l’ethnocentrisme.

> Je ne sais pas si vous parlez du bépo à vos connaissances de 
> temps en temps,

Oui, et je l’ai mentionné plusieur fois sur la ML publique d’Unicode.

> mais de mon côté (où il y a pourtant des personnes 
> instruites), le bépo apparaît déjà comme une préoccupation fumeuse.

C’est probablement dû au fait que le bépo en fait trop. Il aurait fallu rester plus 
près de l’azerty, car on n’a pas besoin de l’ensembles des modifications qui ont été 
faites, pour avoir une ergonomie correcte. À un moment donné, ça devient overkill, 
et le nombre de gens qui décrochent ou se ferment risque d’exploser. Mais ce ne 
seront sûrement pas les diacritiques combinants sur espace qui vont peser sur ce 
bilan. Au contraire, une fois qu’ils savent ce que c’est et à quoi ça sert, ils vont 
sûrement trouver ça très intelligent.

> Alors les caractères combinants… c’est probablement de la science-fiction…

Cela démontre surtout qu’il existe un besoin de formation dans ce domaine. 
Eh bien non, c’est la réalité, mais surtout dans d’autres pays de la Francophonie. 
Elle va comment déjà, la trilogie républicaine ? 
Liberté = les accents et autres diacritiques sur toutes les lettres où l’on veut ; 
Égalité = mettre autre chose sur '≠', par exemple le ^ (ou sur la rangée de repos) ; 
Fraternité = ne pas défavoriser la saisie des diacritiques combinants, c’est-à-dire 
les mettre au moins sur 'touche morte, espace'.

Cdlt,
Marcel

> 
> En tapant ce message, je découvre effectivement qu’en voulant obtenir le 
> signe <¨> avec <¨> puis , j’ai obtenu le signe <">…
> J’ai trouvé ça parfaitement absurde (à quoi ça sert?), je ne vois même 
> pas le rapport… Bref, je voterai A4. :)
> 
> 
> Olivier (Flamme)
> 
> 
> Notes:
> 
> [1] J’appelle “caractère unifié” le glyphe qui comporte la lettre et son 
> diacritique dans un seul code. Ici, len("é") = 1.
> 
> J’appelle “caractère combiné” l’union d’un caractère avec un caractère 
> combinant. Par exemple: e + ´ = é (deux, codes, deux caractères 
> affichés en superposition). Ici, len("é") = 2.




--
Pour ne plus recevoir les messages de cette liste de discussion, envoyez un courriel avec pour destinataire discussions-REQUEST@xxxxxxxxxxx et pour sujet "unsubscribe".