Liste de liens :
Liste de liens :
Offrir un système d'export de graphiques. On peut distinguer 2 niveaux d'export avec le système actuel, l'export au niveau TBX et l'export au niveau RCP.
L'export au niveau TBX consiste à produire un graphique en fonction d'un résultat TXM (AFC, dimensions de partition, etc.). Selon l'implémentation courante du charts engine défini dans les préférences de la TBX, il permet de créer des fichiers (ex. SVG, PNG, etc.) ou des composants Java (ex. objet JFreeChart - objet Java dédié au rendu et à la manipulation de graphiques). C'est cet export TBX qui est en fait utilisé pour “transférer” les graphiques depuis la TBX vers la RCP. On pourrait parler ici d'“export brut”, d'“export du graphique complet” (ou “full chart export”). Le système actuel permet de recadrer (crop) un graphique avant export des formats raster par RChartsEngine ou JFCChartsEngine. Les formats vectoriels ne peuvent pas être recadrés à l'heure actuelle.
L'export au niveau RCP consiste à exporter ce qui est visible dans l'éditeur (EditorPart SWT) dédié au rendu et à la manipulation de graphiques dans la RCP. La RCP peut également utiliser le mécanisme de la TBX et donc proposer un export complet du graphique. Je pensais utiliser ce mécanisme, c'est-à-dire repasser par la TBX pour exporter la vue, en croppant par exemple. Cela fonctionnerait mais en réalité il faudrait anticiper le système d'annotations utilisateur qu'il est prévu de mettre en place. Du coup, il faudrait que l'export de vue ne repasse par TBX mais soit directement effectué depuis les composants SWT.
Dans un premier temps, il faudrait sans doute définir ce qu'il faut proposer à l'utilisateur depuis l'UI de la RCP (export brut, export de vue ?).
L'export de la vue en raster consistera sans doute à du simple cropping de ce qui est rendu dans l'EditorPart.
A noter que cela risque d'être extrêmement difficile d'exporter la vue “telle quelle” en format vectoriel, à moins peut-être d'utiliser un view port (l'attribut sbg.viewBox permettrait peut-être de faire cela facilement, dans ce cas tout le graphique est tout de même exporté mais un viewport est défini restreignant ainsi l'affichage à une zone donnée, cela semble une solution intéressante. Il faudrait voir comment viewBox est gérée par différents logiciels d'édition SVG et par différents navigateurs Internet).
La solution du viewport fonctionne avec JFC, il faudrait maintenant tester l'import des SVG générés dans différents logiciels d'édition de SVG et différents navigateurs.
[2014.03.19]
Voici un diagramme représentant l'état actuel avec le module de production de graphiques.
Les capacités d'export de la RCP restent à définir notamment celles de type “vue”. Sachant que la RCP peut utiliser toutes les capacités d'export de la TBX de type “export complet”. Concrètement la RCP peut/pourrait réexporter ce qu'elle prend en entrée en rappelant les fonctions d'export de la TBX mais certaines préférences stockées au niveau RCP doivent repasser au niveau TBX pour cela mais au final ça n'a pas forcément d'intérêt si l'on privilégie l'export de vues. Même sans cela, étant donné que c'est la TBX qui produit les graphiques, toutes les préférences RCP liées au rendu graphique devraient a priori être définies et stockées au niveau des préférences TBX, en particulier pour la production de graphiques pour le portail.
- Le moteur JFCChartsEngine ne permet pas l'export vers le format .ps. Au besoin voir : EpsGraphics2D class at jibble.org is GPLed