SpringComp a écrit 3 commentaires

  • [^] # Re: Guillemets de second niveau

    Posté par  . En réponse au journal La norme française de dispositions de clavier a été publiée. Évalué à 0.

    Il me semble que ces chevrons simples sont disponibles sur la couche "étendue" via AltGr+h.

  • [^] # Re: Ukelele, pour éditer son mapping de clavier sur macOS

    Posté par  . En réponse à la dépêche La norme française de dispositions de clavier a été publiée. Évalué à 1.

    Pour ma part, je me fais frabriquer une disposition par WASD Keyboards, sur la base d'un gabarit personnalisé. Je suis très fan de la qualité de leur produits !

    Gabarit NF 771-300

  • [^] # Re: Support Software

    Posté par  . En réponse à la dépêche La norme française de dispositions de clavier a été publiée. Évalué à 1.

    Bonjour, je contribue à un projet libre qui vise à produire un pilote Windows pour la disposition du clavier: https://github.com/tbolon/optimized-azerty-win

    J'imagine qu'il existe aussi un autre projet qui doit pouvoir être porté sur d'autres systèmes d'exploitation. La page officielle de la norme liste le pilote suivant:
    https://sourceforge.net/projects/francaisnormaliseazerty/

    J'ai quelques questions techniques qui semblent ne pas avoir été vraiment réfléchies par les concepteurs de la norme, mais je ne veux pas être prétentieux.

    Tout d'abord, en tant qu'informaticien, je note l'absence de l'accent grave (U+0060) au profit de l'accent grave combinant (U+0300). Pourtant, l'accent grave - que j'appelle 'backtick' en anglais - est quand même très utile. Il est d'ailleurs bien présent dans la disposition BÉPO ce qui montre que la communauté d'utilisateurs de cette disposition semble plus intéressée que le public plus large qui aurait intérêt à disposer de la nouvelle norme AZERTY.

    Un autre aspect de la norme qui me gêne est qu'elle est… impossible à mettre en oeuvre dans la plupart des systèmes d'exploitation actuels ! En effet, il est stipulé que les diacritiques soient "combinants" (comme c'est prévu par Unicode) mais qu'ils doivent être tapés avant la touche qui doit être modifiée. C'est-à-dire agir comme des "touches mortes". Or, aujourd'hui, il est très facile d'avoir une touche morte suivie d'un caractère, mais prévoir de chaîner les touches mortes de manière arbitraire rend la conception d'une telle disposition simplement impossible. Il faudrait prévoir un nombre infini de combinaisons de diacritiques !

    Pour ma part, j'ai choisi de rétablir dans ma disposition l'usage des diacritiques sous la forme de touches mortes qui produisent - si aucune correspondance n'est trouvée - un équivalent non combinant. Ainsi, le fonctionnement est le même que les claviers actuels (et on retrouve l'accent grave perdu).

    J'ai également choisi de produire un caractère diacritique combinant en répétant la touche morte. Ce qui permet de taper, par exemple, [AltGr]+[], suivi de U pour produire 'Û', puis de taper deux fois la touche morte [AltGr]+v pour produire, 'Û̧'. Et il est ensuite possible d'enchaîner les diacritiques à volonté.

    Malheureusement, cela empêche de coller à la norme, qui dispose que l'appui répété d'une touche morte diacritique doive sélectionner la version souscrite correspondante. Par exemple, une répétition de la touche 'MACRON' doit sélectionner le 'MACRON SOUSCRIT'.

    Bref, tout ça pour dire que la version AZERTY de la norme - pourtant la plus utile au grand nombre d'utilisateurs francophones - semble encore aujourd'hui hors d'atteinte.