Outils pour utilisateurs

Outils du site


public:specs_graphics_rendering_and_display

Spécifications techniques du composant de production et de rendu de graphiques interactifs

Ces spécifications correspondent au Ticket #269.

Voir la section Avancement dans l'élaboration de la solution pour la description des phases de développement.

Objectif

Méthode

Marche à suivre :

  • Développer l'architecture du moteur de production de graphiques
    • ChartsEngine
    • RChartsEngine : sorties SVG, PDF, EPS, PNG, JPG et BMP.
    • JFCChartsEngine : sortie objet Java JFreeChart
  • Vérifier que les rendus SVG, PNG fonctionne dans la RCP et dans TXM Portal avec cette nouvelle architecture
  • Définir le plus possible les spécifications fonctionnelles
  • Développer l'architecture du fournisseur de composants SWT : ChartsComponentProvider
    • SVGChartsComponentProvider
    • JFCChartsComponentProvider
    • RasterImageChartsComponentProvider
  • Développer un thème graphique JFC basé sur le rendu de la lib GWT highcharts http://www.highcharts.com/demo/line-basic

TBD TXM Portal: GWTHighChartsEngine : produire directement du JavaScript ou du code Java GWT ? Le problème du Java GWT et qu'il faudra le pré-compiler donc a priori il n'y aurait aucun gain à générer du Java. Utiliser aussi un ComponentsProvider pour TXM Portal ?

TXM Portal : voir aussi : http://www.jfree.org/jfreechart/api/javadoc/org/jfree/chart/ChartUtilities.html#getImageMap%28java.lang.String,%20org.jfree.chart.ChartRenderingInfo,%20org.jfree.chart.imagemap.ToolTipTagFragmentGenerator,%20org.jfree.chart.imagemap.URLTagFragmentGenerator%29. JFC permet de créer une imagemap que l'on peut inclure dans du HTML et permettant d'exporter les tool tips (dans quelle mesure ?) et d'ajouter des liens hypertextes sur les items. Voir aussi : http://faresibneyyusuf.blogspot.fr/2008/07/gwt-with-jfreechart-in-jbossportal.html pour un exemple génération dynamique et de visualisation de jpeg depuis JFC avec JBossPortal. Autre lien utilisant des imagemap : http://www.jfree.org/phpBB2/viewtopic.php?t=19080.

TXM Portal : voir en premier lieu le projet Gimv (Google Web Toolkit™ Image Viewer) : https://code.google.com/p/gimv/wiki/UserGuide#JFreeChart_sample et http://code.google.com/p/gimv/source/browse/trunk/gimv/lib/samples/jfreechart?spec=svn3&r=3, dédié à la visualisation d'images interactives.

Après tests de l'exemple fourni, le couple Gimv / JFreeChart semble prometteur et permettrait de produire des graphiques via le JFCChartsEngine, donc de conserver les thèmes graphiques JFC créés et de profiter des fonctionnalités de base apportées par Gimv. L'intérêt ici est de pouvoir profiter de certaines fonctionnalités de JFC, notamment du recalcul du graphique par JFC (changement d'échelle) au zoom/pan, par exemple) de manière asynchrone. Il faudrait tester la compatibilité avec tous les navigateurs, car le projet Gimv semble n'avoir pas été mis à jour depuis 2010. Lien vers le war : gimv_jfreechart_sample.zip. Actuellement je n'ai pas bien compris si le recalcul du graphique était réellement fait via un nouvel appel à JFC qui créerait un nouveau JPG, je pense que c'est ce qui se produit mais je ne trouve pas de nouveau JPG dans le dossier tmp de Tomcat lors d'un zoom ou d'un pan.

État de la plateforme

Avancement dans l'élaboration de la solution

  1. Seb a créé un nouveau type de moteur pour le rendu de Graphique : ChartEngine
    • il comprend des plugins au niveau de la TBX et de la RCP
    • il a ajouté la librarie tierce jfreechart (sous forme de plugin)
  2. Pour des raisons de dépendances cycliques entre plugins et pour pouvoir builder TXM, Seb a déplacer les packages des plugins soit dans la TBX soit dans la RCP
  3. Seb a commité tout son travail le 18/03/2014

Solution

Spécifications techniques/Choix technologiques

Suite aux recherches et aux solutions envisagées, la solution retenue est la suivante :

La solution s'articule sur 3 composants principaux :

  • le développement d'objets Java de résultats, ex. : CA, CAH, etc. contenant la sémantique propre aux besoins de TXM
  • le moteur de production de graphiques (niveau Toolbox)
  • le fournisseur de composants SWT dédiés aux graphiques (niveau RCP)

TODO : TXM Portal :

  • voir GWT HighCharts http://www.highcharts.com/demo/line-basic (c'est par ailleurs ce qui est utilisé pour les stats de download dans SourceForge a priori)
  • implémenter un GWTHighChartsEngine ? produire directement du JavaScript ou du code Java GWT ? Le problème du GWT et qu'il faudra le pré-compiler donc a priori il n'y aurait aucun gain.

Utiliser aussi un ComponentsProvider pour TXM Portal ?

Objets Java de résultats

Voir : solution 3

Moteur de production de graphiques

Il s'agit ici de centraliser toutes les fonctionnalités de production de graphiques dans un seul composant. Le composant définit une interface contenant des méthodes de production de graphiques à partir de tout type de résultats.

Structure

  • ChartsEngine (abstract, root)
  • RChartsEngine (Moteur basé sur R)
  • JFCChartsEngine (Moteur basé sur JFreeChart)

Un moteur courant est défini par une préférence et il est stocké au niveau de la Toolbox. Le moteur prend en entrée un objet de résultat TXM et produit un Object en sortie, en fonction de son implémentation et de sa configuration. Le RChartsEngine, par exemple, prend en entrée un objet CA et produit un fichier SVG, PNG, etc. Le JFCChartsEngine, lui, produit des objets Java JFreeChart.

Fournisseur de composants SWT

Il s'agit ici de centraliser la création de composants SWT (en particulier d'EditorPart) en fonction d'un objet de résultat TXM et du moteur de production de graphiques courant.

