matplotlib-devel Mailing List for matplotlib (Page 3)

On 07/21/2013 04:12 AM, David P. Sanders wrote:
>
> Breaking news from the MathJax site:
>
> The *SVG output processor* is new in MathJax version 2.0, and it uses 
> Scalable Vector Graphics to render the mathematics on the page.
Not everything that views SVG is a web browser with Javascript support, 
so doing so would break using the SVG files in Inkscape and Adobe 
Illustrator, for example. I think that's kind of a non-starter, 
unfortunately.
>
> Mike: Could we use this to finally render all text in STIX *without* 
> using an external TeX installation? This would be fantastic!
You already can render all text in STIX without an external TeX 
installation. That's the purpose of the mathtext support in 
matplotlib. I agree it has the one wart that the default font also 
needs to be set when using stix for the math, but beyond that, it does 
already work today.
Cheers,
Mike
>
> David
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 07/20/2013 10:59 AM, David P. Sanders wrote:
>
>
> By the way, the following is a useful idiom to search for relevant 
> parameters in the rcParams:
>
> [k for k in mpl.rcParams.keys() if 'font' in k]
>
> I think it would be useful to document this -- where would be a good 
> place?
You might want to look at rcParams.find_all().
Mike

The STIX fonts are included with matplotlib, as the licensing permits 
this. We actually ship TTF versions of the fonts, converted from the 
original OTF files, since the built-in font rendering (i.e. when not 
using XeTeX etc.) does not support OTF. See MEP14 for a discussion of 
some of the gory details, if you're interested.
On 07/21/2013 04:08 AM, David P. Sanders wrote:
>
>
>
> On Sat, Jul 20, 2013 at 2:03 PM, Benjamin Root <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
>
> David,
>
> IIRC, we were just starting to investigate how to produce retina
> graphics. Perhaps you might be able to help Mike D and Michael de
> Hoon with there efforts because very few of us have retina displays.
>
>
> Sure, I'm very happy to help.
> First let me return to the fonts issue.
> I had been misunderstanding the rcParams (this seems to be a recurring 
> problem at the moment ;) - some new documentation is definitely 
> required; I will try to get round to add it to my matplotlib.settings 
> notebook).
>
> The fuzziness I referred to was indeed a retina issue, stemming from 
> the fact *that the default output format is still PNG*. It seems to me 
> that these days the default output should be SVG, which immediately 
> resolves all retina issues!! (And a lot of other issues, it seems to me.)
>
> The current status of retina support is actually reasonable. There are 
> two options:
>
> %load_ext retina
> %config InlineBackend.figure_format = 'retina'
>
> In the absence of tab completion for %load_ext and %config, and not 
> understanding the code, I am not sure if these are synonyms or not. 
> But the effect is to have PNGs produced with twice the vertical and 
> horizontal resolution. (The problem comes if, for example, these are 
> included in output sent to nbviewer, in which case they appear twice 
> as large.)
So it appears the fuzziness is specific to the IPython notebook. I 
think at the Scipy sprints we determined that using the MacOSX backend 
directly that there were no issues with the retina display. Let's maybe 
file an issue with the IPython folks about this. Since there is already 
a retina display plugin in IPython, perhaps a dicussion should be 
started about autodetecting the retina case and switching it on in that 
case. (I have no idea if that's technically feasible -- I don't know 
how Safari etc. implement the retina support).
BTW: This is IPython's PR where this was added: 
https://github.com/ipython/ipython/pull/3381
>
> One STIX font question remains: How can I get the text of the tick 
> labels and other things to also be in STIX?
> settings['font.family'] = 'stix'
> does not work, apparently.
STIX is designed to blend seamlessly with Times (New Roman), so you can 
set the default family to that. It might be worth discussing whether 
setting `math.fontset` to `stix` should do that by default. (It's tricky 
because it creates a dependency between different rcParams), but in the 
meantime, that is the best workaround.
>
> And could the default font finally be changed to something else? What 
> are the licensing requirements for the font? Is it distributed with 
> matplotlib, or how does it work?
The default font is Bitstream Vera Sans. At the time it was chosen, it 
was the only really obvious option for an open source font. There are 
better options now -- it would need to be something not only freely 
redistibutable, but also open source (to meet Debian and RedHat 
requirements). I don't know if we need to change the default, so much 
as make it easier to change (a la Tony's PR #2236). If there is a way 
to distribute fonts along with styles, that would be killer. I also 
hope to support WebFonts (which would be "installation free") as part of 
my ongoing work on MEP14, so that will get better, too.
Mike
>
> David.
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 07/20/2013 09:07 PM, Eric Firing wrote:
> On 2013年07月20日 2:38 PM, David P. Sanders wrote:
>> And this is my problem with 'rc': it brings to mind an arcane config
>> file hidden away somewhere that has a terrible syntax and must not be
>> touched.
>>
>> As Chris and Adrian have emphasized, the point is that we *should* be
>> tweaking away at the parameters all the time.
>> I propose to rename as mpl_params=rcParams
>>
> Yes, mpl_params is more descriptive and easy to remember. rcParams is
> ugly, obscure, and archaic. It will have to remain available for a long
> time, but I don't object to changing standard usage to a nicer name.
> There might even be a better name than "mpl_params"--"settings" comes to
> mind, or maybe "style".
I agree those are better. This is *such* a core method, though, that 
the old name can probably never go away -- there are tons of references 
to it in the documentation that would need to be updated, not to 
mention all of the non-documentation information (mailing list, 
stackoverflow) that Google finds. I worry that adding an alias will 
actually contribute to confusion, not eliminate it. I'd prefer to make 
it more obvious what it is and does in the documentation rather than 
change its name.
>
> As for parameter tweaking: the defaults shipped with mpl should be
> changed only rarely, but we should make it as easy as possible for users
> to customize plots, including coming up with good combinations of style
> parameters. In some cases it makes sense to do this via a matplotlibrc
> file, in other cases it is better to do the parameter setting explicitly
> at the top of a script.
>
> Regarding defaults, note that I said "rarely", not "never".
>
> The whole rc system could use a good review--maybe resulting in lots of
> changes, maybe not--so I welcome the attention you are directing to it.
>
My biggest pet peeve is the way that some parameters take effect at 
"construction time" and thus their changes have no effect on existing 
plots. Some take effect at draw time, and are thus more dynamic. We 
should strive for the latter whenever possible. Some things are just 
required to be the former, so these should be documented clearly as 
exceptions.
As for a low-hanging fruit project, the formatting of 
matplotlibrc.template is a mess. It would be great if someone could go 
through it and make the line lengths and tabbing consistent etc.
Mike

https://github.com/matplotlib/matplotlib/issues/959
Does anyone know of a reason not to simply delete the bits of idle_event 
support that are present? It looks like there isn't much, and it 
doesn't do anything. Unless someone knows why we have it at all, and 
has a plan to make it work, I think we should delete it.
Eric

On 2013年07月20日 10:08 PM, David P. Sanders wrote:
> The fuzziness I referred to was indeed a retina issue, stemming from the
> fact *that the default output format is still PNG*. It seems to me that
> these days the default output should be SVG, which immediately resolves
> all retina issues!! (And a lot of other issues, it seems to me.)
>
David,
A major problem with SVG output as default is that for image-type plots 
(e.g., pcolormesh) it yields enormous output that is very slow to 
render. The advantage of png is that although it is not optimal from a 
visual standpoint, it works reliably and predictably with everything. 
Therefore it is a sensible default.
Eric

On 2013年07月20日 10:16 PM, David P. Sanders wrote:
> I am trying to execute (with execfile) a script A.py containing
> matplotlib plotting commands from within a script B.py.
>
> Within B.py, I do execfile("A.py")
>
> The A.py script runs correctly, except that no plot is shown.
>
> I have checked that the A.py script does plot (to a separate window)
> when run
> with python A.py from the terminal.
> A.py does include plt.show()
David,
The attached scripts, which seem to be a minimal example of what you 
describe, work for me with matplotlib 1.2.1, MacOSX backend.
Eric
>
> Could an expert on backends help, please!
>
> Thanks
> David.
>
> --
> Dr. David P. Sanders
>
> Profesor Titular "A" / Associate Professor
> Departamento de Física, Facultad de Ciencias
> Universidad Nacional Autónoma de México (UNAM)
>
> dps...@ci... <mailto:dps...@ci...>
> http://sistemas.fciencias.unam.mx/~dsanders
> <http://sistemas.fciencias.unam.mx/%7Edsanders>
>
> Cubículo / office: #414, 4o. piso del Depto. de Física
> Tel.: +52 55 5622 4965

On Saturday 20 July 2013 09:41:58 David P. Sanders wrote:
> I have the STIX otf or ttf installed on my Mac, but I don't seem to manage
> to get the LaTeX versions installed -- installing LaTeX fonts is *so*
> disgusting (is there some helper script for that?).
There is a very good way to use otf and ttf fonts in LaTeX and matplotlib,
 which you might like:
http://matplotlib.org/users/pgf.html
With this method you can use LuaLaTeX, or XeLaTeX, both of which have
options to load OTF or TTF fonts. This would be done via the LaTeX preamble
in the .matplotlibrc file, which might be storred in the home directory on
your Mac (just a guess, since I do not normally use matplotlib with a Mac).
This might be a bit of a steep learning curve if you haven't done anything
more serious with matplotlib, but you won't have to install the fonts,
which, I must agree, *is* painful.
Hope that helps,
Ignas

On Saturday 20 July 2013 09:59:45 David P. Sanders wrote:
> OK, I found it:
> http://www.catb.org/jargon/html/R/rc-file.html
> 
> This is not good -- there is *no* reason to use the nomenclature 'rc'; this
> is just confusing for users who find it arcane and unwelcoming (I speak
> from experience).
> 
> Could it not just be called
> mpl.parameters, or mpl.mpl_parameters,
> or something like that?
Hello,
I was just wondering what is wrong with using the name rc (because it's just a
convention how to name your variable)? It is still used quite widely on UNIX
(and Mac OS is still a UNIX :)). Also, it is documented here:
http://matplotlib.org/users/customizing.html
I see your point though, in this document there isn't a single word, that the
'rcParams' stand more or less for the parameters which are initialised when
matplotlib loads or starts plotting.
Do not know if we should change this page to add some explanation, why we use
*rc settings*.
Ignas

I am trying to execute (with execfile) a script A.py containing matplotlib
plotting commands from within a script B.py.
Within B.py, I do execfile("A.py")
The A.py script runs correctly, except that no plot is shown.
I have checked that the A.py script does plot (to a separate window) when
run
with python A.py from the terminal.
A.py does include plt.show()
Could an expert on backends help, please!
Thanks
David.
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

Breaking news from the MathJax site:
The *SVG output processor* is new in MathJax version 2.0, and it uses Scalable
Vector Graphics to render the mathematics on the page.
Mike: Could we use this to finally render all text in STIX *without* using
an external TeX installation? This would be fantastic!
David

On Sat, Jul 20, 2013 at 2:03 PM, Benjamin Root <ben...@ou...> wrote:
> David,
>
> IIRC, we were just starting to investigate how to produce retina graphics.
> Perhaps you might be able to help Mike D and Michael de Hoon with there
> efforts because very few of us have retina displays.
>
Sure, I'm very happy to help.
First let me return to the fonts issue.
I had been misunderstanding the rcParams (this seems to be a recurring
problem at the moment ;) - some new documentation is definitely required; I
will try to get round to add it to my matplotlib.settings notebook).
The fuzziness I referred to was indeed a retina issue, stemming from the
fact *that the default output format is still PNG*. It seems to me that
these days the default output should be SVG, which immediately resolves all
retina issues!! (And a lot of other issues, it seems to me.)
The current status of retina support is actually reasonable. There are two
options:
%load_ext retina
%config InlineBackend.figure_format = 'retina'
In the absence of tab completion for %load_ext and %config, and not
understanding the code, I am not sure if these are synonyms or not. But the
effect is to have PNGs produced with twice the vertical and horizontal
resolution. (The problem comes if, for example, these are included in
output sent to nbviewer, in which case they appear twice as large.)
One STIX font question remains: How can I get the text of the tick labels
and other things to also be in STIX?
settings['font.family'] = 'stix'
does not work, apparently.
And could the default font finally be changed to something else? What are
the licensing requirements for the font? Is it distributed with matplotlib,
or how does it work?
David.

On Sat, Jul 20, 2013 at 9:10 PM, David P. Sanders <
dps...@ci...> wrote:
>
>
>
> On Sat, Jul 20, 2013 at 8:48 PM, Chris Beaumont <bea...@ha...>wrote:
>
>>
>>
<snip>
> However, default tweaking need not be painful. As has been mentioned, a
>> first step would be an easier way to change a whole set of rcParams:
>> something like mpl.set_style('style-name'). As long as one style is
>> 'classic', users can keep the current style for as long as they want. It's
>> a one line fix, and could even be rcParams-settable.
>>
>
> This is already implemented! The problem is, it's hidden away in the
> mpltools toolkit:
>
> http://tonysyu.github.io/mpltools/
>
> which nobody seems to know about or use, which is a great shame, since
> it's first class -- great job, Tony!
>
> The first example there is:
>
> >>> from mpltools import style>>> style.use('ggplot')
>
> and then the plot is suddenly jaw-droppingly beautiful!
>
> This is achieved with style files which just have lists of matplotlib
> params like this:
>
> patch.linewidth = 0.5
> patch.facecolor = '#348ABD' # blue
> patch.edgecolor = '#EEEEEE'
> patch.antialiased = True
>
> These are parsed using the ConfigObj package (this package parses config
> files of this type).
>
> Somebody (Chris?) tweeted something about the Vega package earlier:
> http://trifacta.github.io/vega/
>
> They seem to have these kind of things solved already (disclaimer: I only
> browsed briefly their site) using JSON, but actually Tony's approach seems
> like a winner.
>
> mpltools may be installed with
>
> > pip install ConfigObj
> > pip install mpltools
>
> [For some reason the dependency on ConfigObj is not registered in
> mpltools. Tony, are you the packager?]
>
I'm not really sure why the configobj dependency doesn't resolve properly.
As they say: pull requests are welcome. ;)
This is all *crying out* to be dropped straight into matplotlib proper!
>
Here's a PR to add the style sheets from mpltools:
https://github.com/matplotlib/matplotlib/pull/2236
(using matplotlib's parser instead of ConfigObj)
Cheers!
-Tony
> David
>
>

<html>
 <head>
 <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
 </head>
 <body bgcolor="#FFFFFF" text="#000000">
 Regarding whole sets of rcParams, you may want to look at this: <br>
 <meta http-equiv="content-type" content="text/html;
 charset=ISO-8859-1">
 <a href="https://github.com/tonysyu/mpltools">https://github.com/tonysyu/mpltools</a><br>
 <br>
 Kevin<br>
 <br>
 <div class="moz-cite-prefix">On 07/20/2013 09:48 PM, Chris Beaumont
 wrote:<br>
 </div>
 <blockquote
cite="mid:CAFP9tKpZx38kZXVddh0hZfaPpZSJPKP9O=Gf+=pp3...@ma..."
 type="cite">
 <div dir="ltr">'image.cmap' -- nice! Shows how much I know :)
 <div><br>
 </div>
 <div>I don't fully agree with Eric that changing the defaults
 should be treated as an API break -- yes, it may irritate a
 minority of users, but their code will still run. I'd flip
 around your argument for the role of rcParams and
 customization: the majority user is probably someone who
 doesn't know much about rcParams, or all the ways plots can be
 customized. *That* is the use case to optimize, not the
 "legacy" users invested in the current style.</div>
 <div><br>
 </div>
 <div>However, default tweaking need not be painful. As has been
 mentioned, a first step would be an easier way to change a
 whole set of rcParams: something like
 mpl.set_style('style-name'). As long as one style is
 'classic', users can keep the current style for as long as
 they want. It's a one line fix, and could even be
 rcParams-settable.</div>
 <div><br>
 </div>
 <div>With such a framework, it would be possible for people to
 contribute new styles that ship with MPL, and users could
 change styles without having to find (and potentially merge)
 rcParams files from the web. Finally, people could nominate
 that mature styles be made default (you could even assign
 version numbers to track the default style as it evolves
 towards visual awesomeness)</div>
 <div><br>
 </div>
 <div>chris</div>
 <div>&nbsp;</div>
 </div>
 <div class="gmail_extra"><br>
 <br>
 <div class="gmail_quote">On Sat, Jul 20, 2013 at 9:07 PM, Eric
 Firing <span dir="ltr">&lt;<a moz-do-not-send="true"
 href="mailto:ef...@ha..." target="_blank">ef...@ha...</a>&gt;</span>
 wrote:<br>
 <blockquote class="gmail_quote" style="margin:0 0 0
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 <div class="im">On 2013年07月20日 2:38 PM, David P. Sanders
 wrote:<br>
 &gt; And this is my problem with 'rc': &nbsp;it brings to mind
 an arcane config<br>
 &gt; file hidden away somewhere that has a terrible syntax
 and must not be<br>
 &gt; touched.<br>
 &gt;<br>
 &gt; As Chris and Adrian have emphasized, the point is
 that we *should* be<br>
 &gt; tweaking away at the parameters all the time.<br>
 &gt; I propose to rename as &nbsp;mpl_params=rcParams<br>
 &gt;<br>
 <br>
 </div>
 Yes, mpl_params is more descriptive and easy to remember.
 &nbsp;rcParams is<br>
 ugly, obscure, and archaic. &nbsp;It will have to remain
 available for a long<br>
 time, but I don't object to changing standard usage to a
 nicer name.<br>
 There might even be a better name than
 "mpl_params"--"settings" comes to<br>
 mind, or maybe "style".<br>
 <br>
 As for parameter tweaking: the defaults shipped with mpl
 should be<br>
 changed only rarely, but we should make it as easy as
 possible for users<br>
 to customize plots, including coming up with good
 combinations of style<br>
 parameters. &nbsp;In some cases it makes sense to do this via a
 matplotlibrc<br>
 file, in other cases it is better to do the parameter
 setting explicitly<br>
 at the top of a script.<br>
 <br>
 Regarding defaults, note that I said "rarely", not "never".<br>
 <br>
 The whole rc system could use a good review--maybe resulting
 in lots of<br>
 changes, maybe not--so I welcome the attention you are
 directing to it.<br>
 <span class="HOEnZb"><font color="#888888"><br>
 Eric<br>
 </font></span>
 <div class="HOEnZb">
 <div class="h5"><br>
------------------------------------------------------------------------------<br>
 See everything from the browser to the database with
 AppDynamics<br>
 Get end-to-end visibility with application monitoring
 from AppDynamics<br>
 Isolate bottlenecks and diagnose root cause in seconds.<br>
 Start your free trial of AppDynamics Pro today!<br>
 <a moz-do-not-send="true"
href="http://pubads.g.doubleclick.net/gampad/clk?id=48808831&amp;iu=/4140/ostg.clktrk"
 target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=48808831&amp;iu=/4140/ostg.clktrk</a><br>
 _______________________________________________<br>
 Matplotlib-devel mailing list<br>
 <a moz-do-not-send="true"
 href="mailto:Mat...@li...">Mat...@li...</a><br>
 <a moz-do-not-send="true"
 href="https://lists.sourceforge.net/lists/listinfo/matplotlib-devel"
 target="_blank">https://lists.sourceforge.net/lists/listinfo/matplotlib-devel</a><br>
 </div>
 </div>
 </blockquote>
 </div>
 <br>
 <br clear="all">
 <div><br>
 </div>
 -- <br>
 ************************************<br>
 Chris Beaumont<br>
 Graduate Student<br>
 Institute for Astronomy<br>
 University of Hawaii at Manoa<br>
 2680 Woodlawn Drive<br>
 Honolulu, HI 96822<br>
 <a moz-do-not-send="true"
 href="http://www.ifa.hawaii.edu/%7Ebeaumont">www.ifa.hawaii.edu/~beaumont</a><br>
 ************************************
 </div>
 <br>
 <fieldset class="mimeAttachmentHeader"></fieldset>
 <br>
 <pre wrap="">------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=48808831&amp;iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=48808831&amp;iu=/4140/ostg.clktrk</a></pre>
 <br>
 <fieldset class="mimeAttachmentHeader"></fieldset>
 <br>
 <pre wrap="">_______________________________________________
Matplotlib-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Mat...@li...">Mat...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/matplotlib-devel">https://lists.sourceforge.net/lists/listinfo/matplotlib-devel</a>
</pre>
 </blockquote>
 <br>
 </body>
</html>

I have created a page on the Wiki for listing ideas to do with styling:
https://github.com/matplotlib/matplotlib/wiki/Matplotlib-style-suggestions
David
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

Just saw Eric's post (but the mailing list has yet to update to send me the
individual posts apparently, hence the new title of this email).
+1 (or +100) for using 'settings' !
Here is the new version of my notebook:
http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/IPython-notebooks/master/matplotlib_settings.ipynb
*Boy*, does the IPython Notebook desperately need find and replace!!
David

