Re: [EGD-discu] Deux propositions

[Marcel <bkn.ema@xxxxxxxxx>]

Le 19/11/16 21:32, Thomas Vergnaud a écrit (j’ai remis la citation niveau 3) :
> 
> Le samedi 19 novembre 2016, 21:08:43 CET Marcel a écrit :
> > Pas que cela. Sous Windows on déplace les touches par leur keycode en
> > éditant la source en-tête de la locale, qui permet de dédéfinir et
> > redéfinir les keycodes par scancodes (en gros: #undef [scancode] \r\n
> > #define [scancode][keycode]).
> > 
> > > tandis que la géométrie spécifie où se situe 
> > > physiquement la touche en question (à droite, en haut, etc.).
> > 
> > C’est la carte des scancodes qui définit cela. Ensuite, comme dit, pour les
> > keycodes on a une certaine marge de manœuvre.
> 
> Oui, voilà.
> disposition = keycode
> géométrie = scancode

Pardon. J’ai été inclair. En fait, la distinction entre géométrie et disposition 
est floue, admettant que quand par exemple NémOlivier convertit CapsLock en Shift, 
il a modifié la géométrie du clavier. Ou sinon on prend ‘géométrie’ au sens purement 
physique en distinguant entre ISO et ANSI, compact, matriciel, et des mélanges.

Une disposition de clavier se compose d’un mappage des keycodes et d’un mappage des 
caractères. Chacune des deux cartes peut ne pas fonctionner comme définie. En ce qui 
nous intéresse ici, sur certaines touches, la disposition ne peut pas remapper le 
keycode efficacement. Sur d’autres touches, elle peut le faire efficacement. Par 
exemple un membre de la communauté Colemak a remappé CapsLock en Backspace en 
modifiant le keycode directement dans la source en-tête principale kbd..h. Une 
personne a fait remarquer que l’effacement arrière ne fonctionne alors qu’une fois 
sur deux. Quand je l’ai essayé moi-même, VerrMaj est devenue un RetourArrière 
pleinement fonctionnel, sans aucune anomalie. 

> L'AFNOR va normaliser les keycodes. Pas les scancodes. On peut toujours 
> critiquer cette approche,

Il n’y a rien à critiquer, c’est même très louable de s’en tenir aux ressources 
des systèmes d’exploitation et d’éviter de spécifier des choses inimplémentables 
avec les ressources des systèmes d’exploitation, si le but est d’arriver à une 
norme implémentable sous forme de pilotes de disposition Windows (admettant que 
sous Linux et Mac on peut faire plus).

> mais l'AFNOR est la seule à pouvoir décider de ce 
> qu'elle veut normaliser ou pas. Et nous ne sommes pas l'AFNOR.

Nous avons appris que l’AFNOR mène la plume et apporte son concours, mais que les 
décisinos sont prises par les membres du groupe de travail. Le principal membre 
est un organe gouvernemental. Nous sommes en démocratie. L’AFNOR va mener une 
enquête publique, recueillera tous les retours, et invitera tous les proposants. 
Ce processus tel qu’il a été défini par le gouvernement et l’AFNOR, représente un 
pur exemple de démocratie participative. J’ai commis l’erreur de parler de l’AFNOR, 
j’aurais mieux fait d’écrire « le groupe de travail ». « L’AFNOR » est devenue pour 
moi un synonyme (pars pro toto), mais c’est un abus de langage, et je m’en excuse.

> 
> > Il est urgent à mon avis que l’Afnor revoie ses objectifs à la hausse, et
> > qu’elle adopte une conception plus large de ce qu’est une disposition de
> > clavier. C’est indispensable à mon avis pour répondre à un maximum
> > d’attentes de manière adaptée.
> 
> Marcel, je sais bien que tu es très investi dans ces travaux et que tu 
> aimerais vraiment que tout cela aboutisse à des changements très profonds dans 
> la définition du clavier. Cependant, je ne vois pas pourquoi l'AFNOR se 
> mettrait à changer d'idée tout d'un coup.

Nous ne savons pas quelles idées le groupe de travail est en train d’implémenter. 
Je suis simplement sceptique en voyant comment le jeu de caractères est défini, 
alors que les autres pays prenaient pour référence le jeu de caractères spécifié 
par ISO/IEC 9995-3 et consigné dans ISO/IEC 10646, tout en le complétant au besoin 
en spécifiant un nouveau jeu de caractères, sur-ensemble du précédent.

L’AFNOR elle-même (au sens propre) a pris une posture résolument innovante en 
s’investissant à fond dans le développement d’ISO/IEC 9995. C’est un simple rappel, 
les faits sont connus, on en a discuté longuement il y a dix mois. Ce que moi je ne 
vois pas, c’est pourquoi l’AFNOR n’implémente pas ISO/IEC 9995 en la révisant, comme 
d’autres pays ont implémenté ISO/IEC 9995 en la révisant (ou l’ont révisée après 
l’avoir implémentée). Cette norme spécifie un sélecteur de groupe depuis longtemps, 
et on a vu les différentes manières de l’implémenter.. Autre changement profond 
ajouté l’an dernier avec la partie 11 rédigée par le même chef de projet : Tous les 
caractères de touches mortes doivent être des diacritiques combinants, et un 
algorithme doit les réordonner et déclencher la routine de composition canonique, 
si la disposition de clavier est conforme à ISO/IEC 9995-11.

> Il est donc peut-être plutôt urgent 
> d'admettre que l'AFNOR n'a pas pour mandat de normaliser le clavier dont tu 
> rêves.

Je me suis peut-être mal exprimé sur le mandat de l’AFNOR.. Il me semble d’ailleurs 
ne pas en avoir parlé. L’AFNOR a pour mandat de diriger un groupe de travail et de 
normaliser les claviers qu’il faut à la France. Tout le monde est appelé à rêver et 
à faire des propositions, et l’AFNOR a pour mandat de dépouiller toutes ces 
propositions et de créer un consensus sur une disposition de clavier, qui je 
m’imagine doit répondre aux spécificités de notre langue, à nos attentes et aux 
contraintes des systèmes d’exploitation.

> Cela dit, rien ne nous empêche de réfléchir à des choses qui vont au-delà des 
> demandes de l'AFNOR, et de les diffuser sous forme d'un pilote de clavier, 
> comme c'est le cas pour le moment.

+1

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".