<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Hi Ben,</p>

<p dir="auto">On 25 Aug 2017, at 10:53, Benjamin Root wrote:</p>

<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #5855D5; color:#5855D5; margin:0 0 5px; padding-left:5px"><p dir="auto">a) no, it does not exist already<br>
b) at first blush, yes, it would be awesome, and maybe pint might be able<br>
to help us with that.</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">I thought you were going to send me a beer…</p>

<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #5855D5; color:#5855D5; margin:0 0 5px; padding-left:5px"><p dir="auto">however... I would caution against getting side-tracked to add such a<br>
feature at the moment. There is a lot of hidden complexities that I think<br>
has not yet been fully appreciated yet. For example, inches and points are<br>
very different from pixels, and would require diving into the transforms<br>
system.</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">First, I readily admit there is vast swaths of transforms and plotting things in backends I don’t appreciate!  </p>

<p dir="auto">Right now the <code>constrained_layout</code> manager needs to know about pixels versus figure co-ordinates, which I do now as:</p>

<pre style="border:thin solid gray; margin-left:15px; margin-right:15px; max-width:90vw; overflow-x:auto; padding:5px"><code>invTransFig = fig.transFigure.inverted().transform_bbox
bbox = invTransFig(ax.get_tightbbox(renderer=fig.renderer))
</code></pre>

<p dir="auto">so I’m already dealing with two of the three types of co-ordinates.  I was assuming I could get to inches from <code>pixels = inches * fig.renderer.dpi</code>, and I am certain I can figure out centimeters.  However, I’ll look at the transforms, maybe there is already one that deals with the renderer dpi.  </p>

<p dir="auto">Perhaps a relevant question for me to move forward is: what (default) units should a pad between figure elements be?  <code>tight_layout</code> uses fraction of a font size (I assume fraction of <code>M</code>, though I haven’t checked).  Other packages do different things.   Even if we don’t want a flexible way of specifying lengths, having a consistent default would be good.  </p>

<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #5855D5; color:#5855D5; margin:0 0 5px; padding-left:5px"><p dir="auto">We would also open ourselves to a fair amount of confusion from<br>
users. One time, when I was teaching an intro to matplotlib, the tutorial<br>
got derailed by the very first example by a person who was confused that a<br>
figure that was specified to be 7in x 5in wasn't that size on his laptop<br>
screen!</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">If the figure size isn’t right, I’d assume that 12pt fonts don’t come out right either, yet I still think it makes sense to specify fonts in points (well I don’t actually - I’d much prefer mm or inches - but I doubt that’ll get much traction).  So I think its sensible to specify padding and other lengths in physical units.  </p>

<p dir="auto">Anyway, I’d propose that I write a little package to do what I think is right, and then use it with <code>constrained_layout</code>, but with a sensible floating-point default argument in a sensible unit for the padding.  If others think its a good idea then great, maybe it’d get adopted elsewhere. If not, I could remove it from <code>constrained_layout</code> for consistency and just use the sensible default.  </p>

<p dir="auto">Thanks,   Jody</p>

<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #5855D5; color:#5855D5; margin:0 0 5px; padding-left:5px"><p dir="auto">Ben<br>
<br>
<br>
On Fri, Aug 25, 2017 at 1:20 PM, Jody Klymak <jklymak@uvic.ca> wrote:<br>
</p>
<blockquote style="border-left:2px solid #5855D5; color:#00AFCC; margin:0 0 5px; padding-left:5px; border-left-color:#00AFCC"><p dir="auto">Hi all,<br>
<br>
I’m trying to work out how to do the padding on my constrained_layout<br>
geometry manager (which is testable by the way if anyone wants to try to<br>
break it for me: <a href="https://github.com/matplotlib/matplotlib/pull/9082">https://github.com/matplotlib/matplotlib/pull/9082</a>).<br>
Since I do the constraints in figure-normalized co-ordinates, my pad<br>
variable is figure-normalized, which maybe makes sense for some plots, but<br>
I can easily imagine it will set some people’s OCD off if the padding is<br>
thicker in the horizotnal than the vertical because the figure is wider<br>
than it is tall.<br>
<br>
So I could do inches/cm, or pixels, or points. But I guess it’d be nice to<br>
do all four. Do we already have a units parser? I couldn’t find one. I<br>
think it’d be pretty simple: just strip the last two characters off for<br>
unit type and pass the rest as a float.<br>
<br>
1.0px (=1.0 px; i.e. strip spaces)<br>
1.0cm<br>
1.0mm<br>
1.0in<br>
1.0pt<br>
<br>
I don’t think em and en would make sense in this context because we<br>
wouldn’t know the font size, though maybe there is a sensible figure<br>
default we could use?<br>
<br>
Then calls like pad=0.01 and pad=‘5mm’ would both be acceptable.<br>
<br>
a) does this exist already?<br>
b) if not, should it?<br>
<br>
Thanks, Jody<br>
_______________________________________________<br>
Matplotlib-devel mailing list<br>
Matplotlib-devel@python.org<br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel">https://mail.python.org/mailman/listinfo/matplotlib-devel</a><br>
</p>
</blockquote></blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>