matplotlib-devel Mailing List for matplotlib

For reference, the IPython script is in tools/update_whatsnew.py
On Thu Nov 27 2014 at 11:58:40 AM Ian Thomas <ian...@gm...> wrote:
> On 27 November 2014 at 16:16, Thomas Caswell <tca...@gm...> wrote:
>
>> There should be an automatic process, but no one has written it yet. I
>> think IPython has code we can adapt in their doc build process. I had
>> planned to deal with this when we cut the next minor/major release.
>>
>> Tom
>>
>
> Thanks for letting me know Tom.
>
> Ian
>

On 27 November 2014 at 16:16, Thomas Caswell <tca...@gm...> wrote:
> There should be an automatic process, but no one has written it yet. I
> think IPython has code we can adapt in their doc build process. I had
> planned to deal with this when we cut the next minor/major release.
>
> Tom
>
Thanks for letting me know Tom.
Ian

There should be an automatic process, but no one has written it yet. I
think IPython has code we can adapt in their doc build process. I had
planned to deal with this when we cut the next minor/major release.
Tom
On Thu, Nov 27, 2014, 04:18 Ian Thomas <ian...@gm...> wrote:
> Fellow developers,
>
> I know we are now encouraged when writing a PR not to alter
> doc/users/whats_new.rst and doc/api/api_changes.rst directly, but rather to
> create files in the doc/users/whats_new and doc/api/api_changes directories
> instead. When building the master branch docs I was expecting the contents
> of these new files to be automagically incorporated in the appropriate doc
> sections, but this does not happen on my development system (ubuntu 14.04,
> python 2.7, sphinx 1.2.2).
>
> I figure either I am doing something wrong, or this is a bug, or there is
> manual process at release time to cut and paste the new files into the
> parent files. Which is it?
>
> Ian
> ------------------------------------------------------------
> ------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&
> iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Nov 26, 2014 10:04 PM, "Nathaniel Smith" <nj...@po...> wrote:
>
> On Wed, Nov 26, 2014 at 9:30 AM, Todd <tod...@gm...> wrote:
> > On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith <nj...@po...> wrote:
> >>
> >> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> >> appear to be based on any real theory about visualization -- it's just
> >> the corners of the RGB color cube, which is a highly perceptually
> >> non-uniform space. The resulting lines aren't terribly high contrast
> >> against the default white background, and the different colors have
> >> varying luminance that makes some lines "pop out" more than others.
> >>
> >> Seaborn's default is to use a nice isoluminant variant on matplotlib's
> >> default:
> >>
> >>
http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> >> ggplot2 uses isoluminant colors with maximally-separated hues, which
> >> also works well. E.g.:
> >>
> >>
http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
> >
> > About this, I am not expert so forgive me if this is nonsensical.
However,
> > it would seem to me that these requirements are basically the same as
the
> > requirements for the new default colormap that prompted this whole
> > discussion. So, rather than create two inconsistent set of colors that
> > accomplish similar goals, might it be better to instead use the default
> > colormap for the line colors? You could pick "N" equally-spaced colors
from
> > the colormap and use those as the line colors.
>
> The main differences in requirements are:
> - for the color cycle, you want isoluminant colors, to avoid the issue
> where one line is glaring bright red and one is barely-visible-grey.
> For general-purpose 2d colormaps, though, you almost always want the
> luminance to vary to help distinguish colors from each other.
If you used isoluminance colors for the lines, wouldn't that mean a plot
printed in grayscale would have all lines be the same shade of gray?

Fellow developers,
I know we are now encouraged when writing a PR not to alter
doc/users/whats_new.rst and doc/api/api_changes.rst directly, but rather to
create files in the doc/users/whats_new and doc/api/api_changes directories
instead. When building the master branch docs I was expecting the contents
of these new files to be automagically incorporated in the appropriate doc
sections, but this does not happen on my development system (ubuntu 14.04,
python 2.7, sphinx 1.2.2).
I figure either I am doing something wrong, or this is a bug, or there is
manual process at release time to cut and paste the new files into the
parent files. Which is it?
Ian