matplotlib-devel Mailing List for matplotlib

Hi Michael!
Thanks a lot for a thourough reply. I've CCed Saroj, the GSoC
applicant. I hope he'll succeed.
If you could mentor, that'd be great. Do you want to mentor officially
or unofficially? If officially, you need to be a PSF mentor (let me
know, I'll help
you do the administration). If unofficially, I can be the mentor and
you can help Saroj with the TeX part of his app.
Actually, if it's not a problem for you, I'd prefer the official way,
for example you can be a backup mentor. Also you'll get a google GSoC
t-shirt. :)
Ondrej
On Fri, Mar 28, 2008 at 2:22 PM, Michael Droettboom <md...@st...> wrote:
> 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
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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