Discussion:Exposant et indice

Vote

Version soumise au vote

La version soumise au vote est la dernière de la soirée du 29 novembre 2016.

Précision sur le contenu

Pour le placement, gardez en mémoire qu’il y aura probablement d’autres touches mortes à placer :

touche morte barre inscrite (en plus de barre oblique), hypothèses de placement : clavier bépoAltGr+clavier bépod ou clavier bépoAltGr+clavier bépoB ;
touche morte symboles scientifiques, hypothèses de placement : clavier bépoAltGr+clavier bépoS ou clavier bépoAltGr+clavier bépoD ;
touche morte API, hypothèse de placement : clavier bépoAltGr+clavier bépoz ;

Méthode

Les votes à choix multiples utilisent la méthode de Condorcet (en cas de paradoxe, on utilisera la méthode Schulze). Les autres sont simplement à la majorité absolu.

Durée

Fin le samedi 3 décembre 2016 à 20h CET. C’est-à-dire au moins 72 h à compter de la diffusion du vote.

Options

Principe, et placement des touches mortes

A : exposant en clavier bépoAltGr+clavier bépoMaj+clavier bépo^, indice en clavier bépoAltGr+clavier bépoMaj+clavier bépov
B : exposant en clavier bépoAltGr+clavier bépos, indice en sup redondé
C : exposant en clavier bépoAltGr+clavier bépos, indice en clavier bépoAltGr+clavier bépoMaj+clavier bépos
D : exposant en clavier bépoAltGr+clavier bépos, indice en clavier bépoAltGr+clavier bépoMaj+clavier bépob
E : exposant en clavier bépoAltGr+clavier bépos, indice en clavier bépoAltGr+clavier bépoMaj+clavier bépon
F : status quo.
G : exposant en clavier bépoAltGr+clavier bépo^, indice en clavier bépoAltGr+clavier bépov + déplacement de ¿ et ¡ en clavier bépoAltGr+clavier bépoMaj+clavier bépo’/^, du caron en clavier bépoAltGr+clavier bépoMaj+clavier bépov et du crochet en clavier bépoAltGr+clavier bépo’
H : exposant en clavier bépoAltGr+clavier bépo^, indice en sup redondé + déplacement de ¿ et ¡ en clavier bépoAltGr+clavier bépoMaj+clavier bépo’/^ et du crochet en clavier bépoAltGr+clavier bépo’, pas de déplacement du caron.

Les propositions G et H ont été ajoutées en cours de route … merci de mettre à jour vos votes.

Ordinaux masculin et féminin

(pour/contre/neutre) déplacer º et ª, de respectivement clavier bépoAltGr+clavier bépoM et clavier bépoAltGr+clavier bépoF, sur clavier bépoexposants clavier bépoAltGr+clavier bépom et clavier bépoexposants clavier bépoAltGr+clavier bépof. Ces caractères ne servent pas en français car « numéro » s’abrège avec un ^o — o en exposant — et non un º.

Vous voulez dire les déplacer sur exposants  macron et exposants  ogonek ? Je plains les gens de X.org quand vous essaierez de faire adopter une telle aberration (même la notation utilisée avec + exposants +AltGr+m est incohérente puisqu’il ne s’agit pas d’un appui simultané). -- Laurent (discussion) 1 décembre 2016 à 08:36 (CET)

Non, c’est bien exposant suivi de AltGr+M et AltGr+F. ;-) -- Milton (discussion) 1 décembre 2016 à 14:26 (CET)

C’est corrigé, mais sachant que les claviers gérant le key rollover (roulements), donc tous les claviers actuels, permettent l’appui simultané (dans le bon ordre) si c’est au même niveau. Pour touche morte  suivie de quelque chose, le modèle {{tm}} contient déjà l’EFI qui va avec. -- Marcel (discussion) 1 décembre 2016 à 16:15 (CET)

