Je vais brièvement détailler les points qu'il faut que je note pour la révision d'ISO/IEC 9995 :
Tout d'abord il faut expliquer pourquoi il faut que cette norme soit remise à plat. Cela est important pour convaincre parce qu'il s'agit tout de même d'une œuvre très récente (partie 3 révisée ; 2010 ; partie 11 : 2015).
Il faudra souligner la différence épistémologique de fait entre le traitement de la partie matérielle et le traitement de la partie logicielle, et prouver que cette différence n'a pas lieu d'être. Pour le matériel, la norme décrit simplement le clavier standard, le découpe, en nomme et numérote les parties et les éléments. Pour le logiciel par contre (ce qui correspond au driver, à la DLL), la norme invente des choses qui non seulement n'existent pas, mais qui se sont même avérées impossibles à implémenter, au moins dans l'OS prépondérant.
Le sélecteur de groupe sur la touche Alt droite est un pur produit de l'imagination. Je dis un pur produit parce qu'il ne correspond à aucune réalité fût-elle virtuelle. Selon mes informations, une touche modificatrice ne peut en même temps servir à l'entrée de caractères. J'aurais dit qu'en programmant en C, tout est possible. Mais il est par exemple impossible de faire en sorte qu'une touche morte sous Windows produise plus d'une unité de code UTF-16, qu'une touche vive produise plus de 16 de ces unités (4 sur Maj+AltGr), qu'une touche puisse modifier le caractère précédent (sauf dans l'affichage) à moins de l'effacer. Et le fait que le rédacteur de cette norme, qui est informaticien, n'ait pas pu faire de pilote qui fonctionne comme décrit dans la norme, en dit long sur la pertinence de ladite norme.
Il faut donc jeter ce fatras aux oubliettes, ce qui est a priori chose facile à l'ISO qui ne garde jamais en ligne les versions antérieures. Tout le problème, c'est d'arriver à amener une prise de conscience de la nullité de la norme actuelle. Pour ce faire il faut argumenter, bien sûr.
Il faut à mon avis travailler sur plusieurs axes. D'une part il faut démonter ce "groupe secondaire commun" pour le démasquer comme un amas désordonné et peu pertinent. À commencer par les digrammes soudés, que les Français auront avantage à trouver sur une touche, comme c'est fait sur la disposition Latin-9 style Xorg (j'y reviendrai si j'ai le temps avant la veillée de Noël), tandis que les autres nations l'auront mieux en Compose (à voir dans la partie Mécanismes de sélection de groupe). Puis les chiffres en exposant, qui à la fois ne sont pas au complet dans la norme ISO, et s'obtiennent bien mieux par Circonflexe. Et ils n'ont pas mis les indices ! Les fractions ensuite, pareillement incomplètes et mieux générées en Compose. Idem pour les flèches, incomplètes et mieux générées sur le pavé numérique ou en Compose, ou en touche morte plus le chiffres selon la gravure du pavé numérique. Le thorn ensuite, qui ne sert couramment qu'à tirer la langue, et qu'il vaut mieux reléguer en Compose. Les doubles croches, spécimen d'une collection plus importante dans Unicode, pareillement mieux en Compose. Sur le Neo2 c'est le symbole choisi pour la touche Compose. En continuant ainsi, on arrive à réduire considérablement le groupe 2 pour lequel ils se sont tant embêtés.
Un autre axe d'argumentation, c'est les mécanismes de sélection de groupe. De ce qui précède on déduit déjà qu'on n'a plus besoin d'un deuxième groupe et que quatre niveaux sont suffisants. Puis il faut redéfinir la notion de groupe, en la transférant aux touches mortes. Chaque touche morte agit comme un sélecteur de groupe rémanent. Quand on a une touche morte Accent grave et une touche morte Accent aigu en plus du Circonflexe, on peut décider qu'après un appui sur Accent grave, les lettres précomposées du français se transforment en lettres précomposées de l'allemand. Pareil pour l'espagnol et le portugais après un appui sur Accent aigu. En clair, au lieu d'à on peut par exemple avoir ä, è donne ö, é donne ü, ç donne ß. Ou à donne ã, è donne õ, é donne peut-être ñ. On arrive ainsi à résoudre le problème des personnes souhaitant avoir ces lettres en AltGr parce qu'elles pratiquent ces langues et ne souhaitent pourtant pas changer pour une disposition de la langue conernée, qui la plupart du temps n'existe pas pour le clavier français. Le fait de changer entre les dispositions n'est à mon avis adapté que pour les langues non-latines.
Les touches mortes nécessitent d'être redéfinies sur plusieurs points. Tout d'abord le caractère de touche morte. Prendre le diacritique espaçant est une vieillerie non viable. D'abord on se retrouve avec des difficultés dès qu'il n'y a pas au moins un clone espaçant, par exemple pour les hameçons et autres crosses. Puis il est peu convivial de se retrouver avec des petites bidules collées en haut ou en bas d'une espace quand on ne saisit pas un caractère supporté. (Cela vaut pour Windows.) Enfin on perd (sous Windows) un bon moyen d'abréger la saisie, car l'accent circonflexe n'existant pas avec l, m, r, t, on peut économiser le e si le caractère de touche morte est ê. Pour chaque touche morte il faut choisir le caractère diacrité le plus fréquent ou le plus ancien dans Unicode (pour plus de chances qu'il soit inclus dans la fonte), ou celui où le diacritique apparaît le plus clairement. Une vedette quoi.
Autre caractéristique à redéfinir pour les touches mortes, la façon d'obtenir le diacritique combinant. Cette innovation d'Unicode n'est pas bien supportée par un traitement traditionnel des touches mortes. Là il faudrait vraiment avoir la norme sous les yeux. Selon
http://uscustom.sourceforge.net/ l'espace donne le diacritique combinant, tandis que l'espace insécable (Maj+Espace) donne le diacritique espaçant (dit aussi de manière moins sympathique, "pleine chasse"). Il paraît que pour l'ISO, ce soit la double frappe qui donne le diacritique espaçant. Cela sert à rien d'autre qu'à maintenir la tradition, mais impacte au passage les gens qui se servent des diacritiques combinants.. Il est évidemment plus lent de faire des doubles frappes inutiles que d'avoir le pouce qui appuie sur la barre d'espace vite fait. Puis ils ont probablement oublié que certains diacritiques ont DEUX formes espaçantes (petit tilde, et lettre modificative accent circonflexe par exemple). L'"autre" forme s'obtient donc par l'"autre" espace insécable, la fine.
On a donc autant de sélecteurs de groupe que de touches mortes. Il faut démonter l'idée d'un clavier "prévisible" comme le met en avant la partie 11 de la norme. J'avais déjà écrit à l'époque (en début d'année il me semble) que cette idée est une bride inutile et contre-productive. Il suffit que la touche morte produise les lettres diacritées (encore que le Circonflexe doit être optimisé à ce niveau, en fonction de la fréquence d'utilisation, pour le confort des utilisateurs).. Les utilisateurs qui ne demandent pas plus, n'ont pas à se préoccuper du reste. Pour les autres, chaque touche morte doit produire quelque chose d'utile avec chaque caractère de base. On peut ainsi générer beaucoup de caractères utiles pour certaines langues, ou des symboles, à commencer par les ponctuations ascii qui sont possiblement en Maj+AltGr (j'y reviendrai).
Puis il faut ajouter dans la norme, une façon d'avoir les chiffres en Base (accès direct) sur les claviers qui contiennent de nombreuses lettres précomposées, comme le français. C'est la bascule Kana sous Windows, à implanter sur la touche E00 (celle au-dessus de Tab). Quand Kana est verrouillé, les chiffres sont en Base, sinon en AltGr (qui est donc Kana), permettant sur les claviers AZERTY d'avoir les majuscules diacritées en Majuscule. Les ponctuations quant à elles sont en Majuscule quand les chiffres sont en Base, et le surplus prend place sur les touches mortes (dont on n'a pas besoin alors). Les chiffres et les touches mortes sont sensibles à la bascule Verrouillage Kana, les autres non. Cette solution permet aussi à toutes les langues non-latines comme le grec, le cyrillique, l'indien devanagari, hindou, tirhuta, d'avoir un clavier latin à portée sans basculer entre les dispositions. Cela est bien plus confortable pour les utilisateurs.
Enfin on doit à mon avis absolument inclure dans la norme ISO le pavé numérique sur le bloc alphanumérique selon Neo2, mais à activer par un appui sur Verrouillage Majuscule. Cela évite une modificatrice supplémentaire dédiée, et nécessite simplement de donner un petit coup sur cette bascule une fois les chifres, lettres hex, opérateurs et ainsi de suite terminés. Cela est très confortable pour remplir les champs de base de données mixtes où on a tantôt des lettres, tantôt des chiffres à entrer. Windows permet en effet qu'une bascule agisse aussi comme modificatrice. Cela est possible, contrairement au panachage touche morte - modificatrice préconisé dans la norme ISO.
Si vous trouvez des choses à ajouter, comme la symétrie d'AltGr/Kana (ou "Pro", pour un nom français), il faut les inclure pareillement dans l'argumentaire - projet de révision.
Je dois m'arrêter là.
Joyeux Noël, à bientôt.
Marcel