Michael Barton wrote: > >> However, I > >> suggested that matplotlib might be quite suitable for this kind of > >> task. It is a free, pure Python library that can do very > >> sophisticated > >> graphing very easily. It can be 1) wrapped into the GUI display, 2) > >> set to create it's own simple display in a couple of GUI toolkits, or > >> 2) set to output to a graphic file. It is scriptable. I submitted a > >> couple of test scripts to show how this might be accomplished. > > > > We would need to determine how to make it respect the various > > environment variables so that commands which use matplotlib can be > > mixed with those which use the display/raster libraries. > > Sorry, but I don't understand. It is an external library (like > gnuplot, but seems a bit easier to work with for me at least). It can > plot to graphic files or a display canvas it creates, OR it can be > included in the GUI (though this takes somewhat different programming > to make it plot to the GUI display canvas). It was fairly easy to > include this in scrips. But maybe you are thinking of using it in a > more sophisticated way than I am.
The intention is to have a single graphics architecture whose components can be combined in arbitrary ways. Not a bunch of disparate scripts, generating different formats, recognising different options, using different sets of fonts, etc. AFAICT, we would need either a wrapper around matplotlib so that it honours all of the GRASS_* variables related to graphics, or a matplotlib "backend" which uses the display library. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