Oui, c’est ce que je disais, exposants  macron et exposants  ogonek (roulement possible ou pas exposants  et indices  seraient bien des touches morts, pas des modificatrices (quand on tape Maj m pas simultanément, ça ne produit pas M). Donc c’est toujours incohérent d’un point de vue logique. Si les développeurs de X.org vous rembarrent en disant qu’eux ne mélangent pas les cochons et les serviettes (je sais que ce n’est pas l’expression exacte, mais celle-ci est… plus visuelle), il ne faudra pas vous plaindre. Laurent (discussion) 2 décembre 2016 à 12:22 (CET)

Caractères morts associés

A : remettre cette décision à plus tard, et en profiter pour homogénéiser ce point sur toutes les touches mortes ;
B : « ^ » pour exposant et « _ » pour indice, et changer le caractère mort associé au circonflexe par « ê » ;
C : « ² » pour exposant et « ₂ » pour indice ;
D : « ᵉ » pour exposant (sans doute l’exposant le plus utilisé en français), « ᵢ » pour indice ;
E : cohérence avec la touche (donc « ˢ » en exposant si exposant passe en AltGr+s par exemple).

Votes

Principe, et placement des touches mortes

C > B > A > H > E > D = F = G -- Flavien21 (discussion) 30 novembre 2016 à 18:02 (CET)
B > C > H > G > D = E > A > F -- Flamme (discussion) 30 novembre 2016 à 18:30 (CET)
C = B > D = E > H > G > A > F -- Milton (discussion) 30 novembre 2016 à 19:23 (CET)
B > C > D > E > H > G > A > F -- Crako (discussion) 30 novembre 2016 à 21:39 (CET)
De mon point de vue, l’exposant sert suffisement souvent pour ne pas avoir à privilégier le mnémotechnique sur l’ergonomie. Crako (discussion) 1 décembre 2016 à 23:51 (CET)
A > B = C = D = E = F = G = H -- Airevspin (discussion) 1 décembre 2016 à 00:16 (CET)
G = H > F = A > B = C = D = E -- (l’argument de Marcel comme quoi AltGr+S est plutôt une bonne position, malgré la combinaison à une main, puisque S est une touche de repos, m’a convaincu ; par conséquent, je trouve dommage de la gâcher avec quelque chose qui est certes utile, mais pas si fréquemment que ça ; plus généralement, il me semblerait bien préférable de régler la question de redonder ou pas Ç et de déplacer ou pas les caractères utilisés pour les langages informatiques avant de positionner les touches mortes exposant et indice) -- Laurent (discussion) 1 décembre 2016 à 08:18 (CET)
G = A > F > B = C = D = E = H -- (je vais même plus loin que Laurent : on s'en fout d'être sur la touche de repos, on parle d'exposant et indice, des touches mortes qui ne serviront presque jamais et qu'il faudra retrouver sur le clavier le jour où on en aura besoin, donc il vaut mieux que le placement soit mnémotechnique !) Rideĉjo (discussion) 1 décembre 2016 à 08:58 (CET)
Je ne suis pas certain du fait que cela ne servira « presque jamais ». C’était aussi mon point de vue, et la raison pour laquelle j’étais favorable à la proposition A dans un premier temps. Cependant, l’usage d’abréviations est général en français aujourd’hui : titres de civilité, ordinaux (même s’il vaut mieux les écrire en toutes lettres) et un certain nombre d’abréviations. C’est pour cela que je pense qu’a minima une place agréable pour les exposants serait souhaitable. L’indice, en revanche, pourrait se contenter d’une place bien moindre, je te l’accorde, mais c’est là que l’argument de la cohérence intervient. Bien à toi --Milton (discussion) 1 décembre 2016 à 09:47 (CET)
Je ne suis absolument pas d’accord avec Stéphane. Si j’avais cette touche, je m’en servirais plusieurs fois par jour. Ce qui est largement suffisant pour considérer que l’ergonomie (bonne place sur S) doit l’emporter sur l’aspect mnémotechnique (placement sur ^). Crako (discussion) 1 décembre 2016 à 23:51 (CET)
Les exposants sont très utiles, et serviront à moi aussi plusieurs fois par jour. Pourriez-vous envisager de les placer ailleurs que sur AltGr+Maj, n’importe où, mais accessible seulement avec un AltGr. -- Flamme (discussion) 2 décembre 2016 à 01:42 (CET)
Sauf que, si j'ai bien compris, les indices et exposants ont une utilisation particulière, et c'est d'ailleurs pour cela qu'on y trouve pas toutes les lettres. Pour écrire M^me, il ne faut pas utiliser les lettres-exposants, mais la faculté de l'éditeur de mettre le texte en exposant. Ceci dit, il est difficile de dire qu'on l'utilisera (ou ne l'utilisera pas) plusieurs fois par jour tant qu'on ne l'a pas essayé. Ma remarque était donc sans doute un peu trop « agressive ». Rideĉjo (discussion) 2 décembre 2016 à 07:52 (CET)
D’où sortez-vous l’idée qu’il ne faut pas utiliser les lettres exposants? L’Unicode ajoute-t-il des caractères pour nous déconseiller de les utiliser? Du reste, on écrit ailleurs que dans un traitement de texte. Web, courrielleurs, éditeur de texte, markdown, etc. Que vous ne vouliez pas les exposants sur {s}, soit, mais est-il nécessaire de les reléguer sur une place aussi punitive? (AltGr+Maj) -- Flamme (discussion) 2 décembre 2016 à 10:56 (CET)
Tu t'enflamme, Flamme ! ;-) Personne ne dit qu'il ne faut pas utiliser ces lettres, mais qu'elles ont une fonction particulière, qui n'est pas de simplement mettre les lettres en exposant. C'est d'ailleurs le sujet de la discussion en bas de cette page. Rideĉjo (discussion) 2 décembre 2016 à 11:20 (CET)
Mais c’est précisément pour cette fonction particulière qu’on en a besoin. Pas pour ce que vous supposez qu’on en fera. Ajout tardif: je veux dire que l’absence d’uniformité parfois observée n’est pas une gêne puisqu’on ne s’en sert pas pour écrire des phrases entières. -- Flamme (discussion) 2 décembre 2016 à 12:00 (CET)
C > B > E > H > D = A = G > F -- ejpcmac (discussion) 1 décembre 2016 à 09:24 (CET)
F = A > B = C = D = E > G = H -- LeBret (discussion) 1 décembre 2016 à 10:37 (CET)
G > F > A > H > B > C = D = E -- Mimoza (discussion) 1 décembre 2016 à 10:55 (CET)
La proposition G est de mon fait. Elle a pour avantage d'être similaire a ce qui est déjà en place sans perdre vraiment en accessibilité. Par contre elle oblige a déplacer le ¡ et par conséquent le ¿ pour conserver une certaine logique. -- Mimoza (discussion) 1 décembre 2016 à 12:03 (CET)
C'est grosso-modo ce que j'avais proposé moi avec la suite de la valse des touches mortes et où j'avais conclus de moi-même que ces accès étaient très mauvais et que la seule idée à garder était d'avoir indice en double frappe des exposants. C'est que pire à vouloir déplacer le caron en majuscule pour les indices utilisés eux quasi seulement en chimie. On a tout fait pour redonner aux touches mortes un peu plus d'accessibilité, ce n’est clairement pas pour priver le caron de la sienne, déjà qu'il est pénible en clavier bépoAltGr+clavier bépov… Ma proposition en pdd avait un sens y'a trois semaines quand il manquait gravement de place en AltGr simple, mais elle n'a plus vraiment de sens depuis qu'on a la touche morte latin et ponctuation qui a libéré plein d'autres AltGr accessibles. – A2 (discussion) 2 décembre 2016 à 23:19 (CET)
G > F > A > B > C = D = E > H -- logisim (discussion) 1 décembre 2016 à 12:52 (CET)
A > G > H > B = C = D = E > F -- Marcel (discussion) 1 décembre 2016 à 12:56 (CET)
A > B = C = D = E = F = G = H -- Thomas (discussion) 2 décembre 2016 à 22:58 (CET)
B > C > H > D = E = G > A > F -- A2 (discussion) 3 décembre 2016 à 08:49 (CET)
A > G > C > H > B > D = E = F -- Europano (discussion) 3 décembre 2016 à 18:55 (CET)
B > C = D = E > H > G > A = F La touche morte est nécessaire pour saisir les exposants qui ont une valeur sémantique comme le montre Marcel, il y a une chance que ce soit la troisième touche morte la plus utile au français après ^ et ¨ ! Alors il faut une position accessible. J'ai l'impression que beaucoup votent en espérant pouvoir mettre autre chose en AltGr(+Maj)+S, mais on ne sait pas encore quoi y mettre. Il vaut mieux attendre que des propositions soient faites, quitte à ce que de prochains votes proposent de déplacer exposant si on a mieux à mettre dessus. En espérant avoir le droit de voter, c'est la première fois que je prends part aux discussions. --Gazomètre2 (discussion) 3 décembre 2016 à 19:48 (CET)
B > C > D > E > H > G > A = F -- JulieCaroline (discussion) 3 décembre 2016 à 19:50 (CET)
C > B > D = E > H > G > A > F -- nemolivier (discussion) 3 décembre 2016 à 22:29 (CET)

