Transformation de MathML en SVG par XSLT. by alex stevens

Transformation de MathML en SVG par XSLT.

M´ emoire pr´ esent´ e en vue de l’obtention du grade de licenci´ e en informatique par Alexandre Stevens.

Promoteur : Justus H. Piater

Ann´ee acad´emique 2004-2005. Version du 24 juillet 2005.

Remerciements Je remercie Justus H. Piater de m’avoir proposé ce sujet de mémoire qui me correspondait si bien. Merci pour ses bonnes idées et son aide. Je remercie également Olivier Goens, Raphaël Marée, Olivier Barnich ainsi que mon père pour le travail de relecture et les conseils de rédaction. Enfin, je remercie toutes les personnes qui m’ont soutenues durant ces années passées a` l’université et en particulier mon grand-père qui prenait, jusqu’il y a peu, de nombreuses nouvelles de l’état d’avancement de ce travail. Je suis également très reconnaissant envers mes parents et mes grand-parents qui se sont constamment préoccupés de ma scolarité et soutenus pendant toutes mes études universitaires. Merci aussi à Luca Padovani qui n’a jamais refusé de répondre à mes questions et avec qui j’ai pu échanger des réflexions intéressantes à propos de ce travail.

Rien ne se perd, rien ne se crÂ´ee, tout se transforme. Antoine-Laurent de Lavoisier, 1743-1794.

R´ esum´ e MathML1 est le langage recommandé par le W3C2 pour représenter des éléments mathématiques en XML. MathML est exporté par de nombreux outils mathématiques, et est supporté par quelques navigateurs Web (notamment, ceux basés sur Mozilla3 ), ou par des plug-ins. Cependant, il n’y a que très peu d’outils, dont pratiquement aucun logiciel libre, pour transformer du MathML en un format destiné au papier (PDF, etc.). SVG4 est le langage recommandé par le W3C pour représenter des graphiques vectoriels (Scalable Vector Graphics). SVG est exporté par de nombreux outils graphiques, et est supporté par de nombreux navigateurs soit directement, soit par moyen des plug-ins. De plus, il existe des outils pour la mise en page de textes XML pour le papier, dont notamment le logiciel libre FOP, qui traitent directement des graphiques codés en SVG. Par conséquent, une solution (pratique, flexible et générale) serait de mettre en place un outil pour transformer des formules du MathML en SVG afin de les inclure, par exemple, dans des textes à imprimer. De plus, puisque les deux langages en question sont des langages XML, il semble naturel de coder cette transformation en XSLT. Ce travail traite donc de différents dialectes XML et expose une méthode de production d’un document SVG en XSLT à partir d’un document MathML.

http http 3 http 4 http 2

://www.w3.org/Math/ ://www.w3.org/ ://www.mozilla.org/ ://www.w3.org/Graphics/SVG/

Table des mati` eres Remerciements

1 Introduction 1.1 Préliminaire . . . . . . . . . . . . . 1.2 Présentation du travail et objectifs 1.3 Présentation du problème . . . . . 1.4 Résultats obtenus . . . . . . . . . . 1.5 Structure du TFE . . . . . . . . .

. . . . .

10 10 11 12 12 13

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Language Transformations) . . . . . . . . . . . . . . . .

14 14 14 14 16 21 23 26

3 M´ ethode de production 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Une solution en deux étapes. . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Première idée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Une autre idée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Le contexte de formatage . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Du MathML vers un arbre intermédiaire à boˆıtes . . . . . . . . . . 3.3 Génération de l’arbre intermédiaire . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Création du noeud intermédiaire pour une feuille de l’arbre source 3.3.2 Description des opérations . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Création d’une boˆıte pour un noeud possédant un ou plusieurs fils 3.4 De l’arbre intermédiaire au SVG . . . . . . . . . . . . . . . . . . . . . . . 3.5 Rapidité de la transformation . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Construction de l’arbre en une seule passe . . . . . . . . . . . . . . . . . . 3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 27 27 28 28 29 30 30 31 32 33 33 34 34

