Le but de cette page et de synthétiser les éléments de la discussion sur les évolutions a apporter a Scenari / OpaleSup pour améliorer la gestion des formules de math : http://scenari-platform.org/forum/viewtopic.php?t=1552
Tableau de synthèse
Attention, les chiffres sont des éléments donnés à titre d'illustration et d'ordre de grandeur, ce sont des estimations de bonnes foi mais qui ne peuvent pas être confirmées complètement avant la mise en place des évolutions proposées.
| Amélioration des conversions | Transformation LaTeX -> PNG par les outils LaTeX | |
| Description des bénéfices de la méthode | On refait ou corrige progressivement les conversions, en donnant priorité aux problèmes remontés par les membres de la communauté, c'est un processus itératif qui ne couvrira jamais 100% des formules possibles | On utilise LaTeX pour transformer les formules de math en images, ce qui résous directement une grande partie des problèmes de validité des formules LaTeX mais n'adresse pas les problèmes de MathML |
| Formules MathML réparées sous 2-3 mois | 80% | 0% |
| Formules MathML réparées sous 12 mois | 90% | 0% |
| Formules LaTeX réparées sous 3-4 mois | 60% | 95% |
| Formules LaTeX réparées sous 12 mois | 70% | 95% |
| Alourdit le programme d'installation ou nécessite l'installation de LaTeX par l'utilisateur | Non | Oui |
| Sous ensemble des commandes et des symboles LaTeX supportés | un petit sous-ensemble seulement, l'auteur doit réécrire certaines formules LaTeX sans les commandes non prises en charges | presque toutes les commandes supportées lors d'une installation par défaut de LaTeX |
| Amélioration de l'alignement vertical / baseline | Non (dépend d'OpenOffice) | peut être (suivant devs et difficultés d'intégration) |
| Temps de génération | presque inchangé | modifié, on ne sait pas dans quel sens |
| Poids des générations | presque inchangé | dépend des formules, en moyenne plus léger pour le web et plus lourd pour le papier |
| Format en publication web | Flash | png |
| Format en publication papier | ODF embarqué dans ODT | png |
| Qualité visuelle correcte | oui | oui |
| État des développements | Développements en cours | Non décidé, envisagé en tant que solution complémentaire |
| Qui doit développer ? | Franck Rouzé de l'Université de Lille1 (et une petite part d'intégration par Kelis) | Kelis (et une part d'étude par la communauté) |
| Qui doit tester ? | toute la communauté | toute la communauté |
Etude des solutions sur l'affichage des formules de math
Chaîne actuelle de conversion de format des ressources dans opale : LaTeX -> MathML -> ODF -> (objet ODF dans la publi ODT) OU (objet flash dans la publi HTML)
Problème actuelle :
- La conversion MathML vers ODF donne pour certaines formules MathML et LaTeX des résultats faux
- Des tests plus récents ont montré que la conversion LaTeX -> MathML traite un sous ensemble limité du LaTeX, qu'il y a une 2eme faiblisse dans la chaîne de conversion
Parmi les utilisateurs d'OpaleSup ils ont surtout du LaTeX, mais certains acteurs avec du MathML ou de l'ODF.
Questions utiles pour caractériser les contenus
- Combien avez vous de formules par module ? (moyenne et max approximativement, tu dois pouvoir compter le nombre de fichiers swf dans la génération web)
- quelle est la longueur des formules que tu utilise ? y a t'il beaucoup de formules de quelques carractères ? beaucoup de formules sur une seul ligne qui dépasse la largeur d'un écran ? beaucoup de grosses formules sur plusieurs lignes.
- actuellement, quels proportions de formules sont invalides a la publication ?
- sous quel(s) format(s) (latex, mathml, ODF?)
- avez vous des besoins particuliers (du type mise en forme des formules d'une manière particulière, formules en couleur, retravail des formules après la publication a l'intérieur de l'ODT...)
- d'autres problèmes à signaler toujours sur les forumes ?
| Attention ! |
|---|
Nous vous invitons a donner des jeux de contenus exemples (liens sur le forum ou par mail stephane.poinsart@…). |
Solutions possibles
En partie redondantes entre elles
Refaire la conversion MathML vers ODF
- Franck peut travailler pour refaire une XSL de conversion MathML vers ODF. > [anp] Je suis trés optimiste sur cette solution. Le format natif des math dans OpenOffice n'est pas MathML, mais plutôt la syntaxe "String" qui permet d'arriver au même résultat que ce que l'on peut faire avec l'éditeur OO. PISTE : partir d'une XSL MathML2Latex existante, et la personnaliser.
ou
- (si j'ai bien compris,) bricoler à l'intérieur de l'ODF pour essayer de corriger certains problèmes)
[anp] solution de contournement extrêmement chronophage car basée sur la détection de dysfonctionnement et leur contournement.
Tâches :
- ??? jours de travail par Frank pour la partie conversion
- quelques jours par kelis pour l'intégration
+ tests et validation
Avantages :
- Remet le moins en cause la chaîne de transformation des ressources existante
- La communauté peut plus efficacement participer aux développements
- Permettrait de rendre paramétrable et d'homogénéiser le stylage de l'équation
Inconvénients :
- Dépendance vis à vis d'OpenOffice pour tous les autres bugs qu'on peux rencontrer par ailleurs, risque de ne pas corriger 100% des formules rendues invalides
- Dépendance vis à vis d'OpenOffice pour l'alignement vertical (pas de résolution avant des mois, des années...)
- Dépendance vis à vis d'OpenOffice sur la qualité des sorties bitmap si on en voulait pour Opale ou d'autres modèles (pas d'anti-aliasing ?)
- Les scripts LaTeX -> MathML ont aussi des limites, et donc les formules LaTeX auront toujours des erreurs, il est possible d'en corriger certaines mais en raison des très nombreuses possibilités d'expression d'une seul formule en LaTeX, il y aura toujours un grand nombre qui ne passeront pas lors de l'ajout de nouvelles.
Prérequis :
- valider les possibilités offertes par l'éditeur de math d'OpenOffice : spectre identique à MathML2 ou sous-ensemble ?
Conversion outils LaTeX -> PNG
On peux modifier complètement la chaine :
- LaTeX -> DVI -> PNG (100dpi environ pour le web, 300dpi pour le papier)
La qualité semble plutôt bonne, on peux tester sur : http://hausheer.osola.com/latex2png (code source -> http://hausheer.osola.com/software/latex2png.phps )
Exemple d'implémentation en Java dans un autre programme : http://www.thrysoee.dk/laeqed/
Tâches :
- [anp] quels API/outils à intégrer dans SCENARI (garder en tête les problématiques de licence et de multi-OS) ? Quel poids (Mo)?
- ??? jours kelis
- ??? ??? ???
Avantages :
- Les outils LaTeX savent gérer leurs propres formules, on est presque certain que la formule sera aussi valide que celle qu'un utilisateur qui utilise LaTeX sans chaîne éditoriale obtient
- Solution assez conforme a tous les autres système sachant traiter des formules de math (moodle, wikipedia...)
- Piste possible concernant l'alignement vertical sous réserve d'un peu plus de développements ( http://mactextoolbox.sourceforge.net/articles/baseline.html , http://boyle.black-holes.org/dokuwiki_latex ), nécessite confirmation de faisabilité par Kelis
- sortie PNG légèrement plus légère que le flash.
Inconvénients :
- nécessite pas mal de changements coté Scenari (code)
- nécessite d'embarquer un système latex dans la SCENARIapp OpaleSup, les outils Scenari, ou de les faire installer par l'utilisateur (argument modéré par le fait qu'on s'oriente un peu vers cette direction pour des générateurs "full latex")
- sortie PNG pour le papier légèrement plus lourde que l'ODF (dépend de la longueur et du nombre de formules, pas de problème si la majorité des formules sont courtes, ou s'ils y en a un nombre raisonnable, moins de 200 par module)
- on ne sais pas encore si la génération sera plus rapide ou moins rapide
- avec une image en résultat, on ne peux absolument pas faire des ajustements à la main dans l'ODT généré
Autres solutions type LaTeX -> ... -> format publication
- Utiliser mimeTex, un moteur de rendu qui fonctionne en standalone, sur un exécutable de moins d'1 mo http://www.forkosh.com/
http://www.forkosh.com/mimetexmanual.html Il renvoie aussi des données sur l'alignement vertical. Par contre, le rendu est acceptable mais un peu moins naturel que latex (la forme des fonts). Ou
- utiliser LaTeX + pstoedit pour faire des conversions du type LaTeX -> dvi -> ps -> format vectoriel SVG / Flash (mais j'imagine que c'est un peu plus lourd)
Remarques
- Ne répond pas aux besoins des utilisateurs qui saisissent nativement en MathML (a priori une petite partie des utilisateurs), si on choisi de s'en préoccuper, nécessite de tester les XSL de conversions MathML->LaTeX et de voir si elles sont satisfaisantes / si on peux les intégrer ( http://xsltml.sourceforge.net/ , http://www.cse.ohio-state.edu/~gurari/docs/mml-00/xhm2latex.html )
- Doit on aussi utiliser le moteur LaTeX pour la preview dans l'éditeur Scenari ?
Annexes
Cela ne remet pas en question en parallèle le travail de Fabien sur "publi complète latex"
Pour information, autres anciennes pages sur les maths:
