matplotlib-devel Mailing List for matplotlib

I feel a 0.91.2 in the next few weeks, and I'll be sure to do this and
send you a test build.
- Charlie
On Dec 5, 2007 1:30 PM, Russell E Owen <ro...@ce...> wrote:
> At 10:03 AM -0800 2007年12月05日, Christopher Barker wrote:
> >Russell E Owen wrote:
> >>At 10:08 AM -0500 2007年12月05日, Stephen Uhlhorn wrote:
> >>>Just for my edification, why can't the egg version be linked
> >>>against/include a different Tcl/Tk?
> >>
> >>If you mean why can't it be built that way in the first place, I
> >>don't know. The guy who builds it apparently doesn't read this list,
> >
> >Sure he does (if you mean the matplotlib list), and he did ask about
> >it right before this release. Maybe that was asked on
> >matplotlib-devel though (I filter them to the same place).
>
> It was on matploblib-devel. I'll start skimming that newsgroup.
>
> >>I suspect the official egg can somehow be patched, but I find it
> >>easier to just build my own and put that on pythonmac.
> >
> >Ideally, there would be only one binary version, and it would work
> >with either Tcl/Tk. Is that possible? or is this like the old wx
> >situation, where it can only be run with the same version it is
> >built against. Arrggg! I hope not.
>
> The version I build *can* be used with the built in Tcl/Tk. The
> version Charlie Moad builds cannot be used with TkAgg and a 3rd party
> Tcl/Tk -- it not only won't use the library, but it also acts flaky.
> Older versions crashed. 0.91.1 doesn't crash, but import of pylab
> fails with a traceback.
>
> For some reason it seems to be necessary to have a 3rd party Tcl/Tk
> installed when building matplotlib. It seems a shame. Tkinter in
> Python 2.4 was the same way, but that got fixed in Python 2.5 (I
> don't whether the installer got fixed or whether whoever builds Mac
> Python 2.5 installed a 3rd party Tcl/Tk).
>
> >If there really do need to be two, then they should be labeled
> >somehow, and both be up on python mac.
>
> Since there don't need to be two versions this is not necessary.
>
> However, Charlie Moad appears to be willing to start building a
> version that works with 3rd party Tcl/Tk. I really hope that happens.
>
> -- Russell
>
> -------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

At 10:03 AM -0800 2007年12月05日, Christopher Barker wrote:
>Russell E Owen wrote:
>>At 10:08 AM -0500 2007年12月05日, Stephen Uhlhorn wrote:
>>>Just for my edification, why can't the egg version be linked
>>>against/include a different Tcl/Tk?
>>
>>If you mean why can't it be built that way in the first place, I 
>>don't know. The guy who builds it apparently doesn't read this list,
>
>Sure he does (if you mean the matplotlib list), and he did ask about 
>it right before this release. Maybe that was asked on 
>matplotlib-devel though (I filter them to the same place).
It was on matploblib-devel. I'll start skimming that newsgroup.
>>I suspect the official egg can somehow be patched, but I find it 
>>easier to just build my own and put that on pythonmac.
>
>Ideally, there would be only one binary version, and it would work 
>with either Tcl/Tk. Is that possible? or is this like the old wx 
>situation, where it can only be run with the same version it is 
>built against. Arrggg! I hope not.
The version I build *can* be used with the built in Tcl/Tk. The 
version Charlie Moad builds cannot be used with TkAgg and a 3rd party 
Tcl/Tk -- it not only won't use the library, but it also acts flaky. 
Older versions crashed. 0.91.1 doesn't crash, but import of pylab 
fails with a traceback.
For some reason it seems to be necessary to have a 3rd party Tcl/Tk 
installed when building matplotlib. It seems a shame. Tkinter in 
Python 2.4 was the same way, but that got fixed in Python 2.5 (I 
don't whether the installer got fixed or whether whoever builds Mac 
Python 2.5 installed a 3rd party Tcl/Tk).
>If there really do need to be two, then they should be labeled 
>somehow, and both be up on python mac.
Since there don't need to be two versions this is not necessary.
However, Charlie Moad appears to be willing to start building a 
version that works with 3rd party Tcl/Tk. I really hope that happens.
-- Russell

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

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:
>> 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

Russell E Owen wrote:
> At 10:08 AM -0500 2007年12月05日, Stephen Uhlhorn wrote:
>> Just for my edification, why can't the egg version be linked
>> against/include a different Tcl/Tk?
> 
> If you mean why can't it be built that way in the first place, I 
> don't know. The guy who builds it apparently doesn't read this list, 
Sure he does (if you mean the matplotlib list), and he did ask about it 
right before this release. Maybe that was asked on matplotlib-devel 
though (I filter them to the same place).
> I suspect the official egg can somehow be patched, but I find it 
> easier to just build my own and put that on pythonmac.
Ideally, there would be only one binary version, and it would work with 
either Tcl/Tk. Is that possible? or is this like the old wx situation, 
where it can only be run with the same version it is built against. 
Arrggg! I hope not.
If there really do need to be two, then they should be labeled somehow, 
and both be up on python mac.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

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...

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.

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

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

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

Thanks Mike. I checked the contents of all the .cvsignore files and compared 
them with propget svn:ignore. I removed every instance of .cvsignore, with 
the exception of toolkits/basemap/.cvsignore and 
toolkits/basemap-0.9.6.1/.cvsignore.
Darren
On Wednesday 05 December 2007 09:16:11 am Michael Droettboom wrote:
> It looks like these are already set in the "SVN way" (maybe cvs2svn did it):
> > svn propget svn:ignore .
>
> build
> dist
> docs
> *.pyc
> .project
> matplotlibrc
> win32_static
>
>
> ...so it's probably safe to remove them, unless we plan to migrate back
> to CVS someday ;)
>
> Cheers,
> Mike
>
> Darren Dale wrote:
> > Is it safe to remove the instances of .cvsignore from the svn repository?
> >
> > -------------------------------------------------------------------------
> > 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
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

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

It looks like these are already set in the "SVN way" (maybe cvs2svn did it):
 > svn propget svn:ignore .
build
dist
docs
*.pyc
.project
matplotlibrc
win32_static
...so it's probably safe to remove them, unless we plan to migrate back 
to CVS someday ;)
Cheers,
Mike
Darren Dale wrote:
> Is it safe to remove the instances of .cvsignore from the svn repository?
> 
> -------------------------------------------------------------------------
> 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
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Is it safe to remove the instances of .cvsignore from the svn repository?

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

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