pure python TeX math engine

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

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

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. :slight_smile:

Ondrej

···

On Fri, Mar 28, 2008 at 2:22 PM, Michael Droettboom <mdroe@...31...> 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
> 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