Re: [EGD-discu] Trait d’union Unicode, espace insécable, niveaux…

[Marcel <bkn.ema@xxxxxxxxx>]

Le 15/07/17 14:15, Laurent a écrit :
> 
> Le 2017-07-13 à 03:13, Marcel a écrit :
> >> Mais si tu fais de la programmation ou de l’administration système et que tu te retrouves avec des espaces insécables qui traînent
> > Une manière de résoudre ce pb sur le bépo est d’enlever l’insécable de Maj, et de mettre les ponctuations en séquence
> > avec l’EFI en Num, sur B00 sur les claviers du pays qui espace les ponctuations, sans objet au Canada qui n’a pas B00
> > et n’espace que le deux-points. Exception : les TypeMatrix.
> 
> Par contre, ce n’est pas complètement logique avec le « mode Num »…

Surtout, ce n’est pas audible ou sinon c’est très mal pris. Cela dit, déjà sur l’azerty les 
autres niveaux du mode Num servent à autre chose, du fait que par défaut c’est un mode 
non verrouillé (dès que tu lâches Num, c’est terminé).

> 
> > Maintenant en suivant ton conseil de prendre au sérieux le U+2010, j’ai les deux en direct sur ce projet :
> > http://dispoclavier.com/doc/kbfredis/index.html#00S2
> 
> Ce n’est pas mon conseil : c’est toi qui nous a fait remarquer ici même 
> que certaines polices représentaient le « tiret générique » ASCII 
> nettement trop long pour un trait d’union.

Oui, mais je croyais que c’était une exagération de la part du dessinateur de 
Lucida Sans Unicode (et de Lucida Sans). Depuis que nous savons que cela 
est devenu la règle dans Noto et que tu l’as pris au sérieux, je fais de même.

> Puisque de toute façon 
> j’avais déjà une variante typographie, je l’ai pris en charge dans cette 
> variante.

Je vais prendre cela en charge par défaut, sauf que sur bépo je ne sais pas 
comment faire quand les chiffres sont en direct, il n’y a pas assez de touches 
pour les tirets (azerty a U+002D sur E11 et U+2010 sur E06, qzjf/asertuniol’ a 
U+002D sur E11 pareillement, et U+2010 sur E08 — sur bépo 1.0 le tiret est 
bien placé pour un placement dans la rangée E).

> 
> Dans la même veine, j’ai aussi ajouté la lettre modificatrice apostrophe 
> U+02BC pour le breton : contrairement à l’apostrophe normale, celle du 
> breton ne sépare pas des mots, elle en fait partie intégrante ; ça a une 
> incidence sur certains traitement informatiques comme par exemple la 
> sélection (le double-clic qui sélectionne un mot), mais aussi sur 
> l’apparence, certaines polices espaçant moins les lettres qui 
> l’entourent qu’avec l’apostrophe normale. Comme il ne s’agit pas d’une 
> représentation différente d’un caractère mais d’un caractère différent, 
> elle a sa place spécifique en AltGr+Maj+B.

Désolé mais cela paraît trop compliqué ; j’ai pu la paramétrer en AltGr+B06 :
http://dispoclavier.com/pourAFNOR.html#00S12
…ou C11 :
http://dispoclavier.com/pourAFNOR.html#00S
http://dispoclavier.com/pourAFNOR.html#00S2

> 
> > Le « soft hyphen » U+00AD ne s’appelle en fait pas « trait
> > d’union conditionnel » (un véritable non-sens), mais « trait de césure conditionnel ».
> 
> Je t’accorde que c’est beaucoup plus clair pour celui-ci. Peut-être 
> m’éloignerais-je même plus de l’original avec « trait de césure 
> potentielle », mais ça pourrait aussi bien désigner le trait d’union 
> normal. Pour être totalement explicite : « trait conditionnel de césure 
> potentielle ».

