Re: [matplotlib-devel] Experimental overlapping-prevention on the transforms branch

[Michael D. <md...@st...>]

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