On Sat, Jul 20, 2013 at 8:48 PM, Chris Beaumont <bea...@ha...> wrote:
> 'image.cmap' -- nice! Shows how much I know :)
>
> I don't fully agree with Eric that changing the defaults should be treated
> as an API break -- yes, it may irritate a minority of users, but their code
> will still run. I'd flip around your argument for the role of rcParams and
> customization: the majority user is probably someone who doesn't know much
> about rcParams, or all the ways plots can be customized. *That* is the use
> case to optimize, not the "legacy" users invested in the current style.
>
I whole-heartedly agree.
>
> However, default tweaking need not be painful. As has been mentioned, a
> first step would be an easier way to change a whole set of rcParams:
> something like mpl.set_style('style-name'). As long as one style is
> 'classic', users can keep the current style for as long as they want. It's
> a one line fix, and could even be rcParams-settable.
>
This is already implemented! The problem is, it's hidden away in the
mpltools toolkit:
http://tonysyu.github.io/mpltools/
which nobody seems to know about or use, which is a great shame, since it's
first class -- great job, Tony!
The first example there is:
>>> from mpltools import style>>> style.use('ggplot')
and then the plot is suddenly jaw-droppingly beautiful!
This is achieved with style files which just have lists of matplotlib
params like this:
patch.linewidth = 0.5
patch.facecolor = '#348ABD' # blue
patch.edgecolor = '#EEEEEE'
patch.antialiased = True
These are parsed using the ConfigObj package (this package parses config
files of this type).
Somebody (Chris?) tweeted something about the Vega package earlier:
http://trifacta.github.io/vega/
They seem to have these kind of things solved already (disclaimer: I only
browsed briefly their site) using JSON, but actually Tony's approach seems
like a winner.
mpltools may be installed with
> pip install ConfigObj
> pip install mpltools
[For some reason the dependency on ConfigObj is not registered in mpltools.
Tony, are you the packager?]
This is all *crying out* to be dropped straight into matplotlib proper!
David
>
> With such a framework, it would be possible for people to contribute new
> styles that ship with MPL, and users could change styles without having to
> find (and potentially merge) rcParams files from the web. Finally, people
> could nominate that mature styles be made default (you could even assign
> version numbers to track the default style as it evolves towards visual
> awesomeness)
>
> chris
>
>
>
> On Sat, Jul 20, 2013 at 9:07 PM, Eric Firing <ef...@ha...> wrote:
>
>> On 2013年07月20日 2:38 PM, David P. Sanders wrote:
>> > And this is my problem with 'rc': it brings to mind an arcane config
>> > file hidden away somewhere that has a terrible syntax and must not be
>> > touched.
>> >
>> > As Chris and Adrian have emphasized, the point is that we *should* be
>> > tweaking away at the parameters all the time.
>> > I propose to rename as mpl_params=rcParams
>> >
>>
>> Yes, mpl_params is more descriptive and easy to remember. rcParams is
>> ugly, obscure, and archaic. It will have to remain available for a long
>> time, but I don't object to changing standard usage to a nicer name.
>> There might even be a better name than "mpl_params"--"settings" comes to
>> mind, or maybe "style".
>>
>> As for parameter tweaking: the defaults shipped with mpl should be
>> changed only rarely, but we should make it as easy as possible for users
>> to customize plots, including coming up with good combinations of style
>> parameters. In some cases it makes sense to do this via a matplotlibrc
>> file, in other cases it is better to do the parameter setting explicitly
>> at the top of a script.
>>
>> Regarding defaults, note that I said "rarely", not "never".
>>
>> The whole rc system could use a good review--maybe resulting in lots of
>> changes, maybe not--so I welcome the attention you are directing to it.
>>
>> Eric
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

Hi,
Apparently I was misusing the list by having digests sent -- apologies.
I have turned this off.
Maybe the following got lost in the resulting noise:
I completely agree that the current defaults need updating.
In my opinion, 'rcParams' is a bad name, since it conjures up dusty
configuration files hidden in obscure corners which must never be modified.
Indeed, http://en.wikipedia.org/wiki/Run_commands says that the origin of
'rc' is:
> The term *rc* stands for the phrase "*run commands*". It is used for any
file that contains
> startup information for a command. It is believed to have originated
somewhere in 1965
None of these three 'features' of the phrase 'rc' have *anything* to do
with matplotlib.
'rc' evokes fond memories of hacking for a few; it evokes nothing and reeks
of alienating hack-speak to the rest.
I thus suggest that we replace rc_Params -> mpl_params.
As an example, I have made some narrative documentation, which can be
included in the matplotlib documentation (let's discuss where, Nelle and
Mike), on how to tweak mpl_params:
http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/IPython-notebooks/master/mpl_params.ipynb
This is, if you like, a cosmetic change, but I think it's an important
psychological one.
It also avoids the visual interruption caused by the capital 'P'.
Of course, anybody is free to make this change in the way I have in the
notebook by creating an alias, mpl_params = rcParams. But I am advocating
for changing uniformly to mpl_params (or a similar phrase) in the
documentation.
David
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

'image.cmap' -- nice! Shows how much I know :)
I don't fully agree with Eric that changing the defaults should be treated
as an API break -- yes, it may irritate a minority of users, but their code
will still run. I'd flip around your argument for the role of rcParams and
customization: the majority user is probably someone who doesn't know much
about rcParams, or all the ways plots can be customized. *That* is the use
case to optimize, not the "legacy" users invested in the current style.
However, default tweaking need not be painful. As has been mentioned, a
first step would be an easier way to change a whole set of rcParams:
something like mpl.set_style('style-name'). As long as one style is
'classic', users can keep the current style for as long as they want. It's
a one line fix, and could even be rcParams-settable.
With such a framework, it would be possible for people to contribute new
styles that ship with MPL, and users could change styles without having to
find (and potentially merge) rcParams files from the web. Finally, people
could nominate that mature styles be made default (you could even assign
version numbers to track the default style as it evolves towards visual
awesomeness)
chris
On Sat, Jul 20, 2013 at 9:07 PM, Eric Firing <ef...@ha...> wrote:
> On 2013年07月20日 2:38 PM, David P. Sanders wrote:
> > And this is my problem with 'rc': it brings to mind an arcane config
> > file hidden away somewhere that has a terrible syntax and must not be
> > touched.
> >
> > As Chris and Adrian have emphasized, the point is that we *should* be
> > tweaking away at the parameters all the time.
> > I propose to rename as mpl_params=rcParams
> >
>
> Yes, mpl_params is more descriptive and easy to remember. rcParams is
> ugly, obscure, and archaic. It will have to remain available for a long
> time, but I don't object to changing standard usage to a nicer name.
> There might even be a better name than "mpl_params"--"settings" comes to
> mind, or maybe "style".
>
> As for parameter tweaking: the defaults shipped with mpl should be
> changed only rarely, but we should make it as easy as possible for users
> to customize plots, including coming up with good combinations of style
> parameters. In some cases it makes sense to do this via a matplotlibrc
> file, in other cases it is better to do the parameter setting explicitly
> at the top of a script.
>
> Regarding defaults, note that I said "rarely", not "never".
>
> The whole rc system could use a good review--maybe resulting in lots of
> changes, maybe not--so I welcome the attention you are directing to it.
>
> Eric
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
************************************
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
************************************

On Sat, Jul 20, 2013 at 4:47 PM, Chris Beaumont <bea...@ha...> wrote:
> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I put
> together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the idea
> is semi tongue-in-cheek, and meant to gauge to what extent there is
> consensus about plot styles. It's not set up to teach about rcParams, nor
> does it systematically explore all possible styles. The votes (>10K, last I
> checked) are saved, and eventually Adrian or I will look over the feedback
> and report back to you all. I haven't had time for that yet. I hope the
> name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely upon
> daily), I must admit I was disheartened after hearing the MPL devs at SciPy
> discuss styles and defaults. I understand that you don't want to change the
> default styles without a clearly better alternative. I also understand
> that, to some extent, style preferences are subjective. However, there
> seemed to be quite a bit of resistance to the idea that MPL defaults should
> change *at all.*
>
> Even if you ignore the subjective component of this (which I think is a
> mistake, since in my experience there is broad consensus that projects like
> ggplot2, d3, tableau, and spotfire do a "better" job than MPL at styling),
> there are some well-established visual principles that matplotlib violates.
> Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, with
> similar luminance values. The current defaults (bgrcmyk) do not have this
> property -- c and y are harder to see, and thus carry less visual emphasis.
> A color table like the "Dark2" color brewer table (
> http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> colorbrewer2.org) is more uniform, and carefully designed for visibility
> and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
> smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties
> (which is even mentioned on the MPL docs at
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> ordering changes in hue (which is bigger -- purple or yellow?), and better
> at ordering changes in intensity or saturation. A colleague of mine
> designed a visualization tool for doctors, and found that the rainbow color
> table had a dramatic negative effect on the effectiveness of the tool (you
> can watch her TED talk about this at
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> especially frustrating, since it *cannot* be modified via rcParams
>
Jet is terrible for so many reasons, but it can be modified (unless I
misunderstand):
image.cmap : gray
I'm all for changing the current defaults.
Cheers,
-Tony

On 2013年07月20日 2:38 PM, David P. Sanders wrote:
> And this is my problem with 'rc': it brings to mind an arcane config
> file hidden away somewhere that has a terrible syntax and must not be
> touched.
>
> As Chris and Adrian have emphasized, the point is that we *should* be
> tweaking away at the parameters all the time.
> I propose to rename as mpl_params=rcParams
>
Yes, mpl_params is more descriptive and easy to remember. rcParams is 
ugly, obscure, and archaic. It will have to remain available for a long 
time, but I don't object to changing standard usage to a nicer name. 
There might even be a better name than "mpl_params"--"settings" comes to 
mind, or maybe "style".
As for parameter tweaking: the defaults shipped with mpl should be 
changed only rarely, but we should make it as easy as possible for users 
to customize plots, including coming up with good combinations of style 
parameters. In some cases it makes sense to do this via a matplotlibrc 
file, in other cases it is better to do the parameter setting explicitly 
at the top of a script.
Regarding defaults, note that I said "rarely", not "never".
The whole rc system could use a good review--maybe resulting in lots of 
changes, maybe not--so I welcome the attention you are directing to it.
Eric

On Sat, Jul 20, 2013 at 7:38 PM, David P. Sanders <
dps...@ci...> wrote:
>
>
>
> On Sat, Jul 20, 2013 at 5:36 PM, <
> mat...@li...> wrote:
>
>> Send Matplotlib-devel mailing list submissions to
>> mat...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> or, via email, send a message with subject or body 'help' to
>> mat...@li...
>>
>> You can reach the person managing the list at
>> mat...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Matplotlib-devel digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Plot or Not: voting to create better matplotlibrc
>> (Adrian Price-Whelan)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: 2013年7月20日 18:36:42 -0400
>> From: Adrian Price-Whelan <adr...@gm...>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> matplotlibrc
>> To: mat...@li...
>> Message-ID:
>> <CAEUL7mENjKC4ZYeSsm+7Yq7h4oYiA1nMPKi=
>> E9p...@ma...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hi,
>>
>> Definitely don't link from matplotlib. This was a fun hack put together to
>> get people talking about re-styling -- success!
>>
>>
> OK, sorry for the noise. The site is beautiful and functional, and I'm
> very glad that you got the discussion flowing!
>
>
> I have to echo Chris' disappointment about the discussion of defaults in
>> MPL. While there are certainly many subjective elements of style and
>> design, there are also a number of rules that the default settings violate
>> (as Chris mentions below). The way I interpret the push-back to replacing
>> the defaults is: "there are too many better alternatives that we will
>> never
>> agree upon, so let's just keep what's there." To 0th order, just pick one!
>> Fixing the few things that Chris mentions below will go a long way to
>> modernizing the MPL feel and experience. There many other things I would
>> like to change about the defaults, but maybe the right thing to do is just
>> issue a pull request so we can discuss on there?
>>
>
> I agree about the defaults, we desperately need to modernize the look of
> the plots to be competitive with ggplot2 etc.
>
>
>>
>> As a longer term idea, I propose:
>> - normalize what can and can't be modified with an rc file -- right now,
>> it's kind of all over the place
>>
>
> I really do object to the 'rc' terminology.
> According to http://en.wikipedia.org/wiki/Run_commands:
>
> > The term *rc* stands for the phrase "*run commands*". It is used for
> any file that contains startup information for a
> > command. It is believed to have originated somewhere in 1965
>
> And this is my problem with 'rc': it brings to mind an arcane config file
> hidden away somewhere that has a terrible syntax and must not be touched.
>
> As Chris and Adrian have emphasized, the point is that we *should* be
> tweaking away at the parameters all the time.
> I propose to rename as mpl_params=rcParams
>
> At https://gist.github.com/dpsanders/6047005 I have uploaded a short
> script which should be added to the matplotlib documentation, where I show
> how it looks to use mpl_params.
> I think it is much clearer and more inviting to tweak!
>
Sorry, I meant to send the nbviewer version, and call it a notebook, not a
script!
http://nbviewer.ipython.org/6047005
David
>
> David.
>
>
>
>>
>> then:
>> - each plot in the matplotlib gallery should have a drop-down menu with
>> ~3-5 style options
>> - these options can be named or whatever, but should be complete
>> matplotlibrc files that can either be a) shipped with matplotlib, or b)
>> very easily downloaded and installed (think:
>> matplotlib.rc_install('name-of-style'))
>> - on each gallery entry page, selecting an option from the drop-down
>> should
>> show the same plot made with the specified rc style
>>
>> I'm happy to help implement this stuff, but I think this would be a
>> tremendous resource to the community.
>>
>> And if you decide to reject everything from this email, *please* at least
>> change the default colormap :) #downwithJet
>>
>> - Adrian
>>
>> From: Chris Beaumont <bea...@ha...>
>> > Date: Sat, Jul 20, 2013 at 5:47 PM
>> > Subject: Re: Plot or Not: voting to create better matplotlibrc
>> > To: mat...@li...
>> >
>> >
>> > Hi,
>> >
>> > I thought I'd chime in on this discussion -- Adrian Price-Whelan and I
>> put
>> > together plotornot during the SciPy sprints.
>> >
>> > I wouldn't advocate for linking to plotornot from matplotlib -- the idea
>> > is semi tongue-in-cheek, and meant to gauge to what extent there is
>> > consensus about plot styles. It's not set up to teach about rcParams,
>> nor
>> > does it systematically explore all possible styles. The votes (>10K,
>> last I
>> > checked) are saved, and eventually Adrian or I will look over the
>> feedback
>> > and report back to you all. I haven't had time for that yet. I hope the
>> > name didn't *actually* offend anyone.
>> >
>> > At the risk of sounding unappreciative of MPL (which I love, and rely
>> upon
>> > daily), I must admit I was disheartened after hearing the MPL devs at
>> SciPy
>> > discuss styles and defaults. I understand that you don't want to change
>> the
>> > default styles without a clearly better alternative. I also understand
>> > that, to some extent, style preferences are subjective. However, there
>> > seemed to be quite a bit of resistance to the idea that MPL defaults
>> should
>> > change *at all.*
>> >
>> > Even if you ignore the subjective component of this (which I think is a
>> > mistake, since in my experience there is broad consensus that projects
>> like
>> > ggplot2, d3, tableau, and spotfire do a "better" job than MPL at
>> styling),
>> > there are some well-established visual principles that matplotlib
>> violates.
>> > Some of my biggest pet peeves are:
>> >
>> > 1) The default 'axes.color_cycle' values should be equally visible, with
>> > similar luminance values. The current defaults (bgrcmyk) do not have
>> this
>> > property -- c and y are harder to see, and thus carry less visual
>> emphasis.
>> > A color table like the "Dark2" color brewer table (
>> > http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
>> > colorbrewer2.org) is more uniform, and carefully designed for
>> visibility
>> > and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
>> > smarter default?
>> >
>> > 2) The default 'jet' colormap for images has a lot of poor properties
>> > (which is even mentioned on the MPL docs at
>> > http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
>> > ordering changes in hue (which is bigger -- purple or yellow?), and
>> better
>> > at ordering changes in intensity or saturation. A colleague of mine
>> > designed a visualization tool for doctors, and found that the rainbow
>> color
>> > table had a dramatic negative effect on the effectiveness of the tool
>> (you
>> > can watch her TED talk about this at
>> > https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
>> > especially frustrating, since it *cannot* be modified via rcParams
>> >
>> > 3) Some of the defaults violate Tufte principles like minimizing "chart
>> > junk." For example, the 'stepfilled' mode for hist is probably better
>> than
>> > the default, which draws vertical lines between every bin. Those lines
>> make
>> > the histogram noisier -- do they convey any extra information? Again,
>> this
>> > can't be tweaked via rcParams.
>> >
>> > Sorry for being long-winded -- I just want to make the case that this is
>> > an important (and not *entirely* subjective) issue. If nothing else, it
>> > would be great to see some clear statement about where the MPL devs
>> stand
>> > on this issue -- what criteria must be met to consider a change to the
>> > defaults? My apologies if such a document already exists somewhere!
>> >
>> > Cheers,
>> > Chris Beaumont
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Jul 20, 2013 at 3:03 PM, <
>> > mat...@li...> wrote:
>> >
>> >> Send Matplotlib-devel mailing list submissions to
>> >> mat...@li...
>> >>
>> >> To subscribe or unsubscribe via the World Wide Web, visit
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> or, via email, send a message with subject or body 'help' to
>> >> mat...@li...
>> >>
>> >> You can reach the person managing the list at
>> >> mat...@li...
>> >>
>> >> When replying, please edit your Subject line so it is more specific
>> >> than "Re: Contents of Matplotlib-devel digest..."
>> >>
>> >>
>> >> Today's Topics:
>> >>
>> >> 1. Re: Plot or Not: voting to create better matplotlibrc
>> >> (Eric Firing)
>> >> 2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
>> >> 3. Re: Plot or Not: voting to create better matplotlibrc
>> >> (Benjamin Root)
>> >> 4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
>> >>
>> >>
>> >> ----------------------------------------------------------------------
>> >>
>> >> Message: 1
>> >> Date: 2013年7月20日 08:20:11 -1000
>> >> From: Eric Firing <ef...@ha...>
>> >> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> >> matplotlibrc
>> >> To: mat...@li...
>> >> Message-ID: <51E...@ha...>
>> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> >>
>> >> On 2013年07月20日 4:18 AM, David P. Sanders wrote:
>> >> > Hi,
>> >> >
>> >> > Probably many of you know about "Plot or Not", a site where we vote
>> on
>> >> > the same plot presented in different ways, to get feedback about
>> better
>> >> > matplotlibrc params:
>> >> >
>> >> > http://warm-escarpment-9042.herokuapp.com/
>> >> >
>> >> > It seems to me an absolutely fantastic idea! I think many people do
>> not
>> >> > realise how fantastic the plots can look with some of this modern
>> >> > styling. (Styling was mentioned several times at SciPy.)
>> >> >
>> >> > Would it be possible to put a link to this site on the matplotlib web
>> >> > page and encourage people to use it?
>> >>
>> >> David,
>> >>
>> >> Interesting, but I'm not sure this is a good approach. I really don't
>> >> see the point of the voting. What I think would be more useful would
>> be
>> >> a set of matplotlibrc files with examples of their effect on at least a
>> >> few plot types.
>>
>> >>
>> >> >
>> >> > Definitely time to update the defaults!!
>> >>
>> >> Or maybe include a representative set of rcParams combinations to make
>> >> it easier for people to choose a design that suits their purpose. This
>> >> could be part of a toolkit.
>> >>
>> >> Eric
>>
>> >>
>> >> >
>> >> > Best wishes,
>> >> > David.
>> >> >
>> >> > --
>> >> > Dr. David P. Sanders
>> >> >
>> >> > Profesor Titular "A" / Associate Professor
>> >> > Departamento de F?sica, Facultad de Ciencias
>> >> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >> >
>> >> > dps...@ci... <mailto:dps...@ci...>
>> >> > http://sistemas.fciencias.unam.mx/~dsanders
>> >> > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>> >> >
>> >> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>>
>> >> > Tel.: +52 55 5622 4965
>> >> >
>> >> >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > See everything from the browser to the database with AppDynamics
>> >> > Get end-to-end visibility with application monitoring from
>> AppDynamics
>> >> > Isolate bottlenecks and diagnose root cause in seconds.
>> >> > Start your free trial of AppDynamics Pro today!
>> >> >
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Matplotlib-devel mailing list
>> >> > Mat...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 2
>> >> Date: 2013年7月20日 08:55:37 -1000
>> >> From: Eric Firing <ef...@ha...>
>> >> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>> >> plots?
>> >> To: mat...@li...
>> >> Message-ID: <51E...@ha...>
>> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >>
>> >> On 2013年07月20日 4:41 AM, David P. Sanders wrote:
>> >> > I find the default font used in matplotlib horrible. We should be
>> able
>> >> > to do much better these days.
>> >>
>> >> Which font is being used as default on your installation? And what are
>> >> the characteristics that earn the rating of "horrible"?
>> >>
>> >> Eric
>> >>
>> >>
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 3
>> >> Date: 2013年7月20日 14:58:12 -0400
>> >> From: Benjamin Root <ben...@ou...>
>> >> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> >> matplotlibrc
>> >> To: Eric Firing <ef...@ha...>
>> >> Cc: matplotlib development list
>> >> <mat...@li...>
>> >> Message-ID:
>> >> <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
>> >> c4Q...@ma...>
>> >> Content-Type: text/plain; charset="iso-8859-1"
>> >>
>> >> >From discussions with others at SciPy, we found ourselves disagreeing
>> on
>> >> what default we would want. We also weren't sure exactly which params
>> were
>> >> the ones that people tended to change. We have zero data on this. This
>> >> site
>> >> is intended to help start that data collection process.
>> >>
>> >> We can certainly improve this site to collect other kinds of info, but
>> >> this
>> >> is just a start. One could also view this as a launching point for
>> >> teaching
>> >> how to use rcParams (sorry David, i kinda like that name) in mpl. You
>> all
>> >> know I never let a good teaching moment go to waste!
>> >>
>> >> As for linking from matplotlib.org, I am ambivalent. It is a bit
>> >> gimmicky,
>> >> and I do worry about being counterproductive to efforts in SciPy to be
>> >> more
>> >> inclusive of women (given the rather anti-feministic undertones of the
>> >> site
>> >> we are parodying). Of course, that could just be me being overly
>> cautious.
>> >>
>> >> Cheers!
>> >> Ben Root
>> >> On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...> wrote:
>>
>> >>
>> >> > On 2013年07月20日 4:18 AM, David P. Sanders wrote:
>> >> > > Hi,
>> >> > >
>> >> > > Probably many of you know about "Plot or Not", a site where we
>> vote on
>> >> > > the same plot presented in different ways, to get feedback about
>> >> better
>> >> > > matplotlibrc params:
>> >> > >
>> >> > > http://warm-escarpment-9042.herokuapp.com/
>> >> > >
>> >> > > It seems to me an absolutely fantastic idea! I think many people do
>> >> not
>> >> > > realise how fantastic the plots can look with some of this modern
>> >> > > styling. (Styling was mentioned several times at SciPy.)
>> >> > >
>> >> > > Would it be possible to put a link to this site on the matplotlib
>> web
>> >> > > page and encourage people to use it?
>> >> >
>> >> > David,
>> >> >
>> >> > Interesting, but I'm not sure this is a good approach. I really
>> don't
>> >> > see the point of the voting. What I think would be more useful
>> would be
>> >> > a set of matplotlibrc files with examples of their effect on at
>> least a
>> >> > few plot types.
>>
>> >> >
>> >> > >
>> >> > > Definitely time to update the defaults!!
>> >> >
>> >> > Or maybe include a representative set of rcParams combinations to
>> make
>> >> > it easier for people to choose a design that suits their purpose.
>> This
>> >> > could be part of a toolkit.
>> >> >
>> >> > Eric
>>
>> >> >
>> >> > >
>> >> > > Best wishes,
>> >> > > David.
>> >> > >
>> >> > > --
>> >> > > Dr. David P. Sanders
>> >> > >
>> >> > > Profesor Titular "A" / Associate Professor
>> >> > > Departamento de F?sica, Facultad de Ciencias
>> >> > > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >> > >
>> >> > > dps...@ci... <mailto:dps...@ci...>
>> >> > > http://sistemas.fciencias.unam.mx/~dsanders
>> >> > > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>> >> > >
>> >> > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>>
>> >> > > Tel.: +52 55 5622 4965
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > > See everything from the browser to the database with AppDynamics
>> >> > > Get end-to-end visibility with application monitoring from
>> AppDynamics
>> >> > > Isolate bottlenecks and diagnose root cause in seconds.
>> >> > > Start your free trial of AppDynamics Pro today!
>> >> > >
>> >> >
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> > >
>> >> > >
>> >> > >
>> >> > > _______________________________________________
>> >> > > Matplotlib-devel mailing list
>> >> > > Mat...@li...
>> >> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > See everything from the browser to the database with AppDynamics
>> >> > Get end-to-end visibility with application monitoring from
>> AppDynamics
>> >> > Isolate bottlenecks and diagnose root cause in seconds.
>> >> > Start your free trial of AppDynamics Pro today!
>> >> >
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> > _______________________________________________
>> >> > Matplotlib-devel mailing list
>> >> > Mat...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 4
>> >> Date: 2013年7月20日 15:03:20 -0400
>> >> From: Benjamin Root <ben...@ou...>
>> >> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>> >> plots?
>> >> To: "David P. Sanders" <dps...@ci...>
>> >> Cc: matplotlib development list
>> >> <mat...@li...>
>> >> Message-ID:
>> >> <CANNq6Fm0Oz=
>> >> 3uk...@ma...>
>> >> Content-Type: text/plain; charset="iso-8859-1"
>> >>
>> >> David,
>> >>
>> >> IIRC, we were just starting to investigate how to produce retina
>> graphics.
>> >> Perhaps you might be able to help Mike D and Michael de Hoon with there
>> >> efforts because very few of us have retina displays.
>> >>
>> >> Cheers!
>> >> Ben Root
>> >> On Jul 20, 2013 10:43 AM, "David P. Sanders" <
>> dps...@ci...>
>> >> wrote:
>> >>
>> >> > I find the default font used in matplotlib horrible. We should be
>> able
>> >> to
>> >> > do much better these days.
>> >> >
>> >> > One very interesting option, at least for standard (paper)
>> publishing,
>> >> is
>> >> > the STIX fonts, which is a Times-like font set promoted by several
>> >> > publishers.
>> >> >
>> >> > There are various options in matplotlib, such as
>> >> > matplotlib.rcParams["mathtext.fontset"], which allow the option
>> "stix",
>> >> > but I have not been able to get it to work. Can anybody please help
>> me
>> >> with
>> >> > this -- what is required?
>> >> >
>> >> > I have the STIX otf or ttf installed on my Mac, but I don't seem to
>> >> manage
>> >> > to get the LaTeX versions installed -- installing LaTeX fonts is *so*
>> >> > disgusting (is there some helper script for that?).
>> >> >
>> >> > Thanks and best wishes,
>>
>> >> > David.
>> >> >
>> >> > --
>> >> > Dr. David P. Sanders
>> >> >
>> >> > Profesor Titular "A" / Associate Professor
>> >> > Departamento de F?sica, Facultad de Ciencias
>> >> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >> >
>> >> > dps...@ci...
>> >> > http://sistemas.fciencias.unam.mx/~dsanders
>> >> >
>> >> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>>
>> >> >
>> >> > Tel.: +52 55 5622 4965
>> >> >
>> >> >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > See everything from the browser to the database with AppDynamics
>> >> > Get end-to-end visibility with application monitoring from
>> AppDynamics
>> >> > Isolate bottlenecks and diagnose root cause in seconds.
>> >> > Start your free trial of AppDynamics Pro today!
>> >> >
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> > _______________________________________________
>> >> > Matplotlib-devel mailing list
>> >> > Mat...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> >
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >>
>> >> ------------------------------
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> See everything from the browser to the database with AppDynamics
>> >> Get end-to-end visibility with application monitoring from AppDynamics
>> >> Isolate bottlenecks and diagnose root cause in seconds.
>> >> Start your free trial of AppDynamics Pro today!
>> >>
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >>
>> >> ------------------------------
>> >>
>> >> _______________________________________________
>> >> Matplotlib-devel mailing list
>> >> Mat...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>
>> >>
>> >> End of Matplotlib-devel Digest, Vol 86, Issue 17
>> >> ************************************************
>> >>
>> >
>> >
>> >
>> > --
>> > ************************************
>> > Chris Beaumont
>> > Graduate Student
>> > Institute for Astronomy
>> > University of Hawaii at Manoa
>> > 2680 Woodlawn Drive
>> > Honolulu, HI 96822
>> > www.ifa.hawaii.edu/~beaumont
>> > ************************************
>> >
>> >
>> >
>> > --
>> > ************************************
>> > Chris Beaumont
>> > Graduate Student
>> > Institute for Astronomy
>> > University of Hawaii at Manoa
>> > 2680 Woodlawn Drive
>> > Honolulu, HI 96822
>> > www.ifa.hawaii.edu/~beaumont
>> > ************************************
>> >
>>
>>
>>
>> --
>>
>> Adrian M. Price-Whelan ~ Columbia University ~ http://adrian.pw
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>> ------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> End of Matplotlib-devel Digest, Vol 86, Issue 19
>> ************************************************
>>
>
>
>
> --
> Dr. David P. Sanders
>
> Profesor Titular "A" / Associate Professor
> Departamento de Física, Facultad de Ciencias
> Universidad Nacional Autónoma de México (UNAM)
>
> dps...@ci...
> http://sistemas.fciencias.unam.mx/~dsanders
>
> Cubículo / office: #414, 4o. piso del Depto. de Física
>
> Tel.: +52 55 5622 4965
>
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

On Sat, Jul 20, 2013 at 5:36 PM, <
mat...@li...> wrote:
> Send Matplotlib-devel mailing list submissions to
> mat...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> or, via email, send a message with subject or body 'help' to
> mat...@li...
>
> You can reach the person managing the list at
> mat...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Matplotlib-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Plot or Not: voting to create better matplotlibrc
> (Adrian Price-Whelan)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: 2013年7月20日 18:36:42 -0400
> From: Adrian Price-Whelan <adr...@gm...>
> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
> matplotlibrc
> To: mat...@li...
> Message-ID:
> <CAEUL7mENjKC4ZYeSsm+7Yq7h4oYiA1nMPKi=
> E9p...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Definitely don't link from matplotlib. This was a fun hack put together to
> get people talking about re-styling -- success!
>
>
OK, sorry for the noise. The site is beautiful and functional, and I'm very
glad that you got the discussion flowing!
I have to echo Chris' disappointment about the discussion of defaults in
> MPL. While there are certainly many subjective elements of style and
> design, there are also a number of rules that the default settings violate
> (as Chris mentions below). The way I interpret the push-back to replacing
> the defaults is: "there are too many better alternatives that we will never
> agree upon, so let's just keep what's there." To 0th order, just pick one!
> Fixing the few things that Chris mentions below will go a long way to
> modernizing the MPL feel and experience. There many other things I would
> like to change about the defaults, but maybe the right thing to do is just
> issue a pull request so we can discuss on there?
>
I agree about the defaults, we desperately need to modernize the look of
the plots to be competitive with ggplot2 etc.
>
> As a longer term idea, I propose:
> - normalize what can and can't be modified with an rc file -- right now,
> it's kind of all over the place
>
I really do object to the 'rc' terminology.
According to http://en.wikipedia.org/wiki/Run_commands:
> The term *rc* stands for the phrase "*run commands*". It is used for any
file that contains startup information for a
> command. It is believed to have originated somewhere in 1965
And this is my problem with 'rc': it brings to mind an arcane config file
hidden away somewhere that has a terrible syntax and must not be touched.
As Chris and Adrian have emphasized, the point is that we *should* be
tweaking away at the parameters all the time.
I propose to rename as mpl_params=rcParams
At https://gist.github.com/dpsanders/6047005 I have uploaded a short script
which should be added to the matplotlib documentation, where I show how it
looks to use mpl_params.
I think it is much clearer and more inviting to tweak!
David.
>
> then:
> - each plot in the matplotlib gallery should have a drop-down menu with
> ~3-5 style options
> - these options can be named or whatever, but should be complete
> matplotlibrc files that can either be a) shipped with matplotlib, or b)
> very easily downloaded and installed (think:
> matplotlib.rc_install('name-of-style'))
> - on each gallery entry page, selecting an option from the drop-down should
> show the same plot made with the specified rc style
>
> I'm happy to help implement this stuff, but I think this would be a
> tremendous resource to the community.
>
> And if you decide to reject everything from this email, *please* at least
> change the default colormap :) #downwithJet
>
> - Adrian
>
> From: Chris Beaumont <bea...@ha...>
> > Date: Sat, Jul 20, 2013 at 5:47 PM
> > Subject: Re: Plot or Not: voting to create better matplotlibrc
> > To: mat...@li...
> >
> >
> > Hi,
> >
> > I thought I'd chime in on this discussion -- Adrian Price-Whelan and I
> put
> > together plotornot during the SciPy sprints.
> >
> > I wouldn't advocate for linking to plotornot from matplotlib -- the idea
> > is semi tongue-in-cheek, and meant to gauge to what extent there is
> > consensus about plot styles. It's not set up to teach about rcParams, nor
> > does it systematically explore all possible styles. The votes (>10K,
> last I
> > checked) are saved, and eventually Adrian or I will look over the
> feedback
> > and report back to you all. I haven't had time for that yet. I hope the
> > name didn't *actually* offend anyone.
> >
> > At the risk of sounding unappreciative of MPL (which I love, and rely
> upon
> > daily), I must admit I was disheartened after hearing the MPL devs at
> SciPy
> > discuss styles and defaults. I understand that you don't want to change
> the
> > default styles without a clearly better alternative. I also understand
> > that, to some extent, style preferences are subjective. However, there
> > seemed to be quite a bit of resistance to the idea that MPL defaults
> should
> > change *at all.*
> >
> > Even if you ignore the subjective component of this (which I think is a
> > mistake, since in my experience there is broad consensus that projects
> like
> > ggplot2, d3, tableau, and spotfire do a "better" job than MPL at
> styling),
> > there are some well-established visual principles that matplotlib
> violates.
> > Some of my biggest pet peeves are:
> >
> > 1) The default 'axes.color_cycle' values should be equally visible, with
> > similar luminance values. The current defaults (bgrcmyk) do not have this
> > property -- c and y are harder to see, and thus carry less visual
> emphasis.
> > A color table like the "Dark2" color brewer table (
> > http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> > colorbrewer2.org) is more uniform, and carefully designed for visibility
> > and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
> > smarter default?
> >
> > 2) The default 'jet' colormap for images has a lot of poor properties
> > (which is even mentioned on the MPL docs at
> > http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> > ordering changes in hue (which is bigger -- purple or yellow?), and
> better
> > at ordering changes in intensity or saturation. A colleague of mine
> > designed a visualization tool for doctors, and found that the rainbow
> color
> > table had a dramatic negative effect on the effectiveness of the tool
> (you
> > can watch her TED talk about this at
> > https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> > especially frustrating, since it *cannot* be modified via rcParams
> >
> > 3) Some of the defaults violate Tufte principles like minimizing "chart
> > junk." For example, the 'stepfilled' mode for hist is probably better
> than
> > the default, which draws vertical lines between every bin. Those lines
> make
> > the histogram noisier -- do they convey any extra information? Again,
> this
> > can't be tweaked via rcParams.
> >
> > Sorry for being long-winded -- I just want to make the case that this is
> > an important (and not *entirely* subjective) issue. If nothing else, it
> > would be great to see some clear statement about where the MPL devs stand
> > on this issue -- what criteria must be met to consider a change to the
> > defaults? My apologies if such a document already exists somewhere!
> >
> > Cheers,
> > Chris Beaumont
> >
> >
> >
> >
> >
> > On Sat, Jul 20, 2013 at 3:03 PM, <
> > mat...@li...> wrote:
> >
> >> Send Matplotlib-devel mailing list submissions to
> >> mat...@li...
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >> or, via email, send a message with subject or body 'help' to
> >> mat...@li...
> >>
> >> You can reach the person managing the list at
> >> mat...@li...
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of Matplotlib-devel digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >> 1. Re: Plot or Not: voting to create better matplotlibrc
> >> (Eric Firing)
> >> 2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
> >> 3. Re: Plot or Not: voting to create better matplotlibrc
> >> (Benjamin Root)
> >> 4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: 2013年7月20日 08:20:11 -1000
> >> From: Eric Firing <ef...@ha...>
> >> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
> >> matplotlibrc
> >> To: mat...@li...
> >> Message-ID: <51E...@ha...>
> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>
> >> On 2013年07月20日 4:18 AM, David P. Sanders wrote:
> >> > Hi,
> >> >
> >> > Probably many of you know about "Plot or Not", a site where we vote on
> >> > the same plot presented in different ways, to get feedback about
> better
> >> > matplotlibrc params:
> >> >
> >> > http://warm-escarpment-9042.herokuapp.com/
> >> >
> >> > It seems to me an absolutely fantastic idea! I think many people do
> not
> >> > realise how fantastic the plots can look with some of this modern
> >> > styling. (Styling was mentioned several times at SciPy.)
> >> >
> >> > Would it be possible to put a link to this site on the matplotlib web
> >> > page and encourage people to use it?
> >>
> >> David,
> >>
> >> Interesting, but I'm not sure this is a good approach. I really don't
> >> see the point of the voting. What I think would be more useful would be
> >> a set of matplotlibrc files with examples of their effect on at least a
> >> few plot types.
> >>
> >> >
> >> > Definitely time to update the defaults!!
> >>
> >> Or maybe include a representative set of rcParams combinations to make
> >> it easier for people to choose a design that suits their purpose. This
> >> could be part of a toolkit.
> >>
> >> Eric
> >>
> >> >
> >> > Best wishes,
> >> > David.
> >> >
> >> > --
> >> > Dr. David P. Sanders
> >> >
> >> > Profesor Titular "A" / Associate Professor
> >> > Departamento de F?sica, Facultad de Ciencias
> >> > Universidad Nacional Aut?noma de M?xico (UNAM)
> >> >
> >> > dps...@ci... <mailto:dps...@ci...>
> >> > http://sistemas.fciencias.unam.mx/~dsanders
> >> > <http://sistemas.fciencias.unam.mx/%7Edsanders>
> >> >
> >> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> >> > Tel.: +52 55 5622 4965
> >> >
> >> >
> >> >
> >>
> ------------------------------------------------------------------------------
> >> > See everything from the browser to the database with AppDynamics
> >> > Get end-to-end visibility with application monitoring from AppDynamics
> >> > Isolate bottlenecks and diagnose root cause in seconds.
> >> > Start your free trial of AppDynamics Pro today!
> >> >
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Matplotlib-devel mailing list
> >> > Mat...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >> >
> >>
> >>
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 2
> >> Date: 2013年7月20日 08:55:37 -1000
> >> From: Eric Firing <ef...@ha...>
> >> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
> >> plots?
> >> To: mat...@li...
> >> Message-ID: <51E...@ha...>
> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >>
> >> On 2013年07月20日 4:41 AM, David P. Sanders wrote:
> >> > I find the default font used in matplotlib horrible. We should be able
> >> > to do much better these days.
> >>
> >> Which font is being used as default on your installation? And what are
> >> the characteristics that earn the rating of "horrible"?
> >>
> >> Eric
> >>
> >>
> >>
> >> ------------------------------
> >>
> >> Message: 3
> >> Date: 2013年7月20日 14:58:12 -0400
> >> From: Benjamin Root <ben...@ou...>
> >> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
> >> matplotlibrc
> >> To: Eric Firing <ef...@ha...>
> >> Cc: matplotlib development list
> >> <mat...@li...>
> >> Message-ID:
> >> <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
> >> c4Q...@ma...>
> >> Content-Type: text/plain; charset="iso-8859-1"
> >>
> >> >From discussions with others at SciPy, we found ourselves disagreeing
> on
> >> what default we would want. We also weren't sure exactly which params
> were
> >> the ones that people tended to change. We have zero data on this. This
> >> site
> >> is intended to help start that data collection process.
> >>
> >> We can certainly improve this site to collect other kinds of info, but
> >> this
> >> is just a start. One could also view this as a launching point for
> >> teaching
> >> how to use rcParams (sorry David, i kinda like that name) in mpl. You
> all
> >> know I never let a good teaching moment go to waste!
> >>
> >> As for linking from matplotlib.org, I am ambivalent. It is a bit
> >> gimmicky,
> >> and I do worry about being counterproductive to efforts in SciPy to be
> >> more
> >> inclusive of women (given the rather anti-feministic undertones of the
> >> site
> >> we are parodying). Of course, that could just be me being overly
> cautious.
> >>
> >> Cheers!
> >> Ben Root
> >> On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...> wrote:
> >>
> >> > On 2013年07月20日 4:18 AM, David P. Sanders wrote:
> >> > > Hi,
> >> > >
> >> > > Probably many of you know about "Plot or Not", a site where we vote
> on
> >> > > the same plot presented in different ways, to get feedback about
> >> better
> >> > > matplotlibrc params:
> >> > >
> >> > > http://warm-escarpment-9042.herokuapp.com/
> >> > >
> >> > > It seems to me an absolutely fantastic idea! I think many people do
> >> not
> >> > > realise how fantastic the plots can look with some of this modern
> >> > > styling. (Styling was mentioned several times at SciPy.)
> >> > >
> >> > > Would it be possible to put a link to this site on the matplotlib
> web
> >> > > page and encourage people to use it?
> >> >
> >> > David,
> >> >
> >> > Interesting, but I'm not sure this is a good approach. I really don't
> >> > see the point of the voting. What I think would be more useful would
> be
> >> > a set of matplotlibrc files with examples of their effect on at least
> a
> >> > few plot types.
> >> >
> >> > >
> >> > > Definitely time to update the defaults!!
> >> >
> >> > Or maybe include a representative set of rcParams combinations to make
> >> > it easier for people to choose a design that suits their purpose.
> This
> >> > could be part of a toolkit.
> >> >
> >> > Eric
> >> >
> >> > >
> >> > > Best wishes,
> >> > > David.
> >> > >
> >> > > --
> >> > > Dr. David P. Sanders
> >> > >
> >> > > Profesor Titular "A" / Associate Professor
> >> > > Departamento de F?sica, Facultad de Ciencias
> >> > > Universidad Nacional Aut?noma de M?xico (UNAM)
> >> > >
> >> > > dps...@ci... <mailto:dps...@ci...>
> >> > > http://sistemas.fciencias.unam.mx/~dsanders
> >> > > <http://sistemas.fciencias.unam.mx/%7Edsanders>
> >> > >
> >> > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> >> > > Tel.: +52 55 5622 4965
> >> > >
> >> > >
> >> > >
> >> >
> >>
> ------------------------------------------------------------------------------
> >> > > See everything from the browser to the database with AppDynamics
> >> > > Get end-to-end visibility with application monitoring from
> AppDynamics
> >> > > Isolate bottlenecks and diagnose root cause in seconds.
> >> > > Start your free trial of AppDynamics Pro today!
> >> > >
> >> >
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> > >
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > Matplotlib-devel mailing list
> >> > > Mat...@li...
> >> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >> > >
> >> >
> >> >
> >> >
> >> >
> >>
> ------------------------------------------------------------------------------
> >> > See everything from the browser to the database with AppDynamics
> >> > Get end-to-end visibility with application monitoring from AppDynamics
> >> > Isolate bottlenecks and diagnose root cause in seconds.
> >> > Start your free trial of AppDynamics Pro today!
> >> >
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> > _______________________________________________
> >> > Matplotlib-devel mailing list
> >> > Mat...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >>
> >> ------------------------------
> >>
> >> Message: 4
> >> Date: 2013年7月20日 15:03:20 -0400
> >> From: Benjamin Root <ben...@ou...>
> >> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
> >> plots?
> >> To: "David P. Sanders" <dps...@ci...>
> >> Cc: matplotlib development list
> >> <mat...@li...>
> >> Message-ID:
> >> <CANNq6Fm0Oz=
> >> 3uk...@ma...>
> >> Content-Type: text/plain; charset="iso-8859-1"
> >>
> >> David,
> >>
> >> IIRC, we were just starting to investigate how to produce retina
> graphics.
> >> Perhaps you might be able to help Mike D and Michael de Hoon with there
> >> efforts because very few of us have retina displays.
> >>
> >> Cheers!
> >> Ben Root
> >> On Jul 20, 2013 10:43 AM, "David P. Sanders" <
> dps...@ci...>
> >> wrote:
> >>
> >> > I find the default font used in matplotlib horrible. We should be able
> >> to
> >> > do much better these days.
> >> >
> >> > One very interesting option, at least for standard (paper) publishing,
> >> is
> >> > the STIX fonts, which is a Times-like font set promoted by several
> >> > publishers.
> >> >
> >> > There are various options in matplotlib, such as
> >> > matplotlib.rcParams["mathtext.fontset"], which allow the option
> "stix",
> >> > but I have not been able to get it to work. Can anybody please help me
> >> with
> >> > this -- what is required?
> >> >
> >> > I have the STIX otf or ttf installed on my Mac, but I don't seem to
> >> manage
> >> > to get the LaTeX versions installed -- installing LaTeX fonts is *so*
> >> > disgusting (is there some helper script for that?).
> >> >
> >> > Thanks and best wishes,
> >> > David.
> >> >
> >> > --
> >> > Dr. David P. Sanders
> >> >
> >> > Profesor Titular "A" / Associate Professor
> >> > Departamento de F?sica, Facultad de Ciencias
> >> > Universidad Nacional Aut?noma de M?xico (UNAM)
> >> >
> >> > dps...@ci...
> >> > http://sistemas.fciencias.unam.mx/~dsanders
> >> >
> >> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> >> >
> >> > Tel.: +52 55 5622 4965
> >> >
> >> >
> >> >
> >>
> ------------------------------------------------------------------------------
> >> > See everything from the browser to the database with AppDynamics
> >> > Get end-to-end visibility with application monitoring from AppDynamics
> >> > Isolate bottlenecks and diagnose root cause in seconds.
> >> > Start your free trial of AppDynamics Pro today!
> >> >
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> > _______________________________________________
> >> > Matplotlib-devel mailing list
> >> > Mat...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >> >
> >> >
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >>
> >> ------------------------------
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> See everything from the browser to the database with AppDynamics
> >> Get end-to-end visibility with application monitoring from AppDynamics
> >> Isolate bottlenecks and diagnose root cause in seconds.
> >> Start your free trial of AppDynamics Pro today!
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >>
> >> ------------------------------
> >>
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> >> End of Matplotlib-devel Digest, Vol 86, Issue 17
> >> ************************************************
> >>
> >
> >
> >
> > --
> > ************************************
> > Chris Beaumont
> > Graduate Student
> > Institute for Astronomy
> > University of Hawaii at Manoa
> > 2680 Woodlawn Drive
> > Honolulu, HI 96822
> > www.ifa.hawaii.edu/~beaumont
> > ************************************
> >
> >
> >
> > --
> > ************************************
> > Chris Beaumont
> > Graduate Student
> > Institute for Astronomy
> > University of Hawaii at Manoa
> > 2680 Woodlawn Drive
> > Honolulu, HI 96822
> > www.ifa.hawaii.edu/~beaumont
> > ************************************
> >
>
>
>
> --
>
> Adrian M. Price-Whelan ~ Columbia University ~ http://adrian.pw
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> End of Matplotlib-devel Digest, Vol 86, Issue 19
> ************************************************
>
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

On 2013年07月20日 11:47 AM, Chris Beaumont wrote:
> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I
> put together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the idea
> is semi tongue-in-cheek, and meant to gauge to what extent there is
> consensus about plot styles. It's not set up to teach about rcParams,
> nor does it systematically explore all possible styles. The votes (>10K,
> last I checked) are saved, and eventually Adrian or I will look over the
> feedback and report back to you all. I haven't had time for that yet. I
> hope the name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely
> upon daily), I must admit I was disheartened after hearing the MPL devs
> at SciPy discuss styles and defaults. I understand that you don't want
> to change the default styles without a clearly better alternative. I
> also understand that, to some extent, style preferences are subjective.
> However, there seemed to be quite a bit of resistance to the idea that
> MPL defaults should change *at all.*
>
> Even if you ignore the subjective component of this (which I think is a
> mistake, since in my experience there is broad consensus that projects
> like ggplot2, d3, tableau, and spotfire do a "better" job than MPL at
> styling), there are some well-established visual principles that
> matplotlib violates. Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, with
> similar luminance values. The current defaults (bgrcmyk) do not have
> this property -- c and y are harder to see, and thus carry less visual
> emphasis. A color table like the "Dark2" color brewer table
> (http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> colorbrewer2.org <http://colorbrewer2.org>) is more uniform, and
> carefully designed for visibility and contrast. 'rgbcmyk' is clearly an
> arbitrary choice -- why not use a smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties
> (which is even mentioned on the MPL docs at
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> ordering changes in hue (which is bigger -- purple or yellow?), and
> better at ordering changes in intensity or saturation. A colleague of
> mine designed a visualization tool for doctors, and found that the
> rainbow color table had a dramatic negative effect on the effectiveness
> of the tool (you can watch her TED talk about this at
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> especially frustrating, since it *cannot* be modified via rcParams
>
> 3) Some of the defaults violate Tufte principles like minimizing "chart
> junk." For example, the 'stepfilled' mode for hist is probably better
> than the default, which draws vertical lines between every bin. Those
> lines make the histogram noisier -- do they convey any extra
> information? Again, this can't be tweaked via rcParams.
>
> Sorry for being long-winded -- I just want to make the case that this is
> an important (and not *entirely* subjective) issue. If nothing else, it
> would be great to see some clear statement about where the MPL devs
> stand on this issue -- what criteria must be met to consider a change to
> the defaults? My apologies if such a document already exists somewhere!
>
> Cheers,
> Chris Beaumont
Chris,
I appreciate the ideas, and I agree entirely that improvements are in 
order, so it is just a question of exactly what and how, not whether 
there should be changes. (For example, the default line color set often 
irritates me, too, because blue and green look rather similar, 
particularly in comparison to red, which visually overwhelms the others.)
A problem with simply changing the defaults to some sort of consensus or 
majority opinion as to what is better is that inevitably there will be 
users who will be distressed when they upgrade and suddenly find that 
all their plots--perhaps generated automatically by their cron jobs or 
web apps--look very different, and perhaps don't even work well with the 
new defaults. Therefore we have to be somewhat conservative, and the 
tendency is to minimize changes that are not essential. I think that a 
change in the defaults will need to be staged in such a fashion that it 
will be as easy as possible for users to retain the old defaults if they 
prefer them. That leads to the idea that something like a style toolkit 
or cookbook, or set of examples included with mpl, might be helpful. 
There is never going to be one good style for all; it would be good to 
have examples of how to tailor things for the screen, or for paper, or 
for presentations, or for publications (some of which still favor black 
and white).
The mpl examples (gallery) can be the first target for improvement; 
based on some experience and input, an actual change in the defaults 
might be announced and scheduled for some future release, with assurance 
that a matplotlibrc file for the old defaults will remain available for 
some interval.
Eric

Hi,
Definitely don't link from matplotlib. This was a fun hack put together to
get people talking about re-styling -- success!
I have to echo Chris' disappointment about the discussion of defaults in
MPL. While there are certainly many subjective elements of style and
design, there are also a number of rules that the default settings violate
(as Chris mentions below). The way I interpret the push-back to replacing
the defaults is: "there are too many better alternatives that we will never
agree upon, so let's just keep what's there." To 0th order, just pick one!
Fixing the few things that Chris mentions below will go a long way to
modernizing the MPL feel and experience. There many other things I would
like to change about the defaults, but maybe the right thing to do is just
issue a pull request so we can discuss on there?
As a longer term idea, I propose:
- normalize what can and can't be modified with an rc file -- right now,
it's kind of all over the place
then:
- each plot in the matplotlib gallery should have a drop-down menu with
~3-5 style options
- these options can be named or whatever, but should be complete
matplotlibrc files that can either be a) shipped with matplotlib, or b)
very easily downloaded and installed (think:
 matplotlib.rc_install('name-of-style'))
