Ça compte pas Marcel, c’est un de tes commentaires ! 😉
Plus sérieusement le commentaire est pertinent, mais malheureusement mal placé pour être efficace.
Là on a l’impression que la personne nous dit « il y a plein de place : utilisons la. »
Ce n’est pas l’_expression_ d’un besoin.
Ce commentaire aurait été bien plus efficace si il avait été placé sur le tableau des symboles en disant « il manque tel et tel caractères qui me sont utiles »
Sur le processus du GT, cela s’est passé en 2 temps :
1) on a établit la liste des caractères (et à l’époque bépo n’avait pas beaucoup de symboles mathématiques, même pas infini et racine carrée
== > c’est l’_expression_ du besoin
2) ensuite on réfléchit à comment on place ces caractères sur le clavier, mais sans remettre en cause la liste des caractères établie.
== > on apporte une réponse à ce besoin
Dans un processus d’innovation d’entreprise, on bouclerait pour éventuellement améliorer les choses. C’est d’ailleurs ce qui a été fait dans Ergodis. Mais ce n’est pas le principe de fonctionnement de l’AFNOR. Son but est d’expliciter noir sur blanc un consensus entre acteurs du marché.
Une des conditions pour que la norme contiennent à la fois l’Azerty et Bépo est que les dispositions normalisées aient le même ensemble de caractères.
Si les 2 dispositions couvrent des ensembles trop différents, il ne s’agit plus de 2 variantes d’une même norme, mais de 2 normes différentes réunis artificiellement dans le même document et ça, ce n’est pas envisageable.
Quelques concessions ont déjà été obtenu sur ce principe rigide : quelques symboles non supportés par l’Azerty, figurent tout de même dans l’annexe B mais seulement en « recommandé » pas en obligatoire. C’est le cas par exemple du symbole moins − (en AltGr+8).
Cela a été accepté car cela reste limité à quelques cas. On peut difficilement étendre cette concession.
Si ces caractères nous semblent nécessaires dans la norme (je rappelle que rien ne nous l’interdit dans le pilote), il devrait figurer dans la partie 6 et donc être pris aussi en charge par l’Azerty.
Si on souhaite s’engager dans cette voie, il faut venir avec des arguments acceptables par le GT. Ces arguments ne sont pas nécessairement ceux qui nous ont convaincu.
Par exemple, quand le GT s’est penché sur la liste des symboles monétaires à retenir, il y avait une partie importante du groupe qui se contentait de $ € £ et éventuellement ¥.
Pour les convaincre j’ai recherché les documents normatifs sur lesquels m’appuyer. C’est-à-dire Unicode et ISO 9995-9 (qui s’appuie sur Unicode 6 hors monnaies « historique » trop ancienne)
Cela m’a permit de faire 3 propositions :
1) les symboles monétaires de ISO 9995-9
2) même chose plus les symboles ajoutés jusqu’en Unicode 9
3) même chose plus les monnaies historiques et hors du bloc Unicode monétaire.
La 1ème option s’appuyait sur une base normative solide, mais ne retenait pas le rouble et la livre turque qui ont du sens dans un contexte européen.
La 3ème option a été écarté car elle impliquait des caractères nécessitant des police de caractère non systématiquement installée en France.
Par conséquent c’est l’option 2 qui a été retenue.
C’est ce type d’arguments qu’il faut amener devant le GT si on veut les convaincre.