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

[Marcel <bkn.ema@xxxxxxxxx>]

Dimanche 22 Janvier 2017 12:52:31, Flamme a écrit :
> 
> Le 22/01/2017 à 01:03, Marcel a écrit :
> 
> >> 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é. […]
> 
> La liberté n’interdit pas de hiérarchiser les besoins.
> Le point n’est pourtant pas une touche défavorable. Surtout si on ajoute 
> aussi la virgule comme il a été proposé plut tôt.

Cela implique que l’on aurait *besoin* du ^ et du guillemet inverse informatique 
par 'touche morte, espace'. Favoriser cet accès à ces deux caractères importants 
au lieu de leur donner de bonnes places sur des touches vives, c’est se tirer une
balle dans les pieds, et en tirer dans les pieds des autres utilisateurs du bépo.
Une fois que *tous* les caractères informatiques seront bien accessibles sur 
touches vives comme sur toute disposition généraliste qui se respecte et respecte 
ses utilisateurs, le plus important *qui reste* sont les diacritiques combinants, 
car les caractères précomposés sont déjà super bien accessibles.

> 
> > 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 !
> 
> Je n’ai pas la connaissance technique pour avoir un avis sur la 
> question. Mais effectivement, ce serait bien si le pilote pouvait 
> substituer automatiquement des caractères combinés par des précomposés.
> Ce qui importe ici, ce n’est pas le mode de saisie mais le résultat obtenu.

Du fait que les caractères précomposés sont déjà super bien accessibles, les 
utilisateurs garderont le réflexe de taper autant de caractères précomposés que 
possible, et de ne recourir aux diacritiques combinants que quand ils n’ont pas 
le choix. Donc le résultat sera a priori optimal, sans compliquer plus que de raison 
l’accès aux diacritiques combinants, déjà assez compliqué du fait de faire appel aux 
touches mortes.

Le mode de saisie, à mon avis il ne faut jamais le perdre de vue, surtout pas en 
développant une disposition ergonomique. Dans ce sens, la stratégie des deux trois 
caractères informatiques par {espace} et des combinants par {point} est totalement
ratée, car d’une elle complique la programmation, et de deux elle complique 
l’écriture de nombreuses langues africaines, pourtant supportées au niveau des 
lettres de base.

> 
> > 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.
> 
> Ce que je juge être une erreur, c’est la possibilité de deux logiques 
> contraires. S’il n’y avait que des combinants, ce serait cohérent et les 
> outils auraient suivi cette logique. Mais ce n’est pas le cas. Les 
> outils existants ne sont pas encore vraiment adaptés aux combinants.

Cohérent mais tyrannique, et un grand obstacle à l’adoption d’Unicode. À un moment 
donné il y avait à la fois Unicode *et* ISO/IEC 10646, un standard et une norme 
incompatibles entre eux. Pour les harmoniser et ouvrir la voie à la synchronisation, 
il a fallu d’ardues négociations, suivies par d’importantes modifications dans 
Unicode. Il était difficile à la fois pour l’ISO/IEC, et pour Unicode, de larguer 
complètement les jeux de caractères historiques. Certes, si tous les pays du monde 
concernés par les caractères latins composés avaient fait autant de lobbying que 
le Vietnam, on pourrait peut-être aujourd’hui tout écrire en précomposés, si 
vraiment il y avait assez de place, ce qui voudrait dire que l’argument du manque 
de place était bidon, mais je pense que dans ce cas, davantage d’écritures auraient 
fini reléguées dans les SMP, et ça n’aurait fait que déplacer le problème en partie.
En tout cas, dix ans plus tard, c’était trop tard.

> 
> La normalisation n’est qu’une rustine.

Pourquoi ?

> 
> Mon exemple sur les regex n’était qu’un exemple, pas une demande de 
> solution. C’était pour souligner que ça allait compliquer l’écriture des 
> regex, ou bien qu’il faudrait toujours faire du remplacement par des 
> précomposés si on voulait avoir la paix.

Deux fois oui.

> 
> On s’inquiétait, à tort, de la réception de l’apostrophe typographique.
> Si pour manipuler du texte, on est obligé, pour des questions pratiques, 
> de le normaliser et de remplacer les caractères combinés par des 
> précomposés, c’est qu’il y a intrinsèquement un problèmes avec les 
> combinés. Parce que tout le monde comprend aisément que len("déjà") = 6 
> ou 5 ou 4 est par essence problématique.

