Accueil > Projets > ScientificPad / MathMLPad [fr] > ScientificPad / MathMLPad Progression du projet Alpha 201303022100

ScientificPad / MathMLPad Progression du projet Alpha 201303022100

Informations sur la future version de la branche Alpha.

jeudi 7 mars 2013, par ScientificWare

Après avoir hésité assez longtemps sur la manière de produire les glyphes extensibles, je viens d’arrêter mon choix. La solution trouvée donne pour l’instant des résultats assez satisfaisants (pour 4 ou 5 lignes de code). Ça fait du bien de changer de version !

L’image ci-dessous est une capture d’écran de plusieurs calculs à des tailles différentes.

Une rapide discussion avec Calixte Denizet responsable du projet JLatexMath me laisse espérer qu’il est possible de produire un éditeur d’équation conforme à ce qu’attendait Calixte et Markus Hohenwarter créateur de Geogebra. Ils avaient proposé, en 2009 pour Calixte et 2011 pour Markus, la création d’un éditeur mathématiques lors un GSoC [1] sur la même base que ScientificPad pour l’application GeoGebra. Comme beaucoup d’enseignants, je suis un grand utilisateur de Geogebra et la présence d’un éditeur mathématique (même rudimentaire) serait un pur bonheur.

Ce bref échange m’a rassuré sur tout le travail déjà accompli mais il a surtout permis de résoudre indirectement un problème datant de 1998 (avec JAVA/AWT) puis 2007 (avec JAVA/SWING) : comment représenter les glyphes extensibles.
 La solution que j’avais adoptée ne me satisfaisait pas pleinement car le dessin des glyphes ne s’adaptait pas à la taille des caractères.
 J’ai parcouru beaucoup de notes, examiné de nombreux programmes sans trouver ma solution. La plupart des éditeurs de formules ont choisi l’assemblage de glyphes mais les rapports des assemblées TEX, la création OpenType Math et mes propres essais montrent que ce n’est pas simple à mettre en oeuvre. La copie d’écran ci-dessous montre que sous LibreOffice les glyphes de base du caractère « radical » ne sont pas correctement alignés

J’ai découvert JLatexMath en septembre 2012 en voulant installer Scilab. Sous sa forme actuelle il est doté d’une interface utilisateur basée sur Java et peut désormais afficher les formules grace à JLatexMath.
 Une première lecture du code ne m’avait pas permis de comprendre comment fonctionnait le rendu des glyphes extensibles. J’ai donc remis à plus tard mon analyse pensant que ma solution viendrait peut être de MetaFont [2] de Donald Knuth et ses polices Stroked.
 Finalement en fouillant sur le net, je suis tombé sur une description de Calixte pour un éditeur Géogébra. Ce qu’il décrivait correspondait exactement à mon travail mais avec un rendu réalisé avec JLatexMath. Je l’ai donc contacté aussitôt. Sur ses conseils, je me suis replongé pour une nuit blanche dans le code source de son application et ouvert le livre « The TEXBook » de Knuth. JLatexMath est conforme à l’approche de Knuth : glyphes spécifiques puis assemblage de glyphes au delà d’une certaine taille. C’est une déception car cette mise en oeuvre est problématique et dépend trop des polices de caractères.
 Donc retour à ma solution de 2007 et en cherchant un peu dans l’API de Java j’ai trouvé une méthode qui finalement me plait. Les glyphes obtenus ne sont pas parfaits, mais je sais comment améliorer la chose. Le temps de produire tous les grands glyphes puis les glyphes extensibles nécessaires et je me lance sur le chemin que m’a suggéré Calixte (ajouter le parseur de JLatexMath et produire des composants sous forme de JavaBeans pouvant être intégrés à un IDE comme NetBeans par exemple).


[1GSoC désigne le Google Summer of Code, un évènement annuel organisé par Google pour des étudiants et visant à produire un logiciel libre contre rémunération.

[2MetaFont est une application qui permet de créer des polices de caractère pour TEX. Son intérêt réside dans une approche que je qualifirais de « calligraphique » puisqu’elle reproduit le travail d’une plume d’écriture alors que les polices TrueType ou OpenType ... définissent des contours qui sont ensuite peints.