I'm off with family for the holidays, so my response will have to be somewhat brief.
I'm excited about the ideas you bring up... I first heard about sympy at SciPy and was very impressed. Let's try to collaborate in any way possible. I know that "3D in matplotlib" already has some history of which I'm not aware, so I'll leave that for others to comment on. As for the C++ dependencies, Agg is a pretty strong one. Yes, it is possible to do rendering with Gtk or Wx alone, but it's not very pretty (no-aa). Gtk/Cairo is a good high-quality combination, but it (at least currently) leaves out all the other GUI frameworks, and is not BSD-like licensed. The other important C/C++ requirement is matplotlib's interface to freetype (FT2Font). That would be really painful to reimplement in pure Python -- freetype is a complex and mature piece of software. In the trunk, there is a required framework for transformations, and in the "transforms branch" there is a framework for polycurve manipulations, both of which are required to do any plotting. Those would have a major performance penalty going to Python, and even notwithstanding, are non-trivial bits of code to reimplement. Beyond that, there are utilities for contours and images etc., which are reasonably optional but people use all the time. In short, there's a not of C/C++ in the core of matplotlib -- maybe the time would be better spent resolving any build issues that make portability difficult...? I'm not sure it's realistic to expect matplotlib to be pure Python at this point without losing a lot of features, but I agree it would be nice... As for the mathtext Python math rendering engine, it isn't *really* pure Python. It relies on matplotlib's interface to Freetype. Ideally, it would be nice to have a general-purpose Python interface to freetype (I know the PyCairo folks are wanting such a thing), and then the mathtext engine could use that. Unfortunately, the existing freetype wrapper in matplotlib is very incomplete and pretty tied to matplotlib-specific ways of doing things. IMHO, you wouldn't really gain much by releasing FT2Font as a separate project unless it were generalized. I've sort of gone into a holding pattern, hoping someone else will release a Python freetype wrapper that matplotlib could use... Alternatively, the dependency on freetype could be removed by extracting and hardcoding all the font metrics from the math fonts into Python dictionaries etc. -- but then of course it would only work with a fixed set of fonts. This is what jsMath, (a pure-Javascript math rendering engine) does, for instance. With the exception of that issue, removing the mathtext engine from matplotlib should be possible, and I think it's a great idea. There are some matplotlib- specific bits mixed in there, but they should be reasonably straightforward to factor out. It already has support for rendering math to an in-memory image bitmap, which has been used for displaying math on GUI widgets, for example. Anyway -- cool ideas. Let's keep up the discussion. Cheers, Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
