Experimental overlapping-prevention on the transforms branch

[Michael_Droettboom]

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

auto_layout.py (835 Bytes)

···

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

[_Ted_Drain]

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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

Ted Drain Jet Propulsion Laboratory ted.drain@...179...

[Michael_Droettboom]

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

[Andrew_Straw5]

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: Visual stimulation of saccades in magnetically tethered Drosophila | Journal of Experimental Biology | The Company of Biologists 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

[Michael_Droettboom]

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: Visual stimulation of saccades in magnetically tethered Drosophila | Journal of Experimental Biology | The Company of Biologists 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

[_John_Hunter]

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 Dec 4, 2007 4:02 PM, Ted Drain <ted.drain@...179...> 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.

[Darren_Dale]

I mentioned the usetex limitation a while back on mpl-dev, the post was
titled "arbitrary rotation of images".

Darren

···

On Wednesday 05 December 2007 09:39:33 am John Hunter wrote:

On Dec 4, 2007 4:02 PM, Ted Drain <ted.drain@...179...> 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.

[Michael_Droettboom]

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]

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]

Thank you for doing this Mike.

···

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

[Andrew_Straw5]

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

[Michael_Droettboom]

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

[Andrew_Straw5]

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

[Michael_Droettboom]

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