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.
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?
Thanks in advance...
- Paul
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.
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.
- 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.
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).
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.
Cheers,
Mike
- 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.
I was envisioning simply rotating the entire text expression by
rotating the ft2font pixel buffer. Agg could do this and still
preserve subpixel effects, but we would need to expose a little code
(presumably in the agg SWIG module). One couldn't rotate individual
glyphs in a larger expression this way, but by far the most common
use case is to rotate the entire expression so this limitation doesn't
concern me much.
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
The rest of my life has intervened a bit here and I hope to return to
the refactoring soon, but I don't think it should hold you up.
Despite my initial revolutionary fervor, I have tempered a bit, and
favor a more integrationist approach than espoused in some of my
original emails on mpl1. So if you have an approach that will improve
the backend mathtext handling, by all means go for it and we will
incorporate this into further revisions.
JDH
On 8/30/07, Michael Droettboom <mdroe@...31...> wrote:
John Hunter wrote:
- 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.I was envisioning simply rotating the entire text expression by
rotating the ft2font pixel buffer. Agg could do this and still
preserve subpixel effects, but we would need to expose a little code
(presumably in the agg SWIG module).
I was concerned about loss of quality doing the rotation in raster space, particularly due to all of the trouble to get the hinting just right. (Though I'm not sure how much hinting to a grid matters when the glyphs aren't actually parallel with the grid anymore.)
I suppose it's worth some experimentation, though, as that is definitely the path of least resistance.
One couldn't rotate individual
glyphs in a larger expression this way, but by far the most common
use case is to rotate the entire expression so this limitation doesn't
concern me much.
Agreed. My usual response is: TeX doesn't support it, so why should we? 
Cheers,
Mike
On 8/30/07, Michael Droettboom <mdroe@...31...> wrote: