Monday, 29 June 2009

x Marks the Spot

There it is — the first 'equation' ever rendered by Mathtex! Although it may look like nothing more than a 99-DPI 12pt x in italicized Computer Modern it is really something quite special — a vision of progress.

Below is the parse-tree and glyph stream generated by the program:
freddie@fluorine ~/Programming/mathtex $ python
[Hlist <9.42> [Hlist <0.00> ] [Hlist <9.42> `x` k1.17] [Hlist <0.00> ]]
[(-0.5, 7.0, Bunch(symbol_name=x, metrics=Bunch(advance=9.41821289062, iceberg=7.0, ymax=7.0, height=7.0, width=8.25, slanted=True, xmax=8.6875, xmin=0.5, ymin=0.0), num=120, fontsize=12, offset=0.0, postscript_name=Cmmi10, font=, glyph=))]

Over the last couple of days I have been working on the code that I committed last week (here for those that are interested) and as promised now have something that does work.

However, there are several unpleasantness associated with it: firstly it depends on mathtex.ft2font — the FreeType wrapper used by matplotlib; secondly there is currently only a Cairo backend; thirdly the only font series supported Computer Modern, by way of the Bakoma fonts; fourthly the font paths are currently hard-coded.

I plan to fix all of these issues over the next couple of days — starting with using font metrics files as opposed to FT2Font and then writing a C-based renderer and wrapping it using Cython. I expect that this will be done by Friday.


  1. Hey Freddie -- glad to see you have made some progress. One question: you mention that you want to break the dependency on ftfont and use font metric tables. I can see how this could work for any given font, but the current implementation lets users specify the fonts they want to work with, eg the STIX fonts. Do you plan to support multiple or custom fontsets?

    What is the aversion to using ft2ftont -- the extension code dependency? I know Ondrej/sympy want a pure python solution, and this is certainly an admirable goal, but I am curious what your reason is.


  2. I do indeed plan on supporting fonts other than Bakoma (Computer Modern). Once rendering is satisfactory I'll add support in for STIX (already present in and Times New Roman (common TeX font).

    The extension code (CXX) is the main problem with FT2Font — from what I can tell it is not actively maintained. Furthermore C++ is often less accepted than C for extensions. If there was a native FreeType extension for Python (if I have time I'll look into it) then I would probably use that.

    However, it is likely that mathtex will *always* have an extension dependency. This is because it currently seems a lot simpler to write the bitmap renderer in C using FreeType + libpng than it is to wrap the two.

    There is also the option in the future of PIL and Qt backends to augment the Cairo (mostly finished) and bitmap (just starting) backends.

    But as it currently stands if you are just interested in a list of rects/glyphs mathtex is completely dependency-less.

    This week and next will mostly be spent doing code cleanup and refactoring the API. After that I'll look into supporting a larger subset of LaTeX math.