RE: [EGD-discu] Objectifs de la normalisation AFNOR

[Marcel <bkn.ema@xxxxxxxxx>]

Jeudi 4 Août 2016 08:20:58, Thomas Vergnaud a écrit :
> La liste de diffusion est très active ; il est un peu difficile de tout 
> suivre :-)
> 
C’est que le travail est assez volumineux et plutôt compliqué. Échanger sur 
la ML est efficace, mais il y a aussi le canal IRC pour les initiés, qui est
moins visible et incite moins de personnes à réagir. Si par exemple les 
informaticiens qui ont récemment orienté le débat, ne sont pas membres de 
l’IRC, jamais leurs témoignages n’auraient pu être intégrés.

Normalement ce qui est bon ne s’obtient pas sans labeur. Une disposition de clavier
performante et facile à faire, à mon avis ça n’existe pas. Et j’espère qu’on est 
tous d’accord là-dessus.

> Les travaux sur BÉPO2FM sont très intéressants. Cette disposition clavier est 
> très riche. Mais est-il utile de standardiser une disposition aussi complète ? 

Absolument. Moins on y met, plus c’est nul, on le voit à satiété avec les dispos 
Microsoft vs Apple ! Les claviers Windows sont unanimement critiqués pour leur 
nullité, ils ont reçu énormément de plaintes d’utilisateurs. À mesure que les 
exigences montent, le travail s’accroît.

> Par ailleurs, les considérations sur les doubles ou triple frappes de touche 
> morte pour les diacritiques m'inquiètent un peu : il faudra beaucoup de temps 
> (j'imagine un ou deux ans) pour éprouver ces solutions. Il vaut mieux renoncer 
> à ces modifications dans le cadre de la normalisation (mais on peut prévoir des 
> ajouter par la suite).
> 
L’obtention des doubles accents aigu/grave est déjà prévue par double frappe dans
la norme internationale ISO/IEC 9995. Une norme qui toutefois est encore inaboutie 
à tel point que c’en est inquiétant aussi. 

Mais ce qui m’inquiète surtout, c’est que l’AFNOR semble avoir abandonné son idée 
première qui était de partir de cette norme. Je n’aurais jamais cru qu’on allait 
descendre en-dessous des exigences d’une norme internationale que – rappelons-le – 
la France avait mise sur les rails, et à laquelle l’AFNOR a encore ajouté une 
partie l’an dernier.

ISO/IEC 9995 spécifie un jeu de caractères, appelé d’une manière pouvant induire 
en erreur, « JEU PARTIEL MULTILINGUE LATIN ». Pour commencer, il aurait suffi de
simplement le compléter (je dis « pour commencer », car ce serait vraiment bête 
de priver la France d’un clavier latin complet). Or qu’est-ce qu’on voit ? On 
remet tout à plat et on part de zéro. C’est nul ce que nul veut dire.

> Pour le dire autrement, quel est l'objectif de la standardisation ? À mon 
> avis, avoir une disposition standardisée a deux avantages :
> 1- inciter des fabricants de clavier à vendre des marquages BÉPO ;
> 2- inciter les éditeurs de systèmes d'exploitation propriétaires à inclure un 
> pilote pour la disposition BÉPO.
> 
> Pour le point 1, il faut considérer la « carte de base ». Tout le monde semble 
> d'accord pour dire qu'il serait souhaitable de limiter les changements par 
> rapport au BÉPO actuel, pour éviter de se retrouver avec deux marquages de 
> clavier différents appelés tous les deux BÉPO. En fait, j'ai l'impression que 
> les discussions se focalisent de plus en plus essentiellement sur la fameuse 
> touche 105.
> 
Sur la touche 105 et sur les touches mortes, car ces deux-là cachent un potentiel 
qu’il serait très dommage de négliger. Et en optimisant la touche 105 et les 
touches mortes, on ne touche pas, justement, à la carte de base.

Après, je verrais bien aussi les (){}[] sur la ligne de repos, et Compose sur 
AltGr + espace. Mais ce n’est peut-être pas le moment, je ne sais pas.

> Concernant le point 2, il me semble que pour convaincre Microsoft de prendre 
> en charge le BÉPO dans Windows, il vaut mieux ne pas définir quelque chose de 
> trop compliqué, pour éviter de les rebuter. Même chose pour Mac OS. Cela 
> implique de ne pas proposer trop d'innovations, afin d'assurer une 
> implémentation facile.
> 
Ce n’est pas comme si on n’était pas en train de leur prémâcher le travail. 
Ils n’ont strictement rien à faire que de vérifier les sources, y mettre leur 
griffe, et recompiler le tout. De toute façon les développeurs de chez Microsoft 
sont censés utiliser le même outil qu’ils utilisaient depuis la nuit de Windows, 
sauf qu’il a été mis à jour pour le support d’Unicode, et pour sa version 3.40 —
le fameux « Keyboard Table Generation Tool (Unicode) », alias « KbdUTool ».
On a tous KbdUTool, c’est gratuit et c’est dans le MSKLC.

Ça fait des décennies qu’on s’embête avec un clavier inepte côté Windows, et 
on est loin d’être le seul pays à se plaindre. Mais c’est que les gens dans ces 
différents pays sont censés faire eux-mêmes leur part du boulot. Maintenant qu’on 
s’y met, qu’est-ce qui pourrait pousser Microsoft et Apple à mettre des bâtons 
dans les roues ? Ce qu’il ne faut pas faire, c’est de leur balancer des specs et 
d’attendre qu’ils fassent les implémententations à notre place. Là je suis tout à
fait d’accord.

> Le cas de Linux (et des systèmes libres) est différent, puisque nous écrirons 
> nous-même les fichiers de configuration BÉPO : nous serons libres de mettre tout 
> ce que nous voulons (comme actuellement). Pour ces systèmes, la normalisation 
> AFNOR ne changera rien.
> 
Si, elle y change. Au moins côté hardware. Et puis, les développeurs d’XKB ont 
été très soucieux d’implémenter ISO/IEC 9995 à la lettre. Au moins d’après ce 
que j’en ai vu jusqu’à présent. Je ne crois pas que dans le libre, on se fiche 
des normes. Bien au contraire. C’est Microsoft qui avait boycotté le GT de 
l’ISO/IEC 9995, en refusant l’invitation à participer. Mais c’était sous une 
autre gouvernance.

> Puisque finalement, l'initiative de standardisation a pour principal objectif 
> de faciliter l'adoption du BÉPO par des entreprises tierces, nous pourrions 
> peut-être nous simplifier la tâche en procédant ainsi :
> 1- établir la liste des caractères exigés par l'AFNOR (j'ai cru comprendre que 
> cette liste n'était pas très claire) ;

Encore une fois, je voyais l’AFNOR prendre le MLS et le compléter. À l’heure 
actuelle, c’est nous qui devons établir une liste AFNOR, alors qu’à terme, 
« La liste complète des caractères diacrités apparaît dans la norme, avec le 
point de codage. » Mais seules des lignes directrices ont été publiées jusqu’à 
présent. 
« Les signe non retenus • ne sont pas prohibés ; • ne sont pas exigibles pour 
établir la conformité d’un clavier ou d’un pilote à une norme. »

Selon mon interprétation il est permis à tout le monde de créer et de distribuer 
des dispositions de clavier performantes, mais le minimalisme reste une option.
Pour maintenir le clivage entre les éditeurs ?

Ce serait dommage de faire des dispos complètes si c’est pour les faire 
mutiler/massacrer par les éditeurs d’OS derrière. Mais encore une fois, les dispos 
de clavier ce sont les pays qui doivent les faire eux-mêmes.

Au bépo de faire sa part du boulot et de se positionner.

> 2- voir s'ils sont tous pris en charge par la disposition BÉPO actuelle (je 
> crois que ce n'est pas le cas), et se concentrer sur la bonne façon d'ajouter 
> les quelques caractères manquants ;
> 3- prévoir des emplacements « vides » sur certaines touches qui permettront 
> d'ajouter les fonctionnalités du BÉPO2FM tranquillement.
> 
> De cette façon, nous pourrions proposer en septembre une disposition conforme 
> aux exigences minimales de l'AFNOR et permettant de futurs enrichissements.

Prenons déjà le BÉPO2FM ! Le BÉPO actuel on l’oublie, il n’est pas conforme.
Mais il ne manque pas beaucoup. Même le signe moins n’est pas exigé, c’est 
carrément ridicule. Je vois ça comme un coup de quelqu’un à la DGLFLF. (Voyez 
sur Twitter et vous comprendrez…)

Désolé d’être dur. Ce n’est pas comme si on était en train de bosser pour se
faire plaisir à nous…

Marcel

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