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