Tout à fait, mais si la tâche consiste à travailler sur du français ou d’autres 
langues européennes hors lituanien avec marques tonales, le problème est à la source 
car ces langues ne sont pas censées être saisies avec des diacritiques combinants, 
donc s’il s’y en trouve, c’est que le texte a déjà été normalisé dans un sens 
(vers NFD). Quand il y a mélange, soit il a été saisi improprement (comme dans 
ton exemple), soit il s’agit des marques tonales, qui en vietnamien sur clavier 
Windows s’ajoutent systématiquement par diacritiques combinants, malgré l’existence 
du jeu complet des caractères précomposés nécessaires. Pour le bambara, les auteurs 
du clavier unifié français-bambara proposent de faire de même en ajoutant les 
marques tonales par diacritiques combinants même quand il y a des caractères 
précomposés sur le clavier ou dans la touche morte circonflexe, pour la cohérence 
de l’affichage (qui n’était pas encore bien au point). Or dans le cas du bambara 
c’est facile d’assurer la cohérence du texte par la normalisation NFD, car *tous* 
les accents sont des marques tonales (depuis la réforme de l’orthographe qui a 
remplacé notamment 'è' par 'ɛ'), et en vietnamien c’est facile d’avoir un texte 
cohérent par la normalisation NFC, tandis qu’en lituanien, ni l’une ni l’autre 
ne permettent de séparer les lettres (diacritées ou non) et les marques tonales.

> 
> Notre différend est finalement simple: tu dis que ça n’a pas 
> d’importance qu’il suffit de normaliser les textes, et je pense que s’il 
> faut normaliser les textes, c’est qu’il y a un problème avec la saisie 
> et la cohérence des résultats, et qu’il vaut mieux éviter de favoriser 
> ces incohérences, combien même il existe (parfois) des outils pour 
> normaliser.

Oui c’est ça, des textes en désordre ont a priori été mal saisis. Mais ce n’est pas 
la possibilité de saisir les combinants par 'morte, espace' qui va en rajouter.

> 
> Notons par ailleurs que la normalisation ne résout pas tous les 
> problèmes. La position d’un motif détecté par une expression régulière 
> dans un texte normalisé ne correspond pas à la position de ce même motif 
> dans le texte original. Autrement dit, même si on peut traiter le texte 
> pour analyse, les résultats renvoyés ne correspondent pas au texte à 
> traiter en ce qui concerne les positions.

C’est sûr, mais est-ce vraiment important ? Je n’ai pas de cas pratique en tête, 
j’imagine qu’il faut corriger le texte d’origine sans y toucher par ailleurs, alors 
oui ça va être dur. Mais ça me semble un cas limite.

> 
> > 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.
> 
> Argument curieux… puisque c’est ce que je pense qu’on fait en voulant 
> mettre les combinants sur Espace.

C’est vrai, je ne l’avais pas remarqué. Donc en fait le bépo tente de se racheter 
de son esprit de rupture avec l’azerty en gardant des caractères informatiques 
par 'touche morte, espace' (et les chiffres en Maj) ? Je pense surtout à beaucoup 
de symboles qu’on aurait pu laisser, mais ça ne serait plus le bépo, ce serait 
l’asertuniop’ ou quelque chose comme ça. Pour être vraiment le bépo, le bépo devrait 
maintenant ergonomiser TOUS les caractères informatiques qui ne le sont pas encore. 
Mais pas en les proposant par 'touche morte, espace'…

> 
> > 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'.
> 
> Mettre les combinants sur le point ne semble pas une défaveur.
> C’est accessible. Bien sûr, pas autant que la barre Espace, mais pas non 
> plus une relégation dans un coin obscur du clavier.

Ce qui est actuellement relégué dans des « coins obscurs », ce sont les caractères 
informatiques proposés par 'touche morte, espace', le ^ et le `. Une fois qu’ils 
seront sur des positions adaptées à leur usage, la position en accès direct sur 
la barre d’espace sera libre pour éviter de reléguer les combinants de la barre 
d’espace vers les touches point et virgule. À mon avis il ne faudrait pas opposer 
"bof" et "archi-nul", car il suffit que ce soit "bof" pour que ça ne convienne pas 
au bépo.

> 
> La ML bépo est une liste étrange. On peut s’y voir expliquer qu’inverser 
> les deux apostrophes c’est trop compliqué pour madame Michu…
> mais qu’il est indispensable d’avoir des combinants sur Espace pour 
> taper le lituanien, le bambara, etc.

C’est une impression globale, mais en y regardant de près, on se rend compte que 
ce ne sont pas les mêmes gens. Donc jusque-là, rien que de très normal pour une ML.

> alors qu’on voudrait juste avoir un Espace avec un comportement 
> normal et mettre les combinants sur une place presque aussi correcte,

Bien sûr que ce comportement est encore “normal”. Quitte à cultiver cette 
normalité-là, il serait peut-être temps de songer aussi à ce que le bépo peut 
faire pour tous les utilisateurs qui attendent d’un clavier d’ordinateur pour la 
bureautique qu’il ne soit si possible pas moins normal que l’azerty.

> alors qu’on n’a encore rien fait pour l’arabe et le cyrillique…

Ah mais ce n’est pas faute que je l’aie proposé !
http://bepo.fr/wiki/Utilisateur:Marcel/Version_2.0#Les_modificatrices_ajout..C3.A9es_sur_les_bascules

> 
> :)

:|

Cdlt,
Marcel

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