On Thu, Aug 30, 2007 at 02:19:47PM -0400, Michael Droettboom wrote:
> Paul Kienzle wrote:
> > Hi all,
> >
> > I replaced one of the text_rotation examples with r'$\rm{mathtext_{225}}$'
> > to see if rotation is supported for mathtext. It is not in the current
> > trunk downloaded today.
>
> It's only not supported in the bitmap (Agg and Gdk) backends. It works
> fine in the vector backends.
Okay. wxAgg works with $90^\circ$ rotations as well. This will work for
me short term (though $45^\circ$ is better).
> > Before I look to deeply into this myself, is there anyone working on it
> > already? Is there anything I need to look out for when implementing it?
>
> I've made a few excursions down that road --
>
> For bitmap font rendering, the entire math expression is first laid out
> in a greyscale bitmap buffer, which is cached and then transferred to
> the main plot bitmap. It was already that way when I got here, and I
> assume that's an important optimization (so the text doesn't have to be
> re-laid-out when the plot is zoomed/panned). I say "perhaps" because I
> have no data to back it up, and don't know if that came out of profiling
> or not.
>
> There are a few key low level pieces that are missing for rotation:
>
> - FT2Font.draw_glyph_to_bitmap does not support rotation. This would
> have to be added, or there may be a way to use
> set_text/draw_glyphs_to_bitmap which does support rotation. However,
> that would make rendering the entire expression to a single buffer much
> more difficult.
Adding rotation to draw_glyph_to_bitmap looks like the easier option...
>
> - The horizontal lines are all drawn as filled rectangles aligned to the
> pixel grid, directly into the font buffers. That will probably have to
> be pushed upward into the Agg layer to get good line drawing at
> arbitrary angles -- but that also makes caching the bitmap a little more
> difficult. So maybe it makes sense to implement our own Breshenham's
> algorithm in ft2font.cpp.
...but if we need to go into agg anyway, why not use Agg's font handling
capabilities directly?
>
> All this will be affected by John's proposed refactoring of the
> backends, of course, which has kind of kept me off of it in a "wait and
> see" kind of mode. Right now, each backend has a custom interface to
> communicate with mathtext -- whereas mathtext should simply be calling
> the same low-level methods on all backends to get its job done. That,
> of course, would make this buffer optimization harder (or at least it
> would have to be thought about differently).
I haven't followed the refactoring proposal close enough to know if it
makes more sense to implement mathtext via freetype in agg or to use
freetype directly like you are currently doing. Once that decision is
clear, we can certainly prototype the handling of rotated text in the Agg
backend.
Presumably this will have to be repeated for Cairo.
>
> Let me know if you decide to implement this and let me know if you have
> any questions about the code. Otherwise I'm happy to add it to my queue.
I can get by for now with limited text rotation, at least until the
backend refactoring has settled.
- Paul
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
