I have implemented (experimental) support for auto-shrinking of axes to prevent their tick labels, axis labels and titles from overlapping other axes. It's been tested on everything in backend_driver.py and seems to work fairly well, with a few minor glitches related to fixed aspect ratio axes and colorbars. The important user-visible change is that the position of an axes (as set by axes([l, b, w, h])) is now inclusive of the axis labels, tick labels and axes title. The auto-layout algorithm prevents (well, reduces) any of the text from going outside of that bounds. I couldn't figure out a good to maintain the old convention, where the axes position is the position of only the "data" area, since it makes it unclear, particularly with multi-axes figures, when text should be considered "out of bounds". With respect to the examples, this only affected a few of them where the position of the axes was manually nudged to make room for text. Simply removing those lines results in better-looking plots. Maybe this API change doesn't matter, but if it does, we can brainstorm ways around it. I'd prefer not to keep both ways alive indefinitely, but perhaps there is a good argument for that anyway. One of the considerations I made was to keep the axes aligned with one another. For example, if you have two axes stacked on top of one another, and one axes has large numbers on the y-axis, but the other does not, the left edge of both axes' data areas should remain aligned. The layout algorithm ensures that if an edge of an axes was aligned with other axes to begin with, it will always remain so. This applies whether the axes position was specified with "axes([l, b, w, h])" or "subplot(121)", or "axes().set_position([l, b, w, h])". Attached is an example where tick labels have been put in weird places to demonstrate how all this works, with before and after pictures. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Looks very nice! We'd love to have smarter layout systems as we
create a lot of plots for people (i.e. standard scripts that people
run instead of edit) and it's difficult to apply nice layouts that
work for every case that comes up.
Can any of this be extended to make the auto-ticking algorithms smart
enough to not overlap tick mark text fields so much? We get this all
the time with date plots and it drives people nuts.
Ted
At 01:50 PM 12/4/2007, Michael Droettboom wrote:
>I have implemented (experimental) support for auto-shrinking of axes
>to prevent their tick labels, axis labels and titles from
>overlapping other axes. It's been tested on everything in
>backend_driver.py and seems to work fairly well, with a few minor
>glitches related to fixed aspect ratio axes and colorbars.
>
>The important user-visible change is that the position of an axes
>(as set by axes([l, b, w, h])) is now inclusive of the axis labels,
>tick labels and axes title. The auto-layout algorithm prevents
>(well, reduces) any of the text from going outside of that
>bounds. I couldn't figure out a good to maintain the old
>convention, where the axes position is the position of only the
>"data" area, since it makes it unclear, particularly with multi-axes
>figures, when text should be considered "out of bounds". With
>respect to the examples, this only affected a few of them where the
>position of the axes was manually nudged to make room for
>text. Simply removing those lines results in better-looking
>plots. Maybe this API change doesn't matter, but if it does, we can
>brainstorm ways around it. I'd prefer not to keep both ways alive
>indefinitely, but perhaps there is a good argument for that anyway.
>
>One of the considerations I made was to keep the axes aligned with
>one another. For example, if you have two axes stacked on top of
>one another, and one axes has large numbers on the y-axis, but the
>other does not, the left edge of both axes' data areas should remain
>aligned. The layout algorithm ensures that if an edge of an axes
>was aligned with other axes to begin with, it will always remain
>so. This applies whether the axes position was specified with
>"axes([l, b, w, h])" or "subplot(121)", or "axes().set_position([l, b, w, h])".
>
>Attached is an example where tick labels have been put in weird
>places to demonstrate how all this works, with before and after pictures.
>
>Cheers,
>Mike
>
>--
>Michael Droettboom
>Science Software Branch
>Operations and Engineering Division
>Space Telescope Science Institute
>Operated by AURA for NASA
>
>
>
>#!/usr/bin/env python """ Example: simple line plot. Show how to
>make and save a simple line plot with labels, title and grid """
>from pylab import * t = arange(0.0, 1.0+0.01, 0.01) s =
>cos(2*2*pi*t) ax1 = subplot(211) plot(t, s, '-', lw=2)
>xlabel('xlabel for bottom axes') ylabel('ylabel on the right')
>title('About as simple as it gets, folks') grid(True)
>ax1.yaxis.set_label_position('right')
>ax1.xaxis.set_ticklabels(['Monday', 'Tuesday', 'Wednesday',
>'Thursday', 'Friday']) for label in
>ax1.get_xticklabels(): label.set_rotation(45) ax2 = subplot(212)
>plot(t, s, '-', lw=2) grid(True) xlabel('xlabel for bottom axes (the
>ticks are on the top for no good reason)') ylabel('I\'m a lefty')
>ax2.xaxis.set_label_position('bottom')
>ax2.xaxis.set_ticks_position('top') #savefig('simple_plot.png')
>savefig('simple_plot') show()
>-------------------------------------------------------------------------
>SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell. From the desktop to the data center, Linux is going
>mainstream. Let it simplify your IT future.
>http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp...
Ted Drain wrote: > Can any of this be extended to make the auto-ticking algorithms smart > enough to not overlap tick mark text fields so much? We get this all > the time with date plots and it drives people nuts. This doesn't address that particular issue -- but I'd like to get to it at some point. BTW - have you tried using figure().autofmt_xdate()? It will rotate the x-axis label to 30 degrees, which often helps with date plots. Not the whole solution, but may work in a bind... Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Dec 4, 2007 4:02 PM, Ted Drain <ted...@jp...> wrote: > Looks very nice! We'd love to have smarter layout systems as we > create a lot of plots for people (i.e. standard scripts that people > run instead of edit) and it's difficult to apply nice layouts that > work for every case that comes up. > > Can any of this be extended to make the auto-ticking algorithms smart > enough to not overlap tick mark text fields so much? We get this all > the time with date plots and it drives people nuts. This drives me nuts too -- I almost always do autofmt_xdate. Perhaps we should just make rotated and right aligned the default for dates. Particularly in combination with Michael's autolayout, it should help the common use case. One problem that needs to be addressed is autofmt_xdate currently raises if you are not using a subplot geometry (because it turns off xticklabels for the upper subplots), but with a little thought we could make this more generic to work with general axes. This is hte main reason I have been holding off making it the default. One other problem to be aware of in this area: usetex does not support rotated text, so autofmt_xdate and related tricks will still not work until usetex supports arbitrary rotations. One thing that has been on my wish list is to expose the agg image functionality a little better to make things like rotating the ft2font pixel buffer easier. JDH
On Wednesday 05 December 2007 09:39:33 am John Hunter wrote: > On Dec 4, 2007 4:02 PM, Ted Drain <ted...@jp...> wrote: > > Looks very nice! We'd love to have smarter layout systems as we > > create a lot of plots for people (i.e. standard scripts that people > > run instead of edit) and it's difficult to apply nice layouts that > > work for every case that comes up. > > > > Can any of this be extended to make the auto-ticking algorithms smart > > enough to not overlap tick mark text fields so much? We get this all > > the time with date plots and it drives people nuts. > > This drives me nuts too -- I almost always do autofmt_xdate. Perhaps > we should just make rotated and right aligned the default for dates. > Particularly in combination with Michael's autolayout, it should help > the common use case. One problem that needs to be addressed is > autofmt_xdate currently raises if you are not using a subplot geometry > (because it turns off xticklabels for the upper subplots), but with a > little thought we could make this more generic to work with general > axes. This is hte main reason I have been holding off making it the > default. > > One other problem to be aware of in this area: usetex does not support > rotated text, so autofmt_xdate and related tricks will still not work > until usetex supports arbitrary rotations. One thing that has been on > my wish list is to expose the agg image functionality a little better > to make things like rotating the ft2font pixel buffer easier. I mentioned the usetex limitation a while back on mpl-dev, the post was titled "arbitrary rotation of images". Darren
Hi Michael, This looks very impressive. Not understanding what kind of magic is happening underneath, I wonder how this can work to keep the data areas aligned in cases where the user initially sets the axes locations arbitrarily but then later sets them to the final desired values after drawing differently sized tick labels in the different axes. For example, the mplsizer toolkit that lurks in the svn tree relies on doing things this way. I just cooked up the example demo_gridsizer2.py in toolkits/mplsizer/demo to demonstrate. Admittedly, I hand-adjusted the "border" attribute so that the tick labels would not overlap. Should I expect that this type of thing remains possible? Also, while you're working on this stuff, it would be really cool to be able to automatically drop the axes spines off the data area. Our lab makes lots of use of this style, and it would be very cool of MPL could do this out of the box. Here's an example: http://jeb.biologists.org/cgi/content/full/209/16/3170/FIG2 I don't know how far off what you're currently doing this would be, but I figure it can't hurt my cause too much to get the idea on your radar ;) Cheers! Andrew Michael Droettboom wrote: > I have implemented (experimental) support for auto-shrinking of axes to > prevent their tick labels, axis labels and titles from overlapping other > axes. It's been tested on everything in backend_driver.py and seems to > work fairly well, with a few minor glitches related to fixed aspect > ratio axes and colorbars. > > The important user-visible change is that the position of an axes (as > set by axes([l, b, w, h])) is now inclusive of the axis labels, tick > labels and axes title. The auto-layout algorithm prevents (well, > reduces) any of the text from going outside of that bounds. I couldn't > figure out a good to maintain the old convention, where the axes > position is the position of only the "data" area, since it makes it > unclear, particularly with multi-axes figures, when text should be > considered "out of bounds". With respect to the examples, this only > affected a few of them where the position of the axes was manually > nudged to make room for text. Simply removing those lines results in > better-looking plots. Maybe this API change doesn't matter, but if it > does, we can brainstorm ways around it. I'd prefer not to keep both > ways alive indefinitely, but perhaps there is a good argument for that > anyway. > > One of the considerations I made was to keep the axes aligned with one > another. For example, if you have two axes stacked on top of one > another, and one axes has large numbers on the y-axis, but the other > does not, the left edge of both axes' data areas should remain aligned. > The layout algorithm ensures that if an edge of an axes was aligned > with other axes to begin with, it will always remain so. This applies > whether the axes position was specified with "axes([l, b, w, h])" or > "subplot(121)", or "axes().set_position([l, b, w, h])". > > Attached is an example where tick labels have been put in weird places > to demonstrate how all this works, with before and after pictures. > > Cheers, > Mike
Andrew, I'm embarrassed to admit I wasn't familiar with mplsizer before I looked into this. The user "API" of mplsizer actually looks like it would be much easier to support the text-overlapping problem, since the placement of the axes in a grid is more explicit. I may want to reconsider how I'm doing things... But as for your question, it doesn't really "break" things for mplsizer. As you probably know, each axes keeps track of an "original" and "active" bounding box. The "original" can be thought of as "what the user specified", via either subplot(), axes([l,b,w,h]), or mplsizer. The text-overlapping algorithm works by first determining how much the axes bounds need to shrink to make room for the text (for every axes), and then adjusts all axes such that any that were aligned to begin with remain aligned. Since text does not grow as the figure size does, this shrinking and re-alignment happens on every redraw (it technically only has to happen when the figure is resized, the dpi changes or axes are added or removed, but that's an optimization for another time...) The attached image shows your example run through the new text-overlapping routine. I set the mplsizer border to 0.0 to make the effect more obvious. As you can see, the edges of the axes remain aligned. Unfortunately, axes that were the same *size* before adjusting for text are now different. I think this is a problem both aesthetically and for clarity, but it's hard to avoid given that mpl allows the user to arbitrarily put a new axes at any position whatsoever -- that is, there aren't any explicit relationships between axes to suggest that two or more axes should maintain the same aspect ratio. The subplot() API and the mplsizer API do help with that, though... maybe it's better to only do this with axes created that way, and leave arbitrarily placed axes alone. Food for thought... > Also, while you're working on this stuff, it would be really cool to be > able to automatically drop the axes spines off the data area. Our lab > makes lots of use of this style, and it would be very cool of MPL could > do this out of the box. Here's an example: > http://jeb.biologists.org/cgi/content/full/209/16/3170/FIG2 I don't know > how far off what you're currently doing this would be, but I figure it > can't hurt my cause too much to get the idea on your radar ;) Consider it in the long queue (which is generally a dynamic priority queue, not FIFO ;). Good to have things in the back of my mind as I'm looking elsewhere. [As an aside, I had a little trouble installing mplsizer. "python setup.py install" put an mplsizer egg in my site-packages, but "import matplotlib.toolkits.mplsizer" failed. >>> import matplotlib.toolkits.mplsizer as mplsizer Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named toolkits.mplsizer I was able to get this to work my manually copying the mplsizer/build/lib/matplotlib/toolkits/mplsizer directory to site-packages/matplotlib/toolkits/ . I have very little experience with eggs... is there something I'm doing wrong with the install?] Cheers, Mike > Michael Droettboom wrote: >> I have implemented (experimental) support for auto-shrinking of axes >> to prevent their tick labels, axis labels and titles from overlapping >> other axes. It's been tested on everything in backend_driver.py and >> seems to work fairly well, with a few minor glitches related to fixed >> aspect ratio axes and colorbars. >> >> The important user-visible change is that the position of an axes (as >> set by axes([l, b, w, h])) is now inclusive of the axis labels, tick >> labels and axes title. The auto-layout algorithm prevents (well, >> reduces) any of the text from going outside of that bounds. I >> couldn't figure out a good to maintain the old convention, where the >> axes position is the position of only the "data" area, since it makes >> it unclear, particularly with multi-axes figures, when text should be >> considered "out of bounds". With respect to the examples, this only >> affected a few of them where the position of the axes was manually >> nudged to make room for text. Simply removing those lines results in >> better-looking plots. Maybe this API change doesn't matter, but if it >> does, we can brainstorm ways around it. I'd prefer not to keep both >> ways alive indefinitely, but perhaps there is a good argument for that >> anyway. >> >> One of the considerations I made was to keep the axes aligned with one >> another. For example, if you have two axes stacked on top of one >> another, and one axes has large numbers on the y-axis, but the other >> does not, the left edge of both axes' data areas should remain >> aligned. The layout algorithm ensures that if an edge of an axes was >> aligned with other axes to begin with, it will always remain so. This >> applies whether the axes position was specified with "axes([l, b, w, >> h])" or "subplot(121)", or "axes().set_position([l, b, w, h])". >> >> Attached is an example where tick labels have been put in weird places >> to demonstrate how all this works, with before and after pictures. >> >> Cheers, >> Mike > > ------------------------------------------------------------------------ > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Michael Droettboom wrote: > Andrew, > > I'm embarrassed to admit I wasn't familiar with mplsizer before I > looked into this. The user "API" of mplsizer actually looks like it > would be much easier to support the text-overlapping problem, since > the placement of the axes in a grid is more explicit. I may want to > reconsider how I'm doing things... Well, I haven't exactly advertised mplsizer very heavily, so I can't blame you. I don't know what you're implying by putting API in quotes, but in my defense -- I just did my best to copy wx's, so if you want to talk about the wx "API" that's ok by me. Now if you complain about the (lack of) documentation, that'll hurt. ;) > > But as for your question, it doesn't really "break" things for > mplsizer. As you probably know, each axes keeps track of an > "original" and "active" bounding box. The "original" can be thought > of as "what the user specified", via either subplot(), > axes([l,b,w,h]), or mplsizer. The text-overlapping algorithm works by > first determining how much the axes bounds need to shrink to make room > for the text (for every axes), and then adjusts all axes such that any > that were aligned to begin with remain aligned. Since text does not > grow as the figure size does, this shrinking and re-alignment happens > on every redraw (it technically only has to happen when the figure is > resized, the dpi changes or axes are added or removed, but that's an > optimization for another time...) I see, so is it correct that, at some certain minimum figure size, the overlapping code no longer has to shrink axes, and everything will be aligned as before? > > The attached image shows your example run through the new > text-overlapping routine. I set the mplsizer border to 0.0 to make > the effect more obvious. As you can see, the edges of the axes remain > aligned. Unfortunately, axes that were the same *size* before > adjusting for text are now different. I think this is a problem both > aesthetically and for clarity, but it's hard to avoid given that mpl > allows the user to arbitrarily put a new axes at any position > whatsoever -- that is, there aren't any explicit relationships between > axes to suggest that two or more axes should maintain the same aspect > ratio. The subplot() API and the mplsizer API do help with that, > though... maybe it's better to only do this with axes created that > way, and leave arbitrarily placed axes alone. Food for thought... I must admit that I didn't get the attachment, but perhaps all the better as I should download the transforms branch and start testing. I don't have time this week, however... Nevertheless, I'm having difficulty following the above without something to look at. Perhaps a small API addition would help solve the situation. Something that would force disparate axes to share the same aspect ratio and size? That would seem to solve 99% of the problem I worry about. Something like this (egregiously long kwparam version): ax1 = axes([l,b,w,h], shared_data_aspect_key='group1' ) ax2 = axes([l,b,w,h], shared_data_aspect_key='group1' ) ax3 = axes([l,b,w,h], shared_data_aspect_key='group2' ) ax4 = axes([l,b,w,h], shared_data_aspect_key='group2' ) > [As an aside, I had a little trouble installing mplsizer. "python > setup.py install" put an mplsizer egg in my site-packages, but "import > matplotlib.toolkits.mplsizer" failed. > > >>> import matplotlib.toolkits.mplsizer as mplsizer > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ImportError: No module named toolkits.mplsizer > > I was able to get this to work my manually copying the > mplsizer/build/lib/matplotlib/toolkits/mplsizer directory to > site-packages/matplotlib/toolkits/ . I have very little experience > with eggs... is there something I'm doing wrong with the install?] Sigh. I dunno. This works on some of my computers and not on others and I don't know what's different. I'm going to have to either figure it out or rip the setuptools out. Again, not this week...
Andrew Straw wrote: > Michael Droettboom wrote: >> Andrew, >> >> I'm embarrassed to admit I wasn't familiar with mplsizer before I >> looked into this. The user "API" of mplsizer actually looks like >> it would be much easier to support the text-overlapping problem, >> since the placement of the axes in a grid is more explicit. I may >> want to reconsider how I'm doing things... > Well, I haven't exactly advertised mplsizer very heavily, so I can't > blame you. I don't know what you're implying by putting API in > quotes, but in my defense -- I just did my best to copy wx's, so if > you want to talk about the wx "API" that's ok by me. Now if you > complain about the (lack of) documentation, that'll hurt. ;) The quotes didn't mean anything -- Sometimes API means a very specific thing to some people, and I just mean it broadly. >> But as for your question, it doesn't really "break" things for >> mplsizer. As you probably know, each axes keeps track of an >> "original" and "active" bounding box. The "original" can be >> thought of as "what the user specified", via either subplot(), >> axes([l,b,w,h]), or mplsizer. The text-overlapping algorithm works >> by first determining how much the axes bounds need to shrink to >> make room for the text (for every axes), and then adjusts all axes >> such that any that were aligned to begin with remain aligned. >> Since text does not grow as the figure size does, this shrinking >> and re-alignment happens on every redraw (it technically only has >> to happen when the figure is resized, the dpi changes or axes are >> added or removed, but that's an optimization for another time...) > I see, so is it correct that, at some certain minimum figure size, > the overlapping code no longer has to shrink axes, and everything > will be aligned as before? Close, but not quite -- the auto layout algorithm treats the "original" axes bounds as inclusive of the text, so the actual data part of the axes will always be smaller than that (when there is text). >> The attached image shows your example run through the new >> text-overlapping routine. I set the mplsizer border to 0.0 to make >> the effect more obvious. As you can see, the edges of the axes >> remain aligned. Unfortunately, axes that were the same *size* >> before adjusting for text are now different. I think this is a >> problem both aesthetically and for clarity, but it's hard to avoid >> given that mpl allows the user to arbitrarily put a new axes at any >> position whatsoever -- that is, there aren't any explicit >> relationships between axes to suggest that two or more axes should >> maintain the same aspect ratio. The subplot() API and the mplsizer >> API do help with that, though... maybe it's better to only do this >> with axes created that way, and leave arbitrarily placed axes >> alone. Food for thought... > I must admit that I didn't get the attachment, but perhaps all the > better as I should download the transforms branch and start testing. > I don't have time this week, however... Nevertheless, I'm having > difficulty following the above without something to look at. ...probably because I forgot to attach it. (When will my e-mail client read my mind?) I've also attached a version with a new version of the layout algorithm -- in addition to making all axes that were initially aligned remain aligned, it sets an axes that originally were the same size to remain the same size. Better... but aside from it theoretically picking up some false positives, it tends to add more space than necessary between axes. It probably needs a fourth pass to minimize the gaps. > Perhaps a small API addition would help solve the situation. > Something that would force disparate axes to share the same aspect > ratio and size? That would seem to solve 99% of the problem I worry > about. Something like this (egregiously long kwparam version): > > ax1 = axes([l,b,w,h], shared_data_aspect_key='group1' ) ax2 = > axes([l,b,w,h], shared_data_aspect_key='group1' ) ax3 = > axes([l,b,w,h], shared_data_aspect_key='group2' ) ax4 = > axes([l,b,w,h], shared_data_aspect_key='group2' ) That's a possibility. I'd hate to replace one system that takes a lot of manual tweaking, but is at least straightforward, with one that requires understanding complex rules. I'm not saying that your solution does, necessarily, just that whatever this ends up being is simple and obvious. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Michael Droettboom wrote: > ...probably because I forgot to attach it. (When will my e-mail > client read my mind?) I've also attached a version with a new version > of the layout algorithm -- in addition to making all axes that were > initially aligned remain aligned, it sets an axes that originally were > the same size to remain the same size. Better... but aside from it > theoretically picking up some false positives, it tends to add more > space than necessary between axes. It probably needs a fourth pass to > minimize the gaps. Thanks, got them this time. They both look acceptable, the 2nd looks pretty good. I gather it doesn't require any additional user commands, but just picks up the desired layout based on the axes bounds (in other words, the same script)?
Andrew Straw wrote: > Michael Droettboom wrote: >> ...probably because I forgot to attach it. (When will my e-mail >> client read my mind?) I've also attached a version with a new version >> of the layout algorithm -- in addition to making all axes that were >> initially aligned remain aligned, it sets an axes that originally were >> the same size to remain the same size. Better... but aside from it >> theoretically picking up some false positives, it tends to add more >> space than necessary between axes. It probably needs a fourth pass to >> minimize the gaps. > Thanks, got them this time. > > They both look acceptable, the 2nd looks pretty good. I gather it > doesn't require any additional user commands, but just picks up the > desired layout based on the axes bounds (in other words, the same script)? That's correct. The only change to your script that I made was: hsizer.Add(ax,name='row %d, col %d'%(r,c),all=1,border=0.3,expand=1) to hsizer.Add(ax,name='row %d, col %d'%(r,c),all=1,border=0.0,expand=1) And the very latest version of the transforms branch requires auto layout to be turned on by setting the rcParam "figure.autolayout" to True. (That's just so I can continue to experiment without tripping up others...) There should be more padding between the axes and the tick labels -- that's due to an unrelated bug because the dpi is changing on-the-fly. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Darren Dale wrote: >> One other problem to be aware of in this area: usetex does not support >> rotated text, so autofmt_xdate and related tricks will still not work >> until usetex supports arbitrary rotations. One thing that has been on >> my wish list is to expose the agg image functionality a little better >> to make things like rotating the ft2font pixel buffer easier. > > I mentioned the usetex limitation a while back on mpl-dev, the post was > titled "arbitrary rotation of images". Between 0.90 and 0.91, the Agg backend grew a "draw_text_image" method, which can draw an image at an arbitrary angle. It is hardcoded to take the inverted greyscale images generated by FT2Font, but it should provide a roadmap as to how to handle the rgba images used by the usetex machinery. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Michael Droettboom wrote: > Darren Dale wrote: >>> One other problem to be aware of in this area: usetex does not support >>> rotated text, so autofmt_xdate and related tricks will still not work >>> until usetex supports arbitrary rotations. One thing that has been on >>> my wish list is to expose the agg image functionality a little better >>> to make things like rotating the ft2font pixel buffer easier. >> I mentioned the usetex limitation a while back on mpl-dev, the post was >> titled "arbitrary rotation of images". > > Between 0.90 and 0.91, the Agg backend grew a "draw_text_image" method, > which can draw an image at an arbitrary angle. It is hardcoded to take > the inverted greyscale images generated by FT2Font, but it should > provide a roadmap as to how to handle the rgba images used by the usetex > machinery. Usetex now supports arbitrary angles with the Agg backend. It grabs only the greyscale part of the usetex image (which isn't new -- usetex has always thrown away any color coming from (La)TeX), and then uses draw_text_image to do the drawing. (draw_image continues to not support rotation, but that is probably best done elsewhere anyway, if the need ever arises). Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Wednesday 05 December 2007 11:32:29 am Michael Droettboom wrote: > Michael Droettboom wrote: > > Darren Dale wrote: > >>> One other problem to be aware of in this area: usetex does not support > >>> rotated text, so autofmt_xdate and related tricks will still not work > >>> until usetex supports arbitrary rotations. One thing that has been on > >>> my wish list is to expose the agg image functionality a little better > >>> to make things like rotating the ft2font pixel buffer easier. > >> > >> I mentioned the usetex limitation a while back on mpl-dev, the post was > >> titled "arbitrary rotation of images". > > > > Between 0.90 and 0.91, the Agg backend grew a "draw_text_image" method, > > which can draw an image at an arbitrary angle. It is hardcoded to take > > the inverted greyscale images generated by FT2Font, but it should > > provide a roadmap as to how to handle the rgba images used by the usetex > > machinery. > > Usetex now supports arbitrary angles with the Agg backend. It grabs > only the greyscale part of the usetex image (which isn't new -- usetex > has always thrown away any color coming from (La)TeX), and then uses > draw_text_image to do the drawing. (draw_image continues to not support > rotation, but that is probably best done elsewhere anyway, if the need > ever arises). Thank you for doing this Mike.