À césure potentielle, trait conditionnel. J’aimerais bien prendre cela comme une preuve 
supplémentaire qu’on ne peut pas laisser les noms tels quels. Si tu le permets, ce mail 
sera cité dans le commentaire de ce caractère. Par contre je ne suis pas certain que 
l’explicitation telle que tu la proposes aide à faire accepter la révision, car la compacité 
des noms et leur maniabilité est importante aussi…
> 
> > On a aussi la « césure
> > conditionnelle » U+200B (connue comme « espace sans chasse », « zero width space », qu’Andrew West cite
> > parmi les malnommages (dans son premier billet de blog sur les noms de caractères :
> > http://babelstone.blogspot.fr/2006/03/unicode-character-names-part-1-good.html
> > ).
> 
> Pour celui-là, il y a peut-être un peu plus de risque de confusion : des 
> personnes pourraient s’attendre à ce qu’en cas de césure, le trait de 
> césure soit ajouté automatiquement.
> Le problème est que tant que ce terme ne sera pas largement adopté, les 
> gens qui tomberont dessus trouveront difficilement une définition qui 
> l’explicite.

Il y a beaucoup de corrections à faire du fait d’un grand nombre d’erreurs. 
C’est ce qui fait qu’on ne peut plus laisser passer aucune erreur détectée. 
Les personnes qui trébuchent sur l’espace nulle comme étant un contre-sens, 
seront prêtes à chercher la bonne définition de – disons – la « césure franche conditionnelle »?
Une césure sans plus.
> 
> >> Donc il est intéressant d’avoir une variante « moins piégée » pour ce type d’usages.
> > Cela met le bépo devant le dilemme entre la performance et la sûreté.
> 
> Concernant l’espace insécable, c’est quasiment insoluble.

Pas pour la plupart des utilisateurs du bépo. Il suffit d’un tour de main, d’un savoir-faire. 
Ce serait davantage pour les nouveaux arrivants, pour abaisser le seuil d’accès au bépo. 
<troll> Il est où le troll déjà ? </troll>

> 
> Maj+Espace est clairement le seul endroit pratique pour la taper juste 
> avant ou après les ponctuation hautes en Maj.
> 
> On ne peut pas l’associer systématiquement aux ponctuations, parce 
> qu’elles sont aussi utilisées dans les langages informatiques.

C’est la raison pour laquelle elle n’est pas associée aux ponctuations en 
mode Programmeur (bascule des chiffres), et que les ponctuations sont 
accessibles sans espace en mode par défaut, en changeant de modificatrice 
(AltGr au lieu de Maj) ou de touche (C12 sur l’azerty/qzjf proposé), ou en 
accédant aux autres guillemets chevrons par ‹ circonflexe ›{"}.

> Cela dit, si tu prenais en considération la performance et la sûreté, 
> mais pas la compatibilité avec les claviers ergonomiques et pas trop 
> l’ergonomie, il y aurait une solution : déplacer K (touche aussi 
> accessible de l’index gauche que de l’index droit sur un clavier 
> standard) et mettre à la place le « tiret générique » ASCII en direct et 
> l’espace insécable en Maj.

Merci, c’est fait, mais j’ai bien laissé l’EFI sur Maj+[espace], où les personnes 
intéressées peuvent la désactiver dans XKB (Linux) ou avec Clavier+(Windows) 
ou dans le .keylayout (macOS) :
http://dispoclavier.com/pourAFNOR.html#00S12

> 
> Sinon, il faut ajouter un modificateur de plus comme tu le proposes, 
> mais si c’est comme modifier les modificateurs, ça passe déjà mal dans 
> la communauté Bépo, ça ne passera probablement pas mieux à l’AFNOR, ou 
> une variante officielle de la disposition.

L’Afnor et son GT étaient mal avisés de toute manière, c’est pourquoi il y a eu 
tant de retours, pour leur changer les idées.

> Ça passe mal aussi dans la 
> communauté Bépo (ça fait longtemps qu’il y en a qui voudraient une 
> variante programmation officielle).

En fin de compte, une variante Programmeur me paraît contre-productive.. 
Pourquoi ? 
Parce que ça soumet les programmeurs à la tentation de mal orthographier le
français dans les commentaires et — ce qui est pire — dans les bibliothèques 
d’interface utilisateur, voire dans les pages web.

> 
> >> Par ailleurs, si tu t’adresses à des lecteurs qui ont potentiellement un vieux système (Windows XP par exemple),
> >> ils pourraient n’avoir que des pâtés à la place de l’espace fine insécable, du trait d’union Unicode, des inférieur ou égal
> >> et supérieur ou égal inclinés…
> >>
> > Typiquement ce n’est qu’un problème de polices de caractères installées, autrement il ne devrait pas y avoir de problème,
> > au moins l’EFI date de semtembre 1999, et XP de 2001.
> 
> Ce n’est pas parce qu’un caractère existe dans Unicode que les éditeurs 
> se précipitent pour l’ajouter dans leurs polices de caractères…

…s’ils sont fainéants. Ils se tirent des balles dans les pieds, à moins que 
ça leur permette de pourrir XP pour avoir une raison de plus d’arrêter le 
support le moment venu.

> 
> > Mon pilote de clavier actuel doit avoir une table d’allocation à 39 niveaux et il ne
> > fonctionne pas plus mal qu’avec 4 ou 8.
> 
> 39 !!!
> Alors là, sous Linux, je ne sais pas si c’est possible sans recompiler 
> Xkb, mais certainement pas sans au moins redéfinir un certain nombre de 
> trucs toi-même (à moins que certains niveaux puissent être implémentés 
> par un autre mécanisme que les modificateurs, comme les touches mortes, 
> je ne sais pas à quoi exactement correspondent les niveaux de Windows)…

Au départ, ils ne correspondent à rien, il y a juste 8 bits modificateurs. 
Les nommages (KBDKANA, KBDROYA, KBDLOYA pour Oyayubi droit/gauche, 
KBDGRPSELTAP qui doit être un sélecteur de groupe j’imagine) constituent 
une couche supérieure. Après, on en fait ce qu’on veut. J’ai par exemple :
4 pour la carte de base, 4 pour le mode Num, 4+4 pour le mode Programmeur,
4 pour Ctrl+Alt sans et avec mode Programmeur, 4 pour la modificatrice Grec 
(maintenir VerrCap enfoncée), 4 pour la modificatrice Arabe (maintenir VerrPro 
enfoncée), 2 pour Control… Puis différentes combinaisons pour tester, et c’est là 
que ça bugue car plusieurs de ces cartes sont mitées, surtout Grec+Arabe, mais 
aussi Num+Grec — ce qui fait qu’il faut mettre l’hébreu en AltGr+Grec au lieu de 
Num+Grec — et Num+Arabe, ce qui fait la même chose. Peut-être le mitage de 
ces cartes de ces combinaisons de modificatrrices est intentionnel, car il n’y a 
aucune raison pour que ça ne fonctionne pas a priori. Je les laisse pour démontrer 
que Microsoft a pourri le truc à un certain point. 
Mais si Linux n’a que 8 niveaux…

> 
> Cela dit, es-tu sûr qu’un utilisateur (autre que toi) puisse s’y 
> retrouver avec autant de niveaux ?

Tant que ça reste logique, oui.

> Pour ma part, j’essaie de rester assez simple : quatre niveaux, même si 
> ça implique que je n’aurai pas la place à ajouter par exemple le double 
> ou le tripe zéro près des chiffres.

C’est toi qui vois si ça vaut le coup de renoncer aux double et triple zéro.
Et de te priver de bien plus.

> 
> > Merci, je suis content que Linux ait la bascule KanaLock,
> 
> Oui, enfin le nom « KanaLock » est certainement en rapport avec 
> l’implémentation du japonais sous Windows, mais sous Linux, il n’y a pas 
> de rapport. ISO_Level5_(Shift|Latch|Lock) est juste une modificatrice de 
> plus, et à voir la définition pour les dispositions japonaises, elle n’a 
> pas été utilisée pour elles.
> 
> > Et la modificatrice Num, ça marche aussi sous Linux ?
> 
> Là, je ne sais pas, c’est une question de nombre. Hormis Ctrl et Alt, 
> chaque modificatrice double le nombre de niveaux.
> Pour autant que je sache, en standard, il n’est prévu que jusqu’à huit 
> niveaux et pas de modificatrice ISO_Level9. Après, il y a des trucs qui 
> sont eux-mêmes définis dans des fichiers texte (comme les différents 
> types de touches selon le nombre de niveaux qu’elles gèrent), mais je ne 
> saurais pas dire si tu pourrais définir ainsi tous les éléments 
> nécessaires à ajouter les niveaux que tu souhaites ou s’il y aura un 
> élément qui nécessitera de modifier le code de Xkb.

Il faudrait juste 8 bits au total, comme ceci :
0x01 == 0000 0001 Maj
0x02 == 0000 0010 Ctrl
0x04 == 0000 0100 Alt
0x08 == 0000 1000 VerrPro (E00)
0x10 == 0001 0000 AltGr
0x20 == 0010 0000 Num (B00)
0x40 == 0100 0000 en plus sur VerrCap
0x80 == 1000 0000 en plus sur VerrPro


Marcel

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