Re: [EGD-discu] Réunion AFNOR

Plus qu'une dispo A et une non-A je pense que c'est la question du 104-105 qu'il faut poser. La méthode A n'est qu'un des usages possibles de cette 105ème touche.
Et par là celle de l'usagr de claviers ergo, qui sont en 104 pour un certain nombre, et donc non utilisables, en AZERTY comme en BÉPO.
Cette question se pose donc aussi pour l'azerty.
Bon, en BÉPO on a jusqu'alors usé d'une solution qui nous prive d'un grand gain ergonomique, mais avec la disponibilité grandissante des 105 touches, en particulier pour les portables, nous voudrions inverser notre choix passé tout en gardant une roue de secours pour les quelques possesseurs de 104 touches.

Le ven. 28 oct. 2016 01:19, Marcel <bkn.ema@xxxxxxxxx> a écrit :

Oui merci à eux et bon courage pour aujourd’hui.

Si l’on essaie de faire la synthèse, histoire de briefer la réunion à notre niveau,
on a donc d’une part un certain nombre de desiderata concernant les OS :
① Remappage accessible : ≡ logiciel générant la valeur de « Scancode Map » ;
② Choix langue/dispo ≡ généraliser la « Barre de Langues » Windows ;
③ Clavier virtuel ≡ OSK « On Screen Keyboard  » (Windows) ;
④ Harmoniser raccourcis changement dispo

Puis des questions concernant les caractères :
⑤ La lettre apostrophe (où et comment) ;
⑥ Normalisation de deux bépos, un en A et un en non-A ;
⑦ Le thêta latin (quels caractères exactement) ;
⑧ Sélecteurs de groupe (latin étendu, …) conformes ISO/IEC 9995-1 ;
⑨ Remise à plat liste des caractères pris en charge (MLS + extension) ;
⑩ Caractère Unicode U+2212 « − » SIGNE MOINS obligatoire (ou pas) ??
⑪ Cohérence azerty–bépo aussi côté accessibilité des caractères ?

Probablement certains points amèneront à parler des principes comme :
⑫ Rôle de Microsoft : Implémenteur obligé ? Prescripteur ? Anti-ISO/IEC 9995 ?

LISTE NON EXHAUSTIVE ! Merci aux suivants de combler les lacunes.

> Message du 27/10/16 20:44
> De : "Piyou"

> A : discussions@xxxxxxxxxxx
> Copie à :
> Objet : Re: [EGD-discu] Réunion AFNOR
>
>
je complète avec une demande de Jean Z (lors de la discussion sur le verr maj):
>     - rendre accessible le remappage du clavier
>
> la Le 27/10/2016 à 20:32, Piyou a écrit :
>

Bonjour,
>
> Est-ce que la définition de la norme comprend aussi la manière dont la disposition est intégrée au système d'exploitation ?
>     - possibilité de choisir dès l'installation de l'OS
>     - possibilité de choisir lors du démarrage d'une session (pratique quand on est plusieurs à partager un ordi et tt le monde n'est pas bépoète)
>     - accès à la configuration aisée, choix de la langue puis de la disposition
>     - accès à un clavier virtuel, (pratique pour saisir les mots de passe qd on n'a pas le bon clavier)
>     - harmonisation des raccourcis clavier pour passer d'une dispo à l'autre
>
> Merci à ceux qui prennent le temps de participer aux réunions avec l'Afnor
>
> Le 27/10/2016 à 16:47, Marcel a écrit :
>

> Voici pour rappel en vrac et à toutes fins utiles les questions sur
> http://bepo.fr/wiki/Discussion:Version_1.1
> posées à l’intention de l’Afnor :
>
> • Et qu’il faudrait demander à l’AFNOR si l’on change le sort
> actuellement réservé à la lettre-apostrophe (qui se trouve
> aujourd’hui en latin+apostrophe).
>
> • Concernant la variante en A, on est d’accord qu’on part sur un développement
> d’une version séparée, et qu’on demandera le point de vue de l’AFNOR avant de
> trancher si on en fait quelque chose d’officiel ou pas ?
> --Milton (discussion) 29 août 2016 à 12:25 (CEST)
>
> • Premièrement, l'apostrophe-lettre est utilisée en breton (et ça devrait aussi
> être le cas en anglais si l'on en croit [ce lien]). Or le breton est une langue de
> France, et notre travail s'inscrit dans le cadre de la normalisation AFNOR, qui a
> pour but de définir un clavier pour toutes les langues de France. Donc il est
> pertinent d'avoir l'apostrophe-lettre en accès vif.
> Pour des raisons mnémotechniques, il est intéressant de regrouper ce caractère
> avec les autres apostrophes. […]
> --Thomas 30 août 2016 à 10:43 (CEST)
>
> • Ce sont nous les implémenteurs, il n’y aura pas de problèmes sur la présence de la couche latin étendu.--Flavien21 (discussion) 30 août 2016 à 16:51 (CEST)
>
> Je me permet de mettre un bémol sur ce point, l’AFNOR nous a fait comprendre qu’il n’y a que les caractères qu’Elle aura listée qui devront figurer dans les documents de normalisation. Si le drivers que vous préparez est plus complet tant mieux mais les développeurs sur les différents OS se limiterons à ce qu’il y a dans les documents de normalisation, avec une forte probabilité que tout ce qui n’est pas en carte de base (+Shift, Alt-Gr et Shift+Alt-Gr) puisse être déplacé au petit bonheur la chance — tant que c’est accessible d’une manière ou d’une autre. La notion de Couche Latin étendu, Arabe et autres n’apparaitra pas dans la norme et risque de n’exister que dans votre driver. Serait il possible, lors de la prochaine réunion avec l’AFNOR, de soulever ce point afin que cette notion de couche puisse apparaitre dans la norme ? Elivagar (discussion) 10 septembre 2016 à 21:05 (CEST)
>
> Cette liste devrait être soumise à l’enquête publique comme tout le reste. Couper les ailes aux claviers de France en les filtrant par ce jeu partiel insuffisant relèverait de l’inconscience. Après des décennies de laisser-aller et de temps de réflexion — je sais que les gens rigolent ! — les Français ont vraiment droit à quelque chose d’hyper-performant.
> Puis comme déjà dit par d’autres, les implémenteurs c’est nous, ce sont les proposants. Les éditeurs d’OS majeurs n’auront plus qu’à apposer leur griffe (à supposer que Mac OS et Linux soient capables de faire la même chose que Windows !). Marcel (discussion) 10 septembre 2016 à 22:11 (CEST)
>
> Marcel, les accès d’emphase mélodramatiques n’apportent rien au débat, restons sobre et précis.
> L’AFNOR sélectionnera la liste des caractères présents dans la normes en fonction de ce que ses interlocuteurs (entreprises, collectivités, associations) lui demanderont d’y placer et elle demandera de justifier la présence de chacun des nouveaux caractères. Quant à savoir si Ergodis sera l’implémenteur, cela dépend de Microsoft, s’ils peuvent utiliser le driver développé par Ergodis — cela permettrait d’outre passer la norme dans la liste de caractères disponible dans la disposition — ou si ils vont se sentir obligé de faire leur propre version — et là, seul les caractères de la normes seront intégrés (et pas forcement en utilisant les couches supplémentaires proposés ici). Elivagar (discussion) 11 septembre 2016 à 00:31 (CEST)
>
> Il en ressort qu’il est primordial de développer le driver Ergodis pour Windows en utilisant l’outil Microsoft, le « Keyboard Table Generation Tool (Unicode) v3.40 ». Par conséquent, il faut programmer le driver en C [toutefois, au prix de certaines limitations, il est aussi configurable dans un fichier .klc]. Sur dispoclavier.com, tout le monde peut télécharger des exemples/modèles de sources (j’en ai aussi mis sur GitLab mais c’est trop galère pour moi) ainsi qu’un script en batch qui fait tourner KbdUTool. Ce dernier est gratuit. Il est inclus dans le MSKLC. Toutes ces informations sont aussi données par le script (qui s’appelle CreaKbd-fr).
> En démocratie (comme d’ailleurs dans tout autre système politique), il y a naturellement beaucoup d’irrationnel qui entre en ligne de compte. Le prendre en considération, c’est rester réaliste. Objectivement, la démarche DGLFLF-AFNOR est inefficiente, puisqu’ils n’ont pas pris comme point de départ le jeu de caractères spécifié par la norme internationale ISO/IEC 9995. Partir du MLS leur aurait déjà évité de commettre la gaffe la plus symptomatique : l’impasse sur le SIGNE MOINS U+2212. C’est une parfaite illustration de la tournure prise par le processus de normalisation laissé à lui-même. Heureusement, les responsables ont l’intelligence de mener une enquête publique bien avant la publication des normes de dispositions de clavier. Marcel (discussion) 11 septembre 2016 à 05:34 (CEST)
>
> Elivagar, ce n’est pas du tout ce que j’ai compris. Dans la plaquette envoyée par l’AFNOR avec la liste des caractères, il est explicitement précisé que les caractères de la norme pourront être placés en touche morte. Si jamais le BÉPO normalisé tel que défini à l’issue de ces concertations place la lettre apostrophe en {touche morte latin étendu} → {apostrophe}, et si la touche morte latin étendu est attachée à la position AltGr+T, alors un éventuel autre implémenteur n’aura pas le choix. Le seul risque est que les caractères hors-norme passent à la trappe, ainsi bien sûr que les couches ne contenant que des caractères hors-norme (soit, si je ne m’abuse : le cyrillique, le grec étendu et les mathématiques).. ☺|☻ Bien à toi --Milton (discussion) 11 septembre 2016 à 08:28 (CEST)
>
> Ce que je lis du document AFNOR-CN35-GT1_N26_Reunion Couverture des signes.pdf envoyé le 9 Juin par JC Groult sur la mailing list , c’est que les caractères doivent être accessible pour que la disposition proposée corresponde à la norme, à aucun moment il est dit que les touches mortes seront normalisées, nuance. De mon point de vue, outre la carte de base (ce qui sera effectivement gravé sur les touches), tout le reste sera à la discrétion du développeur (touches mortes, couches supplémentaires,…). C’est peut-être réducteur comme interprétation mais cela nous donnera des questions supplémentaires à poser lors de la prochaine réunion avec l’AFNOR pour éclaircir ces zones d’ombres.Elivagar (discussion) 11 septembre 2016 à 16:09 (CEST)
>
> La moitié des caractères de la couche latin étendu faisant partie de la norme (dont la lettre apostrophe), ils seront bien inclus. Pas de soucis à se faire --Flavien21 (discussion) 11 septembre 2016 à 16:19 (CEST)
>
> Le lien a trouvé les exceptions pour l’usage de la lettre apostrophe – contraction de « not », dans les noms propres — il a oublié de parler du cas possessif « ʼs », mais dans tous les autres cas comme dans « They’re » ou « He’s » (qui n’est pas du possessif dans ce cas) c’est bien une apostrophe simple et sépare deux mots. Il se contredit avec ses exemples du français.--Flavien21 (discussion) 30 août 2016 à 14:56 (CEST)
>
> Il y a peut-être des approximations dans son raisonnement, mais ça ne change rien à notre sujet :-) --Thomas (discussion) 30 août 2016 à 15:20 (CEST)
>
> Je rejoins Flavien sur le fait que je doute que la couche latin étendu soit zappée. Elle contiendra plusieurs des caractères imposés par la norme, et ce ne sera pas la seule touche morte non diacritique (il y a déjà le dead_currency et le dead_greek, demain dead_api, dead_cyrl, dead_math). À mon avis, la principale chose qui puisse justifier un passage sur la couche principale, c’est la logique (par exemple, toutes les lettres de l’alphabet latin sont en accès vif, on ne va pas en mettre une en morte) et la visibilité que l’on accorde à un symbole (d’où ma proposition pour le copyleft). Ici, il me paraît en plus plus ergonomique de faire AltGr+T puis apo que AltGr+Maj+Apo, mais je puis me tromper. --Milton (discussion) 30 août 2016 à 18:26 (CEST)
>
> Je propose de laisser le sujet de côté pour le moment. Peut-être que la question pourra être abordée lors de la prochaine réunion avec l'AFNOR, et que nous aurons alors plus d'éléments pour décider: l'AFNOR aura peut-être elle-même une solution, et il sera pertinent de mettre les deux claviers (azerty et bépo) en cohérence. --Thomas (discussion) 30 août 2016 à 21:00 (CEST)

>

>

> Message du 27/10/16 16:18
> > De : "Jean-Christophe Groult"
> > A : "discussions"
> > Copie à :
> > Objet : [EGD-discu] Réunion AFNOR
> >
> >

Bonjour,
> >

> > La réunion afnor aura lieu demain, mais je n’ai toujours pas l’ordre du jour, donc je ne peux pas vous dire de quoi on va parler.
> >
Au mois de juin, il était question d’écrire le premier brouillon de la norme, et pour cela une journée entière était prévue.
> >
Comme cette réunion a été réduite à 3 heures, je suppose que ce n’est plus l’objectif (ou alors pas toute la norme?).
> >
J’enverrais un compte rendu demain.
> >
A+
> >
> >
LeBret
> >

>
>

>
>

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