Well, that work has gone from a "paid to work on it" to a "hobby project", so it's harder to find the time.
In terms of "math rendering" features, it's pretty complete. It's not 100% of TeX, and it never will be, but it's able to do most of the really common things.
I would like to see this as an independent Python package. The pieces that are missing to do this are:
Freetype wrappers: One could just extract the existing freetype wrappers in mpl. But that duplicates that code in two places, and those wrappers were built on a sort of "as needed" basis, and wouldn't be considered complete for any other purpose. (Maybe not a bad thing, though). The ctypes-based wrapper in pyglet is a candidate, but last time I looked, it's missing some features to extract the glyph metadata that mathtext needs. Plus, there always seem to be version mismatch problems with ctypes-based stuff, at least for me. I'd still love to see a proper C freetype wrapper as an independent project. PIL has a very basic one, that doesn't even come close to what we need -- but perhaps it's a starting point that could be extended.
A basic bitmap rendering engine: It needs to be able to take the glyph buffers from freetype and blend them onto an image, as well as draw filled rectangles. So it doesn't need to be anything as full-blown as Agg, and could probably be built on top of numpy or PIL, or as a C extension, but pure Python ain't gonna cut it. This should then integrate with PILand/or pyglet to save PNG, JPEG files etc.
Non-bitmap backends: These would be subsets of the matplotlib backends, but we would probably want the basic ability to write out PS, PDF and SVG etc. This is probably the biggest part of matplotlib that would need to be "pulled out", and the trickiest. It would still be useful to just have the "generic" vector description of the equations from mathtext and consider these backends as a secondary feature for later. An HTML backend that does glyph placement with CSS and Canvas would probably also be very useful for webpage output.
So, that's a lot of work there, but it's all doable and should be fairly unsurprising. I'd be happy to unofficially help mentor someone doing a GSoC project on this, but I don't think I'll have time to do all of the work myself in the near future.
Cheers,
Mike
Ondrej Certik wrote:
···
Hi,
was there any new progress for the TeX engine since our last conversation?
We got a GSoC application for SymPy, that (among other things) would
try to disentangle the TeX engine from matplotlib, so that it can be
easily used from other projects as well.
What are your intentions with the engine - do you still hack on it, or
do you consider it more or less complete for your needs? I don't want
to have 2 incompatible engines in python - but if you are not going to
hack on it (much), then I think it makes sense to create a new project
for this and you can just include it. Because I think it's an
extremely cool and useful thing.
And we want to have this in sympy too, because we have quite nice
ascii art printing, so having nice graphics printing is just a next
step.
Ondrej
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA