Archive Liste Typographie
Message : Re: Unicode [Maths] (suite)

(Olivier RANDIER) - Vendredi 28 Juillet 2000
Navigation par date [ Précédent    Index    Suivant ]
Navigation par sujet [ Précédent    Index    Suivant ]

Subject:    Re: Unicode [Maths] (suite)
Date:    Fri, 28 Jul 2000 00:02:04 +0200
From:    Olivier RANDIER <orandier@xxxxxxxxxxx>

>Olivier RANDIER a écrit :
>> 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 ?
>
>Le codage relève de l'implémentation. Ce qui est nécessaire, c'est de
>disposer dans le source MathML d'entités sémantiques précises : a n'est
>pas une petite lettre latine, c'est un single letter math identifier,
>sin n'est pas un texte composé de trois lettres, c'est un multi-letter
>math operator, etc. (terminologie inventée pour cet envoi, hein.)
>
>Il me semble que la philosophie de MathML consisterait à avoir un source
>XML dans lequel une variable notée a serait codée &amathvar; (idem).
>Côté saisie, on peut imaginer soit sélectionner ledit caractère unicode
>s'il existe, soit indiquer au logiciel qu'on tape des maths et taper a
>(dollars de tex). Côté formatage, on peut soit dire que &amathvar;
>imprime le code unicode ad hoc, soit avoir un système qui sait que
>&amathvar; est un a ital ou romain, selon la feuille de style, à prendre
>dans telle police.
>
>Donc oui, dans la mesure où les maths n'ont pas inventé la plupart des
>symboles qu'elles utilisent, mais les piquent ailleurs, on peut se
>passer d'avoir les variantes glyphiques des alphabets dans Unicode, en
>s'appuyant plutôt sur le programme de formatage (c'est ce que font les
>logiciels actuels, de toute façon). Mais on peut aussi considérer que
>leur présence dans unicode simplifie les échanges de fichier, ce pour
>quoi unicode est fait, non ?

Ce raisonnement se tiendrait, et je l'approuverais, si le langage
scientifique était un ensemble fini, connu d'avance. Tu sais mieux que moi
que les scientifiques adorent inventer de nouvelles notations. Il est quand
même plus simple de rajouter une routine à un programme que de mobiliser
tout le consortium Unicode pour approuver chaque lubie d'universitaire. Tu
l'avoues toi-même : MathML est tout à fait capable de comprendre que
&sinmulti-lettermathoperator; correspond aux troix lettres s-i-n. Quel est
l'intérêt de rajouter un intermédiaire qui revient à passer de s-i-n à
{sin} pour revenir à s-i-n ?
Si un jour, on réforme la notation mathématique, comme cela s'est déjà
produit en partie, ne sera-t-il plus simple de modifier les routines des
programmes plutôt que de jeter Unicode aux horties ?
De plus, Unicode est, lui aussi, limité. Les japonais se plaignent déjà
qu'il prétend limiter leur langue à 20 000 idéogrammes. Combien de langues
devra-t-on sacrifier pour des codages de maths dont on pourrait se passer ?
Enfin, toutes ces redondances multiplient les ambiguïtés et les risques
d'incompréhension. Si l'index d'Unicode comporte une entrée pour K et une
entrée pour kelvin, combien d'utilisateurs en concluront que le K et le
kelvin sont deux glyphes différents et s'amuseront à affubler le kelvin de
typos farfelues ?

>> Même chose pour bien des codages superflus. Combien de personnes iront
>> chercher le signe pour kelvin au lieu de taper un K ?
>
>Je suis confronté à ce pb tous les jours : si j'applique un style
>particulier aux maths, en particulier en matière d'espacement, il est
>catastrophique pour moi qu'un auteur ne balise pas ses maths (exemple
>habituel : dans le courant du texte, l'auteur saisira a en ital, tandis
>qu'une grosse formule sera faite avec l'éditeur d'équations, où on
>trouvera donc un a en mode math : ça marche en word, c'est pas
>sémantique, et ça n'est pas récupérable sans intervention manuelle dans
>un système qui distingue les maths du reste).

Je ne vois pas ce que l'implémentation dans Unicode changerait à ce
problème : au lieu d'avoir un a en ital et un a en mode math, t'auras un a
en ital et un a en mode math Unicode... Et tu amènes de l'eau à mon moulin,
là.

De plus, il me semble que le problème est pris un peu à l'envers :
Plutôt que de remplacer ton K par un &kelvin; et chaque "idéogramme
mathématique" par sa notation spécifique, ne serait-il pas plus simple de
d'encadrer tout ce qui est maths par une balise <math></math>, à charge
pour le programme d'en déduire la nature du contenu des balises ? Parce
qu'il est évident que <math>K</math> est un kelvin et <math>_a_</math> une
variable. Et ce sera cent fois plus simple à traiter et dix mille fois plus
simple à obtenir de l'auteur (par exemple, tu lui demande de souligner tout
ce qui est des maths, et tu remplaces <souligné></souligné> par
<math></math>).
Un codage est un codage, on ne va pas lui demander d'être intelligent.
C'est le rôle du programme, du format de fichier (et, éventuellement, de
l'utilisateur) d'être intelligent.
Unicode est en chantier depuis, combien ? dix ans ? et il n'est toujours
qu'une construction théorique sans usage réel. À côté de ça, HTML devient
et est en pratique un format d'échange quasi universel pour un grand nombre
de données. Qu'est-ce que tu préfères, un format de fichier intelligent,
pratique, souple et utilisable tout de suite, ou un codage absolu qui sera
opérationnel, peut-être, au quatrième millénaire ?
Ce dont on a besoin, c'est d'un codage fiable et efficace, pour lequel un K
est un K, et un format de fichier universel capable de distinguer un a ital
d'un a romain. Il me semblait que c'était le rôle de MathML...

>Pour moi, mettre le bon K, c'est assez analogue à mettre les caps, les
>petites caps, l'ital, les guilles là où il faut.
>
>Note : Ne pas surcharger microsoft de tous les maux. Le lobby le plus
>actif pour incorporer tous les signes utilisés en math dans unicode
>était constitué de mathématiciens et d'éditeurs scientifiques.

J'ai cédé à la facilité, d'accord, mais Microsoft est toujours le premier à
s'engager dans tout ce qui peut flatter les pigeons : exemple, le logo de
l'euro.

>L'argument revient à considérer essentiellement la notation mathématique
>comme idéogrammatique.

Supposons que l'on applique la logique idéogrammatique à tous les langages
scientifiques. En chimie, ça imposerait d'implémenter dans Unicode tous les
symboles d'éléments chimiques, qui ne sont pourtant constitués que de
lettres. Ensuite, on nous demandera d'implémenter tous les composés
simples. Et on s'arrête où ? aux polymères ? à la chimie organique ?
La notation idéogrammatique a des qualités pour le langage. Mais, sur le
plan pratique, il ne faudrait pas oublier que la notation alphabétique est
un énorme progrès, par la simplicité et la modularité qu'elle apporte.
C'est elle qui a permis le développement de l'imprimerie. Et un gros apport
des imprimeurs a été de simplifier le "codage" en supprimant les notations
parasites. Pourquoi vouloir revenir à un système lourd et compliqué ?

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).