La proposition B l’emporte.

Ordinaux masculin et féminin

neutre -- Flavien21 (discussion) 30 novembre 2016 à 18:02 (CET)
pour -- Flamme (discussion) 30 novembre 2016 à 18:30 (CET)
pour -- Milton (discussion) 30 novembre 2016 à 19:25 (CET)
pour -- Crako (discussion) 30 novembre 2016 à 21:41 (CET)
pour -- Airevspin (discussion) 1 décembre 2016 à 00:18 (CET)
contre -- Laurent (discussion) 1 décembre 2016 à 08:37 (CET)
neutre -- ejpcmac (discussion) 1 décembre 2016 à 09:24 (CET)
contre -- Mimoza (discussion) 1 décembre 2016 à 11:03 (CET)
contre -- Thomas (discussion) 2 décembre 2016 à 22:59 (CET)
pour -- A2 (discussion) 3 décembre 2016 à 08:49 (CET)
neutre -- nemolivier (discussion) 3 décembre 2016 à 22:30 (CET)

Le pour l’emporte.

Caractères morts associés

C > E > D > A > B -- Flavien21 (discussion) 30 novembre 2016 à 18:02 (CET)
D > C > A > E > B -- Flamme (discussion) 30 novembre 2016 à 18:30 (CET)
D = E > C > A > B -- Milton (discussion) 30 novembre 2016 à 19:28 (CET)
C = D > A > E > B -- Crako (discussion) 30 novembre 2016 à 21:47 (CET)
D = C > A > E > B -- ejpcmac (discussion) 1 décembre 2016 à 09:24 (CET)
A > E > B > D > C -- Mimoza (discussion) 1 décembre 2016 à 11:06 (CET)
B > A > C = D = E -- Marcel (discussion) 1 décembre 2016 à 12:58 (CET)
D > C > A > B = E -- Thomas (discussion) 2 décembre 2016 à 23:01 (CET)
D > C > A > B > E -- A2 (discussion) 3 décembre 2016 à 08:51 (CET)
D > C > A > E > B -- Europano (discussion) 3 décembre 2016 à 11:24 (CET)
D > C > B > E > A -- nemolivier (discussion) 3 décembre 2016 à 22:32 (CET)

La proposition D l’emporte.

Barre espace

Hello,

Je suis assez surpris par le choix des caractères sur la barre d’espace. Pourquoi ceux-ci précisément ?

Bien cordialement --Milton (discussion) 20 novembre 2016 à 15:02 (CET)

Le ² et ₂ sont les caractères utilisés pour représenter la touche, je les ai donc mis logiquement en espace, après j’ai mis le ³ en maj car il est souvent utiliser pour m³ mais c’est optionnel Flavien21 (discussion) 20 novembre 2016 à 19:40 (CET)

Ah, je ne me souvenais pas que le caractère ² avait été retenu pour symboliser cette touche morte. Ce n’est pas absurde, mais vue la fréquence du « e » en exposant, on aurait aussi pu penser à celle-ci. Cordialement --Milton (discussion) 20 novembre 2016 à 22:08 (CET)

Rien n’a été retenu, c’est une décision arbitraire de ma part Flavien21 (discussion) 21 novembre 2016 à 09:17 (CET)

Caractères morts

Je ne comprends pas cette section :

en quoi doit-on absolument mettre ^ et _ en caractères morts sur ces touches mortes ?
en quoi cela serait-ce incompatible avec la touche morte circonflexe, tout en étant compatible avec le _ existant ?

