<div dir="ltr"><div><div><div><div><div>one thought:<br><br></div>Do not allow pixels to specify anything :-)<br><br></div>the final length-units (in, mm, points) to pixels conversion should only happen at the last minute when you need to actually render to an image.<br><br></div>The user can change the ppi setting at any pint until then -- their layout shouldn't change if they do.<br><br></div>Ideally, changing the dpi will result in exactly the same image -- other than resolution.<br><br></div>-CHB<br><br><div><div><br><div><div><br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 25, 2017 at 1:16 PM, Jody Klymak <span dir="ltr"><<a href="mailto:jklymak@uvic.ca" target="_blank">jklymak@uvic.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>




<div>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Hi Ben,</p><span class="">

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

<p dir="auto"></p></span></div><span class="">
<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>
</span><div style="white-space:normal">

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

<p dir="auto"></p></div><span class="">
<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>
</span><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().<wbr>transform_bbox
bbox = invTransFig(ax.get_tightbbox(<wbr>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><span class="">
<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>
</span><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><div class="h5">
<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 <<a href="mailto:jklymak@uvic.ca" target="_blank">jklymak@uvic.ca</a>> 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" target="_blank">https://github.com/matplotlib/<wbr>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>
______________________________<wbr>_________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/matplotlib-<wbr>devel</a><br>
</p>
</blockquote></blockquote></div>
<div style="white-space:normal">
</div>
</div></div></div>
</div>

<br>______________________________<wbr>_________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/matplotlib-<wbr>devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div></div></div></div></div></div></div>