Re: Unicode (suite)

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

>----- Message d'origine -----
>De : "Thierry Bouche" <Thierry.Bouche@xxxxxxxxxxxxxxx>
>À : <typographie@xxxxxxxx>
>Envoyé : Wednesday, July 26, 2000 8:35 AM
>Objet : Re: Unicode (suite)
>
>
>> Concernant « Re: Unicode (suite) », Lacroux écrit : «
>> » TOUTE lettre latine, qu'elle soit romaine ou italique, cap, petite cap
>> » ou bas de casse, a potentiellement sa place dans l'étonnante catégorie
> symboles
>> » de type lettre »...
>>
>> Sauf erreur de ma part, c'est assez largement fait dans Unicode-3 : la
>> plupart des symboles mathématiques (y compris variations
>> « glyphiques »  de l'alphabet latin) y ont trouvé leur place en vue de
>> pouvoir coder les « entités » mathml...
>
>Pas tout à fait, on nous prépare (Murray Sargent de Microsoft pour mathml)
>de coder beaucoup plus de variantes de caractères (gothique, italique, de
>ronde ou de scripte, ajourée) pour une prochaine mise à jour d"Unicode (3.1
>?). En fait toutes les lettres de l'alphabet latin sous toutes ces formes,
>certains s'y opposent farouchement : ce n'est pas du texte brute mais des
>infos de police, d'autres disent qu'on ne peut confondre deux lettres de
>variantes différentes dans un même texte mathématique et qu'il ne s'agit
>donc pas de propriétés de fantaisie...

En fait, les deux ont raison, plus ou moins. Certes les attributs
typographiques mathématiques ont une valeur sémantique plus critique que
dans la typographie ordinaire. Un a romain et un a italique ont des
significations profondément différentes. Mais est-ce au codage de résoudre
ça ? N'est-ce pas trop lui demander ? Que je sache, MathML est proche de
HTML, qui sait parfaitement (enfin, presque) gérer des attributs
typographiques. On peut imaginer d'y intégrer des attributs typographiques
mathématiques dont le comportement serait différent de leurs équivalents
typographiques courants (par exemple verrouillables, comme évoqué dans la
discussion K2/XPress). Mais se défausser sur le codage, à mon avis, c'est
s'imposer le tonneau des Danaïdes. C'est au format de fichier de gérer ça
proprement (je sais, c'est beaucoup demander au spécialiste des usines à
gaz). On n'aura jamais fini de tout coder, et l'usage d'un tel codage sera
impraticable. Les gens de Microsoft feraient peut-être bien d'atterrir et
de se mettre au niveau du _vulgum pecus_. Franchement, croyez-vous qu'un
étudiant en sciences moyen ira chercher un a italique dans le codage
d'Unicode ? Non, évidemment, il prendra un a romain et il cliquera sur
l'icône "italique" de Mot 2010 v3.1.7015ß. Et il aura raison, à mon avis...
Même chose pour bien des codages superflus. Combien de personnes iront
chercher le signe pour kelvin au lieu de taper un K ? 1%, 0,1%, 0,0001% ?
(Rayer la mention inutile.) Donc, à quoi sert un code qui sera erroné dans
99,999% des cas ?
À mon avis, l'intention est claire : il s'agit d'infantilliser encore plus
l'utilisateur pour le rendre dépendant d'un éditeur d'équation monstrueux
chaque fois qu'il aura une variable à mettre en ital. Ceci afin de tenter
-- vainement -- de le forcer à coder politiquement correct, pour pouvoir
passer le résultat dans une moulinette de traitement automatique, histoire
de mettre au chômage quelques typos et éditeurs scientifiques de plus, et
de les remplacer par des arpettes de 3° classe, chargés de corriger (mal)
les innombrables erreurs de la machine.
Le résultat sera, je pense, tout aussi évident : un bordel indescriptible.
L'absurdité de l'orientation "caractère" d'Unicode révèle ici tout son suc.

Quand certains arrêteront de fumer la moquette, on pourra peut-être
travailler sérieusement ;-)))

______________________________________
Et les shadoks pompaient, pompaient...

Olivier RANDIER -- Experluette		mailto:orandier@xxxxxxxxxxx
	http://technopole.le-village.com/Experluette/index.html
Experluette : typographie et technologie de composition. L'Hypercasse
(projet de base de données typographique), l'Outil (ouvroir de typographie
illustrative).