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).
- Re: Unicode (suite), (continued)
- Re: Unicode (suite), Thierry Bouche (26/07/2000)
- Re: Unicode (suite), Olivier RANDIER (27/07/2000)
- Re: Unicode [Maths] (suite), Thierry Bouche (27/07/2000)
- Re: Unicode [Maths] (suite), Olivier RANDIER <=
- Re: Unicode [Maths] (suite), Thierry Bouche (28/07/2000)
- Re: Unicode [Maths] (suite), Emmanuel CURIS (29/07/2000)
- Re: Unicode [Maths] (suite), Jacques Andre (29/07/2000)
- Re: Unicode [Maths] (suite), Jacques Andre (30/07/2000)
- Re: Unicode (suite), Patrick Andries (09/08/2000)
- Re: Unicode (suite), Olivier RANDIER (10/07/2000)
- Re: Unicode (suite), Patrick Andries (10/07/2000)