Cette proposition de caractères morts ne présente que des inconvénients, et n’a aucun intérêt. Pourquoi l’avoir exposé ? Crako (discussion) 27 novembre 2016 à 12:34 (CET)

Ok, après échange sur IRC j’ai compris qu’il y a une différence de comportement entre X.Org et MacOS/Windows :

sous X.Org : clavier bépo^ clavier bépoq ne produit rien, car il n’y a pas de règle de composition définie. On ne peut pas modifier ce comportement ;
sous MacOS : clavier bépo^ clavier bépoq produit ^q ;
sous Windows : clavier bépo^ clavier bépoq produit ^q. Et il existe une contrainte d’unicité sur le caractère associé à la touche morte, qui fait qu’on ne peut pas avoir le ^ utilisé à la fois pour circonflexe et exposant, c’est à dire qu’on ne peut pas avoir à la fois clavier bépo^ clavier bépoq qui produit ^q ET clavier bépoexposant clavier bépoq qui produit ^q.

Sous Windows je suggère donc d’utiliser respectivement ² et ₂ comme caractères morts.

--

Crako (discussion) 27 novembre 2016 à 13:07 (CET)

Utiliser ²  et ₂  est inefficient, car les caractères insupportés sortent de manière inutile, alors qu’avec ^  et _  on a automatiquement le tout au format TeX.

Dans l’autre sens : ne pas utiliser ê  comme caractère mort pour l’accent circonflexe induit une perte d’ergonomie quand la touche ê sera réaffectée (tirets ou autre), car sous Windows et macOS, des séquences comme ê m sortent automatiquement en 'êm' (comportement émulable sous X.Org, et fonctinnant avec 'd', 'f', 'l', 'm', 'n', 'p', 'r', 't', 'v', sous X.Org aussi en majuscule). Marcel (discussion) 27 novembre 2016 à 13:44 (CET)

Le truc en plus c’est que si ^ est à la fois le caractère pour circonflexe et exposant et en non mort à côté, alors faire ^ ^ , ^ exposant  et ^ ^ donneront tous les 3 la même chose (sur Windows). -- Flavien21 (discussion) 27 novembre 2016 à 14:07 (CET)

Comme Nicolas l’a écrit, il ne faut jamais utiliser le même caractère mort pour deux touches mortes, sinon c’est chaque fois la ligne qui se trouve être la première dans la deadlist qui fonctionne, et l’autre qui est pareille, est en panne. C’est pareil quand on utilise des lettres diacritées comme caractères morts : il faudrait éviter de prendre celles qui sont sur le clavier comme touches vives. Comme dans l’exemple que tu cites, où le circonflexe vif après le circonflexe mort fait le même effet qu’une double frappe du circonflexe mort.

C’est juste que pour la touche morte exposant, on n’a pas vraiment le choix si l’on veut une sortie raisonnable. Perso dans ma version obsolète (que j’utilise toujours, faute d’avoir eu le temps de terminer le redéveloppement des drivers), j’ai encore '↑' et '↓' comme caractères morts d’exposant et indice… Parlant, mais inefficient car obligeant l’utilisateur à tout effacer au lieu de pouvoir le laisser tel quel, du moment qu’il sait que le format TeX est plus utile pour communiquer, même s’il n’utilise pas LaTeX. Marcel (discussion) 27 novembre 2016 à 14:55 (CET)

Utiliser ê dans ce rôle dans le but d’obtenir « êm » en tappant ^ m me parait complètement délirant puisque ces deux touches sont sur la même main, et qu’il me parait beaucoup plus naturel de taper ^ em pour obtenir le même résultat.

--

Crako (discussion) 27 novembre 2016 à 19:11 (CET)

C’est beaucoup dire, mais il est vrai que ê  n’est pas assez performant pour pallier la disparition d’ê pour ses utilisateurs. — On peut bien sûr continuer de taper comme d’habitude avec la touche morte, mais il reste peut-être une séquence intéressante : ê p. Marcel (discussion) 27 novembre 2016 à 19:31 (CET)

Je n’ai pas testé les fréquences respectives, mais pour la touche morte exposant, je me demande si ᵉ ne serait pas plus pertinent, ou éventuellement ˢ si la touche morte était sur AltGr+s. De même pour l’indice, on pourrait par cohérence choisir la lettre associée à la touche choisie. Cordialement --Milton (discussion) 27 novembre 2016 à 15:53 (CET)

Le plus pertinent est de choisir pour chaque touche morte en priorité le caractère qui est le plus pertinent quand il est inséré avant les caractères non supportés, sous Windows et macOS. Dans le cas d’exposant et indice, on sait désormais que le seul choix pertinent est '^' et '_'. Pour l’accent circonflexe, le plus pertinent en français est 'ê'. Pour la plupart des autres touches, on peut choisir le caractère le plus parlant, ou le mieux supporté par les polices. Là c’est le moment d’associer 'ɍ' à rayé et de placer cette touche morte en Maj+AltGr+R , par exemple pour la mnémonique (enfin c’est ce que j’ai). Marcel (discussion) 27 novembre 2016 à 16:06 (CET)

« Dans le cas d’exposant et indice, on sait désormais que le seul choix pertinent est '^' et '_'. » Marcel, répéter encore et toujours le même argument sans aucune justification plausible aura pour seul et unique effet le même que celui qui se produit sur la liste de diffusion. Les gens t’ignoreront purement et simplement, et te laisseront dans tes délires. Il est grand temps que tu poses le crayon, et que tu prennes un peu de recul sur tes propositions.

--

Crako (discussion) 27 novembre 2016 à 19:11 (CET)

Il me semblait que le markup utilisé dans LaTeX et plus largement, était une justification assez plausible. Et plus que ça : c’est la raison même pourquoi je change pour '^' et '_', recommandant dans la foulée au bépo d’en faire de même. — Cela dit, merci du conseil. Reste à pouvoir l’appliquer… Marcel (discussion) 27 novembre 2016 à 19:31 (CET)

Propositions

Je souhaiterais aussi que soient proposées les options suivantes :

Pour le caractère non mort, cohérence avec la touche (donc ˢ en exposant si exposant passe en AltGr+s par exemple).
Pour le caractère non mort, mettre ᵉ (sans doute l’exposant le plus utilisé en français)
Pour º et ª, les mettre plutôt en exposant > AltGr+o et AltGr+a

À moins qu’il n’y ait de raisons de ne pas proposer ces options au vote évidemment. ;-) --Milton (discussion) 30 novembre 2016 à 13:12 (CET)

Oui, les raisons sont ꟹ et ᴭ. -- Flavien21 (discussion) 30 novembre 2016 à 13:27 (CET)

Qu’entends-tu par caractère non mort ? Est-ce le caractère qui est affiché sous Windows quand la séquence n’est pas gérée ? Ou est-ce simplement le symbole utilisé pour représenter la touche morte sur les cartes ?
As-tu des propositions pour les indices ?
pour º et ª ce n’est pas possible comme l’a fait remarquer Flavien21 mais c’est possible sur clavier bépoAltGr+clavier bépom et clavier bépoAltGr+clavier bépof. Cette proposition est déjà tracée mais uniquement en PDD (sur une section commentée car le vote n’est pas ouvert)

Faisabilité

Même remarque que pour le vote sur barré/rayé : s'est-on assuré de la faisabilité de ces modifications sur tous les systèmes ? Il me semble qu'avec X11 nous n'avons pas la main sur les combinaisons associées aux touches mortes, celles-ci sont valables pour toutes les dispositions. Cela veut dire que nous ne pouvons pas « inventer » de nouvelles combinaisons (à moins qu'elles aient vraiment un sens), et que nous ne pouvons pas faire de truc du style clavier bépolettre morte +clavier bépoAltGr+clavier bépolettre. Rideĉjo (discussion) 1 décembre 2016 à 08:50 (CET)

Les touches mortes exposants, indices, rayés et barrés ont un sens, mettre un caractères sur les touche AltGr+lettre est logique, même si elle est différente de celles utiliser par Linux.

De même si l’on va par là il n’est pas possible d’avoir la pression multiples des touches comme on l’entend sur BÉPO 1.1, ça prouve que c’est à Linux de changer sa gestion des touches mortes que, pour ma part, je trouve assez merdique (excusez-moi du terme).

Flavien21 (discussion) 1 décembre 2016 à 09:21 (CET)

En fait, il y a plusieurs moyens de s’en sortir en l’état présent : un Compose perso, ou bien l’usage des autres locales. Un choix de développement fait aujourd’hui par l’équipe de X.org dont j’ignore les tenants et les aboutissants est de mettre un seul Compose global dans la locale en-US, servant à tous les claviers occidentaux. C’est assez incohérent, et rien que le fait de faire un Compose dans les locales fr-FR (et autres) pourrait simplifier le truc. En attendant, bien entendu, que les développeurs de X.org nous proposent une solution alternative pour la gestion des touches mortes — aujourd’hui incohérente avec ce qui se pratique sur les autres systèmes de gestion de fenêtres —, même si cela risque d’être un peu compliqué par l’architecture client-serveur. Mais comme on dit chez les gaullistes, « l’intendance suivra » et je ne doute pas que nous trouverons une solution strictement moins bancale que l’actuelle pour implémenter une norme concernant a minima soixante-dix millions de personnes, et avec un peu de chance beaucoup (beaucoup) plus… Bien à toi --Milton (discussion) 1 décembre 2016 à 09:40 (CET)

Ce ne sont pas des variantes de formes

Les « vrais » exposants, indices et petites majuscules sont des variantes de formes. Or les caractères introduits dans les couches indices et exposants ne sont pas destinés à être des variantes de formes. C’est d’ailleurs pour ça qu’il n’y a pas tout l’alphabet. Par exemple le N minuscule exposant est marqué « superscript » car c’est pour un usage mathématique (10ⁿ). Alors que le R et le M minuscule exposant sont marqués « modifier letter », notamment utilisé avec les caractères de l’IPA.

La conséquence direct pour l’utilisateur est que ces différents caractères peuvent ne pas être rendus dans le même style, ce qui les rend inutilisables pour un travail soigné.

La page qui présente les indices et les exposants s’affichent comme ça chez moi :

On voit clairement que les r, n et m minuscules ne sont pas dans le même style.

Ces couches ne peuvent être utilisées que comme solution de secours. Donc elles sont moins importantes que les symboles scientifiques, par exemple. LeBret (discussion) 1 décembre 2016 à 12:04 (CET)

Les signes exposants pour les nombres ordinaux (1ᵉʳ, 2ᵉ, etc.) pour les notes de bas de page ou de fin de chapitre. Comme tu le soulignes, ça sert en mathématiques. Ce ne sont pas des solutions de secours, ce sont les caractères dédiés à cet usage.

Qu’on ne mette pas les touches exposants et indices sur {s}, pourquoi pas, mais il faut au moins veiller à placer la touche exposant ailleurs qu’en AltGr+Maj+{^}. Elle serait dans ce cas moins accessible que nombre de signes diacritiques inutiles en français. Il faudrait au moins accepter la proposition G. -- Flamme (discussion) 1 décembre 2016 à 13:17 (CET)

« ce sont les caractères dédiés à cet usage » Ce n’est pas ce que dit Unicode et c’est bien comme ça que l’interprètent les créateurs de police comme tu peux le voir sur la capture d’écran. Pour un travail typographique irréprochable il ne faut pas utiliser ces caractères, mais les fonctionnalités de mise en forme du traitement de texte. LeBret (discussion) 1 décembre 2016 à 17:53 (CET)

Les fonctionnalités de mise en forme des exposants et indices sont à prioriser quand elles sont disponibles, c'est un fait. Reste que quand on a UTF-8 sous la main et pas de mise en forme possible, c’est un bel avantage que de pouvoir saisir même ces lettres modificatives ceci à défaut d’avoir de réels exposants dans Unicode. Si Unicode venait à inclure l'intégralité des exposants/indices, ils auraient évidement leur place sur cette touche morte à la place des caractères que l’on a pioché en remplacement. C’est écrit sur l’article soumis au vote. On peut aussi se dire que la création de ce genre de touche morte démontre un besoin réel qui pourra inciter au développement d’Unicode en ce sens. – A2 (discussion) 1 décembre 2016 à 21:49 (CET)

Ce sont de vrais exposants, cf. http://www.unicode.org/mail-arch/unicode-ml/y2016-m10/0098.html. C’est juste le GT qui semble ne pas l’avoir remarqué, ne croyant pas ceux qui essaient de leur expliquer… -- Marcel (discussion) 1 décembre 2016 à 22:03 (CET)

Ah, bah, si le bépo est réservé à ceux qui tapent sur un traitement de texte, je n’ai rien compris au bépo. Sérieusement, on tape beaucoup de texte ailleurs que dans traitement de texte. Même sur le Web, les balises sup produisent un résultat médiocre. Et puis, perdre son formatage lors d’un copier-coller, c’est vraiment pénible. Je ne sais pas ce que dit réellement Unicode, mais on ne me fera pas croire qu’ils ont ajouté des caractères avec l’intention de nous priver de les utiliser. Flamme (discussion) 2 décembre 2016 à 01:15 (CET)

Oui, ça arrive. Exemple volontairement pris hors des exposants/indices : ŉ. Comme tu peux le voir le script group de ce caractère est « Deprecated letter ».

Pour revenir aux exposants/indices, les caractères proposés ressemblent à des exposants mais n’en sont pas. On peut faire la comparaison avec les caractères ci-dessous :

ʃ	U+0283	LATIN SMALL LETTER ESH
∫	U+222B	INTEGRAL
∑ 	U+2211	N-ARY SUMMATION 
Ʃ	U+01A9	LATIN CAPITAL LETTER ESH

Ces caractères se ressemblent bel et bien. Pourtant si tu tapes une intégral alors que tu veux la lettres esh minuscule, cela a des conséquences :

la correction orthographique ne marche pas
des fonctionnalités comme le comptage de mots, le changement de casse… ne marchent pas
le caractère peut être dans une police de caractère différentes du reste du mot
etc.

Avec ces pseudo-exposants c’est pareil. Actuellement Unicode ne propose pas de vrais exposants/indices, pas plus qu’il ne propose de vrais gras ou italique. LeBret (discussion) 2 décembre 2016 à 12:32 (CET)

J’entends la critique. Mais dans ce cas, il faut être cohérent. Soit on supprime les faux exposants de la touche Exposant, considérant que ce n’est pas une bonne pratique. Soit on acte qu’il n’y a rien d’autre pour les exposants et on accepte cet état de fait. Mais encourager et décourager en même temps une pratique, ce n’est pas cohérent. Pour ma part, j’ai acté que certains des caractères servent pour autre chose que ce qui est prévu, mais puisqu’il n’est offert aucune autre solution, qu’il en soit ainsi. -- Flamme (discussion) 2 décembre 2016 à 13:19 (CET)

Ce n'est pas encourager et décourager en même temps. Mon point de vue, c'est qu'on sait qu'on peut le faire, mais dans la pratique, on ne le fera presque jamais. Donc on le met à un endroit du clavier facilement mémorisable, et pas forcément facilement accessible. Et le jour où je veux faire une note de bas de page dans un courriel, je sais où se trouve l'exposant (ce qui ne sera pas le cas avec AltGr+S) ; de même le jour où je veux me la péter et écrire M^me dans du texte pur. Mais encore une fois, ce n'est que mon point de vue, et c'est en ce sens que je vote. Si vous avez un point de vue différent, votez différemment ! Il me semble que les règles de fonctionnement du groupe n'imposent pas l'unanimité pour chaque vote… ;-) Rideĉjo (discussion) 2 décembre 2016 à 15:20 (CET)

Il faut bien se manifester un peu pour tenter de convaincre. Je crois le (més)usage de ces caractères plus répandu que vous ne le pensez. Mais je vous laisse tranquille, je n’ai rien à ajouter. :) -- Flamme (discussion) 2 décembre 2016 à 16:05 (CET)

+1 Quand je dis que j’en aurais besoin, c’est plusieurs fois par jour, et j’exclus évidemment les discussions sur le sujet qui fausseraient totalement ces statistiques. De l’usage que j’ai, l’ajout de cette touche morte est la modification la plus utile de la v1.1 avec l’inversion des apostrophes. J’ai la désagréable impression que l’argumentaire se rapproche d’une part de ceux qui ne voulaient pas de certains caractères « car c’est le rôle du traitement de texte », et d’autre part de « on ne peut pas utiliser ’ comme apostrophe car ça ne fait partie de sa définition unicode » (ce n’était pas encore la préconisation unicode à l’époque). Par contre j’entends bien que ce n’est pas les bons caractères, mais c’est ce qui s’en rapproche le plus. -- Crako (discussion) 2 décembre 2016 à 16:15 (CET)

