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... ------------------------------------------------------------------------- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel