Hi all,
Please John, take some time before SciPy conf to answer at least some of
this questions, because the SoC deadline (21st August) is *very* near.
1) I'm having some problems regarding FT2Font.
The problem is when I instantiate FT2Font like:
font = FT2Font(filename)
and when I call it's method font.set_text("Some text"), and afterwards,
font.draw_glyphs_to_bitmap(), the latter simply deletes every glyph that
was drawn before it, and just paints in the internal image buffer the
text that was passed on last invocation of set_text (or load_char).
This is a pain, because draw_glyphs_to_bitmap implements the layout
(with kerning etc.), but if one wants to paint several words in different
x,y positions in the same image buffer, he has to do the layout for every
character in every word manually via draw_glyph_to_bitmap(x, y, glyph)
(like you did with the BaKoMa fonts in mathtext).
Why hasn't draw_glyphs_to_bitmap been implemented so that it takes x, y as
arguments (draw_glyphs_to_bitmap(x, y)) and leaves the image
buffer intact (as does draw_glyph_to_bitmap)?
2) As I have said before, I have started the complete rewrite of mathtext
(the parsing stuff etc.). I have completely removed the dependency on
pyparsing (please don't yell at me :), and I was wondering about how much
of TeX should mathtext support. I'm not talking about support for \frac,
\above, \choose (which I plan to add one by one) etc., but about more
general things - macros (\def etc.). I was thinking of just simulating
them, at least to a tolerable extent, via notion of an enviroment.
Example:
\rm in plain TeX sets the current font to roman (until the end of the
current scope - 'till it hits "}").
Implementation:
At render time, when the parser hits "\rm", it does the folowing:
env["facetype"] = "rm", where env is the environment in the current scope.
Also, I am planing to create a separate class for every new layout item
that gets implemented.
Example: sub/superscripted item (nucleus_sub^sup) gets translated to an
instance of class Scripted that has the attributes nucleus, superscript
and subscript.
3) I was thinking of focusing on just the Agg backend for now (that is
till' the deadline). Is this OK?
4) I think that we should move the job of
math_parse_s_ft2font, math_parse_s_ft2font_svg, and math_parse_s_ps etc.
to the corresponding backends, and that some general function like:
math_parse_s(x, y, s, prop, angle)
should be implemented directly in mathtext.py (perhaps even without the
"angle" parameter) so that it returns a list of the following type:
[(x1, y1, s1, prop1, angle1), ... , (xn, yn, sn, propn, anglen)]
Then the backend should call draw_text for every item in the list.
Something like
def draw_mathtext(self, gc, x, y, s, prop, angle):
items = math_parse_s(x, y, s, prop, angle)
for item in items:
draw_text(*items)
instead of current:
def draw_mathtext(self, gc, x, y, s, prop, angle):
"""
Draw the math text using matplotlib.mathtext
"""
if __debug__: verbose.report('RendererAgg.draw_mathtext',
'debug-annoying')
size = prop.get_size_in_points()
width, height, fonts = math_parse_s_ft2font(
s, self.dpi.get(), size, angle)
if angle == 90:
width, height = height, width
for font in fonts:
if angle == 90:
font.horiz_image_to_vert_image() # <-- Rotate
self._renderer.draw_text( font, int(x)-width, int(y)-height, gc)
else:
self._renderer.draw_text( font, int(x), int(y)-height, gc)
if 0:
self._renderer.draw_rectangle(gc, None,
int(x),
self.height-int(y),
width, height)
Is this possible? I'm aware of overseeing the dpi and fontsize arguments,
but I don't think that this is much of an issue.
5) What would be the consequences of distributing a GPL font (FreeFont)
with matplotlib. I mean, it's not that using a GPL font in some non-GPL
app could be a breach of the GPL. Is there any interest in this?
The new mathtext.py is attached. Please do not try it at home 
because nothing visible yet works.
Cheers,
Edin
mathtext.py (18.3 KB)