Après recherche, j’ai l’impression que le problème constaté est davantage lié aux polices, qui ne prennent pas en charge tous les ajouts d’Unicode. Comme vous pouvez le constater ici, les lettres en exposant du bloc API sont bien canoniquement équivalentes aux lettres latines en exposant. Notez que dans cette proposition d’ajout des caractères manquants, les lettres en exposant sont proposées en tant que modifier letters alors qu’elles ne figurent pas dans l’API. Bien cordialement --Milton (discussion) 3 décembre 2016 à 12:59 (CET)

Nota : je ne vois que le n qui sorte différemment des autres caractères en exposant. ;-) --Milton (discussion) 3 décembre 2016 à 14:01 (CET)

+1. – ⚓ – L’argument des polices dysfonctionnelles ne vaut jamais pour Unicode, ni pour argumenter des demandes d’encodage, ni pour déconseiller des pratiques. Si le travail doit être soigné, la police doit être de bonne qualité, cela est toujours valable.

La question à répondre en premier lieu est le statut des exposants dans les abréviations françaises. Comme dans le temps, les exposants Unicode n’existaient pas, on partait toujours sur une mise en forme. Cela n’implique pas que sémantiquement, le point de vue qui en est déduit, soit valable. En effet, dès que le texte sans mise en forme n’a plus du tout le même sens qu’avec mise en forme, la mise en forme est sémantiquement porteuse de sens, et Unicode est tenu, de par ses principes, d’encoder de nouveaux caractères pour donner le moyen de conserver le sens au format texte brut. Unicode encode du texte brut, est-il écrit dans le standard.

Puisqu’en français, « nos » n’est pas « nᵒˢ » (on pourrait multiplier les exemples), les exposants ont une valeur sémantique et doivent donc être disponibles en texte brut.

Les noms de caractères avec « lettre modificative » ne préjugent pas de la fonction d’exposant. Paraphrasons le standard Unicode^[1] :
« Lettres en exposant. » Parmi les lettres modificatives, il y en a qui sont des formes en exposant, et on en trouve dans différents blocs. Il y a aussi un bloc spécialement pour des exposants et indices, et c’est là que se trouvent l’ⁿ et l’ⁱ. « Le fait que ces deux lettres contiennent le mot ‹ exposant › dans leurs noms au lieu de ‹ lettre modificative › est un artifice historique provenant des sources d’origine de ces caractères, et n’a pas pour but d’exprimer une distinction au niveau fonctionnel dans l’utilisation de ces lettres dans le standard Unicode. » Les lettres en exposant servent à porter un sens spécifique, comme en phonétique [notez le « comme » ; on a donc le droit de les utiliser ailleurs qu’en phonétique], et « ne sont pas un substitut à la mise en forme » dans les appels de note ou les formules mathématiques et scientifiques. — Le mieux est de lire cela directement dans le standard. Voir aussi au chapitre 22.