2 Etude du domaine 2.1 Introduction . . . . . . . . . 2.2 Représentation des données 2.2.1 XML . . . . . . . . . 2.2.2 MathML . . . . . . 2.2.3 SVG . . . . . . . . . 2.2.4 Introduction à XSLT 2.3 Conclusion . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (eXtensible Style . . . . . . . . . .

. . . . .

` TABLE DES MATIERES

4 Particularit´ es du rendu de formules math´ ematiques 35 4.1 Le choix de la police utilis´ee . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2 Le probl`eme d’ajustement optique . . . . . . . . . . . . . . . . . . . . . . 37 5 R` egles de transformations 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 La racine du document MathML . . . . . . . . . . . . . . . . . . . . . . 5.3 mi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 mn, mtext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 ms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 mspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 mo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8 mglyph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.9 msub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10 msup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11 msubsup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.12 msqrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.13 mroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.14 mfrac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.15 munder, mover, munderover . . . . . . . . . . . . . . . . . . . . . . . . . 5.16 mrow, merror, mphantom . . . . . . . . . . . . . . . . . . . . . . . . . . 5.17 mpadded, mstyle, mfenced, mtable, mlabeledtr, mtr, mtd, maction, menclose, mmultiscripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.18 La gestion des attributs des balises du MathML . . . . . . . . . . . . . . 5.19 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. 52 . 56 . 57

6 Les 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9

. . . . . . . . .

r´ esultats Einstein . . . . . . . . . . . . . . . . . . . . . Une simple équation . . . . . . . . . . . . . . Une racine . . . . . . . . . . . . . . . . . . . . Fractions imbriquées . . . . . . . . . . . . . . Equation contenant des fractions . . . . . . . Friedman-Robertson-Walker . . . . . . . . . . Un exposant et des fractions . . . . . . . . . . Un petit mélange de divers éléments MathML Des indices . . . . . . . . . . . . . . . . . . .

7 Conclusions

. . . . . . . . .

. . . . . . . . . . . . . . . .

38 38 38 39 40 41 42 42 44 44 45 45 46 47 48 50 50

58 58 58 59 59 59 60 60 60 61 62

Table des figures 1.1 1.2 1.3 1.4

Transformation MathML en Formule quadratique . . . . Un peu de trigonom´etrie . . Fraction et exposant . . . .

2.1 2.2

Représentation de la célèbre formule d’Einstein sous forme d’arbre MathML Transformation supplémentaire à réaliser si le MathML est décrit au moyen d’un balisage de contenu. . . . . . . . . . . . . . . . . . . . . . . . SVG : L’ordonnée augmente lorsqu’on se déplace du haut vers le bas. . . . Processeur XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3 2.4 3.1 3.2 3.3 3.4

4.1

SVG . . . . . . . . .

par XSLT . . . . . . . . . . . . . . . . . .

: le chaˆınon . . . . . . . . . . . . . . . . . . . . .

manquant. . . . . . . . . . . . . . . . . . . . . .

. . . .

La transformation s’opère en deux étapes . . . . . . . . . . . . . . . . . Ensemble des boˆıtes correspondant à la formule E = mc2 . . . . . . . . Construction récursive de l’arbre intermédiaire : les noeuds du MathML (ronds) deviennent des boˆıtes (carrés) de l’arbre intermédiaire. . . . . . E = mc2 . De l’arbre intermédiaire vers le SVG. Parcours niveau par niveau en partant de la racine en créant les noeuds dans l’arbre résultat. . . . .

. . . .

12 13 13 13 17 19 22 23

. 28 . 29 . 30 . 33

Les symboles dont la taille est variable sont généralement dessinés à l’aide de symboles composés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10

Modèle s’appliquant à la racine de l’arbre MathML . . . . . . . . . . . . . Exemples simples de transformation d’un élément ’mi’. . . . . . . . . . . . Exemple de redimensionnement d’un type d’élément mo. . . . . . . . . . . Schéma aidant au calcul de la taille de la boˆıte de msub. . . . . . . . . . . Schéma aidant au calcul de la taille de la boˆıte de msup. . . . . . . . . . . Schéma aidant au calcul de la taille de la boˆıte de msubsup. . . . . . . . . Dessin du radical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schéma aidant au calcul de la taille de la boˆıte de mroot. . . . . . . . . . Schéma aidant au calcul de la taille de la boˆıte de mfrac. . . . . . . . . . . La balise mfrac dans le cas o` u le numérateur et le dénominateur ont la même largeur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.11 Schéma aidant au calcul de la taille de la boˆıte de mrow et à la compréhension de la manière dont les fils sont construits. . . . . . . . . . . . . . . . . . . 6

39 40 43 45 45 46 47 48 48 49 51

TABLE DES FIGURES 5.12 5.13 5.14 5.15

Ajustement des éléments sur une même ligne de base. . . . . . . . . . . Matrice identité 3*3 représentée en MathML. . . . . . . . . . . . . . . . Problèmes liés au calcul de la boˆıte correspondant à un élément mtable. Gestion des attributs MathML vers SVG via la balise de groupement g.

7 . . . .

51 53 55 56

Liste des tableaux 2.1

Elements de prÂ´esentation MathML. . . . . . . . . . . . . . . . . . . . . . . 20

3.1

Contexte de formatage initial de MathML . . . . . . . . . . . . . . . . . . 29

Note Ce travail a été présenté en juin 2005 et a été réussi avec la mention Grande Distinction. Les modèles XSLT, à l’heure o` u ce rapport est publié, ne sont pas encore utilisables et demandent encore un peu de développement à cause de l’envergure de MathML. Cependant, le concept est bon et prend en compte tout ce qu’il faut pour permettre de compléter l’implémentation de manière nette. Bonne lecture.

Chapitre 1

Introduction 1.1

Pr´ eliminaire

La production de documents scientifiques nécessite la possibilité d’exprimer et de manipuler une grande diversité d’objets comme du texte simple, des formules mathématiques ou des schémas. Ces données doivent pouvoir être partagées avec d’autres utilisateurs en les publiant sur un site Web ou en les pla¸cant dans des documents au format PDF1 et à terme, en permettant une impression et/ou une modification aisée de ceux-ci. Par exemple, les navigateurs les plus utilisés tels que Mozilla, Microsoft Internet Explorer ou Safari permettent d’afficher des documents écrits dans le langage HTML, le langage de balisage des sites Web. Or, l’HTML ne prend pas automatiquement en charge les formules mathématiques. Comment, dès lors, publier de tels documents sur Internet ? Le moyen actuel le plus répandu pour réaliser cette tâche est de créer ces formules via un programme d’édition d’équations (ou via un programme qui crée automatiquement ces formules en les convertissant depuis une autre représentation) et ensuite de les convertir en une image (de type bitmap2 ) affichable par un navigateur. On insère alors ces images dans une page en tant que graphique. Cette méthode pose quelques problèmes : les opérations copier/coller sont irréalisables, la qualité d’impression est assez faible, on ne dispose d’aucune interaction avec la formule, le document ne peut-être agrandi sans perte de qualité, ces formats ne sont pas standards pour le Web et pour les mathématiques. 1 2

Portable Document Format. Format de données qui se compose d’un tableau de points de couleur (généralement rectangulaire).

CHAPITRE 1. INTRODUCTION

1.2

Pr´ esentation du travail et objectifs

Le langage MathML (Mathematical Markup Language)3 a été developpé dans le but de répondre au problème du codage et de la représentation des mathématiques grâce à des balises adaptées à ce type d’information. La reconnaissance de MathML comme standard est aujourd’hui atteinte, mais son utilisation par un large public dépendra également beaucoup des logiciels d’édition et de traitement développés autour de ce langage. Ce mémoire traite de la génération automatisée, à partir d’un document source MathML, de graphiques vectoriels au format SVG4 , standard permettant de répondre aux problèmes précités. Le fait que le SVG soit très répandu et soit basé sur XML en fait un format extrêmement flexible. On cherche donc à transformer le code MathML en SVG, ce dernier opérant le rendu final pouvant être vu par l’utilisateur. Le but de ce travail est de définir une solution permettant cette transformation et de l’implémenter dans un langage non usuel : le XSLT, dialecte XML qui a été créé dans le but de transformer une structure XML en une autre structure XML. Il existe cependant d’autres solutions opérant du rendu de formules mathématiques à partir du MathML. Ces solutions utilisent la majorité du temps TEX 5 qui va à terme disparaˆıtre pour laisser la place à des chaˆınes d’outils basés sur XML. Le but de ce travail est donc de définir une solution unique qui peut être utilisée dans des contextes variés. Réaliser cette transformation en XSLT offre une grande portabilité et énormément de flexibilité. Un logiciel dédié à cette tâche existe déjà dans le domaine propriétaire : Custard6 qui réalise cette transformation (dans les langages XSLT et JAVA) moyennement bien (à cause d’une mauvaise gestion des polices). Ce programme est payant (ce qui freine sa distribution au grand public) et le code source n’est pas disponible. Un étudiant russe7 a également fait des recherches concernant cette transformation (celles-ci sont désormais à l’arrêt). Bien que la majorité des règles de transformation étaient implémentées, le rendu final était de très mauvaise qualité : la méthode fournissait une piètre gestion des placements entre les différents éléments composant la formule mathématique. 3 Noté aussi MML. Dérivé du XML. Format émergeant recommandé par le W3C (World Wide Web Consortium) - http ://www.w3c.org/ 4 SVG est le langage recommandé par le W3C pour représenter des graphiques vectoriels (Scalable Vector Graphics). SVG est exporté par de nombreux outils graphiques, et est supporté par de nombreux navigateurs et plug-ins. De plus, il existe des outils pour la mise en page de textes XML (plus précisement, XSL-FO XSL Formatting Objects) pour le papier, dont notamment le logiciel libre FOP, qui traitent directement des graphiques codés en SVG. 5 Le logiciel TEX est un traitement de texte scientifique particulièrement adapté ` a l’écriture des symboles mathématiques. 6 http ://www.schemasoft.com/MathML/ 7 http ://sourceforge.net/projects/mmltosvg

CHAPITRE 1. INTRODUCTION

MathML

XSLT SVG

PDF (transformation et formatage d'objets)

HTML

Diagramme SVG composite

Fig. 1.1 – Transformation MathML en SVG par XSLT : le chaˆınon manquant.

Un autre objectif de ce mémoire est donc de développer une alternative (au rendu le plus optimal possible) sous licence libre (et donc gratuite) à ces produits et de pouvoir fournir, à celui qui le souhaite, ces règles de transformations.

1.3

Pr´ esentation du probl` eme

Le mot mathématique est associé de manière inhérente à différents concepts : formalisation, compréhension ou sémantique. Les mathématiques, c’est aussi un langage, avec une notation visuelle complexe (et bidimensionnelle), qui a évolué au cours des différents siècles. Formater ou faire du rendu de formules mathématiques à partir d’une représentation électronique est loin d’être évident : cela peut dépendre de la sémantique de la formule mathématique, du contexte culturel, des resources disponibles (par exemple : largueur de l’écran ou largueur du document). Des problèmes particuliers se posent pour les formules mathématiques. Ces problèmes sont dˆ us à leurs structures et aux types de sous-formules qu’elles peuvent contenir : fractions, matrices, intégrales, ou même exposants ou indices. Ce rapport doit montrer le processus utilisé pour formater le MathML en SVG via XSLT. Ce processus doit répondre aux différents problèmes précités.

1.4

R´ esultats obtenus

Voici quelques exemples (basiques) de formules générées à partir de ce travail. Vous retrouverez plus d’exemples dans la suite de ce document. – La police utilisée est celle de TEX (définie dans le SVG) ; – l’image est au format SVG (et donc vectorielle, ce qui permet de l’agrandir ou la réduire proprement et d’imprimer celle-ci avec une haute qualité ou de l’intégrer, comme le démontrent ces exemples, avec une qualité de rendu proche de TEX dans un document PDF) ; – la taille de l’image est proportionnelle à la formule qu’elle contenait.

CHAPITRE 1. INTRODUCTION

Fig. 1.2 – Formule quadratique

Fig. 1.3 – Un peu de trigonom´etrie

Fig. 1.4 – Fraction et exposant

Ce travail tente de s’approcher au plus pr`es de la qualit´e de rendu des formules de TEX .

1.5

Structure du TFE

Dans ces pages, nous allons donc parler : – de langages de balisages, d’applications XML ; – de typographie numérique, de mise en page, de métrique de polices ; – d’une formalisation de mise en page ; – de XSLT, langage permettant la transformation. La première étape fut d’expliquer brièvement ce que sont le XML, MathML, SVG et XSLT : les bases de ce travail. Ensuite, la méthode de production du graphique vectoriel SVG est expliquée. Les différentes étapes de transformations sont présentées, ainsi que la manière dont la tâche a été réalisée tout en précisant toutes les phases du développement. Ce rapport se clôture par quelques exemples.

Chapitre 2

Etude du domaine 2.1

Introduction

Pour bien comprendre ce mémoire et l’application développée, il est nécessaire d’être familier avec l’univers XML, technologie standard qui peut être exploitée pour l’encodage, la communication et la maintenance de documents structurés. En effet, on veut transformer du MathML en SVG. Ces langages sont des applications (ou dialectes) du XML : les règles du XML ont été appliquées pour créer le langage MathML et le langage SVG. Nous allons donc commencer par présenter le XML. Nous présenterons ensuite chacun de ces langages. On terminera par une présentation de XSLT, langage qui permet, comme nous l’avons déjà signalé au chapitre précédent, de modifier une structure XML en une autre structure XML.

2.2 2.2.1

Repr´ esentation des donn´ ees XML

Nous allons, dans cette sous-section, dessiner une petite description de XML. Si vous n’êtes pas familier avec ce standard, mieux vaut vous rapporter à des ouvrages traitant de manière plus détaillée de ce sujet. XML est l’acronyme de eXtensible Markup Language (langage de balisage1 extensible). Ce standard dispose d’une structure hiérarchique qui permet de représenter des documents et leurs structures. Ce langage, ainsi que ses librairies, sont décrits par des recommandations publiées par le W3C. Sa syntaxe lui permet de définir d’autres langages de description plus spécifiques (le MathML pour les formules mathématiques par exemple). L’intérêt du XML est de contenir la définition de la structure du document à l’intérieur de ce même document. XML décrit donc uniquement une structure et la 1 Le plus utilisé et répandu d’entre-eux est le HTML (attention : l’HTML n’est pas un dialecte XML, juste un langage de balisage).

CHAPITRE 2. ETUDE DU DOMAINE

signification du contenu d’un document. Dès lors, des programmes peuvent traiter ces documents de manière très flexible : – Aucune connaissance d’un langage spécifique préalable n’est requis. – Il est facile de les éditer, les valider, accéder à une sous-partie des documents, les manipuler, les construire ou les transformer. Ce langage descriptif permet donc de créer, selon les besoins, des balises utiles à un document. D´ efinition de la structure d’un document XML Un document XML doit respecter des règles. Nous allons vous en présenter quelques unes : 1. Le document doit commencer par la déclaration XML. 2. Les éléments contenant des données doivent avoir une balise ouvrante et une balise fermante. 3. Les éléments vides ne comportant qu’une balise doivent la clore par />. 4. Le document doit contenir un et un seul élément racine qui est le parent des autres. 5. Les éléments peuvent s’imbriquer mais pas se chevaucher. 6. Les valeurs des attributs doivent être délimités par des guillemets (ou des apostrophes). 7. Les méta-caractères < et & ne doivent être utilisés que pour démarrer respectivement une balise et une référence d’entité2 . On remarque donc qu’un document XML est bien plus strict qu’un document HTML. XML est composé de deux niveaux de conformité : 1. Pour la bonne formulation : critère minimum afin de permettre la lecture d’un fichier XML. Un programme analysant un document XML ne peut corriger celuici : c’est interdit par la spécification du XML. 2. Pour la validité : le concepteur d’un document XML doit avoir la possibilité d’imposer à l’auteur d’un document des règles de structuration qu’il aura défini. C’est le rôle de la DTD3 qui a pour but de définir ces règles. Il existe cependant deux alternatives : – Définir ces règles à partir de schémas (définis en) XML. On peut contrôler, via ces schémas, plus finement la DTD. – Utiliser Relax-NG. Ce dialecte XML permet de définir précisément les différentes contraintes qui déterminent la classe de documents XML qui peuvent passer l’étape de validation. 2 Les entités sont des substituts pour des séquences d’informations. Ces entités doivent être définies dans l’entête du document XML, ou dans la DTD (présentation de la DTD ci-après), et peuvent être référencées ` a une ou plusieurs reprises dans le document. 3 Document Type Definition

CHAPITRE 2. ETUDE DU DOMAINE

2.2.2

MathML

Pr´ eliminaire Maintenant que l’on a introduit le XML, on peut introduire le MathML qui est une application de notation mathématique. MathML, actuellement dans sa recommandation 2.0 (21 février 2001), a pour but d’identifier à la fois la typographie et/ou le sens mathématique d’une expression. Il dispose, comme tout dialecte XML, d’une DTD. Un petit exemple pour comprendre Une fraction est constituée d’un numérateur et d’un dénominateur. MathML fournit donc une balise <mfrac> qui contient deux balises pouvant être de tout type. La première représente obligatoirement le numérateur, la deuxième représente obligatoirement le dénominateur. a b

s’´ecrit :

<mfrac> <mi>a</mi> <mi>b</mi> </mfrac> Repr´ esentation d’un document MathML sous la forme d’arbre Prenons la célèbre formule d’Einstein E = mc2 . On peut la représenter par le document MathML suivant : <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE math PUBLIC "-//W3C//DTD MathML 2.0//EN" "dtd/mathml2.dtd"> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" id="mymath"> <mrow> <mi>E</mi> <mo>=</mo> <mrow> <mi>m</mi> <msup> <mi>c</mi> <mn>2</mn> </msup> </mrow> </mrow> </math>

CHAPITRE 2. ETUDE DU DOMAINE

On peut assimiler les expressions MathML à des arbres, dont chaque noeud correspond à un élément MathML, dont chaque branche sous un noeud père correspond aux fils de celui-ci. Les noeuds terminaux de l’arbre correspondent à une notation atomique ou à des unités de contenu4 .

math

mrow

msup

Fig. 2.1 – Représentation de la célèbre formule d’Einstein sous forme d’arbre MathML

El´ ements de pr´ esentation et de contenu MathML Il y a deux types d’éléments MathML : ceux qui concernent la présentation et ceux qui concernent le contenu. La majorité des éléments MathML sont constitués d’une balise ouvrante et d’une balise fermante, qui englobent à leur tour le balisage de leur contenu. Dans le cas des atomes, il s’agit d’un contenu de données textuelles. Dans la majorité des autres cas, le contenu est formé du balisage des fils.

Eléments mi, mn et mo pour ce qui concerne les éléments de présentation ; ci, cn et csymbol pour les éléments de contenu (nous reviendrons sur ce point dans la suite).

CHAPITRE 2. ETUDE DU DOMAINE

Une forme de balisage de pr´ esentation pour (a + b)2 . <mrow> <msup> <mfenced> <mrow> <mi>a</mi> <mo>+</mo> <mi>b</mi> </mrow> </mfenced> <mn>2</mn> </msup> </mrow> Les éléments de présentation permettent la construction de la notation mathématique traditionnelle5 . Ces éléments sont indépendants du médium : ils ont été con¸cus pour contenir suffisamment d’informations pour leur bon rendu sous différentes formes. Une forme de balisage de contenu pour (a + b)2 . <mrow> <apply> <power/> <apply> <plus/> <ci>a</ci> <ci>b</ci> </apply> <cn>2</cn> </apply> </mrow> Les opérations mathématiques existent et sont signifiantes pour de nombreuses applications de manière absolument indépendante de leurs rendus. L’objectif du balisage de contenu est de fournir un codage explicite de la structure mathématique d’une expression (et non pas un rendu particulier). Les balises de pr´ esentation de MathML Le balisage de présentation MathML (celui que nous transformons dans ces pages) consiste en une trentaine d’éléments qui acceptent plus de 50 attributs6 . Pour chaque 5 Proche des symboles et des structures de construction d’expression de base ` a partir desquels toute expression mathématique est construite. 6 La spécification complète du langage MathML est définie sur le site du W3C http ://www.w3.org/Math/.

CHAPITRE 2. ETUDE DU DOMAINE

balise (ou, par analogie avec un arbre : pour chaque noeud), il faut établir une règle de transformation vers SVG. Là est la difficulté de ce travail : trouver le moyen de faire cohabiter 30 éléments (présenté sous forme de tableau ci-après) et étudier la spécification du MathML, de ses balises et de ses attributs en profondeur7 .

Le choix du balisage de pr´ esentation du MathML Le choix a été fait de ne convertir que les éléments de présentation de MathML vers le SVG. En effet, celui-ci ayant pour but d’aider les personnes souhaitant faire du rendu de formules, c’est précisément ce balisage qui peut permettre de réaliser au mieux la transformation. Ce mémoire ayant pour titre Transformation de MathML en SVG par XSLT, nous nous devions toutefois de justifier un peu plus ce choix. Après quelques recherches sur Internet, j’ai découvert8 la présence de modèles XSLT permettant de transformer le balisage de contenu en un balisage de présentation MathML. Dès lors, une personne souhaitant utiliser la transformation expliquée dans ce travail, mais ayant décrit sa formule mathématique en un balisage de contenu, pourrait d’abord opérer une première transformation vers un balisage de présentation (cMML vers pMML). Cette transformation a évidemment un coˆ ut et il pourrait être envisagé d’appliquer les règles de transformations (expliquées dans ce document) à ce type de balisage. Ce choix a été fait afin de limiter, dans ce travail, le nombre de règles de transformations à réaliser. MathML (contenu)

mmlCtoP.xsl

MathML (présentation)

pMML2SVG.xsl

SVG

Fig. 2.2 – Transformation supplémentaire à réaliser si le MathML est décrit au moyen d’un balisage de contenu.

Dans le tableau ci-après, on y parle de glyphe. Un glyphe est une représentation graphique (parmi une infinité possible) d’un signe typographique. Il est également ` a noter que seuls les éléments mi, mn, mo, mtext et ms peuvent contenir du texte. En ce qui concerne la notation, 1∗ sous-entend l’ajout automatique d’une balise mrow si le nombre d’arguments est ≥ 1 (on dit alors que le mrow est inféré ). 8 Sur le site de l’Ontario Research Centre for Computer Algebra, http ://www.orcca.on.ca/

CHAPITRE 2. ETUDE DU DOMAINE Element

Arguments

Exemple

mi mn mo mtext ms mspace mglyph

Nombre d’arguments -

x 2 &#x2295; string string -

x 2 ⊕ string string

mrow

0 ou plus

x1 . . . xn

mfrac msqrt mroot mstyle

2 1* 2 1*

xy x xn x

merror mpadded

1* 1*

x x

mphantom

mfrenced

0 ou plus

x1 . . . xn

menclose

msub msup msubup

2 2 3

xa xb xab

munder mover

2 2

xa xb

munderover

xab

mmultiscripts

1 ou plus

x(ai bi ) ∗ (cj dj )∗

mtable mlabeledtr

0 ou plus 1 ou plus

r1 . . . r n ld1 . . . dn

mtr mtd maction

0 ou plus 1* 1 ou plus

d1 . . . d n x x1 . . . xn

Description

identifiant nombre operateur texte texte entre guillemets espace vide ℘ glyphes dépendant du système x1 . . . xn aligne n sous-expressions sur une même ligne de base x , x/y fraction y √ x racine carrée √ n x racine avec index x changement du style de l’argument x encadrement de l’argument x ajustement de l’espacement autour d’un élément contenu invisible (cache l’argument) mais taille respectée (x1 , . . . , xn ) ajout de parenthèses et de séparateurs à des sousexpressions utilisation de notation pour un argument xa indice inférieur xb indice supérieur b xa paire d’indices inférieurs et supérieurs indice sous un élément indice au-dessus d’un élément paire d’indices en-dessous et au-dessus d’un élément pré-indices et indices tensorielles table ou matrice d1 . . . dn (l) ligne d’une table avec un label d1 . . . d n ligne d’une table x cellule d’une table xi actions accociées à une sousexpression

Tab. 2.1 – Elements de pr´esentation MathML.

CHAPITRE 2. ETUDE DU DOMAINE

2.2.3

SVG

Choisir le format SVG pour faire du rendu de formules mathématiques présente plusieurs avantages : – Rendu vectoriel : possibilité de mettre à l’échelle une image sans aucune perte de qualité (une image vectorielle est définie par une fonction mathématique). – Style adaptable. – Compressibilité élevée. – Les éléments graphiques sont des objets hiérarchiques. – Création de document interactifs : grâce au SVG, il est possible de de mixer formules et diagrammes. – Conversion facile : vers du vectoriel (PostScript), vers tout type d’image, vers d’autres dialectes XML. – Facile à imprimer et à inclure dans un document PDF (car il existe de nombreux logiciels permettant de convertir du SVG en PDF). – Facile à intégrer dans un site Internet. Un point important à souligner ici est que l’utilisateur doit posséder des polices systèmes pour le rendu des formules mathématiques en SVG. Cela peut présenter un avantage au niveau de la portabilité du SVG mais dans notre cas, on pourrait voir cela comme une restriction. Le placement des éléments mathématiques, dans le cadre de ce travail, est totalement dépendant de la métrique des caractères utilisés. Dès lors, si un utilisateur ne possède pas la police de caractères spécifiée dans le document SVG, il va la substituer par une autre. Dans le cas o` u la métrique de la police substitut est différente, cela pourrait conduire à divers problèmes lors du rendu, chaque élément étant placé dans l’image vectorielle à l’aide de coordonnées absolues. Le choix a donc été fait de définir une police à l’intérieur même du document SVG. Nous reviendrons sur ce point et sur le choix de la police utilisée dans le chapitre 4. Notons aussi qu’il existe de nombreux logiciels permettant de créer et d’éditer du SVG. Pour exemple, soulignons la présence, en Open Source, de Inkscape9 . Dans le domaine propriétaire, certains logiciels d’Adobe Systems Incorporated10 (Illustrator par exemple) permettent également l’édition et la création de tels documents. Il faut également savoir que SVG est disponible sur tout type de plate-forme : PC (Linux, Windows), MAC (Mac Os X), PDA, etc. Syst` eme de coordonn´ ees SVG Nous allons parler, dans cette section, d’une particularité importante de SVG pour comprendre la suite de ce document. 9 10

http ://www.inkscape.org/ http ://www.adobe.fr/

CHAPITRE 2. ETUDE DU DOMAINE

Dans le système cartésien, la valeur de la coordonnée x augmente de la gauche vers la droite, alors que la valeur de la coordonnée y augmente du bas vers le haut du graphique. SVG n’utilise pas cette convention et inverse la direction de l’axe des ordonnées. De cette fa¸con, le point (0,0) est placé dans le coin supérieur gauche et la coordonnée y augmente lorsqu’on se déplace du haut vers le bas. (0,0)

Fig. 2.3 – SVG : L’ordonnée augmente lorsqu’on se déplace du haut vers le bas. SVG dispose cependant d’un outil puissant pour transformer le système de coordonnées et l’adapter aux besoins des applications. Il est donc possible de travailler avec des coordonnées locales. El´ ements SVG Il faut se référer à la spécification du W3C pour connaˆıtre tous les détails des balises du SVG. Nous allons ici montrer quelques exemples utiles pour la suite de ce document. SVG définit quelques dizaines d’attributs que l’on peut appliquer à certains éléments. Par exemple : – stroke définit comment le bord d’un objet est peint – fill définit comment le contenu d’un objet est peint On trace une ligne dans un document SVG à l’aide de la balise <line> ayant au minimum 4 attributs : x1, y1 et x2, y2. Ces attributs correspondent aux coordonnées du point de départ et du point d’arrivée. La balise <text> entraˆıne le rendu d’une chaˆıne de texte. Un texte est un objet graphique : on peut appliquer les fonctions de transformation de système de coordonnées, de peinture, de rognage et de masquage ainsi qu’un style CSS11 . Le texte suit les recommandations générales des caractères XML et n’effectue ni retour à la ligne ni césure automatique. La balise <tspan> permet, par exemple, d’afficher un texte sur plusieurs lignes. Il faut alors précalculer les retours à la ligne et employer une seule balise <text> avec un 11

CSS (Cascading Style Sheets : feuilles de style en cascade) est utilisé pour décrire la présentation d’un document structuré écrit en HTML ou en XML. Nous utiliserons cette application XML dans la suite de ce document.

CHAPITRE 2. ETUDE DU DOMAINE

ou plusieurs fils <tspan> ainsi que des valeurs adéquates pour les attributs x, y (coordonnées absolues12 ) et dx, dy (coordonnées relatives13 ). La balise <g> permet de regrouper des éléments qui vont ensemble. Les fils de cette balise héritent de ses propriétés. En SVG, les longueurs sont indiqués soit par un nombre, soit par des unités absolues ou relatives. – Les unités relatives sont em, ex et px (le pixel14 ). Si aucune unité n’est spécifiée dans le document SVG, alors c’est le px qui est utilisé. em et ex sont relatifs à la police de référence : 1 em est égal à la taille de cette police, tandis que 1 ex est la hauteur du x dans cette police. – Les unités absolues sont pt (le point), pc (le pica), cm (le centimètre), mm (le millimètre) et in (le pouce)15 .

2.2.4

Introduction ` a XSLT (eXtensible Style Language Transformations)

Le langage XSLT apporte de la souplesse aux documents XML en permettant de générer diverses sorties en divers formats. Il permet de réorganiser complétement des arbres XML. XSLT permet de rester dans la continuité des langages XML.

source XML (dans notre cas : MathML)

processeur XSLT

Résultat (dans notre cas : SVG)

Règles XSLT (objectif de ce mémoire)

Fig. 2.4 – Processeur XSLT On va vu qu’un document XML peut être représenté comme une structure arborescente. Ainsi, XSLT permet de transformer les documents XML à l’aide de feuilles de 12

Les coordonnées absolues permettent de positionner un élément indépendamment des autres. Les coordonnées relatives indiquent le décalage par rapport ` a un autre élément. 14 Le pixel est l’unité atomique d’une image numérique. Son nom provient de l’expression anglaise picture element, c’est-` a-dire, élément d’image. 15 (1 in = 2,54 cm = 25,4 mm = 72 pt = 6 pc) 13

CHAPITRE 2. ETUDE DU DOMAINE

style contenant des règles appelées template rules ou modèles de transformation. La structure globale d’un fichier XSLT a la forme : <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> ... <xsl:template match="..."> ... </xsl:template> ... </xsl:stylesheet> XSLT distingue 7 types de noeuds (ou balises) : – La racine du document – Les éléments. – Les attributs. – Les noeuds texte. – Les commentaires . – Les instructions de traitement <?...?>. – Les définitions d’espaces de nom. L’élément <xsl:template ...> définit une règle de transformation. Son attribut match="..." spécifie les noeuds auxquels s’applique la règle : la valeur / désigne la racine du document16 . Le langage est basé sur des sélections d’objets typés <xsl:apply-templates> auxquels on applique une transformation <xsl:template>. L’attribut select de l’élément <xsl:apply-templates> spécifie l’ensemble des noeuds à traiter. C’est à partir de la racine du document d’entrée que sont effectuées des sélections puis les transformations. Chaque modèle de transformation définit des traitements à effectuer sur un élément (noeud ou feuille) de l’arbre source. XSLT permet, entre-autre, de : – Créer de nouveaux éléments dans la cible : <xsl:element>, <xsl:attribute> et <xsl:attribute-set> – Générer du texte : <xsl:text> – Générer des sous-arbres issus de la source : <xsl:copy> – Effectuer des commandes de choix : <xsl:if> et <xsl:choose> 16

Grˆ ace ` a la notation XPath (autre recommandation du W3C), on peut choisir les ´el´ements du document XML sur lesquels s’applique la transformation.

CHAPITRE 2. ETUDE DU DOMAINE

– – – – – – –

Déclarer des variables : <xsl:variable> et <xsl:param> Déclarer des listes d’objets identifiés : <xsl:key> Utiliser les listes d’objets identifiés dans les transformations : <key> Parcourir un ensemble d’éléments : <xsl:for-each> Trier un ensemble d’éléments : <xsl:sort> Modulariser les feuilles de styles en différents fichiers <xsl:import> et <xsl:include> Modulariser les feuilles de styles en modules de traitement factorisés : <xsl:call-template> et <xsl:with-param> – Contrôler le type d’écriture de la sortie <xsl:output>, <xsl:strip-space> et <xsl:preserve-space> XSLT : un langage r´ ecursif ! XSLT étant un langage permettant d’appeler récursivement des noeuds d’un arbre et de leur appliquer des règles de transformation, c’est récursivement qu’il faut penser. Ce langage de programmation est très particulier et très spécifique au XML. Pour vous donner une idée : les variables en XSLT ne peuvent être modifiées une fois déclarées. On ne peut donc utiliser que des constantes (pas d’incrémentation possible donc). Dès lors, faire une boucle (avec, par exemple, une variable qui s’incrémente) en XSLT n’est pas quelque chose d’évident ! Ce langage permet uniquement des algorithmes récursifs, et non pas itératifs. Voici comment, en XSLT, on pourrait simuler une boucle ayant comme arguments $debut et $fin. Ces valeurs, si elles ne sont pas précisées lors de l’appel du modèle, sont par défaut à 0. Cette boucle aura pour but d’afficher les nombres compris entre les deux valeurs passées en argument (le premier nombre étant compris dans l’affichage, le dernier ne l’est pas). Vous trouvez que le &lt; est bizzare ? Tout ceci reste du XML, et donc le caractère < ne peut pas s’écrire tel quel. <xsl:template name="boucle"> <xsl:param name="debut" select="0" /> <xsl:param name="fin" select="0" /> <xsl:text>i = </xsl:text> <xsl:value-of select="$debut" /> <xsl:text>; </xsl:text> <xsl:if test="$debut &lt; $fin"> <xsl:call-template name="boucle"> <xsl:with-param name="debut" select="($debut)+1" /> <xsl:with-param name="fin" select="$fin" /> </xsl:call-template> </xsl:if> </xsl:template>

CHAPITRE 2. ETUDE DU DOMAINE

A l’aide d’un transformateur XSL (XSLT), on peut modifier la structure d’un document XML. La feuille de style regroupe un ensemble de règles de transformations qui vont s’appliquer au document. Un transformateur XSL prend en argument, comme nous l’avons vu, deux fichiers. L’application de la transformation crée un nouveau fichier dont la structure est créée selon les règles (ou modèles) des feuilles de styles, les données et la structure XML (dans notre cas, du MathML). Rappelons ici, plus en détail, la lecture parallèle des deux fichiers (source et de transformation) dans le cadre d’une transformation via XSLT : – Construire le document d’entrée en mémoire (souvent il est lu sur le disque). Le point de départ est la racine du document MathML. – Opérer une recherche dans l’ensemble des modèles XSLT afin d’en trouver un que l’on pourrait appliquer. Si un modèle reconnaˆıt la racine, il est appliqué. – Le modèle essaie ensuite d’appliquer récursivement d’autres modèles au reste du document.

2.3

Conclusion

Il a fallu apprendre et maˆıtriser toutes ces applications XML : MathML, SVG, XSLT, XPath, CSS, etc.

Chapitre 3

M´ ethode de production 3.1

Introduction

Ce chapitre a pour but d’expliquer la méthode de production, sans entrer dans les détails des règles spécifiques (de chaque balise de l’arbre d’entrée), d’un document SVG à partir d’un fichier MathML.

3.2 3.2.1

Une solution en deux ´ etapes. Premi` ere id´ ee

La première idée a été de fonctionner en coordonnées relatives, en n’opérant qu’une seule passe sur le fichier d’entrée. Cette solution, une fois réalisée, présentait de nombreux problèmes. Dans cette réalisation, chaque élément n’est pas indépendant des autres vu que l’on travaille en coordonnées relatives. En effet, par exemple, le fait de mettre un caractère sous forme d’exposant décalait la suite du document. Le problème vient du fait qu’il n’est pas aisé de dire au reste du document de revenir s’aligner sur sa ligne de base après avoir opéré le rendu l’exposant. Pour tracer une barre fraction dans le document SVG, cela est réalisé via une balise contenant ses coordonnées, celles-ci étant calculées en fonction de la position courante dans l’image en cours de création, du contenu du numérateur et de celui du dénominateur de la fraction. Or, XSLT ne nous permet pas d’obtenir directement ces données. Il était également impossible de connaˆıtre la taille (hauteur et largeur) de la formule à priori et donc d’initaliser le document SVG à la bonne taille. Cette méthode a donc été abandonnée et son code a été envoyé aux oubliettes. Cette méthode présentait toute fois certains avantages : nul besoin de se soucier des problèmes liés à la métrique de la police utilisée (nous y reviendrons plus tard) car les caractères étaient placés l’un à la suite des autres avec une valeur d’attributs décrivant une position relative. Dès lors, tous les problèmes de placement dus à la métrique des

´ CHAPITRE 3. METHODE DE PRODUCTION

polices était réglé par le moteur de rendu SVG.

3.2.2

Une autre id´ ee

Le but final de ce travail est d’obtenir une représentation qui contient l’information à propos – des glyphes nécessaires, – de leur taille, – de leur position dans le document final, – de leurs autres attributs (couleurs, etc.). Pour réaliser cette tâche et éviter les problèmes précités, la deuxième idée a été de procéder en deux étapes : 1. Transformer l’arbre source MathML en un arbre intermédiaire de formatage MathML. 2. Parcourir l’arbre intermédiaire construit et le convertir en un arbre SVG.

arbre MathML

Le parcours de cet arbre produit

un arbre MathML dont chaque balise possède un contexte de formatage

Le parcours de cet arbre produit

un arbre SVG

Fig. 3.1 – La transformation s’op`ere en deux ´etapes

L’idée est d’ajouter à chaque noeud de l’arbre source un contexte de formatage défini par un ensemble d’attributs. Ainsi, les éléments de présentation MathML1 peuvent être vus comme des éléments de formatage ayant un effet sur le document de sortie. Ces éléments dépendent : – de leur contexte, – de leurs attributs, – de leurs enfants.

3.2.3

Le contexte de formatage

Le contexte de formatage doit donc être défini tel qu’il puisse fournir un certain nombre d’informations : – La taille de la police là o` u le formatage est en cours. 1 mi, mn, mi, mtext, ms, mspace, mrow, mstyle, mphantom, merror, mfenced, menclose, msqrt, mroot, mfrac, msub, msup, msubsup, multiscripts, munder, mover, munderover, mtable, mtr, mlabeledtr, mtd, maligngroup, malignmark, maction, etc.

´ CHAPITRE 3. METHODE DE PRODUCTION

– La position (relative) courante dans le formatage en cours. Dès lors, nous définissons le contexte de formatage de MathML comme étant une structure contenant un certain nombre de champs : Nom size minSize

Valeur par d´efaut

sizeMult

0,71

x y

0 0

Description taille de la police taille minimale de la police (constante définie globalement) nombre par lequel la taille de la police est multiplié lorsque le niveau est augmenté de 1 (constante définie globalement) position par rapport à l’origine (abscisse) position par rapport à l’origine (ordonnée)

Tab. 3.1 – Contexte de formatage initial de MathML

3.2.4

Du MathML vers un arbre interm´ ediaire ` a boˆıtes

L’idée qui a été retenue dans le cadre de ce travail a été de créer un arbre intermédiaire composé (conceptuellement) de boˆıtes. La deuxième étape a pour but d’ajuster son formatage et de l’afficher. Cet arbre à boˆıtes est obtenu, dans ce cas-ci, à partir de l’arbre source MathML. Reprenons, par exemple, la célèbre formule d’Einstein (E = mc2 ), dont la présentation sous forme d’arbre MathML a été présentée dans le chapitre précédent. mrow mi

mrow mo

msup mi

Fig. 3.2 – Ensemble des boˆıtes correspondant à la formule E = mc2 On peut voir sur la figure que chaque noeud de l’arbre source MathML correspond a` un noeud de l’arbre intermédiaire, pouvant maintenant représenter une sorte d’arbre de boˆıtes. La structure hiérarchique du MathML est également préservée. Il est heureux qu’il en soit ainsi : le balisage de présentation a été créé pour cela. L’objectif de ce premier parcours est donc de définir la position (relative ou absolue), la largeur et la hauteur de ces boˆıtes.

´ CHAPITRE 3. METHODE DE PRODUCTION

3.3

G´ en´ eration de l’arbre interm´ ediaire

On peut voir deux types de transformations : – celles qui concernent les feuilles de l’arbre (les seuls éléments pouvant contenir du contenu autre que des attributs), – et celles qui concernent les noeuds possédant des fils dans l’arbre MathML.

Fig. 3.3 – Construction récursive de l’arbre intermédiaire : les noeuds du MathML (ronds) deviennent des boˆıtes (carrés) de l’arbre intermédiaire.

3.3.1

Cr´ eation du noeud interm´ ediaire pour une feuille de l’arbre source

Nous allons définir maintenant les opérations séquentielles propres à la création d’un noeud intermerdiaire pour une feuille de l’arbre MathML d’entrée. 1. Récupérer le contexte du noeud parent. 2. Déclarer dans une variable le nom du noeud local. 3. Placer dans une variable la longueur de la chaˆıne de caractères. 4. Modifier le contexte re¸cu selon le type de noeud courant. 5. Traiter les attributs de la feuille de l’arbre. 6. Calculer la hauteur et la largeur de la boˆıte entourant ce(s) caractère(s). 7. Sauver le nouveau contexte et les attributs dans l’arbre intermédiaire.

´ CHAPITRE 3. METHODE DE PRODUCTION

3.3.2

Description des op´ erations

Dans les cas triviaux, seul le code est donné. Dans des cas plus complexes, une brève explication est donnée. R´ ecup´ erer le contexte du noeud parent : <xsl:param name="size"/> <xsl:param name="x"/> <xsl:param name="y"/> D´ eclarer dans une variable le nom du noeud local : <xsl:variable name="localName"> <xsl:value-of select="local-name(.)"/> </xsl:variable> Placer dans une variable la longueur de la chaˆıne de caract` eres : <xsl:variable name="contentLen"> <xsl:value-of select="string-length(.)"/> </xsl:variable> Modifier le contexte re¸ cu selon le type de noeud courant, traiter les attributs de la feuille de l’arbre, calculer la hauteur et la largeur de la boˆıte entourant ce(s) caract` ere(s) : Par exemple, pour introduire ce point, notons que la police peut-être spécifiée comme devant être ’normale’ pour les nombres, alors qu’elle doit passer en mode ’italique’, dans certains cas, pour une lettre de la formule. La largeur ainsi que la hauteur des boˆıtes varie selon la métrique de la police représentant le caractère. Afin de permettre un meilleur rendu visuel, le caractère 2 possède une taille inférieure au C, précisément 0.71 ∗ cHeight o` u cHeight représente ici le hauteur du caractère C. Nous développerons ces points, précisément, dans le chapitre 5. Sauver le nouveau contexte et les attributs dans l’arbre interm´ ediaire : <xsl:copy> <xsl:copy-of select="@*"/> <xsl:attribute name="t:X"><xsl:value-of select="$x"/> </xsl:attribute> <xsl:attribute name="t:Y"><xsl:value-of select="$y"/></xsl:attribute> <xsl:attribute name="t:FONTSIZE"><xsl:value-of select="$size"/></xsl:attribute> ... </xsl:copy>

´ CHAPITRE 3. METHODE DE PRODUCTION

Si l’on reprend notre figure précédente, nous venons de sauver des attributs pour les caractères E, =, m, c et 2 de la formule d’Einstein.

3.3.3

Cr´ eation d’une boˆıte pour un noeud poss´ edant un ou plusieurs fils

Nous allons maintenant devoir calculer la taille de boˆıtes entourant (autrement dit, étant noeud parent dans l’arbre hiérarchique) les boˆıtes créées. Cela se fait récursivement à partir des boˆıtes créées pour les noeuds feuilles. 1. Récupérer le contexte re¸cu du noeud parent. 2. Construire les boˆıtes des fils en leur fournissant un contexte spécifique selon la nature du noeud courant2 . Créer un pointeur repérant les boˆıtes des fils. 3. Regarder si l’élément contient des attributs spéciaux. 4. Calculer la hauteur et la largeur de la boˆıte entourant les fils. 5. Garder, si besoin, des attributs permettant d’améliorer le placement des fils. 6. Sauver le nouveau contexte et les attributs dans l’arbre intermédiaire. Dans l’arbre intermédiaire, nous avons donc sauvé les attributs de la boˆıte entourant le c et le 2 (balise <msup>) ainsi que les attributs des deux balises <mrow> contenus dans le fichier MathML. La largeur et la hauteur de la balise <mrow> entourant toute la formule permettent de connaˆıtre la taille de l’image de sortie à générer. La majorité de ces opérations ont été expliquées au point précédent. Les étapes non expliquées dans cette section sont celles qui concernent la construction de chaque balise de l’arbre source MathML. Chaque balise possède sa propre spécification et donc, une transformation bien précise. Cette construction est le sujet du chapitre 5. Nous y détaillerons donc ces opérations. Remarque ` a propos de la construction On voit donc tout le caractère récursif de la construction : – on construit les élements fils ; – une fois construits, on peut accéder à l’information calculée contenue à l’intérieur de ceux-ci ; – une fois cet arbre intermédiaire construit, nous avons dans la racine de l’arbre (et dans l’arbre) toutes les informations nécessaires à la génération du fichier de sortie SVG.

´ CHAPITRE 3. METHODE DE PRODUCTION

math

svg

mrow

mi (E)

mo (=)

mrow text (E) mi (m)

text (=)

text (m)

text (c)

text (2)

msup

mi (c)

mn (2)

Fig. 3.4 – E = mc2 . De l’arbre intermédiaire vers le SVG. Parcours niveau par niveau en partant de la racine en créant les noeuds dans l’arbre résultat.

3.4

De l’arbre interm´ ediaire au SVG

Le parcours de l’arbre intermédiaire se fait lui aussi récursivement en partant de la racine du document. Chaque noeud parent opère son propre rendu si besoin et demande à son ou ses fils (s’il en possède) d’effectuer lui (eux) aussi son rendu vers le document SVG. Chaque noeud possède un certain nombre d’attributs permettant de produire son (leur) rendu de manière appropriée. Ces appels récursifs, concernant ce parcours final, se font à l’aide de paramètres supplémentaires, qui permettent d’ajuster, si besoin en est, la position (coordonnées x,y) du noeud appelé. En effet, certaines coordonnées relatives doivent devenir absolues : nous reviendrons également sur ce point dans le chapitre 5.

3.5

Rapidit´ e de la transformation

La complexité de l’algorithme opérant la transformation se pose assez vite. Le style de programmation XSLT étant fortement imposé, il est difficile d’opérer des optimisations telles que l’ont pourrait opérer dans un language itératif classique. L’optimisation d’une feuille de transformation XSLT depend surtout du transformateur : certains sont plus rapides sur certaines opérations. Le complexité3 de la transformation décrite dans ces pages est de l’ordre N (N étant 2 Par exemple, pour la balise <msup> : la règle est de construire le fils ` a gauche ’normalement’ et d’ensuite placer le fils ` a droite selon la largeur prise par le fils ` a gauche et selon la taille de la police du fils ` a gauche) 3 L’analyse de la complexité consiste ` a déterminer une fonction associant un coˆ ut (en unité de temps

´ CHAPITRE 3. METHODE DE PRODUCTION

le nombre de noeuds faisant partie de l’arbre d’entr´ee MathML). En effet, la construction du document final se fait lin´eairement.

3.6

Construction de l’arbre en une seule passe

La deuxième passe ayant pour but principal de transformer des coordonnées relatives en coordonnées absolues, le choix aurait pu être fait de générer l’arbre SVG en une seule fois, en pla¸cant dans l’arbre de sortie des valeurs permettant de déplacer les éléments et de laisser le calcul des coordonnées absolues au moteur de rendu SVG. Cette solution aurait mené à un document de sortie moins propre car augmenté de nombreux nouveaux noeuds4 . Le choix a été d’intégrer tous ces calculs directement dans la méthode de production. Cette solution en deux étapes permettait surtout, lors de son élaboration, de présenter une solution plus claire en séparant les différents problèmes.

3.7

Conclusion

Les éléments de mise en forme de formules mathématiques font appel à de nombreux concepts variés et parfois complexes. Cette solution permet de rendre le programme évolutif. Pour améliorer un rendu d’une balise en particulier, il suffit d’améliorer le modèle s’occupant de créer le noeud intermédiaire, et d’affiner de même, la règle correspondante permettant d’ajouter un ou plusieurs noeuds dans l’arbre final. Le concept de contexte de formatage permet de répondre à ces impératifs car un noeud considère ses descendants comme étant des boˆıtes et ce, quels que soient le type de formules contenues dans ses descendants.

ou de m´emoire) ` a chaque entr´ee soumise ` a l’algorithme. 4 Cet argument est discutable.

Chapitre 4

Particularit´ es du rendu de formules math´ ematiques Nous allons, au cours de ce chapitre, discuter de certains problèmes liés à la qualité du rendu de formules mathématiques : – Le choix de la police utilisée. – Le problème d’ajustement optique.

4.1

Le choix de la police utilis´ ee

Tous les éléments d’une image vectorielle produite dans le cadre de ce travail sont placés à l’aide de coordonnées absolues. Il est à noter que le caractère a possède une plus petite largueur que le caractère m dans la majorité des polices. Dès lors, le placement des éléments est fortement dépendant de la police utilisée (et donc de la métrique de celle-ci). Or, dans un document SVG, on peut spécifier un type de police mais dans le cas o` u celle-ci n’est pas installée sur le système, une police de substitution sera utilisée. Cela n’est pas sans poser des problèmes dans le cadre de ce travail. Il fallait donc chercher et trouver une police installée sur la majorité des systèmes et qui disposait, de plus, d’un jeu de caractères suffisament étendu afin de permettre la représentation de tous les caractères mathématiques. Après diverses investigations, nous avons découvert que SVG disposait d’un système permettant de définir une police de caractère à l’intérieur même du document. Dès lors, toute personne disposant d’un moteur de rendu SVG disposera de la même police : quel que soit le système d’exploitation utilisé, quel que soit les polices installées sur celui-ci. L’étape suivante fut donc de choisir la police à définir dans le SVG produit. Beaucoup de documents scientifiques, spécialement pour ce qui concerne la physique et les mathématiques, sont rédigés à l’aide de TEX . Ce dernier joue un rôle dominant lors de la publication de documents scientifiques. Sa fa¸con de formater des formules mathématiques est un modèle reconnu. Nous avons donc essayé, via ce travail, de nous 35

´ DU RENDU DE FORMULES MATHEMATIQUES36 ´ CHAPITRE 4. PARTICULARITES rapprocher le plus près possible de la qualité de rendu des formules mathématiques de TEX . Il fallait donc trouver le moyen de définir les polices TEX à l’intérieur du document SVG. Après quelques recherches, nous avons trouvé un article répondant au problème : TEX SVG, Fonts [23] qui explique comment convertir une police TEX vers le SVG. Il suffisait donc de reprendre ces résultats et de les inclure dans ce travail. Ce choix a un coˆ ut au niveau de la taille du fichier SVG final : la place occupée sur le disque dur par la police est inférieure à 300 kilo-octets. Celle-ci est automatiquement inclue dans chaque document SVG produit par ce travail. Cependant, ce coˆ ut est discutable : on pourrait définir à l’intérieur du document produit uniquement les caractères correpondants aux glyphes utilisés dans la formule produite ; on pourrait compresser le document SVG et partager un document de type SVGz (fichier de type SVG compressé). Dès lors, ce coˆ ut devient négligeable. Il existe bien entendu des polices avec largeur fixe, ce qui aurait pu faciliter le problème dans le cas o` u l’on aurait choisit une police de ce type présente sur la majorité des systèmes. La largeur d’un caractère n’est pas tellement un obstacle étant donné que l’on dipose de ces données dans le cas o` u nous définissons la police à l’intérieur du document car ces valeurs sont accessibles (car présentes dans la définition du caractère). Exemple de d´ efinition d’un glyphe dans un document SVG Le caractère décrit ci-dessous, en XML directement dans le document SVG, est le Theta (Θ) de TEX (dans la police CMR) : <defs><font id="CMR"><font-face font-family="CMR"/> ... <glyph unicode="&#xE002;" glyph-name="Theta" horiz-adv-x="777.8"> <path style="fill:#000000; fill-rule=evenodd; stroke:none" d="M 56 665 339 c 0 204 -151 366 -333 366 c -179 0 -332 -160 -332 -366 c 0 154 -361 332 -361 c 182 0 333 159 333 361 z M 721 339 m -332 -338 c -99 0 -236 86 -236 338 c 0 257 139 344 235 c 101 0 236 -91 236 -344 c 0 -255 -141 -338 -235 -338 z M 389 1 m 178 413 h -25 v -34 h -307 v 34 h -25 v -144 h 25 v 34 h v -34 h 25 z"/> </glyph> ... </font-face></font></defs>

0 m -205 344 307

On remarque que la définition de la balise glyph contient un attribut donnant une information à propos de la largeur du glyphe (horiz-adv-x ). Cette valeur a été utilisée dans ce travail afin de spécifier la largeur d’un élément feuille de notre arbre intermédiaire. Il

´ DU RENDU DE FORMULES MATHEMATIQUES37 ´ CHAPITRE 4. PARTICULARITES faudrait, pour bien faire, connaˆıtre également précisément la hauteur de la boˆıte. Cela peut se faire en se servant du fichier de métrique, défini par Don Knuth 1 , correspondant à la police de caractère. Ce dernier étant sous forme binaire, il n’est pas facile de récupérer ces informations. De plus, cette description semble aujourd’hui assez révolue étant donné l’existence de XML. Luca Padovani a trouvé une réponse à ce problème et a écrit un petit programme permettant la transformation de ces fichiers binaires en document XML. La transformation ainsi que les fichiers XML générés sont disponibles sur internet2 . L’intégration de ces valeurs reste tout à fait possible dans la structure actuelle des modèles XSLT.

4.2

Le probl` eme d’ajustement optique

Parlons maintenant d’une des spécificités des formules mathématiques afin de comprendre mieux en quoi la recherche d’une solution la plus optimale possible n’est pas une chose aisée. Une formule mathématique est composée de différentes lettres provenant P de différentes familles (a, α, . . .) ainsi que de symboles mathématiques spécifiques (∞, , . . .). Ces éléments ont des tailles différentes. Par exemple, dans l’expression c2 , si c possède une taille de 12 points, alors le 2 devrait avoir une taille de 10 points. De plus, des règles concernant les fractions, déterminants, etc. sont nécessaires. Il en est de même d’un ensemble de symboles ayant une taille variable : le signe de l’intrégrale, le signe de sommation, les parenthèses, le signe de la racine carrée, etc. Certains éléments suivent des règles d’ajustement optique. Par exemple, certains grands symboles sont composé à l’aide de morceaux plus petits. En effet, une parenthèse devrait, pour bien faire, être constituée d’un coin arrondi dans le haut de sa représentation, d’un autre coin arrondi dans le bas de sa représentation tandis que la jonction entre les deux coins se fait à l’aide d’un ou plusieurs segment(s) de droite. Les parenthèses doivent ajuster leur taille en fonction du contenu qu’elles englobent.

Fig. 4.1 – Les symboles dont la taille est variable sont généralement dessinés à l’aide de symboles composés.

1 2

Le p`ere de TEX . http ://www.cs.unibo.it/ lpadovan/software/libxtfm/xtfm.html

Chapitre 5

R` egles de transformations 5.1

Introduction

Ce chapitre est consacré à l’étude, assez technique, de la transformation pour chaque balise MathML du document. Pour chaque balise de présentation d’un document MathML, nous allons définir : – Des règles concernant la création du noeud intermédiaire. – Des règles concernant la génération du noeud dans le document SVG de sortie. Nous avons expliqué, dans le chapitre 3, comment les différents arbres étaient parcourus. Nous allons décrire, dans cette partie, pour chaque noeud de l’arbre MathML source rencontré par les parcours précités, leurs modèles de transformation.

5.2

La racine du document MathML

Lorsque l’on fournit, au transformateur, des modèles de transformations ainsi qu’un document source, il va d’abord regarder à appliquer la règle servant de départ : celle consacrée au traitement du noeud racine de l’arbre XML source. <xsl:template match="/"> ... </xsl:template> Cette règle est donc notre point de départ : c’est la première appelée par le transformateur XSLT !

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

pointeur

math

svg g

font

sous-arbre SVG (rendu de la formule) Arbre MathML

Arbre intermédiaire

Arbre SVG

Fig. 5.1 – Mod`ele s’appliquant `a la racine de l’arbre MathML

Op´ erations r´ ealis´ ees s´ equentiellement par ce mod` ele – Lancer la construction1 de l’arbre intermédiaire. Placer un pointeur sur la racine de l’arbre intermédiaire construit2 . – A l’aide du pointeur du point précédent, regarder quelle est la largeur ainsi que la hauteur de la boˆıte entourant la totalité de la formule (dans le noeud racine de l’arbre intermédiaire). – Générer la racine de l’arbre SVG (balise <SVG>) en spécifiant sa taille (largeur et hauteur) à l’aide des données récoltées au point précédent. – Ajouter un noeud fils à la racine (balise <g> du SVG) contenant des attributs d’ajustement visuel. Tous les fils de ce noeud héritent des propriétés de celui-ci3 . – Définir la police de caractères comme étant fils direct de l’arbre SVG. – Construire le sous-arbre SVG en parcourant l’arbre intermédiaire construit. Ce sous-arbre SVG devient descendant de la balise <g> construite au point n˚3.

5.3

Sp´ ecification du W3C concernant le rendu Dans la majorité des cas, le contenu d’un élément mi représentera un identifiant mathématique tel qu’une variable ou un nom de fonction. Un moteur de rendu graphique typique rendrait un élément mi selon les caractères de son contenu, sans expacement supplémentaire autour des caractères (sauf l’espacement associé aux éléments voisins). La valeur par défaut de ses attributs mathvariant et fontstyle serait (typiquement) normal (non-penché), à moins que le contenu ne soit qu’un seul caractère, auquel cas ce 1

Par construire ou construction, on sous-entend l’appel récursif correspondant ` a la première étape (décrite dans le chapitre précedent) de la méthode de production. 2 C’est du XSLT : il faut, bien entendu, penser récursivement. 3 Nous y spécifions donc, par exemple, la police de caractère utilisée par les balises <text> fils de cet élément.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

serait la valeur italic.

R` egle pour la construction de l’arbre final – Calculer la position absolue de l’élément en fonction des valeurs re¸cues en argument lors de l’appel de cette règle ainsi que du contexte de formatage propre à l’élément. – Construire le noeud dans l’arbre SVG à l’aide d’une balise de type <text> complétée d’attributs dépendant du contexte de formatage, de la spécification du MathML et des attributs spécifiés dans l’arbre MathML source.

a contexte de formatage

b contexte de formatage

<text x="20" y="20" font-size="8">a</text> + attribut pour rendu en italique

<text x="20" y="20" font-size="8">b</text> + attribut pour rendu en italique

Fig. 5.2 – Exemples simples de transformation d’un ´el´ement ’mi’.

5.4

mn, mtext

Sp´ ecification du W3C concernant le rendu mn : Un élément mn représente un « littéral numérique » ou d’autres données qui devraient être rendues comme littéral numérique. Généralement parlant, un littéral numérique est une séquence de chiffres, incluant éventuellement un point décimal, représentant un entier non signé ou un nombre réel.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

Les règles de transformations d’une balise mn sont identiques à celles concernant une balise mi. mtext : Un élément mtext s’utilise pour représenter un texte arbitraire devant être rendu en tant que tel. En général, l’élément mtext est destiné à indiquer un commentaire. Les règles de transformations d’une balise mtext sont identiques à celles concernant une balise mi.

5.5

Sp´ ecification du W3C concernant le rendu L’élément ms s’utilise pour représenter des chaˆınes littérales dans les expressions destinées à être interprétées par des systèmes de calcul algébrique ou d’autres systèmes contenant des langages de programmation. Par défaut, les chaˆınes littérales sont affichées entourées par des guillemets doubles. Comme tous les éléments atomiques, l’élément ms rogne et fusionne les blancs de son contenu. Pour les moteurs de rendu visuel, le contenu d’un élément ms est typiquement rendu sans espacement supplémentaire rajouté autour de la chaˆıne et avec un caractère guillemet au début et à la fin de celle-ci. Par défaut, les caractères guillemets de gauche et de droite sont tous deux des guillemets doubles standard &quot;. Cependant, on peut remplacer ces caractères par les attributs lquote et rquote respectivement.

R` egle pour la construction de l’arbre interm´ ediaire – Compter le nombre de caractères contenus dans la balise. – Sauver le contexte de formatage (attributs concernant la balise) dans l’arbre intermédiaire. Le calcul des attributs width et height (largueur et hauteur) de la boˆıte entourant le(s) caractère(s) dépend du glyphe représentant celui-ci (ceux-ci) ainsi que du nombre de caractères contenus dans l’élément. La largeur de la boˆıte doit être augmentée proportionnellement à la largeur des boˆıtes de chacun des deux guillemets disposés de part et d’autre de la chaˆıne littérale contenue dans la balise. Ces guillements héritent du contexte de formatage courant.

R` egle pour la construction de l’arbre final – Calculer la position absolue de l’élément en fonction des valeurs re¸cues en argument lors de l’appel de cette règle ainsi que du contexte de formatage propre à l’élément. Le calcul de la position absolue des éléments dépend également des guillemets à placer de part et d’autre de la chaˆıne littérale (dans ce cas, il faut avancer tout

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

le contenu de la chaˆıne en augmentant la valeur de l’abscisse de chaque élément atomique afin de placer sur leur gauche, un guillemet : l’autre guillement prend la place restante à la fin de la boˆıte courante). – Construire le noeud dans l’arbre SVG à l’aide d’une balise de type <text> complétée d’attributs dépendant du contexte de formatage, de la spécification du MathML et des attributs spécifiés dans l’arbre MathML source.

5.6

mspace

Sp´ ecification du W3C concernant le rendu Un élément vide mspace représente un espace de n’importe quelle taille voulue, réglée par ses attributs. On peut aussi l’utiliser pour suggérer des sauts de ligne à un moteur de rendu visuel. Remarquez que les valeurs par défaut des attributs ont été choisies pour typiquement n’avoir aucun effet sur le rendu. Ainsi, l’élément mspace est généralement employé avec une ou plusieurs valeurs d’attribut explicitement spécifiées.

R` egle pour la construction de l’arbre interm´ ediaire – Calculer la taille de la boˆıte en fonction des attributs de l’élément. – Sauver le contexte de formatage (attributs concernant la balise) dans l’arbre intermédiaire.

R` egle pour la construction de l’arbre final Aucun rendu concernant cet ´el´ement.

5.7

Sp´ ecification du W3C concernant le rendu Un élément mo représente un opérateur ou toute autre chose qui devrait se rendre comme un opérateur. En général, les conventions de notation pour les opérateurs mathématiques sont assez compliquées, c’est pourquoi MathML offre un mécanisme relativement sophistiqué pour la spécification du comportement de rendu d’un élément mo. Les opérateurs représentent un type particulier d’élément atomique. Les deux différences par rapport aux autres éléments atomiques sont : – Les opérateurs ont de l’espace autour d’eux. Cet espace est déterminé par la forme de l’opérateur. Les règles détaillées pour la détermination de l’espacement de l’opérateur dans les rendus visuels sont décrites dans la spécification du W3C. – Les opérateurs peuvent devoir être étirés à une taille particulière.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

La majorité de ces éléments prennent leur valeur depuis le dictionnaire des opérateurs 4 . Le contexte de formatage de l’élément est donc déterminé par ces règles qui doivent être insérées dans le cadre de la transformation. Il reste un travail de développement à faire afin d’aboutir à une solution claire et complète pour ce cas. Nous allons donc juste énumérer les différents problèmes à résoudre concernant le rendu des opérateurs MathML.

Dessin des parenthèses à l'aide des éléments les constituants

(

)

Construction actuelle

Etirement des boîtes mo correspondant aux parenthèses (cas à réaliser)

Fig. 5.3 – Exemple de redimensionnement d’un type d’´el´ement mo.

Le problème principal provient du mode de parcours de l’arbre initial. En effet, prenons, par exemple, le cas de parenthèses englobant une matrice. La parenthèse gauche sera la première construite. Autrement dit, la taille de sa boˆıte sera calculée avant que le calcul du contenu qu’elle entoure. Il faudrait donc prévoir un mécanisme qui permet de redimensionner les boˆıtes correspondant aux parenthèses, en fonction de ce qu’elles englobent. Une solution générale pourrait être d’inférer une balise de type mrow pour le contenu étant à l’intérieur de parenthèses. Dès lors, lorsque que cette boˆıte est calculée, il faudrait venir placer de nouveaux arttributs dans les boˆıtes correspondant aux parenthèses, afin de, par exemple, en augmenter leur hauteur (afin que celle-ci corresponde à la hauteur de la boˆıte calculée). 4

De nombreux symboles mathématiques, tels qu’un signe d’intégration, un signe plus ou une parenthèse, ont un emploi en notation bien établi, prévisible et traditionnel. Typiquement, cet emploi se résume ` a certaines valeurs d’attribut par défaut pour les éléments mo ayant des contenus spécifiques et un attribut form spécifique. Comme ces valeurs par défaut varient d’un symbole ` a l’autre, MathML anticipe que les moteurs de rendu (pour le MathML) auront un dictionnaire des opérateurs des attributs par défaut pour les éléments mo (voir l’Appendice F de la spécification MathML par le W3C) indexé par le contenu de chaque élément mo et attribut form.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

Le dessin et le placement des caractères consitutant les parenthèses se ferait alors lors de la deuxième passe. Ces différents éléments seraient dès lors placés en fonction de la taille des boˆıtes correspondant à celles-ci. Ici encore, la construction de l’arbre en une une seule passe rendrait moins claire la solution élaborée. Un gros travail de développement reste à faire concernant ce point.

5.8

mglyph

Sp´ ecification du W3C concernant le rendu L’élément mglyph est le moyen par lequel les utilisateurs peuvent accéder directement aux glyphes des caractères qui ne sont pas définis par Unicode ou qui sont inconnus du moteur de rendu. Les auteurs devraient avoir à l’esprit que le rendu exige les polices appelées par l’élément mglyph, auxquelles le moteur de rendu MathML peut ne pas avoir accès ou lesquelles ne sont pas gérées par le système sur lequel tourne le moteur de rendu. Pour ces raisons, on encourage les auteurs à n’utiliser l’élément mglyph que quand cela est absolument nécessaire et pas pour des effets de style. Aucune gestion dans ce travail de ce type de balise à l’heure actuelle.

5.9

msub

Sp´ ecification du W3C concernant le rendu La syntaxe de l’élément msub est ; <msub> base ´ ecriture_en_lettres_inf´ erieures </msub> Dans le cas o` u la base serait x et le deuxième fils serait i, le rendu devrait être xi .

R` egle pour la construction de l’arbre interm´ ediaire – – – – –

Construire la base (fils à gauche) en l’appellant avec le contexte courant. Récupérer la hauteur et la largeur de la boˆıte du fils à gauche construite. Construire le fils à droite avec le contexte courant modifié. Calculer la hauteur et la largueur de la boite courante. Sauver le contexte modifié à l’aide des valeurs calculées.

R` egle pour la construction de l’arbre final Demander le rendu des fils de l’´el´ement.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

(0,0)

Fig. 5.4 – Sch´ema aidant au calcul de la taille de la boˆıte de msub.

5.10

msup

Cette balise est fort semblable à msub. Le premier fils est écrit normalement, le second est écrit en lettres supérieures (en exposant). Dès lors, si le premier argument est x et si le deuxième est 2, alors le rendu sera x2 . Les règles sont les mêmes que pour msub hormis pour le contexte envoyé au second fils dans le cadre des règles permettant la construction de l’arbre intermédiaire : le paramètre y est différent. (0,0)

Fig. 5.5 – Schéma aidant au calcul de la taille de la boˆıte de msup. Il faut prévoir, dans ce cas, un mécanisme permettant de placer le second fils de telle manière que le fond de sa boˆıte co¨ıncide à la valeur correspondant à environ 71% de la hauteur de la boˆıte du premier fils.

5.11

msubsup

La balise msubsup est un mélange de msub et de msup. La balise possède donc 3 fils. Le premier fils est construit avec le contexte courant. Le second est construit avec le contexte décrit pour la deuxième fils de msub tandis que le troisième fils est appelé avec le contexte utilisé pour la deuxième fils de msup. Le calcul de la taille de la boˆıte de l’élément est quant à lui un rien différent.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

(0,0)

10 i

2 x+i

Fig. 5.6 – Sch´ema aidant au calcul de la taille de la boˆıte de msubsup.

5.12

msqrt

Sp´ ecification du W3C concernant le rendu Cet élément construit un radical. L’élément msqrt s’utilise pour les racines carrées. Il accepte n’importe quel nombre d’arguments ; si ce nombre n’est pas égal à 1, son contenu est traité comme un seul élément mrow inféré contenant ses arguments.

R` egle pour la construction de l’arbre interm´ ediaire – Construire les fils en appelant le modèle s’occupant de gérer les mrow. – Calculer la taille de la boˆıte courante comme ayant la même hauteur que la boˆıte créée par l’appel précédent mais ayant un largeur plus grande afin de laisser la place, à gauche, pour le dessin de l’insigne radical. Pour bien faire, il faudrait également étirer un tout petit peu la boˆıte en hauteur.

R` egle pour la construction de l’arbre final – D´eplacer vers la droite tout le contenu du (des) fils du radical en demandant leur rendu. – Dessiner le radical.

Le dessin du radical Pour simplifier le rendu, la solution choisie a été de dessiner le radical à l’aide de 4 lignes, en calculant les 5 coordonnées permettant le dessin de celui-ci. Ce rendu n’est donc certainement pas optimal. En effet, pour être optimal, il faudrait que l’on utilise le caractère correspondant au radical (défini dans la police utilisée) et d’ensuite tracer les lignes supplémentaire permettant de terminer le dessin. Or, pour se faire, il faut définir la taille de la police correspondant au caractère et calculer les coordonnées permettant la fin du dessin, via des balises line. Un autre problème se pose : il faut choisir une bonne valeur pour l’épaisseur de la ligne prolongant le caractère précité afin que le radical et la ligne se confondent. Le calcul des 5 coordonnées permet, dans une premier temps, d’éviter ces calculs et de fournir, rapidement, une rendu visuel basique.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

msqrt mrow inféré

dessin du radical : traçage de lignes via 4 balises <line> msqrt mrow inféré

Fig. 5.7 – Dessin du radical.

5.13

mroot

Sp´ ecification du W3C concernant le rendu Cet élément construit également un radical. L’élément mroot s’utilise pour dessiner des radicaux avec des indices, par exemple, une racine cubique. L’élément mroot requiert exactement deux arguments.

R` egle pour la construction de l’arbre interm´ ediaire – Construire le fils a` gauche et le fils à droite. – Calculer la taille de la boˆıte courante. Ces calculs, à l’heure actuelle, n’ont pas encore été effectués. Il faut définir le placement des fils l’un par rapport à l’autre et calculer la taille de la boˆıte entourant ces deux boˆıtes.

R` egle pour la construction de l’arbre final Il faut appeler les deux fils en leur spécifiant des valeurs de déplacement x et y concernant le placement calculé lors de la construction précédente. Il faut à nouveau calculer les 5 coordonnées correspondant au dessin de la racine. Cette balise n’ayant pas été implémentée à l’heure actuelle, nous ne détaillerons pas plus ce point.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

fils à gauche

fils à droite

mroot fils à droite fils à gauche

Fig. 5.8 – Sch´ema aidant au calcul de la taille de la boˆıte de mroot.

5.14

mfrac

Sp´ ecification du W3C concernant le rendu L’´el´ement mfrac s’utilise pour des fractions.

R` egle pour la construction de l’arbre interm´ ediaire – Construire le fils à gauche et le fils à droite. Le contexte passé en paramètre est le courant avec quelques modifications. – Calculer la taille de la boˆıte courante.

Calcul de la boˆıte courante numérateur (fils à gauche)

dénominateur (fils à droite)

cas n ° 1 (largeur) numérateur > dénominateur cas n°2 (largeur) numérateur < dénominateur hauteur (height)

cas n°3 (largeur) numérateur = dénominateur

calcul de la boîte dans le cas n°1

largeur (width)

Fig. 5.9 – Sch´ema aidant au calcul de la taille de la boˆıte de mfrac. La hauteur de la boˆıte mfrac se calcule comme suit :

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

"hauteur" := "hauteur 1er fils" + "hauteur du deuxi` eme fils" + "espace entre les deux bo^ ıtes pour le dessin de la barre de fraction"; La largeur, quant `a elle, se calcule en prenant pour valeur, la plus grande valeur de largeur.

R` egle pour la construction de l’arbre final Il faut, dans ce cas, si aucun n’attribut n’est spécifié, que le plus petit des deux soit centré par rapport à l’autre. Ce centrage se fait en pla¸cant des attributs consacrés à cela dans les noeuds intermédiaires lors de la construction de l’arbre à boˆıtes. C’est aussi lors de cette construction que l’on place le deuxième fils en fonction de la hauteur du premier fils, l’espace ayant été réservé à cet effet lors du calcul de la taille de la boˆıte courante. Dans certains cas, des problèmes surviennent. En effet, dans le cas o` u le numérateur 1

1 2

et 34 , on voit sur le rendu opéré par TEX ( 23 ) 4 que la barre de fraction entre le numérateur et le dénominateur est plus large. On voit également que le numérateur et le dénominateur sont centrés par rapport à cette barre. Dès lors, quelques règles ont été ajoutées lors de la construction de la fraction. et le dénominateur sont respectivement

R` egle suppl´ ementaire pour la construction de l’arbre interm´ ediaire Pour résoudre le problème expliqué au point précédent, l’idée est de prévoir une largeur de boˆıte un rien plus grande, tracer une barre de fraction prenant la totalité de la largeur de la boˆıte et enfin, centrer le numérateur ainsi que le dénominateur par rapport à la barre tracée. Dès lors, le problème précité est réglé.

1 2 3 4 Fig. 5.10 – La balise mfrac dans le cas o` u le numérateur et le dénominateur ont la même largeur.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

5.15

munder, mover, munderover

La balise munder prend en arguments deux éléments. Elle place le deuxième élément (exemple : ∼) comme indice inférieur au premier (exemple : >). Exemple : > ∼ La balise mover prend en arguments deux éléments. Elle place le deuxième élément (exemple : α) comme indice supérieur au premier (exemple : −→). α Exemple : −→ La balise munderover prend en arguments trois éléments. Elle place P le deuxième élément (exemple : i = 0) comme indice inférieur au premier (exemple : ) et le troisième élément (exemple : n) comme indice supérieur, également au premier. Exemple : n X i=0

Ces balises n’ont étées implémentées qu’en partie mais l’idée est de réaliser le même type de calcul que ceux effectués pour mfrac, sans tracer la barre de fraction. Une attention toute particulière devra être consacrée aux éléments mo qui doivent être étirés.

5.16

mrow, merror, mphantom

Sp´ ecification du W3C concernant le rendu Un élément mrow s’utilise pour regrouper un nombre quelconque de sous-expressions, étant consitutées habituellement d’un ou plusieurs éléments mo. Ceux-ci agissent comme opérateurs sur une ou plusieurs expressions, qui sont leurs opérandes. La balise mrow sert aussi à regrouper des sous-expressions qui ont besoin d’être alignées avec respect de leur ligne de base. C’est aussi à l’intérieur de cette balise que devrait être, dans le cas idéal, implémenté un algorithme de coupure de formules mathématiques. En effet, l’utilisateur pourrait spécifier une largeur maximale que devrait occuper la formule mathématique. Dans le cas o` u une formule serait trop longue, il faudrait trouver le point de coupure (et donc placer le reste du contenu à la ligne suivante) de cette formule. Actuellement, la transformation réalisée par la balise mrow est assez basique. L’opération faite est de parcourir récursivement la liste des fils de mrow, de gauche vers la droite (autrement dit, de la même manière que la formule est lue). Chaque élément envoie à son frère de droite (s’il y en a un), son contexte de formatage. Lors de sa construction, le noeud est donc placé à droite de son frère de gauche (ou selon le contexte courant s’il n’en possède pas). Un problème reste à résoudre : il faudrait que cet élément gère l’alignement des différents éléments sur une même ligne de base. Par exemple, dans le cas o` u un élément

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

mrow

étape suivante

mrow

contexte

contexte mrow

mrow

contexte

mrow

Fig. 5.11 – Schéma aidant au calcul de la taille de la boˆıte de mrow et à la compréhension de la manière dont les fils sont construits.

mfrac est présent dans les éléments fils de mrow, les autres éléments doivent s’aligner de fa¸con à ce que l’opérateur soit sur la même hauteur que la barre de fraction. L’autre élément (le caractère a) est lui aussi déplacé à hauteur de la barre de fraction.

lignes de base

A + B -

A + B 2

Fig. 5.12 – Ajustement des éléments sur une même ligne de base.

Pour réaliser cela, la démarche est simple : lors du premier parcours, on place le 1er fils de l’élément mrow sur une ligne de base définie. Les appels des autres fils se fait avec cette valeur de ligne de base et viennent s’aligner sur celle-ci. Des attributs sont alors ajoutés à l’intérieur de la balise mrow de l’arbre intermédiaire afin d’aligner tout le contenu de l’élément mrow (lors du second parcours) sur celui de ses frères, s’il en a.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

Actuellement, l’alignement sur une même ligne de base n’étant pas géré complètement, tous les éléments atomiques disposent d’une hauteur fixe (non dépendante de la métrique des caractères). L’axe des ordonnée étant inversé, ces éléments sont placés dans le document SVG à la position y + height o` u height est la hauteur de la boˆıte. Cette valeur correspond donc à leur ligne de base actuelle. Dès lors, ce n’est qu’une fois que le problème d’ajustement sur une même ligne de base sera résolu que l’on pourrait implémenter, avec précision, la métrique des caractères de la police utilisée. Sans cela, plus rien ne serait aligné avec le positionnement tel qu’il est implémenté actuellement. La balise merror subit le même traitement à la différence prêt que lors du rendu, une balise rect est ajoutée dans le document SVG, permettant de dessiner la boˆıte courante et donc d’encadrer le contenu englobé par merror. La balise mphantom subit le même traitement à la différence prêt que lors du rendu, le rendu des éléments fils n’est pas opéré.

5.17

mpadded, mstyle, mfenced, mtable, mlabeledtr, mtr, mtd, maction, menclose, mmultiscripts

Aucune solution n’a été implémentée ou développée concernant ces points. Malgré tout, nous allons essayer de décrire certaines pistes permettant, via la solution exposée dans ces pages, de résoudre ces cas.

mpadded Spécification du W3C concernant le rendu : Un élément mpadded rend la même chose que son contenu, mais avec sa taille globale et d’autres dimensions (telle que la position de la ligne de base) qui sont modifiées en fonction de ses attributs. L’élément mpadded n’adapte pas (n’étire ni ne retrécit) son contenu ; son seul effet est de modifier la taille et la position apparente de la « boˆıte englobante » autour de son contenu. Il agit donc sur le positionnement relatif du contenu par rapport aux éléments environnants. Pour résoudre ce cas, on pourrait, lors de la construction de l’arbre intermédiaire, modifier le calcul de la boˆıte englobant la formule et y ajouter des attributs concernant le positionnement des éléments à l’intérieur de cette même boˆıte.

mstyle Spécification du W3C concernant le rendu : L’élément mstyle s’utilise pour effectuer des changements de style qui affectent le rendu de son contenu. On peut donner à l’élément mstyle n’importe lequel des attributs acceptés par les éléments de présentation MathML, pourvu que la valeur de l’attribut soit héritée, calculée ou a une valeur par défaut ; les attributs des éléments de présentation dont les valeurs sont requises ne sont

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

pas acceptés par l’élément mstyle. Une méthode consisterait en l’ajout d’un noeud de type <g> dans l’arbre résultat, ce noeud contenant les attributs spécifiés. La structure hiérachique serait préservée dans le document SVG afin que les attributs soient hérités par les mêmes éléments fils. Cette idée est expliquée de manière plus détaille à la section 5.18.

mfenced Spécification du W3C concernant le rendu : L’élément mfenced fournit une forme commode dans laquelle exprimer des constructions communes faisant intervenir des délimiteurs (i.e., accolades, crochets et parenthèses), incluant éventuellement des séparateurs (telles que des virgules) entre les arguments.

mtable, mlabeledtr, mtr, mtd Spécification du W3C concernant le rendu : Les matrices, tableaux et autres notations mathématiques en table sont balisés en utilisant des éléments mtable, mtr, mlabeledtr et mtd. Ces éléments sont similaires aux éléments TABLE, TR et TD de HTML, sauf qu’ils offrent des attributs spécialisés qui contrôlent la disposition fine nécessaire pour les diagrammes commutatifs, les blocs de matrices et ainsi de suite. L’élément mlabeledtr représente une rangée étiquetée d’une table et peut s’utiliser pour des équations numériques. On peut représenter une matrice identité 3 par 3 comme suit :

mtable

mtr

mtd

Fig. 5.13 – Matrice identité 3*3 représentée en MathML.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

Le rendu concernant ce code MathML devrait être : 1 0 0 0 1 0 0 0 1 Dans ce cas, la matrice est composé de 9 éléments. Les boˆıtes des 9 feuilles correspondantes sont de taille égale. Dans ce cas simple, il est facile de calculer les boˆıtes correspondant à chaque noeud dans l’arbre intermédiaire : – La taille de l’élément mtd est celle de l’élément fils mn. – La taille de l’élément mtr est telle que la hauteur soit celle des éléments fils ; la largeur est trois fois celle des fils. – La taille de l’élément mtable est telle que la largeur soit celle des éléments fils ; la hauteur est trois fois celle des fils. Pla¸cons nous maintenant dans un cas moins évident o` u la matrice à générer à partir du MathML serait 1000 0 0 1 20 0 2 0 30 Dans ce cas, la largeur de l’élément mtable devrait être calculée de manière plus générale. Isolons, pour mieux raisonner, la première colonne de la matrice précitée : 1000 1 2 La largeur de l’élément mtable est proportionnelle à la somme de la largeur de chaque élément le plus large de chaque colonne. Sa hauteur est plus simple à calculer : elle correspond à la somme des hauteurs de chaque élément mtd. A cela, l’on peut rajouter un peu d’espace horizontal entre chaque boˆıtes. Tous ces calculs pourraient s’effectuer lors de la construction et le parcours de l’élément mtable. N’ayant pas réalisé ce point, nous n’irons pas plus loin dans le développement de ce problème.

maction, menclose, mmultiscripts Aucune étude ni implémentation n’a été réalisée concernant ces points.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

largeur d'une colonne = largeur de l'élément le plus large 1000

largeur d'une ligne = somme de la largeur de chaque colonne

les éléments sont centrés par rapport à l'élément le plus large de la colonne

Fig. 5.14 – Problèmes liés au calcul de la boˆıte correspondant à un élément mtable.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

5.18

La gestion des attributs des balises du MathML

La gestion des attributs du MathML vers le SVG dans le cadre de ce travail n’a, à l’heure actuelle, pas été réalisée. Cependant, dans notre méthode de production, tout cela reste réalisable. En effet, une solution consisterait à traduire un attribut de MathML en un attribut SVG. Lors du parcours de l’arbre intermédiaire (lors de la production du SVG), il faut rajouter un noeud de type <g> dans l’arbre SVG ayant pour attributs ceux du MathML traduits en SVG5 .

mstyle mathcolor ='blue'

arbre intermédiaire vers le SVG

mrow mo

mathcolor ='green'

mathcolor ='red'

g style='fill:blue'

style='fill:green'

style='fill:red'

text

A+B

text moteur de rendu SVG

B SVG produit

Fig. 5.15 – Gestion des attributs MathML vers SVG via la balise de groupement g.

5 Pour rappel, la balise <g> de SVG a pour but de regrouper des éléments, ces éléments (enfants de ce noeud) héritent des propriétés définies dans cette balise.

` CHAPITRE 5. REGLES DE TRANSFORMATIONS

5.19

Conclusion

Ne maˆıtrisant pas vraiment le langage XML en débutant ce projet, il subsiste, à l’heure actuelle, une certaine frustration de n’avoir pas su (pour cause de lenteur due au manque de maˆıtrise du langage) concrétiser plus toutes les idées développées. La lecture de ces pages pourrait, néanmoins, permettre de continuer facilement la réflexion à propos du sujet et surtout, son implémentation.

Chapitre 6

Les r´ esultats Nous allons présenter dans ce chapitre différentes formules mathématiques. Certaines ayant certains défauts, nous allons expliquer pour chacunes la provenance de ces imperfections.

6.1

Einstein

– Les alignements sont corrects. – Les proportions et le placement des différents éléments sont corrects. – L’espace autour du caractère « = » est discutable. L’implémentation du dictionnaire des opérateurs serait nécessaire pour régler ce problèmes. Les formules suivantes ont ce même problème. Nous ne rappelerons donc pas celui-ci à chaque description critique.

6.2

Une simple ´ equation

Les remarques que l’on pourrait faire concernant cet exemple sont similaires à celles de la formule précédente. 58

´ CHAPITRE 6. LES RESULTATS

6.3

Une racine

– Le dessin du radical n’est pas optimal. Pour ce faire, il faudrait utiliser le caractère spécifié dans la définition de la police utilisée.

6.4

Fractions imbriqu´ ees

Exemple de formule tel qu’expliqu´e `a la section 5.14.

6.5

Equation contenant des fractions

– L’implémentation du dictionnaire des opérateurs est indispensable ainsi que le recalcul des boˆıtes correspondant aux parenthèses. – L’espace compris entre le haut du a et la barre de fraction de la première fraction est trop important. La raison est que la métrique des caractères n’est actuellement implémentée que pour la largeur d’un caractère.

´ CHAPITRE 6. LES RESULTATS

6.6

Friedman-Robertson-Walker

Les remarques faites au point pr´ec´edent restent d’application pour cette formule.

6.7

Un exposant et des fractions

Une fois de plus, on voit les problèmes survenir du fait que la hauteur d’un élément mi est actuellement fixée. L’ajout d’informations à propos de la métrique des caractères est nécessaire. De plus, la spécification de MathML dit qu’un caractère ne peut pas être rendu avec une taille inférieure à 8pt. Cette caractéristique est également à ajouter à l’implémentation.

6.8

Un petit m´ elange de divers ´ el´ ements MathML

Â´ CHAPITRE 6. LES RESULTATS

6.9

Des indices

<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg xmln="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" xmlns:t="http://localhost/tmp" version="1.1" width="570.86876" height="97.04724999999999"> <g style="stroke:none;fill:#000000;text-rendering:optimizeLegibility; font-family:CMR;"> <text style="font-family:CMMI;" x="483.58756999999997" y="77.5" font-size="100">x</text> <text x="541.530812" y="92.04724999999999" font-size="50.41">4</text> <text x="541.530812" y="41.54725" font-size="50.41">2</text> <text style="font-family:CMMI,CMSY,CMR;" x="406.33957" y="77.5" font-size="100">=</text> <text style="font-family:CMMI;" x="324.05838" y="77.5" font-size="100"> x</text> <text x="382.001622" y="92.04724999999999" font-size="50.41">3</text> <text style="font-family:CMMI,CMSY,CMR;" x="246.81038" y="77.5" font-size="100">+</text> <text style="font-family:CMMI;" x="164.52919000000003" y="77.5" font-size="100">x</text> <text x="222.47243200000003" y="92.04724999999999" font-size="50.41"> 2</text> <text style="font-family:CMMI,CMSY,CMR;" x="87.28119000000001" y="77.5" font-size="100">+</text> <text style="font-family:CMMI;" x="5" y="77.5" font-size="100">x</text> <text x="62.943242000000005" y="92.04724999999999" font-size="50.41"> 1</text> </g> <defs> <font id="CMR"> ... </font> </defs> </svg>

Chapitre 7

Conclusions Lorsque j’ai choisi ce sujet, je ne connaissais pas grand chose au monde XML : aucun cours n’est donné sur ce sujet actuellement à l’institut Montéfiore. A l’université, nous avons appris à apprendre. Une longue étude préliminaire lors de l’élaboration de cette solution a donc été necessaire. Nous avons montré que la transformation, en utilisant uniquement XSLT, est possible : chose qui n’était certainement pas évidente lorsque j’ai commencé à étudier le problème. On pourrait bien évidemment développer plus longuement la transformation et améliorer les règles en étudiant profondément, par exemple, les règles de rendu de formules du TeXBook de D. Knuth [6]. Au moment o` u se clôture ce travail, une série de bonnes nouvelles, justifiant une fois de plus l’intérêt de ce travail, arrivent sur nos écrans : – Un étudiant allemand, Björn Eickvonder, vient de rendre public son travail de fin d’études consistant, lui aussi, à transformer du MathML vers le SVG. Celui-ci utilise une solution basée sur XSLT et JAVA1 . – Luca Padovani, dont la thèse de doctorat MathML Formatting [11] m’a considérablement aidée dans l’élaboration de la solution précitée, est actuellement occupé à ajouter la possibilité d’ajouter à son application GtkMathView 2 la possibilité de créer du SVG à partir du formatage opéré par son programme. En effet, lorsqu’il a apprit le sujet de mes recherches et tenté de répondre à quelques unes de mes questions, l’idée lui est venue d’ajouter cette possibilité à son application. Dans l’un de ses derniers mails, il ajoute : The more I think about it, the more I like the idea of rendering to SVG, and I think that there are a large number of possibilities of combining SVG and MathML for drawing complex formulas + diagrams.

1 2

http ://lufgi9.informatik.rwth-aachen.de/lehre/diplom/eickvonder/abschluss/ http ://helm.cs.unibo.it/software/mml-widget/

CHAPITRE 7. CONCLUSIONS

Clôturons par une note un peu plus personnelle. En plus de l’informatique, l’architecture et la photographie me passionnent. L’architecture consiste, quelque part, à imaginer la position de certains éléments en fonction de certaines contraintes (culturelles ou pratiques) bien précises. La photographie consiste, quelque part, à capturer dans une structure bidimensionnelle, une image. Une belle photographie dépend bien entendu du sujet, mais aussi de la manière dont les différents éléments y sont placés, de fa¸con à ce que celui qui la regarde trouve l’image visuellement belle. Je suis donc heureux que, quelque part, l’université m’ait permis, même involontairement, de faire cohabiter quelques unes de mes passions à l’intérieur d’un seul et même travail.

Bibliographie [6]

Donald Knuth, ”The TeXbook”, Addison-Wesley : Reading, 1984.

[11] Luca Padovani, ”MathML Formatting”, Ph. D. Thesis, Technical Report UBLCS2003-03, Dept. Computer Science, Bologna, Italy, 2003. [21] J. Andr´e, I. Vatton, ”Contextual Typesetting of Mathematical Symbols Taking Care of Optical Scaling”, INRIA, 23 Juin 1993. [23] Michel Goossens and Vesa Sivunen, ”TEX SVG, Fonts”, TUGboat, Vol. 0, 2001.