J'ai l'impression qu'il manque une bonne librairie pour tracer des graphs dans le monde du libre.
Très bonne remarque. Je suis de ceux qui aimeraient voir gnuplot devenir aussi une librairie. Il y a bien Qwt (C++) et matplotlib (python), mais si on avait une vraie librairie en C, on pourrait imaginer des bindings vers n'importe quel langage.
Voici le statut actuel des choses:
* le problème majeur est d'extraire une API du code de gnuplot. Actuellement, le 'parser' (analyseur lexical/syntaxique) de gnuplot est complètement mélangé au reste du code. Il faudrait séparer tout ce petit monde en deux couches distinctes, la première étant l'interface utilisateur, la deuxième étant accessible en tant que librairie "standard", via des commandes du genre:
* un deuxième problème est la séparation entre les fonctions de plot et de lecture des fichiers de données. Gnuplot est très fort pour lire des fichiers formatés en colonne, avec des séparateurs variés, ou en matrice (sans abscisses ni ordonées explicites), ou encore avec des dates/heures. Heureusement, cette partie du code est déjà relativement séparée du reste.
* enfin, pour ce qui est de l'export graphique, je suis d'avis qu'il faut garder la plupart des terminaux gnuplot comme ils sont : latex, metapost, gd (gif, png, jpeg) et cairo (svg, postscript, pdf, mais Xlib, Win32, Quartz). La bonne nouvelle est que tout ce code existe déjà ! Gnuplot 4.2 utilise cairo pour le terminal interactif 'wxt', un patch est en développement pour exporter en pdf avec (et ce patch est minuscule comparé au code déstiné à cairo déjà dans gnuplot, c'est la force de cairo), et il serait relativement simple de l'étendre sous forme de librairie pour que gnuplot exporte vers n'ilmporte quelle surface que gnuplot sait gérer.
Il ya donc du travail, mais rien n'est impossible. S'il y a des volontaires, au passage...
[^] # Re: Et pourquoi pas une libgnuplot ?
Posté par tipote . En réponse à la dépêche Gnuplot 4.2 est disponible !. Évalué à 5.
Très bonne remarque. Je suis de ceux qui aimeraient voir gnuplot devenir aussi une librairie. Il y a bien Qwt (C++) et matplotlib (python), mais si on avait une vraie librairie en C, on pourrait imaginer des bindings vers n'importe quel langage.
Voici le statut actuel des choses:
* le problème majeur est d'extraire une API du code de gnuplot. Actuellement, le 'parser' (analyseur lexical/syntaxique) de gnuplot est complètement mélangé au reste du code. Il faudrait séparer tout ce petit monde en deux couches distinctes, la première étant l'interface utilisateur, la deuxième étant accessible en tant que librairie "standard", via des commandes du genre:
gnuplot_crerate_context(...);
gnuplot_set_borders(...);
gnuplot_set_pm3d(...);
gnuplot_plot(data);
* un deuxième problème est la séparation entre les fonctions de plot et de lecture des fichiers de données. Gnuplot est très fort pour lire des fichiers formatés en colonne, avec des séparateurs variés, ou en matrice (sans abscisses ni ordonées explicites), ou encore avec des dates/heures. Heureusement, cette partie du code est déjà relativement séparée du reste.
* enfin, pour ce qui est de l'export graphique, je suis d'avis qu'il faut garder la plupart des terminaux gnuplot comme ils sont : latex, metapost, gd (gif, png, jpeg) et cairo (svg, postscript, pdf, mais Xlib, Win32, Quartz). La bonne nouvelle est que tout ce code existe déjà ! Gnuplot 4.2 utilise cairo pour le terminal interactif 'wxt', un patch est en développement pour exporter en pdf avec (et ce patch est minuscule comparé au code déstiné à cairo déjà dans gnuplot, c'est la force de cairo), et il serait relativement simple de l'étendre sous forme de librairie pour que gnuplot exporte vers n'ilmporte quelle surface que gnuplot sait gérer.
Il ya donc du travail, mais rien n'est impossible. S'il y a des volontaires, au passage...