| Re: [EGD-discu] La touche morte ‹ symbole scientifique › et l’AFNOR |
[ Thread Index |
Date Index
| More ergodis.org/discussions Archives
]
Le commentaire 27 n’est pas de moi, mon numéro n’est pas 966659.
Marcel
> Message du 13/07/17 10:59
> De : "Jean-Christophe Groult"
> A : "discussions"
> Copie à :
> Objet : Re: [EGD-discu] La touche morte ‹ symbole scientifique › et l’AFNOR
>
>
> Ça compte pas Marcel, c’est un de tes commentaires ! 😉
>
>
> Plus sérieusement le commentaire est pertinent, mais malheureusement mal placé pour être efficace.
>
Là on a l’impression que la personne nous dit « il y a plein de place : utilisons la. »
> Ce n’est pas l’expression d’un besoin.
>
> Ce commentaire aurait été bien plus efficace si il avait été placé sur le tableau des symboles en disant « il manque tel et tel caractères qui me sont
utiles »
>
>
Sur le processus du GT, cela s’est passé en 2 temps :
>
1) on a établit la liste des caractères (et à l’époque bépo n’avait pas beaucoup de symboles mathématiques, même pas infini et racine carrée
>
== > c’est l’expression du besoin
>
>
2) ensuite on réfléchit à comment on place ces caractères sur le clavier, mais sans remettre en cause la liste des caractères établie.
>
== > on apporte une réponse à ce besoin
>
>
Dans un processus d’innovation d’entreprise, on bouclerait pour éventuellement améliorer les choses. C’est d’ailleurs ce qui a été fait dans Ergodis. Mais
ce n’est pas le principe de fonctionnement de l’AFNOR. Son but est d’expliciter noir sur blanc un consensus entre acteurs du marché.
>
>
Une des conditions pour que la norme contiennent à la fois l’Azerty et Bépo est que les dispositions normalisées aient le même ensemble de caractères.
>
Si les 2 dispositions couvrent des ensembles trop différents, il ne s’agit plus de 2 variantes d’une même norme, mais de 2 normes différentes réunis
artificiellement dans le même document et ça, ce n’est pas envisageable.
>
>
Quelques concessions ont déjà été obtenu sur ce principe rigide : quelques symboles non supportés par l’Azerty, figurent tout de même dans l’annexe B
mais seulement en « recommandé » pas en obligatoire. C’est le cas par exemple du symbole moins − (en AltGr+8).
>
Cela a été accepté car cela reste limité à quelques cas. On peut difficilement étendre cette concession.
>
>
Si ces caractères nous semblent nécessaires dans la norme (je rappelle que rien ne nous l’interdit dans le pilote), il devrait figurer dans la partie 6 et
donc être pris aussi en charge par l’Azerty.
>
Si on souhaite s’engager dans cette voie, il faut venir avec des arguments acceptables par le GT. Ces arguments ne sont pas nécessairement ceux qui
nous ont convaincu.
>
>
Par exemple, quand le GT s’est penché sur la liste des symboles monétaires à retenir, il y avait une partie importante du groupe qui se contentait de $ €
£ et éventuellement ¥.
>
Pour les convaincre j’ai recherché les documents normatifs sur lesquels m’appuyer. C’est-à-dire Unicode et ISO 9995-9 (qui s’appuie sur Unicode 6 hors
monnaies « historique » trop ancienne)
> Cela m’a permit de faire 3 propositions :
>
1) les symboles monétaires de ISO 9995-9
>
2) même chose plus les symboles ajoutés jusqu’en Unicode 9
>
3) même chose plus les monnaies historiques et hors du bloc Unicode monétaire.
>
>
La 1ème option s’appuyait sur une base normative solide, mais ne retenait pas le rouble et la livre turque qui ont du sens dans un contexte européen.
>
La 3ème option a été écarté car elle impliquait des caractères nécessitant des police de caractère non systématiquement installée en France.
>
Par conséquent c’est l’option 2 qui a été retenue.
>
>
C’est ce type d’arguments qu’il faut amener devant le GT si on veut les convaincre.
>
> Je n’aurais pas le temps de faire ce genre de recherche. Mais si certains veulent les faire je me ferais un plaisir de défendre leurs arguments
>
>
LeBret
>
>
>
Le 12 juillet 2017 à 23:11, Marcel a écrit :
>
Le commentaire http://dispoclavier.com/ret/index.html#27 propose comment
> compléter la touche morte ‹ scientifique ›, ne sachant pas qu’elle a été vidée de
> presque la totalité de son contenu pour la faire rentrer dans la norme. En termes
> d’image du bépo, ça me semble avoir été une mauvaise chose.
>
> Peut-être le GT ne voulait-il pas reprendre cette touche morte afin de laisser
> l’avantage au bépo ? Dans ce cas-là aussi, il aurait fallu conserver son intégrité…
>
> Cela vient nuancer l’impression que le bépo est entre de bonnes mains. Est-ce
> qu’il a été proposé de négocier avec le GT ou l’Afnor la normalisation du bépo 1.1
> entier ? À mon avis, il y a seulement un problème de production. Les tableaux et
> tout le reste est tapé à la main (fautes de frappe et omissions à la clé).
>
> Ce que l’AFNOR doit faire (toujours à mon avis personnel…), en plus d’automatiser
> la génération des tableaux comme indiqué dans l’un des commentaires, c’est de
> rendre le brouillon au projet bépo pour qu’on puisse remplir et compléter les tableaux —
> et corriger les erreurs de rédaction au passage.
>
> La promesse de ce jour – prioriser la qualité et non la rapidité de la production –
> prend tout son sens.
>
> Veillons à ce que cela se concrétise.
>
> 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".
>
>
>
--
Pour ne plus recevoir les messages de cette liste de discussion, envoyez un courriel avec pour destinataire discussions-REQUEST@xxxxxxxxxxx et pour sujet "unsubscribe".