v2.0.0b2

Folks,

Last night (and in time for the first day of scipy 2016) we tagged v2.0.0b2.

Hopefully this will be the last beta, and we will have an rc soon after
scipy.

By the end of the day I would like to have a (source) pre release on pypi
and available via conda forge.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160713/9dbf5e4b/attachment.html>

Did you take a look at the image I posted regarding the font issue I mentioned with regards tables?

···

From: Thomas Caswell <tcaswell at gmail.com>
To: matplotlib development list <matplotlib-devel at python.org>
Sent: Wednesday, 13 July 2016, 20:48
Subject: [Matplotlib-devel] v2.0.0b2
   
Folks,
Last night (and in time for the first day of scipy 2016) we tagged v2.0.0b2.
Hopefully this will be the last beta, and we will have an rc soon after scipy.
By the end of the day I would like to have a (source) pre release on pypi and available via conda forge.
Tom
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160713/1d1291f9/attachment.html>

Hi,

Folks,

Last night (and in time for the first day of scipy 2016) we tagged v2.0.0b2.

Hopefully this will be the last beta, and we will have an rc soon after
scipy.

By the end of the day I would like to have a (source) pre release on pypi
and available via conda forge.

Wheels building over at
https://travis-ci.org/MacPython/matplotlib-wheels/builds/144560516

32-bit wheels failing as before.

OSX builds delayed because of a travis-ci OSX backlog.

OK to upload when done?

Cheers,

Matthew

···

On Wed, Jul 13, 2016 at 7:48 PM, Thomas Caswell <tcaswell at gmail.com> wrote:

@Matthew Yes please, I just push the source tarball up and am working on
sorting out how to turn the crank on the many linux docker

@oceanwolf yes, but I did not understand the issue.

···

On Wed, Jul 13, 2016 at 4:59 PM Matthew Brett <matthew.brett at gmail.com> wrote:

Hi,

On Wed, Jul 13, 2016 at 7:48 PM, Thomas Caswell <tcaswell at gmail.com> > wrote:
> Folks,
>
> Last night (and in time for the first day of scipy 2016) we tagged
v2.0.0b2.
>
> Hopefully this will be the last beta, and we will have an rc soon after
> scipy.
>
> By the end of the day I would like to have a (source) pre release on pypi
> and available via conda forge.

Wheels building over at
https://travis-ci.org/MacPython/matplotlib-wheels/builds/144560516

32-bit wheels failing as before.

OSX builds delayed because of a travis-ci OSX backlog.

OK to upload when done?

Cheers,

Matthew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160713/960cf789/attachment.html>

Okay, I have cropped and enlarged the image (see attached) for you to see the problem with how the example renders on my computer.? As you see all of "y"s in "year" sit flush with the bottom (no gap/padding) apart from "20 year" which has a 1px gap from the bottom of the "y" to edge of the cell.? Notice also that the "0"s on 20 and 10 have a one pixel gap above them, whilst on the others they have a 2px gap.

I don't know where the trouble comes from, I haven't looked into the text part of the codebase yet, so I don't know how we calculate the row height and whether/how we use external font-libraries to do some of this for us, so ignoring that, I would expect it to (at least in this simple table situation) calculate a theoretical max height, i.e. from the bottom of the glyph with the lowest descender to the top of the glyph with the highest ascender, and then add whatever padding we specify around that and use that for every text row, so that the imaginary "ascender height" and "descender height" lines seen in the figure here https://en.wikipedia.org/wiki/Ascender_(typography) appear in the same place in each cell.? I have oversimplified my expected logic here for sensible default scenario and assuming 1 line of text per cell, and nothing other than text in the table.

Does that clarify the problem?? I thought that as we touch the default style here we might as well get it looking perfect, but if I go too nitpicky then we can save it for a bug-fix release / feature release.
Best,OceanWolf

···

From: Thomas Caswell <tcaswell at gmail.com>
To: Matthew Brett <matthew.brett at gmail.com>
Cc: matplotlib development list <matplotlib-devel at python.org>
Sent: Thursday, 14 July 2016, 0:23
Subject: Re: [Matplotlib-devel] v2.0.0b2
   
@Matthew Yes please, I just push the source tarball up and am working on sorting out how to turn the crank on the many linux docker
@oceanwolf yes, but I did not understand the issue.
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160713/a18abc5e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table_new_zoomed.png
Type: image/png
Size: 10103 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160713/a18abc5e/attachment-0001.png>

