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
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
On 8/30/07, Michael Droettboom <md...@st...> 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). 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
John Hunter wrote: > On 8/30/07, Michael Droettboom <md...@st...> 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
Paul Kienzle wrote: > On Thu, Aug 30, 2007 at 02:19:47PM -0400, Michael Droettboom wrote: >> Paul Kienzle wrote: >>> Hi all, >>> 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? Perhaps historical reasons. I wonder if they're still relevant. >> 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. Cairo already works, as of a few weeks ago, it no longer uses bitmaps for mathtext rendering. (I should have been more clear earlier -- my brain has it filed in with the vector backends, though obviously it has a resterizer.) >> 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. That may be a while (re: John's latest message). In the meantime, I'm going to explore, as he suggested, how bad doing a raster rotation would look, as that's the easiest path forward. Cheers, Mike
SVN r3776 now has support for rotation of mathtext to any angle in the Agg backend (i.e. it's now supported in all backends). Enjoy! Mike Michael Droettboom wrote: > Paul Kienzle wrote: >> On Thu, Aug 30, 2007 at 02:19:47PM -0400, Michael Droettboom wrote: >>> Paul Kienzle wrote: >>>> Hi all, >>>> 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? > > Perhaps historical reasons. I wonder if they're still relevant. > >>> 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. > > Cairo already works, as of a few weeks ago, it no longer uses bitmaps > for mathtext rendering. (I should have been more clear earlier -- my > brain has it filed in with the vector backends, though obviously it has > a resterizer.) > >>> 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. > > That may be a while (re: John's latest message). In the meantime, I'm > going to explore, as he suggested, how bad doing a raster rotation would > look, as that's the easiest path forward. > > Cheers, > Mike > > ------------------------------------------------------------------------- > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On 8/30/07, Michael Droettboom <md...@st...> wrote: > > ...but if we need to go into agg anyway, why not use Agg's font handling > > capabilities directly? > > Perhaps historical reasons. I wonder if they're still relevant. Yes, that's it. agg did not have font support when the agg backend was added. It was always easier to continue adding and extending what we had (ft2font) than to port over to agg's support. JDH
John Hunter wrote: > On 8/30/07, Michael Droettboom <md...@st...> wrote: > >>> ...but if we need to go into agg anyway, why not use Agg's font handling >>> capabilities directly? >> Perhaps historical reasons. I wonder if they're still relevant. > > Yes, that's it. agg did not have font support when the agg backend > was added. It was always easier to continue adding and extending what > we had (ft2font) than to port over to agg's support. I think that's probably still the case -- while we could do rendering with agg at this point, agg doesn't provide a very complete interface to the font's metrics. We'd still have to maintain *some* sort of C code for that anyway. IMHO, I don't see any compelling reason to reduce the code in ft2font in favor of agg at this point. Cheers, Mike