Structure

  • ChartsComponentProvider (abstract, root)
  • SVGChartsComponentProvider (crée un objet File de type SVG via le RChartsEngine ou le JFCChartsEngine en fonction du type de résultat et retourne un EditorPart contenant un viewer SVG)
  • RasterImageChartsComponentProvider (crée des objet File de type raster : PNG, JPG, etc. via le RChartsEngine ou le JFCChartsEngine en fonction du type de résultat et retourne un TXMWebBrowserEditor)
  • JFCChartsComponentProvider (crée un objet JFreeChart/Java2D via le JFCChartsEngine en fonction du type de résultat et retourne un EditorPart)

TODO

  • RasterImageChartsComponentProvider a été développé de manière “rapide”, pour les tests et pour continuer à proposer la production directe et surtout la visualisation directe de fichier PNG, JPG. D'autre part, c'est lui qui gère également la production de fichiers vectoriels PDF et PS et qui lance le viewer externe par défaut de la machine cliente. C'est donc plutôt actuellement une classe de tests sur laquelle il faudra revenir une fois que nous aurons défini les besoins en export et en visualisation de la RCP voir Export des graphiques. Dans l'absolu je pense que cette classe devrait disparaître au profit de l'export en PDF, PS, PNG, JPG depuis d'autres EditorPart.
  • Dans le cas du JFCChartsComponentsProvider, les structures et systèmes de liaison entre l'objet JFreeChart/Java2D, l'objet Java de résultat et les listeners d'événements restent à définir

Fonctionnement autonome Toolbox

Fonctionnement avec RCP

Prototypes

  • Le moteur de production de graphiques courant est stocké en tant que membre statique dans la classe org.txm.toolbox/src/java/org/txm/Toolbox.java
  • Le fournisseur de composants SWT courant est stocké en tant que membre statique dans la classe org.txm.rcp/src/main/java/org/txm/rcpapplication/Application.java

Version finale

Terminologie/Traduction

Recherche sur une terminologie pour englober tous les types de graphiques. Plusieurs mots anglais : chart, graphic, graph, plot. Il semblerait que “plot” en anglais n'est pas un nom mais plutôt un verbe qui veut dire “tracer un graphique”. “graphic” dans le sens “graphique de stats” ne semble pas s'utiliser comme nom mais uniquement comme adjectif. Quant à lui, “graphic” en tant que nom, semble signifier plutôt “graphisme” (comme dans Graphics Engine). Pour englober tout type de graphiques il semblerait qu'il ne reste que “chart” et “graph” mais comme “graph” signifie également “graphe” en français ça semble trompeur mais de plus nous aurons également a priori besoin de réserver ce mot pour qualifier les graphes dans le code source.

Le choix a donc été fait d'utiliser “chart” dans le code source pour définir la “racine” de tout type de graphiques.

En attente

Procédure générale des recettes

  1. Faire fonctionner TXM (d'après les sources dans Eclipse) : test en run, faire un build et vérifier les graphiques (~recette minimale) (SJ + MD)
  2. Découper en morceau le ticket #269
  3. Écrire la recette ALPHA
  4. Publier la mise à jour en ALPHA (BP + SH)
  5. Faire la recette ALPHA de TXM 0.7.6 (version cible virtuelle pour ce travail avec les tickets CBP) et cycles de réglage
    • il y aura peut-être à retravailler des specs
      • des recettes partielles
  6. Écrire la recette BETA
  7. Publier la mise à jour en BETA
  8. Mettre à jour le manuel
    • voir avec Serge
  9. Publier la mise à jour en STABLE

A discuter avant les tests ?

  • discuter de l'ancienne fonction “export SVG” accessible depuis l'arbre des corpus au clic droit sur un graphique ou depuis la tool bar RCP, que doivent exporter ces fonctions ? la vue ? le graphique complet ? Actuellement elles exportent le graphique complet et ne tienne pas compte du charts engine courant, les fonctions utilisent toujours R et SVG.
    • si l'éditeur est fermé, on ne peut pas exporter la vue, ceci est couplé avec la discussion de Framapad sur ce que représentent ces noeuds de type graphique dans l'arbre (mais pour les autres types de noeuds également). Est-ce qu'il s'agit de l'éditeur ou bien d'un résultat source ? Concrètement si on ferme un onglet de graphique après avoir effectué des zooms, pans, changement de couleur, des polices, etc., lorsqu'on réouvre cet éditeur doit-on restaurer ces changements fait par l'utilisateur ? Le comportement actuel de TXM, sur tout type de noeuds dans l'arbre, est de régénérer complètement un nouvel éditeur et donc de perdre toutes les modifications utilisateur
    • c'est en lien aussi avec la discussion sur la création de sous-noeuds pour les graphiques
    • suite à la dernière réunion, on avait décidé de remplacer cette commande par la nouvelle commande commande d'export des graphiques en fonction du moteur courant mais il faudrait en rediscuter notamment car WordCloud l'utilise. Dans un premier temps il faudrait peut-être désactiver l'affichage de cette commande pour les éditeurs de type Chart Editor ? (vu que l'export se fait maintenant via la toolbar directement dans les éditeurs)
    • d'autre part, attention cette commande est utilisée par exemple par WordCloud qui est généré hors des charts engines
    • [Après discussions : renommer la fonction “Export SVG” en “Export chart” et la linker au charts engine courant. Cette fonction exportera le graphique directement via le charts engine (donc sur le même principe que lorsqu'il est créé pour la première fois quand il est passé au chart editor, et donc sans tenir compte de la vue dans l'éditeur)] SJ: FAIT
  • discuter du fait d'adapter les graphiques R à ceux JFC : ajout des mêmes labels et des mêmes titres (ex. Singular Values Bar Plot)
    • par ailleurs jusqu'à quel point abstraire le système, ex. : permettre d'afficher/masquer les labels, changement de couleur des titres, des polices, etc. pour le moteur R ?
    • concrètement discuter de l'investissement dans le moteur de graphiques R, sachant qu'à priori cela restera celui utilisé par le portail pendant quelques temps (ou tout simplement pour continuer à le proposer dans TXM tout en l'améliorant grandement)
    • D'autre part, ceci peut être fait soit directement au niveau de R (TBX) soit au niveau Batik (RCP, mais très difficilement étant donné que les SVG générés sont différents selon les moteurs de graphiques mais également selon les devices R SVG)
    • [Après discussions : le but est de se baser sur JFC et de reporter dans R, les titres, noms d'axes, etc. afin d'avoir une homogénéité]

Recette

Protocole de test

Notes pour les tests de la 0.7.6 alpha

  • les graphiques implémentés actuellement dans le nouveau mode de rendu Java/JFreeChart sont : AFC, Diagramme à bâtons des valeurs propres, Dimensions de partition, Spécificités (mode lignes et mode bâtons), Progression (cumulative, implémentation partielle à retester). La Progression (densité) génère un graphique factice afin de montrer à quoi pourra ressembler le rendu une fois implémenté et notamment le rendu de courbes “lisses”
    • NOTE DEV : remettre la version R de la Progression si une release publique est faite et que l'implémentation JFC n'a pas encore été faite
  • pour les retours de test de type bug ou modification, je propose de modifier directement les tickets :
    • AFC #702
    • Diagramme à bâton des valeurs propres #702
    • Dimensions de partition #706
    • Spécificités #707
    • Progression #709
  • pour les ajouts de fonctionnalités, je propose de modifier directement les pages de spécifications du Wiki (en français) : Spécifications fonctionnelles de la visualisation et des interactions avec les graphiques de résultats et/ou de poster sur txm-info
  • (NOTE : pour les retours, voir aussi la section “Etat courant” en bas de page qui liste les bugs connus et les fonctionnalités non encore implémentés dans la version 0.7.6)
  • la sélection du moteur de graphiques courant est définie dans les préférences de la RCP : “TXM\Advanced\Charts engine” (“Current Engine”), on peut choisir “R” ou “Java” (“Java” correspondant au nouveau moteur JFreeChart)
  • les éditeurs possèdent maintenant un bouton nommé “Export view” dans leur barre d'outil qui permet d'exporter le graphique tel qu'il apparaît dans l'éditeur (pan et zoom compris)
  • commandes des éditeurs :
    • Zoom : molette souris
    • Pan : drag + clic droit
  • les graphiques suivants ne sont pas encore implémentés dans le moteur Java/JFC :
    • CAH
    • Progression (densité)
    • les préférences “Draw curves/Draw bars” des Spécificités fonctionnent un peu différemment avec JFC par rapport à R. R superpose les 2 types de graphiques si les 2 check boxes sont cochées. JFC, quant à lui, trace soit en lignes soit en diagramme à bâton mais ne gère pas la superposition (NOTE DEV : en attente de discussion)
  • le thème graphique créé pour l'implémentation JFC définit actuellement 4 couleurs et 4 formes pour les séries/catégories des différents graphiques. Les formes et les couleurs des 4 premières séries sont basées sur le default theme de la lib Javascript Highcharts. Au delà de 4 séries, les séries supplémentaires utilisent le thème par défaut de JFC pour produire les formes et les couleurs. Les 2 séries des nuages de points de l'AFC ont été traitées à part.

Alpha

[SJ: les tests/questions suivants n'ont semble-t-il pas été traités lors de l'apha 0.7.6, je les transfère dans la roadmap 0.7.7 avant de les trier]

  • NOTE : s'il est activé, il faut désactiver le “Mode expert” dans les préférences avancées de TXM. Le mode expert permet de spécifier le type de sortie de chaque moteur, ce qui est inutile pour les tests
  • pour chaque type de graphique actuellement implémenté, créer un graphique en mode R et le même graphique en mode Java/JFreeChart pour les comparer en mettant les onglets cote à cote (cela implique de changer de “Current Engine” dans les préférences entre chaque commande)
    • tester les graphiques avec les différentes préférences possibles et qui sont liées au rendu de graphiques (ex. : Specifités : draw bars, draw curves, grayscale, etc.)
    • tester le rollover sur les entités des graphiques et les tool tips générés au rollover (en mode JFC)
  • tester “Export view/Exporter la vue” en mode R et en mode Java/JFreeChart pour chaque type de graphique implémenté et pour chaque type de fichier proposé à l'export (SVG, PNG, etc.) (Le choix du format d'export se fait en sélectionnant l'extension de fichier dans la boîte de dialogue d'export)
    • tester dans les 2 modes que les fichiers générés par “Export view” sont bien conformes à la vue réelle du graphique dans l'onglet de visualisation de graphiques TXM (tester tous les formats d'export)
    • tester l'ouverture de différents fichiers SVG générés dans différents logiciels d'édition de fichiers SVG (ex. Inkscape) et dans différents navigateurs Web
      • les fichiers SVG et PDF exportés en mode Java/JFreeChart doivent normalement contenir des textes éditables/sélectionnables
      • les fichiers SVG et PDF exportés en mode R doivent également contenir des textes éditables/sélectionnables mais ça n'est pas le cas actuellement pour le format SVG à cause du problème de device R Cairo ne générant pas de balise “text” dans les fichiers SVG
  • fermer et réouvrir des éditeurs de graphique en ayant changé de “Current Engine” entre temps (actuellement seule les CA créent une entrée dans l'arbre des corpus, CAH n'étant pas implémentée pour le moment en mode JFC, le test ne peut donc se faire que sur les CA)
  • tester et définir la politique de redimensionnement des graphiques lorsque l'on redimensionne un onglet/éditeur (ex. : contraindre l'AFC à des dimensions carré ?)
  • vérifier les textes des nouveaux labels : tool tip, préférences, label de bouton, etc. dans les langues FR et EN
  • pour les CA, vérifier la colonne du cumul des pourcentages que j'ai ajoutée dans l'onglet “Singular values” #802

Beta

État courant

  • export view depuis R vers SVG ne cadre pas la vue telle qu'elle apparaît dans l'éditeur (le graphique complet est exporté) * NOTE DEV : j'ai besoin de trouver comment passer la zone de visualisation dans le fichier SVG généré. Actuellement le graphique complet est exporté et ne tient donc pas compte du zoom/pan : en attente de discussion sur l'investissement à consacrer au moteur de production de graphiques R [SJ: moved to issue #1113]
  • les fichiers exportés en SVG depuis le mode R utilise le nouveau RDevice Cairo-SVG et il n'y a donc pas de balise “text” dans les SVG, ce qui les rendra difficilement exploitables dans des éditeurs SVG
public/specs_graphics_rendering_and_display.txt · Dernière modification : 03/12/2014 13:52 de sebastien.jacquot@univ-fcomte.fr