might be an even/odd thing?

···

On Wed, Jul 13, 2016 at 7:26 PM, OceanWolf via Matplotlib-devel < matplotlib-devel at python.org> wrote:

Okay, I have cropped and enlarged the image (see attached) for you to see
the problem with how the example renders on my computer. As you see all of
"y"s in "year" sit flush with the bottom (no gap/padding) apart from "20
year" which has a 1px gap from the bottom of the "y" to edge of the cell.
Notice also that the "0"s on 20 and 10 have a one pixel gap above them,
whilst on the others they have a 2px gap.

I don't know where the trouble comes from, I haven't looked into the text
part of the codebase yet, so I don't know how we calculate the row height
and whether/how we use external font-libraries to do some of this for us,
so ignoring that, I would expect it to (at least in this simple table
situation) calculate a theoretical max height, i.e. from the bottom of the
glyph with the lowest descender to the top of the glyph with the highest
ascender, and then add whatever padding we specify around that and use that
for every text row, so that the imaginary "ascender height" and "descender
height" lines seen in the figure here
https://en.wikipedia.org/wiki/Ascender_(typography) appear in the
same place in each cell. I have oversimplified my expected logic here for
sensible default scenario and assuming 1 line of text per cell, and nothing
other than text in the table.
<https://en.wikipedia.org/wiki/Descender>

Does that clarify the problem? I thought that as we touch the default
style here we might as well get it looking perfect, but if I go too
nitpicky then we can save it for a bug-fix release / feature release.

Best,
OceanWolf

------------------------------
*From:* Thomas Caswell <tcaswell at gmail.com>
*To:* Matthew Brett <matthew.brett at gmail.com>
*Cc:* matplotlib development list <matplotlib-devel at python.org>
*Sent:* Thursday, 14 July 2016, 0:23
*Subject:* Re: [Matplotlib-devel] v2.0.0b2

@Matthew Yes please, I just push the source tarball up and am working on
sorting out how to turn the crank on the many linux docker

@oceanwolf yes, but I did not understand the issue.

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160713/ff79a606/attachment.html>

Maybe related to some kind of fractional pixel shift? Every so often, it
accumulates enough to shift a whole pixel?

Ryan

···

On Wed, Jul 13, 2016 at 10:29 PM, Benjamin Root <ben.v.root at gmail.com> wrote:

might be an even/odd thing?

On Wed, Jul 13, 2016 at 7:26 PM, OceanWolf via Matplotlib-devel < > matplotlib-devel at python.org> wrote:

Okay, I have cropped and enlarged the image (see attached) for you to see
the problem with how the example renders on my computer. As you see all of
"y"s in "year" sit flush with the bottom (no gap/padding) apart from "20
year" which has a 1px gap from the bottom of the "y" to edge of the cell.
Notice also that the "0"s on 20 and 10 have a one pixel gap above them,
whilst on the others they have a 2px gap.

I don't know where the trouble comes from, I haven't looked into the text
part of the codebase yet, so I don't know how we calculate the row height
and whether/how we use external font-libraries to do some of this for us,
so ignoring that, I would expect it to (at least in this simple table
situation) calculate a theoretical max height, i.e. from the bottom of the
glyph with the lowest descender to the top of the glyph with the highest
ascender, and then add whatever padding we specify around that and use that
for every text row, so that the imaginary "ascender height" and "descender
height" lines seen in the figure here
https://en.wikipedia.org/wiki/Ascender_(typography) appear in the
same place in each cell. I have oversimplified my expected logic here for
sensible default scenario and assuming 1 line of text per cell, and nothing
other than text in the table.
<https://en.wikipedia.org/wiki/Descender>

Does that clarify the problem? I thought that as we touch the default
style here we might as well get it looking perfect, but if I go too
nitpicky then we can save it for a bug-fix release / feature release.

Best,
OceanWolf

------------------------------
*From:* Thomas Caswell <tcaswell at gmail.com>
*To:* Matthew Brett <matthew.brett at gmail.com>
*Cc:* matplotlib development list <matplotlib-devel at python.org>
*Sent:* Thursday, 14 July 2016, 0:23
*Subject:* Re: [Matplotlib-devel] v2.0.0b2

@Matthew Yes please, I just push the source tarball up and am working on
sorting out how to turn the crank on the many linux docker

@oceanwolf yes, but I did not understand the issue.

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160714/52e5dfa8/attachment-0001.html>