↑ [http://www.unicode.org/versions/Unicode9.0.0/ch07.pdf#G24762 The Unicode Standard, v9.0.0, chapitre 7, § 8 : Lettres modificatives > Lettres modificatives espaçantes > Lettres en exposant (page 327). Ouvrage sous droit d’auteur !

— Le message qui précède, non signé a été déposé par Marcel (d), le 3 décembre 2016 à 14:18.

Ordinaux masculin et féminin 2ᵉ

Les commentaires de l’enquête publique proposent de rendre accessible les ordinaux º et ª par la couche latin étendu au lieu de la couche exposant.

Méthode

Le vote utilise la méthode de Condorcet (en cas de paradoxe, on utilisera la méthode Schulze). Si le vote ne propose que deux options, on utilise simplement la majorité absolue.

Durée

Une semaine à compter de la diffusion du vote, soit jusqu’au 29 avril 2018 à 7h (CET).

Propositions

A : Dupliquer les ordinaux en Latin étendu+m et Latin étendu+f
B : Déplacer les ordinaux en Latin étendu+m et Latin étendu+f
C : Laisser les ordinaux uniquement sur Exposants+AltGr+m et Exposants+AltGr+f (status quo)

Votes

B > C > A. -- Ariasuni (discussion)
A > C > B -- Flavien21 (discussion) 22 avril 2018 à 00:48 (CEST)
A = B = C -- Milton (discussion) 22 avril 2018 à 01:16 (CEST)
A > B > C -- Laurent (discussion) 22 avril 2018 à 04:31 (CEST)
A > C > B -- Mimoza (discussion) 23 avril 2018 à 00:46 (CEST)
C > B > A -- Flamme (discussion) 23 avril 2018 à 11:11 (CEST)
A = B > C -- Il faut que les deux soient en ‹ latin et ponctuation › (et symboles), d’autant plus qu’aucune lettre n’y est pressentie pour F ou M. Mais pour l’ergonomie, on peut aussi les y doubler en AltGr sur A et O, pour faire des roulements à deux mains le pouce sur AltGr. D’ailleurs c’est pas une mauvaise idée de combler tout l’AltGr de ‹ latin › avec des symboles, comme diamètre ⌀ sur D, certes pour ça il y a ‹ scientifique ›. L’essentiel c’est ne ne pas y mettre de lettres bicamérales en AltGr, sauf sur A O U où ça fonctionne sur le bépo. -- Marcel (discussion) 28 avril 2018 à 20:29 (CEST)
A > B > C -- Logisim (discussion) 28 avril 2018 à 23:48 (CEST)
B = C > A -- A2 (discussion) 29 avril 2018 à 05:14 (CEST)

Dépouillement

A vs. B : A vainqueur à 4 contre 3.
A vs. C : A vainqueur à 5 contre 3.
B vs. C : B vainqueur à 4 contre 3.

La proposition A est acceptée

Validation nouvelle place

Validation ou non de la nouvelle place en AltGr+t suite au vote sur la touche morte ‹ latin étendu ›.

Méthode

Le vote utilise la méthode de Condorcet (en cas de paradoxe, on utilisera la méthode Schulze).

Durée

5 jours à compter de la diffusion du vote, soit jusqu’au 4 mai 2018 à 7h (CEST).

Propositions

A : Validation d’‹ exposant › en clavier bépoAltGr+clavier bépot (Statu quo – ‹ indice › en double ‹ exposant ›)
B : ‹ Exposant › en clavier bépoAltGr+clavier bépot et ‹ indice › en clavier bépoAltGr+clavier bépoMaj+clavier bépov
C : ‹ Exposant › en clavier bépoAltGr+clavier bépot, ‹ indice › en clavier bépoAltGr+clavier bépov, et ‹ hatchek › en clavier bépoAltGr+clavier bépoMaj+clavier bépov
D : ‹ Exposant › en clavier bépoAltGr+clavier bépoMaj+clavier bépo^ et ‹ indice › en clavier bépoAltGr+clavier bépoMaj+clavier bépov
E : ‹ Exposant › en clavier bépoAltGr+clavier bépot (‹ indice › en double ‹ exposant ›) + ‹ exposant › en clavier bépoAltGr+clavier bépoMaj+clavier bépo^ et ‹ indice › en clavier bépoAltGr+clavier bépoMaj+clavier bépov
F : ‹ Exposant › en clavier bépoAltGr+clavier bépoj (‹ indice › en double ‹ exposant ›)
G : ‹ Exposant › en clavier bépoAltGr+clavier bépot, ‹ indice › en clavier bépoAltGr+clavier bépoj

Votes

E² > D² > B² > A² > C² > G¹ > F¹ -- Deux choses : ① Éviter si possible de déplacer des touches mortes sur clavier bépoAltGr+clavier bépoj (autre que ‹ rayé ›, cf. la suite), car il y en a besoin de deux touches là-haut pour avoir les guillemets doubles et simples chevrons avec leur espace fine insécable en séquences automatiques (deux touches côte à côte, décaler légèrement ‹ rayé › de clavier bépoAltGr+clavier bépoz sur clavier bépoAltGr+clavier bépoj), sinon l’ergonomie du bépo est sous‐optimale en écriture du français de France et de notations à base de guillemets chevrons. — ② Arriver à libérer clavier bépoAltGr+clavier bépot pour le ‹ tréma › dont l’ergonomie actuelle sur le bépo – bien que meilleure que sur l’azerty – est sous‐optimale au final car du même côté que les voyelles qui forment quand même la majorité comme lettres de base pour cette touche morte. Mais pour cela il faut un accès plus ergonomique encore aux exposants du français, que sont les touches vives en clavier bépoMaj+clavier bépoNombres, cette modificatrice sur LSGT (B00), sachant que les claviers sans cette touche sont souvent des claviers ergonomiques où il y a toujours une touche à hacker pour l’y mettre, ou ajouter une scancode map (clé de redisposition de codes matériels) mettant clavier bépoNombres sur clavier bépoAlt. Faute de quoi il faut ‹ exposants › très accessible, donc sur clavier bépoAltGr+clavier bépot (mais ce n’est qu’un pis‐aller). -- Marcel (discussion) 29 avril 2018 à 08:30 (CEST)
A > E > B > D > F > G > C -- Flavien21 (discussion) 29 avril 2018 à 08:59 (CEST)
A > B > C > E > D > G > F (mais j’ai du mal à comprendre pourquoi nous revotons à ce sujet un an plus tard) -- Milton (discussion) 29 avril 2018 à 11:32 (CEST)
A > F > C > E > G > B > D (je ne comprend pas non plus, sachant que la moitié des propositions sont complètement débiles. Sérieusement, vous avez déjà essayé de taper des symboles chimiques avec indice sur clavier bépoAltGr+clavier bépoMaj+clavier bépov ? Et exposant sur clavier bépoAltGr+clavier bépoMaj+clavier bépo^ c’est encore pire. La mnémotechnique c’est bien, mais ça n’empêche pas de réfléchir avant de proposer de telles inepties… Quel intérêt de les redonder ?) -- Crako (discussion) 1 mai 2018 à 20:12 (CEST)
A > C > F > E > G > B > D (+1 Difficile de comprendre la motivation de revoter sur les exposants/indices…) -- Flamme (discussion) 1 mai 2018 à 22:28 (CEST)
E > D > B > C > G > A > F -- Mimoza (discussion) 2 mai 2018 à 01:08 (CEST) Difficile de comprendre pourquoi refuser la redondance …
E > G > B = C = D > A = F -- Laurent (discussion) 2 mai 2018 à 05:03 (CEST)
E > D > C > B > A > G > F -- Logisim (discussion) 2 mai 2018 à 21:45 (CEST)

Dépouillement

[1] [http://www.unicode.org/versions/Unicode9.0.0/ch07.pdf#G24762 The Unicode Standard, v9.0.0, chapitre 7, § 8 : Lettres modificatives > Lettres modificatives espaçantes > Lettres en exposant (page 327). Ouvrage sous droit d’auteur !

[1]