- on each gallery entry page, selecting an option from the drop-down should
show the same plot made with the specified rc style
I'm happy to help implement this stuff, but I think this would be a
tremendous resource to the community.
And if you decide to reject everything from this email, *please* at least
change the default colormap :) #downwithJet
- Adrian
From: Chris Beaumont <bea...@ha...>
> Date: Sat, Jul 20, 2013 at 5:47 PM
> Subject: Re: Plot or Not: voting to create better matplotlibrc
> To: mat...@li...
>
>
> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I put
> together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the idea
> is semi tongue-in-cheek, and meant to gauge to what extent there is
> consensus about plot styles. It's not set up to teach about rcParams, nor
> does it systematically explore all possible styles. The votes (>10K, last I
> checked) are saved, and eventually Adrian or I will look over the feedback
> and report back to you all. I haven't had time for that yet. I hope the
> name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely upon
> daily), I must admit I was disheartened after hearing the MPL devs at SciPy
> discuss styles and defaults. I understand that you don't want to change the
> default styles without a clearly better alternative. I also understand
> that, to some extent, style preferences are subjective. However, there
> seemed to be quite a bit of resistance to the idea that MPL defaults should
> change *at all.*
>
> Even if you ignore the subjective component of this (which I think is a
> mistake, since in my experience there is broad consensus that projects like
> ggplot2, d3, tableau, and spotfire do a "better" job than MPL at styling),
> there are some well-established visual principles that matplotlib violates.
> Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, with
> similar luminance values. The current defaults (bgrcmyk) do not have this
> property -- c and y are harder to see, and thus carry less visual emphasis.
> A color table like the "Dark2" color brewer table (
> http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> colorbrewer2.org) is more uniform, and carefully designed for visibility
> and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
> smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties
> (which is even mentioned on the MPL docs at
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> ordering changes in hue (which is bigger -- purple or yellow?), and better
> at ordering changes in intensity or saturation. A colleague of mine
> designed a visualization tool for doctors, and found that the rainbow color
> table had a dramatic negative effect on the effectiveness of the tool (you
> can watch her TED talk about this at
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> especially frustrating, since it *cannot* be modified via rcParams
>
> 3) Some of the defaults violate Tufte principles like minimizing "chart
> junk." For example, the 'stepfilled' mode for hist is probably better than
> the default, which draws vertical lines between every bin. Those lines make
> the histogram noisier -- do they convey any extra information? Again, this
> can't be tweaked via rcParams.
>
> Sorry for being long-winded -- I just want to make the case that this is
> an important (and not *entirely* subjective) issue. If nothing else, it
> would be great to see some clear statement about where the MPL devs stand
> on this issue -- what criteria must be met to consider a change to the
> defaults? My apologies if such a document already exists somewhere!
>
> Cheers,
> Chris Beaumont
>
>
>
>
>
> On Sat, Jul 20, 2013 at 3:03 PM, <
> mat...@li...> wrote:
>
>> Send Matplotlib-devel mailing list submissions to
>> mat...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> or, via email, send a message with subject or body 'help' to
>> mat...@li...
>>
>> You can reach the person managing the list at
>> mat...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Matplotlib-devel digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Plot or Not: voting to create better matplotlibrc
>> (Eric Firing)
>> 2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
>> 3. Re: Plot or Not: voting to create better matplotlibrc
>> (Benjamin Root)
>> 4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: 2013年7月20日 08:20:11 -1000
>> From: Eric Firing <ef...@ha...>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> matplotlibrc
>> To: mat...@li...
>> Message-ID: <51E...@ha...>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2013年07月20日 4:18 AM, David P. Sanders wrote:
>> > Hi,
>> >
>> > Probably many of you know about "Plot or Not", a site where we vote on
>> > the same plot presented in different ways, to get feedback about better
>> > matplotlibrc params:
>> >
>> > http://warm-escarpment-9042.herokuapp.com/
>> >
>> > It seems to me an absolutely fantastic idea! I think many people do not
>> > realise how fantastic the plots can look with some of this modern
>> > styling. (Styling was mentioned several times at SciPy.)
>> >
>> > Would it be possible to put a link to this site on the matplotlib web
>> > page and encourage people to use it?
>>
>> David,
>>
>> Interesting, but I'm not sure this is a good approach. I really don't
>> see the point of the voting. What I think would be more useful would be
>> a set of matplotlibrc files with examples of their effect on at least a
>> few plot types.
>>
>> >
>> > Definitely time to update the defaults!!
>>
>> Or maybe include a representative set of rcParams combinations to make
>> it easier for people to choose a design that suits their purpose. This
>> could be part of a toolkit.
>>
>> Eric
>>
>> >
>> > Best wishes,
>> > David.
>> >
>> > --
>> > Dr. David P. Sanders
>> >
>> > Profesor Titular "A" / Associate Professor
>> > Departamento de F?sica, Facultad de Ciencias
>> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >
>> > dps...@ci... <mailto:dps...@ci...>
>> > http://sistemas.fciencias.unam.mx/~dsanders
>> > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>> >
>> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> > Tel.: +52 55 5622 4965
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >
>> >
>> >
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: 2013年7月20日 08:55:37 -1000
>> From: Eric Firing <ef...@ha...>
>> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>> plots?
>> To: mat...@li...
>> Message-ID: <51E...@ha...>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2013年07月20日 4:41 AM, David P. Sanders wrote:
>> > I find the default font used in matplotlib horrible. We should be able
>> > to do much better these days.
>>
>> Which font is being used as default on your installation? And what are
>> the characteristics that earn the rating of "horrible"?
>>
>> Eric
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: 2013年7月20日 14:58:12 -0400
>> From: Benjamin Root <ben...@ou...>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> matplotlibrc
>> To: Eric Firing <ef...@ha...>
>> Cc: matplotlib development list
>> <mat...@li...>
>> Message-ID:
>> <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
>> c4Q...@ma...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> >From discussions with others at SciPy, we found ourselves disagreeing on
>> what default we would want. We also weren't sure exactly which params were
>> the ones that people tended to change. We have zero data on this. This
>> site
>> is intended to help start that data collection process.
>>
>> We can certainly improve this site to collect other kinds of info, but
>> this
>> is just a start. One could also view this as a launching point for
>> teaching
>> how to use rcParams (sorry David, i kinda like that name) in mpl. You all
>> know I never let a good teaching moment go to waste!
>>
>> As for linking from matplotlib.org, I am ambivalent. It is a bit
>> gimmicky,
>> and I do worry about being counterproductive to efforts in SciPy to be
>> more
>> inclusive of women (given the rather anti-feministic undertones of the
>> site
>> we are parodying). Of course, that could just be me being overly cautious.
>>
>> Cheers!
>> Ben Root
>> On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...> wrote:
>>
>> > On 2013年07月20日 4:18 AM, David P. Sanders wrote:
>> > > Hi,
>> > >
>> > > Probably many of you know about "Plot or Not", a site where we vote on
>> > > the same plot presented in different ways, to get feedback about
>> better
>> > > matplotlibrc params:
>> > >
>> > > http://warm-escarpment-9042.herokuapp.com/
>> > >
>> > > It seems to me an absolutely fantastic idea! I think many people do
>> not
>> > > realise how fantastic the plots can look with some of this modern
>> > > styling. (Styling was mentioned several times at SciPy.)
>> > >
>> > > Would it be possible to put a link to this site on the matplotlib web
>> > > page and encourage people to use it?
>> >
>> > David,
>> >
>> > Interesting, but I'm not sure this is a good approach. I really don't
>> > see the point of the voting. What I think would be more useful would be
>> > a set of matplotlibrc files with examples of their effect on at least a
>> > few plot types.
>> >
>> > >
>> > > Definitely time to update the defaults!!
>> >
>> > Or maybe include a representative set of rcParams combinations to make
>> > it easier for people to choose a design that suits their purpose. This
>> > could be part of a toolkit.
>> >
>> > Eric
>> >
>> > >
>> > > Best wishes,
>> > > David.
>> > >
>> > > --
>> > > Dr. David P. Sanders
>> > >
>> > > Profesor Titular "A" / Associate Professor
>> > > Departamento de F?sica, Facultad de Ciencias
>> > > Universidad Nacional Aut?noma de M?xico (UNAM)
>> > >
>> > > dps...@ci... <mailto:dps...@ci...>
>> > > http://sistemas.fciencias.unam.mx/~dsanders
>> > > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>> > >
>> > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> > > Tel.: +52 55 5622 4965
>> > >
>> > >
>> > >
>> >
>> ------------------------------------------------------------------------------
>> > > See everything from the browser to the database with AppDynamics
>> > > Get end-to-end visibility with application monitoring from AppDynamics
>> > > Isolate bottlenecks and diagnose root cause in seconds.
>> > > Start your free trial of AppDynamics Pro today!
>> > >
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > Matplotlib-devel mailing list
>> > > Mat...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> > >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>> Message: 4
>> Date: 2013年7月20日 15:03:20 -0400
>> From: Benjamin Root <ben...@ou...>
>> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>> plots?
>> To: "David P. Sanders" <dps...@ci...>
>> Cc: matplotlib development list
>> <mat...@li...>
>> Message-ID:
>> <CANNq6Fm0Oz=
>> 3uk...@ma...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> David,
>>
>> IIRC, we were just starting to investigate how to produce retina graphics.
>> Perhaps you might be able to help Mike D and Michael de Hoon with there
>> efforts because very few of us have retina displays.
>>
>> Cheers!
>> Ben Root
>> On Jul 20, 2013 10:43 AM, "David P. Sanders" <dps...@ci...>
>> wrote:
>>
>> > I find the default font used in matplotlib horrible. We should be able
>> to
>> > do much better these days.
>> >
>> > One very interesting option, at least for standard (paper) publishing,
>> is
>> > the STIX fonts, which is a Times-like font set promoted by several
>> > publishers.
>> >
>> > There are various options in matplotlib, such as
>> > matplotlib.rcParams["mathtext.fontset"], which allow the option "stix",
>> > but I have not been able to get it to work. Can anybody please help me
>> with
>> > this -- what is required?
>> >
>> > I have the STIX otf or ttf installed on my Mac, but I don't seem to
>> manage
>> > to get the LaTeX versions installed -- installing LaTeX fonts is *so*
>> > disgusting (is there some helper script for that?).
>> >
>> > Thanks and best wishes,
>> > David.
>> >
>> > --
>> > Dr. David P. Sanders
>> >
>> > Profesor Titular "A" / Associate Professor
>> > Departamento de F?sica, Facultad de Ciencias
>> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >
>> > dps...@ci...
>> > http://sistemas.fciencias.unam.mx/~dsanders
>> >
>> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> >
>> > Tel.: +52 55 5622 4965
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>> ------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> End of Matplotlib-devel Digest, Vol 86, Issue 17
>> ************************************************
>>
>
>
>
> --
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>
>
>
> --
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>
-- 
Adrian M. Price-Whelan ~ Columbia University ~ http://adrian.pw