[EGD-discu] Indicateurs ordinaux français

[Marcel <bkn.ema@xxxxxxxxx>]

Je renvoie ceci correctement et avec la date, pardon pour ce manque de soin..
J’en profite aussi pour faire quelques mises à jour et ajouts.

Le 15/01/2017, 15:58, j’ai écrit  (Re: Fractions et Compose) :
> 
> > > Envoyé: samedi 14 janvier 2017 à 16:46
> > > De: Marcel <bkn.ema@xxxxxxxxx>
[…]
> > > > Reste la question “pourquoi ça et pas autre chose”. Par exemple la barre de
> > > > fraction U+2044 au lieu de ½, le trait d’union insécable au lieu du ¼, et le
> > > > symbole diamètre (aujourd’hui en AltGr sur le clavier allemand T2) au lieu
> > > > des ¾. Mais la réponse a déjà été donnée : Parce qu’il n’y avait pas de
> > > > touche compose sur le bépo. Pas de touche morte émulant la fonctionnalité
> > > > de composition. À cela aussi il y a une raison que l’on sait : Parce qu’on ne
> > > > savait pas encore que Windows peut le faire. Ni on, ni moi, mais il y avait
> > > > des gens qui le savaient, bien entendu. Mais qui en faisaient un secret,
> > > > sans doute toujours pour mettre en valeur les logiciels Office, qui ont
> > > > quelque chose de prévu pour la saisie de symboles (AutoMath, …).
> 
> Ils continuent d’ailleurs dans Unicode, en créant et entretenant la légende urbaine 
> que les lettres en exposant ne doivent pas être utilisées en écriture courante. 

J’ai appris de source sûre qu’il n’y a pas de « conspiration », autrement dit, 
Microsoft n’est pas le seul à s’opposer à ce que la performance soit déportée vers 
Unicode qui empiéterait ainsi sur la chasse gardée des logicicels haut de gamme comme 
QuarkXPress, Adobe InDesign, Adobe Illustrator, Microsoft Publisher, Serif PagePlus 
ou PagePro (je ne sais plus), Apple PageMaker. Il se pourrait même que Microsoft 
n’était pas impliqué dans ce trucage du standard Unicode, car plusieurs personnes 
travaillant pour Microsoft (en tant qu’employé ou contributeur wiki MVP) proposent 
d’utiliser les exposants et indices numériques d’Unicode pour écrire des fractions 
et des expressions mathématiques, contrairement aux spécifications d’Unicode…

En fait, je n’arrive pas à déterminer qui exactement a introduit cette spécification 
dans le standard Unicode. Mon affirmation que c’est pour des raisons de marketing de 
logiciels n’a par contre pas été contredite, ni sur la ML d’Unicode (où j’ai vu les 
affirmations inexactes rapidement corrigées/invalidées par d’autres participants), 
ni hors liste. Microsoft étant le plus puissant, il devient vite la bête noire, 
mais désormais je pense qu’Adobe pourrait être pire. C’est bien Eric Muller d’Adobe 
http://www.unicode.org/history/photoalbum/irg2007.html
qui était ou est en même temps un vice-président de l’Unicode Technical Committee
http://www.unicode.org/history/previousofficers.html
qui a bricolé au cours de la réunion de l’UTC le tissu de mensonges 
http://www.unicode.org/L2/L2010/10315-comment.pdf
qui devait servir de prétexte pour rejeter le q minuscule en exposant 
http://www.unicode.org/L2/L2010/10230-modifier-q.pdf
http://www.unicode.org/L2/L2010/10316-cmts.pdf

Si aujourd’hui, Microsoft et d’autres peuvent en profiter (ou pas), pendant les 
quatre premières années du consortium, Lotus et WordPerfect, encore concurrents de 
Microsoft à l’époque, étaient pareillement membres votants :
http://www.unicode.org/history/contributors.html#members1991to1999

Certes, Unicode est parti de Xerox et d’Apple, et n’a été « présenté à Microsoft 
et à IBM » que trois ans après le lancement du projet, soit en « octobre 1989 », 
« conjointement avec la coopération Apple-Microsoft pour TrueType »:
http://www.unicode.org/history/versionone.html

Il n’en reste pas moins qu’il y avait déjà à l’époque une volonté caractérisée de 
dissuader les utilisateurs lambda de se servir de ces lettres en exposant pour écrire 
des ordinaux/abréviations, et les dessinateurs de fontes, de prendre en charge ces 
caractères de manière cohérente et extensive comme je les trouve dans Calibri, où il 
manque toutefois toujours la prise en charge des diacritiques combinants pour ces 
lettres… Le refrain « C’est pas prévu pour » repose sur un choix parfaitement 
arbitraire qui est contraire aux préférences réelles des typographes de métier comme 
Olivier Randier :
http://www.cairn.info/article.php?ID_REVUE=DN&ID_NUMPUBLIE=DN_063&ID_ARTICLE=DN_063_0089&FRM=B

Je le trouve assez désolant que ces choses ne soient pas détaillées quelque part d’un 
point de vue neutre et objectif, et en gardant à l’œil le côté pratique et le bien-être 
des utilisateurs qui sont au final ceux qui sont amenés à bosser le plus avec tout ça.
Au lieu de quoi, des novices comme moi doivent rentrer dans la matière en essayant de 
démêler tant bien que mal le vrai du faux, pour tenter d’éviter des plantages 
pitoyables et spectaculaires à la fois à l’image de cet « indicateur ordinal » à faire 
encoder dans Unicode, pour lequel une place serait réservée sur le futur azerty…

Il paraît que le GT de l’Afnor, soit il a pris le standard à la lettre (chose à 
ne pas faire car à un moment donné ça se retourne contre l’utilisateur, puisque le 
standard Unicode n’est pas centré sur l’utilisateur mais sur l’industrie du logiciel),
soit a reçu (de qui ?) le conseil de plutôt faire encoder un nouveau caractère — 
conseil bidon s’il en est. Microsoft non plus ne prend pas le standard à la lettre, 
autrement ils auraient implémenté la barre de fraction au plus tard dans Edge (et 
dans Word bien sûr ; dans LibreOffice pour Windows, HarfBuzz arrive avec la v5.3). 
Comme Microsoft ne fait pas fonctionner U+2044 même avec les polices à jour (sauf 
peut-être dans Publisher), on est obligé·e·s de continuer à l’ancienne :
https://fr.wikipedia.org/wiki/Mod%C3%A8le:Fraction
C’est peut-être la meilleure façon de l’utiliser. En écriture latine on utilise tant 
de polices qu’on n’arrivera jamais à toutes les mettre à jour en OpenType, contrairement 
aux écritures complexes qui utilisent peu de polices et ont le plus besoin de HarfBuzz.

Donc en tout cas il a fallu rectifier ici ces deux points sur l’implication de 
Microsoft dans Unicode, car dans un échange hors liste on m’a corrigé sur cela.

[…]
> 
> Tout ça ne nous toucherait pas si l’Afnor avait suffisamment d’indépendance pour 
> passer outre et émettre ses propres recommandations, comme elle l’avait fait dans 
> le cadre d’ISO/IEC 9995-11 où les recommandations de cette norme sont détaillées. 

On nous avait d’ailleurs annoncé qu’ISO/IEC 9995 allait être implémentée en France 
à la faveur des concessions négociées de bonne heure avec Karl Pentzlin. 

Qu’en est-il aujourd’hui ?

Cela dit je ne prendrais pas cette norme à la lettre au point d’utiliser le point pour 
les diacritiques combinants.

> Maintenant, on se dirige vers une dispo azerty nouvelle où une place est réservée 
> à l’indicateur ordinal « ᵉ » (tout le monde voit cet « e » en exposant ? Eh bien 
> ça prouve qu’il existe et peut être utilisé, souvent même avec accent aigu combinant)
> mais avec rien dessus, « dans l’attente de son encodage dans Unicode » qui n’aura 
> jamais lieu, puisque chez Unicode, d’une ils n’encodent pas deux fois le même 
> caractère mais disent d’utiliser les caractères pour plusieurs choses, et de deux 
> ils n’encodent pas de nouveaux indicateurs ordinaux pour remplacer la mise en 
> exposant disponible dans les logiciels et les langages de formatage. Et les trois 
> autres lettres, au passage ? Après, les anglophones viendront demander la même chose.

À savoir bien sûr les indicateurs ordinaux supplémentaires propres à l’anglais : 
le 'ʰ', le 'ⁿ' et le 'ᵗ' (attendu qu’en français, on écrit '2ᵈ', non '2ⁿᵈ' :
http://www.academie-francaise.fr/abreviations-des-adjectifs-numeraux
http://www.les-abreviations.com/adjectifs.html
).

> Non sérieusement, les indicateurs ordinaux existent sons la forme de caractères 
> mal nommés en contradiction avec les titres, les commentaires, et les lettres en 
> indice. On a ce qu’il faut, et c’est à prendre ou a laisser. Je vais d’ailleurs 
> demander que des alias informatifs soient ajoutés (après le signe égal):
> […]
> 1D48 MODIFIER LETTER SMALL D
> = latin superscript small letter d
> # <super> 0064
> 1D49 MODIFIER LETTER SMALL E
> = latin superscript small letter e
> # <super> 0065
> […]

Jusqu’à présent, il n’y a eu aucune réaction négative sur la Mailing List à propos 
d’une telle liste (qui se veut complète) postée entre-temps (le 15/1/2017) :
http://www.unicode.org/mail-arch/unicode-ml/y2017-m01/0090.html

J’ai mis à jour la traduction française à ce propos ; une fois la révision terminée 
elle sera en ligne, j’espère prochainement. (Il me reste encore à vérifier toute la 
liste face à l’original anglais d’Unicode.) Parce que je vais mettre en ligne 
des fichiers KLC pour que les gens puissent faire eux-mêmes des dispositions 
simplifiées (pour l’instant c’est fini les .exe), et comme le MSKLC affiche les noms 
des caractères (heureusement), il faut quʼil y ait aussi une liste des noms à jour. 
À mon avis c’est mauvais d’embêter tout le monde avec ces identifiants biaisés 
(LETTRE MODIFICATIVE ...) où les vrais identifiants commenceraient par 
EXPOSANT LETTRE ... LATINE, comme les indices commencent par INDICE LETTRE .... LATINE 
selon la version originale comme dans U+2091 LATIN SUBSCRIPT SMALL LETTER E (qui sont 
aussi des lettres phonétiques !).

On voit bien qu’ils anticipaient qu’on allait se servir des exposants pour écrire, 
et que cesrtains (qui exactement ?) ont cherché à nous la gâcher. Chiche ! 

Rappelons tout de même que pour utiliser toutes les polices, il faut utiliser des 
lettres normales avec mise en forme,et le cas échéant, une macro de conversion 
préformaté→formaté.

Cdlt,
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".