matplotlib-devel Mailing List for matplotlib

Paul Hobson wrote:
> On Thu, May 30, 2013 at 5:03 PM, Michael Droettboom
> <md...@st...> wrote:
> 
>> On 05/30/2013 02:27 PM, Chris Barker - NOAA Federal wrote:
>> >
>> > With a fully-function mathtex, it could be the default (only?) text
>> > layout system for MPL, simplifying things quite a bit.
>>
>> I'm not sure that's realistic. The usetex backend gets a great deal of
>> use, and I don't think it's only because it handles multiline text
>> better -- it's also the easiest way to make the text match that of a
>> larger TeX document in which it's included (though the new PGF backend
>> goes some way to helping that in an entirely different way).
> 
> 
> Exactly! I like that I can set text.usetex=True and add
> \usepackage{fourier} and I *know* that my figures and document will look
> the same.
> 
> That said, I've never been able to get the PGF backend to work well. Random
> elements are pixelated. It's surely user-error on my end, but the usetex is
> comparatively easy to set up.
> 
> 
>> It might
>> be worth collating a list of reasons that users are using "usetex" to
>> include in the MEP -- if we can address them all in another way, great,
>> but if not it's not too difficult to keep something that already works
>> fairly well working. The problem I have with it is not really that it
>> exists, only that it has tendrils all throughout matplotlib that could
>> be better localized into a single set of modules.
>>
> 
> As I state above -- I absolutely require One Font throughout my documents.
> If it's a serif font, I use the fourier TeX package. If it's a sans-serif
> font, I do the weird \sansmath voodoo (I still owe you a PR with an example
> of setting that up). Point is, it works well.
> 
> Cheers,
> -paul
I had the impression that XeTeX had stopped development and that LuaTeX was 
the path forward.

> 1) It's implemented in ctypes. I'm not much of a fan of ctypes, as it 
> has the potential to segfault in nasty ways if the API changes in any 
> way from what was expected (which would normally be caught at compile 
> time in a C extension). I'm also concerned about the overhead of 
> ctypes, given that there are already so many required optimizations in 
> the matplotlib freetype wrapper to make it fast enough. But I'm willing 
> to hold judgement on that until some measurements have been made.
> 
I would never have thought ctypes would be a problem for speed/optimization and I never benchmarked the freetype-py. Not sure how to do that though.
> 2) It's not Numpy-aware. For example, it loads image buffers into 
> regular Python lists. This really should use Numpy for speed.
Yes, and I recently discovered it may make things really slow in some cases.
> 3) It exposes the fixed point numbers to Python as integers -- it should 
> really return all of these as floats -- the user shouldn't have to know 
> or remember which values are 16.16 and which are 24.8 etc. It should 
> just give floats. Double precision (with 52 bits in the mantissa) is 
> enough for any of these 32-bit fixed-point values. I think that's just a 
> remnant of older systems and needing to run on hardware without an FPU 
> that doesn't need to be brought forward into the Python wrapper.
You're right. I try to keep the very-low level to stick to the freetype implementation/type and the mid-level wrapper should use float everywhere (I may need to check that).
This + your comment on Google App Engine makes me think that freetype-py might not be so useful in the end. Anyway, I would gladly (try to) contribute to the new system.
Nicolas

On 05/30/2013 08:21 PM, Michael Droettboom wrote:
> 1) It's implemented in ctypes. I'm not much of a fan of ctypes, as it 
> has the potential to segfault in nasty ways if the API changes in any 
> way from what was expected (which would normally be caught at compile 
> time in a C extension). I'm also concerned about the overhead of 
> ctypes, given that there are already so many required optimizations in 
> the matplotlib freetype wrapper to make it fast enough. But I'm 
> willing to hold judgement on that until some measurements have been 
> made. 2) It's not Numpy-aware. For example, it loads image buffers 
> into regular Python lists. This really should use Numpy for speed. 3) 
> It exposes the fixed point numbers to Python as integers -- it should 
> really return all of these as floats -- the user shouldn't have to 
> know or remember which values are 16.16 and which are 24.8 etc. It 
> should just give floats. Double precision (with 52 bits in the 
> mantissa) is enough for any of these 32-bit fixed-point values. I 
> think that's just a remnant of older systems and needing to run on 
> hardware without an FPU that doesn't need to be brought forward into 
> the Python wrapper. 4) It should have another layer to handle the 
> decoding of SFNT tables in a consistent manner. I know the 
> sfnt-names.py example does this, but that should be built into the 
> library. There are certain places where hiding the details of the 
> underlying font file is a good thing -- and I think one of the reasons 
> freetype doesn't do this is the lack of a standard Unicode type in C. 
> We don't have that problem in Python. I think all of these are fixable 
> by adding another layer on top, with the exception of (1) of course. 
> Maybe it makes sense to build that intermediate layer, adapt 
> matplotlib to it, benchmark the ctypes issue, and if necessary 
> reimplement the core using C/API.
Additionally, I just discovered that ctypes isn't available on Google 
App Engine, for obvious security reasons. That sort of, unfortunately, 
makes it a non-starter for matplotlib.
Wish that weren't the case, but I think Google App Engine support is an 
important thing to keep going...
Mike

On Thu, May 30, 2013 at 5:03 PM, Michael Droettboom <md...@st...> wrote:
> On 05/30/2013 02:27 PM, Chris Barker - NOAA Federal wrote:
> >
> > With a fully-function mathtex, it could be the default (only?) text
> > layout system for MPL, simplifying things quite a bit.
>
> I'm not sure that's realistic. The usetex backend gets a great deal of
> use, and I don't think it's only because it handles multiline text
> better -- it's also the easiest way to make the text match that of a
> larger TeX document in which it's included (though the new PGF backend
> goes some way to helping that in an entirely different way).
Exactly! I like that I can set text.usetex=True and add
\usepackage{fourier} and I *know* that my figures and document will look
the same.
That said, I've never been able to get the PGF backend to work well. Random
elements are pixelated. It's surely user-error on my end, but the usetex is
comparatively easy to set up.
> It might
> be worth collating a list of reasons that users are using "usetex" to
> include in the MEP -- if we can address them all in another way, great,
> but if not it's not too difficult to keep something that already works
> fairly well working. The problem I have with it is not really that it
> exists, only that it has tendrils all throughout matplotlib that could
> be better localized into a single set of modules.
>
As I state above -- I absolutely require One Font throughout my documents.
If it's a serif font, I use the fourier TeX package. If it's a sans-serif
font, I do the weird \sansmath voodoo (I still owe you a PR with an example
of setting that up). Point is, it works well.
Cheers,
-paul

On 05/30/2013 06:06 PM, Russell E. Owen wrote:
> I uploaded a binary installer for MacOS X, 64-bit python.org python 2.7.
> I built it using numpy 1.7.1. This version does not include pytz,
> dateutil or six, but the included ReadMe says they are prerequisites and
> suggests installing them with pip.
>
> The tests showed more problems than usual. I have appended the whole set.
>
> A few questions:
> - Why does setupext.py's dateutil finder have this:
> return ['python_dateutil']
> when the package is called python-dateutil (hyphen instead of
> underscore)? If it is intentional, it might be worth noting with a
> comment.
Thanks for noticing that. You are correct, and that underscore should 
be replaced with a hyphen. However, I think in practice it's making no 
difference. distribute automatically replaces underscores with hyphens 
before it does the PyPI lookup. In any event, I've fixed this in e2e89eb.
> - Why include licenses for pytz and dateutil?
I just forgot to remove those during the refactor. They have been 
removed in 441fe10.
As for the tests: The warnings are all normal (it would be great to 
hide them, but I haven't invested much time to investigate that).
The first two failures are related to the PGF backend, and I suspect are 
failing because of a missing package in your LaTeX installation. I've 
created issue #2097 and Cc'd you and Peter Wurtz (the PGF backend 
author) who may have some insight.
The last failure is a puzzler -- for some reason, the 
test_coding_standards test module isn't importing, though it was found. 
I'll let you know if there's more information I need from you about 
that, but at this point I'm not even sure how to investigate that one.
Thanks for working on this,
Mike
>
> -- Russell
>
> Here is the test log:
>
> localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
> .........................................................................
> .........................................................................
> .........................................................................
> ..........kpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
> Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
> EK.....K.................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> ...................................../Library/Frameworks/Python.framework
> /Versions/2.7/lib/python2.7/site-packages/numpy/ma/core.py:777:
> RuntimeWarning: invalid value encountered in absolute
> return umath.absolute(a) * self.tolerance >= umath.absolute(b)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/ma/core.py:3791: UserWarning: Warning: converting a masked
> element to nan.
> warnings.warn("Warning: converting a masked element to nan.")
> .........................................../Library/Frameworks/Python.fra
> mework/Versions/2.7/lib/python2.7/site-packages/matplotlib/gridspec.py:29
> 8: UserWarning: This figure includes Axes that are not compatible with
> tight_layout, so its results might be incorrect.
> warnings.warn("This figure includes Axes that are not "
> ............................................/Library/Frameworks/Python.fr
> amework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py:8
> 07: RuntimeWarning: invalid value encountered in absolute
> z = abs(x-y)
> ........E
> ======================================================================
> ERROR: matplotlib.tests.test_backend_pgf.test_pathclip
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
> result = func(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 145, in test_pathclip
> plt.savefig(os.path.join(result_dir, "pgf_pathclip.pdf"))
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/pyplot.py", line 561, in savefig
> return fig.savefig(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/figure.py", line 1410, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backend_bases.py", line 2220, in print_figure
> **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 864, in print_pdf
> self._print_pdf_to_fh(fh, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 822, in _print_pdf_to_fh
> self.print_pgf(fname_pgf, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 804, in print_pgf
> self._print_pgf_to_fh(fh, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 784, in _print_pgf_to_fh
> RendererPgf(self.figure, fh),
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 409, in __init__
> self.latexManager = LatexManagerFactory.get_latex_manager()
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 223, in get_latex_manager
> new_inst = LatexManager()
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 309, in __init__
> raise LatexError("LaTeX returned an error, probably missing font or
> error in preamble:\n%s" % stdout)
> LatexError: LaTeX returned an error, probably missing font or error in
> preamble:
> This is XeTeX, Version 3.1415926-2.4-0.9998 (TeX Live 2012)
> restricted \write18 enabled.
> **entering extended mode
> LaTeX2e <2011年06月27日>
> Babel <v3.8m> and hyphenation patterns for english, dumylang,
> nohyphenation, ge
> rman-x-2012年05月30日, ngerman-x-2012年05月30日, afrikaans, ancientgreek,
> ibycus, arabi
> c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian,
> czech, danis
> h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi,
> finnis
> h, french, friulan, galician, german, ngerman, swissgerman, monogreek,
> greek, h
> ungarian, icelandic, assamese, bengali, gujarati, hindi, kannada,
> malayalam, ma
> rathi, oriya, panjabi, tamil, telugu, indonesian, interlingua, irish,
> italian,
> kurmanji, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal,
> nynorsk,
> polish, portuguese, romanian, romansh, russian, sanskrit, serbian,
> serbianc, s
> lovak, slovenian, spanish, swedish, turkish, turkmen, ukrainian,
> uppersorbian,
> welsh, loaded.
>
> *(/usr/local/texlive/2012/texmf-dist/tex/latex/base/minimal.cls
> Document Class: minimal 2001年05月25日 Standard LaTeX minimal class
> )
> (Please type a command or say `\end')
> *
> *(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/expl3.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3names.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3bootstrap.sty))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/etex-pkg/etex.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/color.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/color.cfg)
> (/usr/local/texlive/2012/texmf-dist/tex/xelatex/xetex-def/xetex.def))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphics.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/trig.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/graphics.cfg))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3basics.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3expan.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3tl.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3seq.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3int.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3quark.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prg.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3clist.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3token.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prop.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3msg.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3file.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3skip.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3keys.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3fp.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3box.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3coffins.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3color.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3luatex.sty))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3packages/xparse/xparse.st
> y)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-patches.s
> ty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/base/fixltx2e.sty)
> *************************************************
> * LaTeX warning: "xparse/redefine-command"
> *
> * Redefining document command \oldstylenums with arg. spec. 'm' on line
> 107.
> *************************************************
> )
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1enc.def)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> (/usr/local/texlive/2012/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/tipa/t3enc.def
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmss.fd))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphicx.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/keyval.sty)))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !
> ! fontspec error: "font-not-found"
> !
> ! The font "Bitstream Vera Serif" cannot be found.
> !
> ! See the fontspec documentation for further information.
> !
> ! For immediate help type H <return>.
> !...............................................
> 
> <*> \setmainfont{Bitstream Vera Serif}
> 
> No pages of output.
> Transcript written on texput.log.
>
>
> ======================================================================
> ERROR: matplotlib.tests.test_backend_pgf.test_mixedmode
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
> result = func(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 157, in test_mixedmode
> compare_figure('pgf_mixedmode.pdf')
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 56, in compare_figure
> plt.savefig(actual)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/pyplot.py", line 561, in savefig
> return fig.savefig(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/figure.py", line 1410, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backend_bases.py", line 2220, in print_figure
> **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 864, in print_pdf
> self._print_pdf_to_fh(fh, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 822, in _print_pdf_to_fh
> self.print_pgf(fname_pgf, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 804, in print_pgf
> self._print_pgf_to_fh(fh, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 784, in _print_pgf_to_fh
> RendererPgf(self.figure, fh),
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 409, in __init__
> self.latexManager = LatexManagerFactory.get_latex_manager()
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 223, in get_latex_manager
> new_inst = LatexManager()
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 309, in __init__
> raise LatexError("LaTeX returned an error, probably missing font or
> error in preamble:\n%s" % stdout)
> LatexError: LaTeX returned an error, probably missing font or error in
> preamble:
> This is XeTeX, Version 3.1415926-2.4-0.9998 (TeX Live 2012)
> restricted \write18 enabled.
> **entering extended mode
> LaTeX2e <2011年06月27日>
> Babel <v3.8m> and hyphenation patterns for english, dumylang,
> nohyphenation, ge
> rman-x-2012年05月30日, ngerman-x-2012年05月30日, afrikaans, ancientgreek,
> ibycus, arabi
> c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian,
> czech, danis
> h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi,
> finnis
> h, french, friulan, galician, german, ngerman, swissgerman, monogreek,
> greek, h
> ungarian, icelandic, assamese, bengali, gujarati, hindi, kannada,
> malayalam, ma
> rathi, oriya, panjabi, tamil, telugu, indonesian, interlingua, irish,
> italian,
> kurmanji, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal,
> nynorsk,
> polish, portuguese, romanian, romansh, russian, sanskrit, serbian,
> serbianc, s
> lovak, slovenian, spanish, swedish, turkish, turkmen, ukrainian,
> uppersorbian,
> welsh, loaded.
>
> *(/usr/local/texlive/2012/texmf-dist/tex/latex/base/minimal.cls
> Document Class: minimal 2001年05月25日 Standard LaTeX minimal class
> )
> (Please type a command or say `\end')
> *
> *(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/expl3.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3names.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3bootstrap.sty))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/etex-pkg/etex.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/color.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/color.cfg)
> (/usr/local/texlive/2012/texmf-dist/tex/xelatex/xetex-def/xetex.def))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphics.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/trig.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/graphics.cfg))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3basics.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3expan.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3tl.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3seq.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3int.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3quark.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prg.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3clist.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3token.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prop.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3msg.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3file.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3skip.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3keys.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3fp.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3box.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3coffins.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3color.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3luatex.sty))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3packages/xparse/xparse.st
> y)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-patches.s
> ty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/base/fixltx2e.sty)
> *************************************************
> * LaTeX warning: "xparse/redefine-command"
> *
> * Redefining document command \oldstylenums with arg. spec. 'm' on line
> 107.
> *************************************************
> )
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1enc.def)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> (/usr/local/texlive/2012/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/tipa/t3enc.def
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmss.fd))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphicx.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/keyval.sty)))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !
> ! fontspec error: "font-not-found"
> !
> ! The font "Bitstream Vera Serif" cannot be found.
> !
> ! See the fontspec documentation for further information.
> !
> ! For immediate help type H <return>.
> !...............................................
> 
> <*> \setmainfont{Bitstream Vera Serif}
> 
> No pages of output.
> Transcript written on texput.log.
>
>
> ======================================================================
> ERROR: Failure: AttributeError ('module' object has no attribute
> 'test_coding_standards')
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/loader.py", line 379, in loadTestsFromName
> module = resolve_name(addr.module)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/util.py", line 331, in resolve_name
> obj = getattr(obj, part)
> AttributeError: 'module' object has no attribute 'test_coding_standards'
>
> ----------------------------------------------------------------------
> Ran 1458 tests in 833.661s
>
> FAILED (KNOWNFAIL=2, errors=3)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/__init__.py:1141: UserWarning: This call to
> matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
>
> warnings.warn(_use_error_msg)
> localhost$
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 05/30/2013 03:33 PM, Nicolas Rougier wrote:
>
> For the free type wrapper, maybe the freetype-py may be of some help:
> http://code.google.com/p/freetype-py/
>
> I did not wrap all the freetype library but it already allows a fair amount of font manipulation/rendering.
I looked at this a number of years ago, and just looked at it again 
today. I think in general it's a better approach than what we have now 
in matplotlib, in that it's a thin wrapper around freetype rather than a 
"just enough to for what we need approach", which should make things 
more flexible in the long run. It's a lot like what I have in mind.
However, I do have some concerns about it and I'd like to get a sense of 
your receptibility to these changes.
1) It's implemented in ctypes. I'm not much of a fan of ctypes, as it 
has the potential to segfault in nasty ways if the API changes in any 
way from what was expected (which would normally be caught at compile 
time in a C extension). I'm also concerned about the overhead of 
ctypes, given that there are already so many required optimizations in 
the matplotlib freetype wrapper to make it fast enough. But I'm willing 
to hold judgement on that until some measurements have been made.
2) It's not Numpy-aware. For example, it loads image buffers into 
regular Python lists. This really should use Numpy for speed.
3) It exposes the fixed point numbers to Python as integers -- it should 
really return all of these as floats -- the user shouldn't have to know 
or remember which values are 16.16 and which are 24.8 etc. It should 
just give floats. Double precision (with 52 bits in the mantissa) is 
enough for any of these 32-bit fixed-point values. I think that's just a 
remnant of older systems and needing to run on hardware without an FPU 
that doesn't need to be brought forward into the Python wrapper.
4) It should have another layer to handle the decoding of SFNT tables in 
a consistent manner. I know the sfnt-names.py example does this, but 
that should be built into the library. There are certain places where 
hiding the details of the underlying font file is a good thing -- and I 
think one of the reasons freetype doesn't do this is the lack of a 
standard Unicode type in C. We don't have that problem in Python.
I think all of these are fixable by adding another layer on top, with 
the exception of (1) of course. Maybe it makes sense to build that 
intermediate layer, adapt matplotlib to it, benchmark the ctypes issue, 
and if necessary reimplement the core using C/API.
>
>
> For unicode/harfbuzz, I've found this example
>
> https://github.com/lxnt/ex-sdl-freetype-harfbuzz
>
> to be incredibly useful to understand the (poorly documented) library. The strong point of harfbuzz is to have no heavy dependencies (compared to pango for example). By the way, Behad is considering a refactoring of the library and it might be worth to interact with him (on the harfbuzz list) to see how this could ease a python wrapper (if you intend to use it of course).
That example is very helpful. Thanks. I should add to the MEP, for 
those that are not aware, that even though Harfbuzz is a part of the 
Gtk/Gnome/Cairo ecosystem, it is a very standalone library itself, and 
is the closest to "works everywhere with minimal requirements" of any of 
the available options. I should definitely clarify that even though 
there are many options for font layout libraries, including both 
cross-platform/open source and closed-source-vendor ones, Harfbuzz could 
be the "one to rule them all" so we wouldn't necessarily need to wrap 
all of them.
>
>
> In the current draft, you're speaking of rich text but I found no reference for a possible markup (or equivalent) to specify the different font, color, boldness, etc.
Yeah -- I need to make that more explicit. I think MEP14 needs to 
consider the *possibility* of adding rich text support down the line so 
that the API can support it, but the details of how we might actually do 
that should be postponed for another MEP. It's already a lot to bite 
off as it is. Does that make sense to you -- are there things in the 
proposed API that would inhibit that from being added in the future?
Cheers,
Mike
>
>
>
> Nicolas
>
>
>
> On May 30, 2013, at 8:27 PM, Chris Barker - NOAA Federal <chr...@no...> wrote:
>
>> On Thu, May 30, 2013 at 8:59 AM, Michael Droettboom <md...@st...> wrote:
>>> I've drafted a MEP with a plan to improve some of the text and font handling
>>> in matplotlib.
>>>
>>> I'd love any and all feedback.
>> nice writ-up and thanks for workign on this.
>>
>> One idea (alternative?) would be to put more effort into the
>> "mathtext" renderer. TeX itself, of course does an outstanding job of
>> laying out text, paragraphs, etc. I'm assuming that the core stuff is
>> already in mathtext, so adding better support for regular old non-math
>> text would be a less-than-huge deal. And we still wouldn't need the
>> full how-to-split-pages and all that code for MPL.
>>
>> Not sure about properly handling unicode issues, though modern TeX
>> does support unicode.
>>
>> With a fully-function mathtex, it could be the default (only?) text
>> layout system for MPL, simplifying things quite a bit.
>>
>> ... just a thought.
>>
>> -Chris
>>
>>
>>
>> -- 
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R (206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> Chr...@no...
>>
>> ------------------------------------------------------------------------------
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 05/30/2013 02:27 PM, Chris Barker - NOAA Federal wrote:
> On Thu, May 30, 2013 at 8:59 AM, Michael Droettboom <md...@st...> wrote:
>> I've drafted a MEP with a plan to improve some of the text and font handling
>> in matplotlib.
>>
>> I'd love any and all feedback.
> nice writ-up and thanks for workign on this.
>
> One idea (alternative?) would be to put more effort into the
> "mathtext" renderer. TeX itself, of course does an outstanding job of
> laying out text, paragraphs, etc. I'm assuming that the core stuff is
> already in mathtext, so adding better support for regular old non-math
> text would be a less-than-huge deal. And we still wouldn't need the
> full how-to-split-pages and all that code for MPL.
That's an interesting idea, that we should definitely ruminate on. That 
still doesn't address the Unicode issues, which are really complex to 
get right -- I'd really rather depend on something else for that. But 
what you suggest might be the best way forward to improve the built-in 
rendering for a good fraction of users that don't really care about Unicode.
>
> Not sure about properly handling unicode issues, though modern TeX
> does support unicode.
Right -- and I think moving to XeTeX for the "usetex" backend, which is 
now pretty widely available, might be a good improvement on that front. 
I still don't want to reimplement all of that, if I can avoid it.
>
> With a fully-function mathtex, it could be the default (only?) text
> layout system for MPL, simplifying things quite a bit.
I'm not sure that's realistic. The usetex backend gets a great deal of 
use, and I don't think it's only because it handles multiline text 
better -- it's also the easiest way to make the text match that of a 
larger TeX document in which it's included (though the new PGF backend 
goes some way to helping that in an entirely different way). It might 
be worth collating a list of reasons that users are using "usetex" to 
include in the MEP -- if we can address them all in another way, great, 
but if not it's not too difficult to keep something that already works 
fairly well working. The problem I have with it is not really that it 
exists, only that it has tendrils all throughout matplotlib that could 
be better localized into a single set of modules.
>
> ... just a thought.
>
>
Thanks. Keep em coming!
Mike

I uploaded a binary installer for MacOS X, 64-bit python.org python 2.7.
I built it using numpy 1.7.1. This version does not include pytz, 
dateutil or six, but the included ReadMe says they are prerequisites and 
suggests installing them with pip.
The tests showed more problems than usual. I have appended the whole set.
A few questions:
- Why does setupext.py's dateutil finder have this:
 return ['python_dateutil']
when the package is called python-dateutil (hyphen instead of 
underscore)? If it is intentional, it might be worth noting with a 
comment.
- Why include licenses for pytz and dateutil?
-- Russell
Here is the test log:
localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
.........................................................................
.........................................................................
.........................................................................
..........kpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
EK.....K.................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
...................................../Library/Frameworks/Python.framework
/Versions/2.7/lib/python2.7/site-packages/numpy/ma/core.py:777: 
RuntimeWarning: invalid value encountered in absolute
 return umath.absolute(a) * self.tolerance >= umath.absolute(b)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/ma/core.py:3791: UserWarning: Warning: converting a masked 
element to nan.
 warnings.warn("Warning: converting a masked element to nan.")
.........................................../Library/Frameworks/Python.fra
mework/Versions/2.7/lib/python2.7/site-packages/matplotlib/gridspec.py:29
8: UserWarning: This figure includes Axes that are not compatible with 
tight_layout, so its results might be incorrect.
 warnings.warn("This figure includes Axes that are not "
............................................/Library/Frameworks/Python.fr
amework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py:8
07: RuntimeWarning: invalid value encountered in absolute
 z = abs(x-y)
........E
======================================================================
ERROR: matplotlib.tests.test_backend_pgf.test_pathclip
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
 result = func(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 145, in test_pathclip
 plt.savefig(os.path.join(result_dir, "pgf_pathclip.pdf"))
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/pyplot.py", line 561, in savefig
 return fig.savefig(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/figure.py", line 1410, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backend_bases.py", line 2220, in print_figure
 **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 864, in print_pdf
 self._print_pdf_to_fh(fh, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 822, in _print_pdf_to_fh
 self.print_pgf(fname_pgf, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 804, in print_pgf
 self._print_pgf_to_fh(fh, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 784, in _print_pgf_to_fh
 RendererPgf(self.figure, fh),
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 409, in __init__
 self.latexManager = LatexManagerFactory.get_latex_manager()
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 223, in get_latex_manager
 new_inst = LatexManager()
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 309, in __init__
 raise LatexError("LaTeX returned an error, probably missing font or 
error in preamble:\n%s" % stdout)
LatexError: LaTeX returned an error, probably missing font or error in 
preamble:
This is XeTeX, Version 3.1415926-2.4-0.9998 (TeX Live 2012)
 restricted \write18 enabled.
**entering extended mode
LaTeX2e <2011年06月27日>
Babel <v3.8m> and hyphenation patterns for english, dumylang, 
nohyphenation, ge
rman-x-2012年05月30日, ngerman-x-2012年05月30日, afrikaans, ancientgreek, 
ibycus, arabi
c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian, 
czech, danis
h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi, 
finnis
h, french, friulan, galician, german, ngerman, swissgerman, monogreek, 
greek, h
ungarian, icelandic, assamese, bengali, gujarati, hindi, kannada, 
malayalam, ma
rathi, oriya, panjabi, tamil, telugu, indonesian, interlingua, irish, 
italian, 
kurmanji, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal, 
nynorsk,
 polish, portuguese, romanian, romansh, russian, sanskrit, serbian, 
serbianc, s
lovak, slovenian, spanish, swedish, turkish, turkmen, ukrainian, 
uppersorbian, 
welsh, loaded.
*(/usr/local/texlive/2012/texmf-dist/tex/latex/base/minimal.cls
Document Class: minimal 2001年05月25日 Standard LaTeX minimal class
)
(Please type a command or say `\end')
*
*(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3names.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3bootstrap.sty))
(/usr/local/texlive/2012/texmf-dist/tex/latex/etex-pkg/etex.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/color.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/local/texlive/2012/texmf-dist/tex/xelatex/xetex-def/xetex.def))
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/graphics.cfg))
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3basics.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3expan.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3tl.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3seq.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3int.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3quark.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prg.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3clist.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3token.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prop.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3msg.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3file.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3skip.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3keys.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3fp.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3box.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3coffins.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3color.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3luatex.sty))
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3packages/xparse/xparse.st
y)
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-patches.s
ty
(/usr/local/texlive/2012/texmf-dist/tex/latex/base/fixltx2e.sty)
*************************************************
* LaTeX warning: "xparse/redefine-command"
* 
* Redefining document command \oldstylenums with arg. spec. 'm' on line 
107.
*************************************************
) 
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/base/fontenc.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1enc.def)
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmr.fd))
(/usr/local/texlive/2012/texmf-dist/tex/xelatex/xunicode/xunicode.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/tipa/t3enc.def
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmss.fd))
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/keyval.sty)))
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! fontspec error: "font-not-found"
! 
! The font "Bitstream Vera Serif" cannot be found.
! 
! See the fontspec documentation for further information.
! 
! For immediate help type H <return>.
!............................................... 
 
<*> \setmainfont{Bitstream Vera Serif}
 
No pages of output.
Transcript written on texput.log.
======================================================================
ERROR: matplotlib.tests.test_backend_pgf.test_mixedmode
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
 result = func(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 157, in test_mixedmode
 compare_figure('pgf_mixedmode.pdf')
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 56, in compare_figure
 plt.savefig(actual)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/pyplot.py", line 561, in savefig
 return fig.savefig(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/figure.py", line 1410, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backend_bases.py", line 2220, in print_figure
 **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 864, in print_pdf
 self._print_pdf_to_fh(fh, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 822, in _print_pdf_to_fh
 self.print_pgf(fname_pgf, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 804, in print_pgf
 self._print_pgf_to_fh(fh, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 784, in _print_pgf_to_fh
 RendererPgf(self.figure, fh),
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 409, in __init__
 self.latexManager = LatexManagerFactory.get_latex_manager()
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 223, in get_latex_manager
 new_inst = LatexManager()
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 309, in __init__
 raise LatexError("LaTeX returned an error, probably missing font or 
error in preamble:\n%s" % stdout)
LatexError: LaTeX returned an error, probably missing font or error in 
preamble:
This is XeTeX, Version 3.1415926-2.4-0.9998 (TeX Live 2012)
 restricted \write18 enabled.
**entering extended mode
LaTeX2e <2011年06月27日>
Babel <v3.8m> and hyphenation patterns for english, dumylang, 
nohyphenation, ge
rman-x-2012年05月30日, ngerman-x-2012年05月30日, afrikaans, ancientgreek, 
ibycus, arabi
c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian, 
czech, danis
h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi, 
finnis
h, french, friulan, galician, german, ngerman, swissgerman, monogreek, 
greek, h
ungarian, icelandic, assamese, bengali, gujarati, hindi, kannada, 
malayalam, ma
rathi, oriya, panjabi, tamil, telugu, indonesian, interlingua, irish, 
italian, 
kurmanji, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal, 
nynorsk,
 polish, portuguese, romanian, romansh, russian, sanskrit, serbian, 
serbianc, s
lovak, slovenian, spanish, swedish, turkish, turkmen, ukrainian, 
uppersorbian, 
welsh, loaded.
*(/usr/local/texlive/2012/texmf-dist/tex/latex/base/minimal.cls
Document Class: minimal 2001年05月25日 Standard LaTeX minimal class
)
(Please type a command or say `\end')
*
*(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3names.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3bootstrap.sty))
(/usr/local/texlive/2012/texmf-dist/tex/latex/etex-pkg/etex.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/color.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/local/texlive/2012/texmf-dist/tex/xelatex/xetex-def/xetex.def))
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/graphics.cfg))
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3basics.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3expan.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3tl.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3seq.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3int.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3quark.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prg.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3clist.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3token.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prop.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3msg.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3file.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3skip.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3keys.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3fp.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3box.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3coffins.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3color.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3luatex.sty))
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3packages/xparse/xparse.st
y)
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-patches.s
ty
(/usr/local/texlive/2012/texmf-dist/tex/latex/base/fixltx2e.sty)
*************************************************
* LaTeX warning: "xparse/redefine-command"
* 
* Redefining document command \oldstylenums with arg. spec. 'm' on line 
107.
*************************************************
) 
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/base/fontenc.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1enc.def)
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmr.fd))
(/usr/local/texlive/2012/texmf-dist/tex/xelatex/xunicode/xunicode.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/tipa/t3enc.def
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmss.fd))
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/keyval.sty)))
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! fontspec error: "font-not-found"
! 
! The font "Bitstream Vera Serif" cannot be found.
! 
! See the fontspec documentation for further information.
! 
! For immediate help type H <return>.
!............................................... 
 
<*> \setmainfont{Bitstream Vera Serif}
 
No pages of output.
Transcript written on texput.log.
======================================================================
ERROR: Failure: AttributeError ('module' object has no attribute 
'test_coding_standards')
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/loader.py", line 379, in loadTestsFromName
 module = resolve_name(addr.module)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/util.py", line 331, in resolve_name
 obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_coding_standards'
----------------------------------------------------------------------
Ran 1458 tests in 833.661s
FAILED (KNOWNFAIL=2, errors=3)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/__init__.py:1141: UserWarning: This call to 
matplotlib.use() has no effect
because the the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.
 warnings.warn(_use_error_msg)
localhost$

For the free type wrapper, maybe the freetype-py may be of some help:
http://code.google.com/p/freetype-py/
I did not wrap all the freetype library but it already allows a fair amount of font manipulation/rendering.
For unicode/harfbuzz, I've found this example
https://github.com/lxnt/ex-sdl-freetype-harfbuzz
to be incredibly useful to understand the (poorly documented) library. The strong point of harfbuzz is to have no heavy dependencies (compared to pango for example). By the way, Behad is considering a refactoring of the library and it might be worth to interact with him (on the harfbuzz list) to see how this could ease a python wrapper (if you intend to use it of course).
In the current draft, you're speaking of rich text but I found no reference for a possible markup (or equivalent) to specify the different font, color, boldness, etc.
Nicolas
On May 30, 2013, at 8:27 PM, Chris Barker - NOAA Federal <chr...@no...> wrote:
> On Thu, May 30, 2013 at 8:59 AM, Michael Droettboom <md...@st...> wrote:
>> I've drafted a MEP with a plan to improve some of the text and font handling
>> in matplotlib.
>> 
>> I'd love any and all feedback.
> 
> nice writ-up and thanks for workign on this.
> 
> One idea (alternative?) would be to put more effort into the
> "mathtext" renderer. TeX itself, of course does an outstanding job of
> laying out text, paragraphs, etc. I'm assuming that the core stuff is
> already in mathtext, so adding better support for regular old non-math
> text would be a less-than-huge deal. And we still wouldn't need the
> full how-to-split-pages and all that code for MPL.
> 
> Not sure about properly handling unicode issues, though modern TeX
> does support unicode.
> 
> With a fully-function mathtex, it could be the default (only?) text
> layout system for MPL, simplifying things quite a bit.
> 
> ... just a thought.
> 
> -Chris
> 
> 
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
> 
> Chr...@no...
> 
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thu, May 30, 2013 at 8:59 AM, Michael Droettboom <md...@st...> wrote:
> I've drafted a MEP with a plan to improve some of the text and font handling
> in matplotlib.
>
> I'd love any and all feedback.
nice writ-up and thanks for workign on this.
One idea (alternative?) would be to put more effort into the
"mathtext" renderer. TeX itself, of course does an outstanding job of
laying out text, paragraphs, etc. I'm assuming that the core stuff is
already in mathtext, so adding better support for regular old non-math
text would be a less-than-huge deal. And we still wouldn't need the
full how-to-split-pages and all that code for MPL.
Not sure about properly handling unicode issues, though modern TeX
does support unicode.
With a fully-function mathtex, it could be the default (only?) text
layout system for MPL, simplifying things quite a bit.
... just a thought.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Wed, May 29, 2013 at 5:54 PM, Michael Droettboom <md...@st...> wrote:
> It looks like the ability to include pytz and other dependencies in
> binary distributions has been removed?
>
> It's really just that the matplotlib source no longer includes them.
> Binaries can be built however we want them to be. Not knowing how the .dmg
> is put together, is it possible to add pytz, dateutil, pyparsing and six to
> the dmg during its creation?
I agree -- adding them to the binary package is the way to go here --
it's packaging issue, not a development or building issue.
I can't imagine it would be hard to write a little script that
includes them all in one mpkg.
> Right -- and we're not using pip (because we can't) to handle our C/C++
> dependencies, many of which we continue to ship with matplotlib.
Should the code that's shipped with MPL be build-able with PIP? But
the harder issue is third-party dependencies that we expect the system
to provide: libpng, libfreetype, ....
On the building side, I'd really like to see more support for this --
the Linux package managers handle it OK on LInux, but there is no good
system for Windows or OS-X.
I'm taking a look at gattai:
http://sourceforge.net/projects/gattai/
Mostly for the Mac, but it does support Windows and linux as well.
I'm not looking at Windows right now, as Christoph's repository gives
me all I need -- which makes me think:
Christoph, do you have a build system for all those that might be a
good basis for a multi-platform solution?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I've drafted a MEP with a plan to improve some of the text and font 
handling in matplotlib.
I'd love any and all feedback.
https://github.com/matplotlib/matplotlib/wiki/Mep14
Mike

OK, that worked. I uploaded Windows binaries, which include all test files.
Christoph
On 5/29/2013 5:34 PM, Michael Droettboom wrote:
> Must be a problem with the upload. I'm reuploading it now. I'm not
> going to bother upping the version -- it's just the result of a failed
> transfer apparently.
>
> Mike
>
> On 05/29/2013 04:12 PM, Christoph Gohlke wrote:
>> Sorry, but that tarball does not include setup.py and other files. It is
>> only ~25 MB.
>>
>> Christoph
>>
>>
>> On 5/29/2013 12:48 PM, Michael Droettboom wrote:
>>> Ok, folks. 1.3.0rc2 is here:
>>>
>>> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc2/matplotlib-1.3.0rc2.tar.gz
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>> On 05/29/2013 03:41 PM, Michael Droettboom wrote:
>>>> On 05/29/2013 03:30 PM, Christoph Gohlke wrote:
>>>>> Removing the hardcoded paths works.
>>>>>
>>>>> I noticed two more build issues.
>>>>>
>>>>> 1) On Python 3.x I see the following errors/warnings, however the
>>>>> build succeeds.
>>>>>
>>>>> ```
>>>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\artist.py
>>>>> line 1265: ParseError: bad token: type=55, value="'", context=('',
>>>>> (1265, 38))
>>>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>>>> line 3344: TokenError: ('EOF in multi-line statement', (2, 0))
>>>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>>>> line 3345: ParseError: bad input: type=5, value=' ',
>>>>> context=('\n\n<snip>\n\n', (3345, 0))
>>>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>>>> line 3346: ParseError: bad input: type=5, value=' ',
>>>>> context=('\n\n<snip>\n\n', (3346, 0))
>>>>> Can't parse docstring in
>>>>> build\lib.win-amd64-3.2\matplotlib\backends\backend_agg.py line 322:
>>>>> TokenError: ('EOF in multi-line statement', (2, 0))
>>>>> ```
>>>> While annoying, I think these are benign --- the 2to3 tool is tripping
>>>> up on these docstrings. Overtime, the docstrings will get rewritten in
>>>> numpydoc format and we *might* see these go away.
>>>>
>>>>> 2) On Python 2.6 with distribute-0.6.45, the build fails during
>>>>> packaging. See <https://github.com/matplotlib/matplotlib/pull/2085>
>>>> Good catch. Thanks.
>>>>
>>>> Mike
>>>>> Christoph
>>>>>
>>>>>
>>>>> On 5/29/2013 12:08 PM, Michael Droettboom wrote:
>>>>>> It seems that in the setuptools way [TM] it is rather difficult to not
>>>>>> include this folder. Does it work if you only remove those hardcoded
>>>>>> paths? It should be easy for me to fix that by not having it search for
>>>>>> system libraries when building a tarball.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> On 05/29/2013 02:55 PM, Christoph Gohlke wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> minor issue: the tarball contains a lib\matplotlib.egg-info directory.
>>>>>>> The SOURCES.txt contains absolute paths (/usr/src/CXX/...) and
>>>>>>> therefore fails to build on my system. Deleting the
>>>>>>> lib\matplotlib.egg-info folder works.
>>>>>>>
>>>>>>> Does the release announcement mention that Windows binaries won't
>>>>>>> include required dependencies (pytz, dateutil, pyparsing, six) any
>>>>>>> longer?
>>>>>>>
>>>>>>> Christoph
>>>>>>>
>>>>>>>
>>>>>>> On 5/29/2013 11:41 AM, Michael Droettboom wrote:
>>>>>>>> I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
>>>>>>>>
>>>>>>>> Once the binaries from Christoph and Russell have been uploaded, I'll
>>>>>>>> make a broader announcement to get some testing of this in advance of
>>>>>>>> the final release.
>>>>>>>>
>>>>>>>> The tarball is available here:
>>>>>>>>
>>>>>>>> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc1/matplotlib-1.3.0rc1.tar.gz
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The documentation for this version is viewable here:
>>>>>>>>
>>>>>>>> http://matplotlib.org/1.3.0
>>>>>>>>
>>>>>>>> Thanks everyone for their hard work getting this out the door!
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>> ------------------------------------------------------------------------------
>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>> Get 100% visibility into your production application - at no cost.
>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>> Download for free and get started troubleshooting in minutes.
>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>> Get 100% visibility into your production application - at no cost.
>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>> Download for free and get started troubleshooting in minutes.
>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>> ------------------------------------------------------------------------------
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>

On 05/29/2013 05:19 PM, Russell E. Owen wrote:
> In article <51A...@st...>,
> Michael Droettboom <md...@st...>
> wrote:
>
>> I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
>>
>> Once the binaries from Christoph and Russell have been uploaded, I'll
>> make a broader announcement to get some testing of this in advance of
>> the final release.
>>
>> The tarball is available here:
>>
>> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3
>> .0rc1/matplotlib-1.3.0rc1.tar.gz
>>
>> The documentation for this version is viewable here:
>>
>> http://matplotlib.org/1.3.0
>>
>> Thanks everyone for their hard work getting this out the door!
> It looks like the ability to include pytz and other dependencies in
> binary distributions has been removed?
It's really just that the matplotlib source no longer includes them. 
Binaries can be built however we want them to be. Not knowing how the 
.dmg is put together, is it possible to add pytz, dateutil, pyparsing 
and six to the dmg during its creation?
>
> Is this really what we want? In the past we always included them.
> Excluding them certainly makes sense if using pip or a similar installer
> that can handle dependencies, but that is not the case for binaries.
Right -- and we're not using pip (because we can't) to handle our C/C++ 
dependencies, many of which we continue to ship with matplotlib.
>
> I guess we could serve the associated packages (pytz, dateutil and six),
> or if they can be installed by pip, ask users to install those. But
> users using binary installers may not even have pip available, so it's a
> big initial hurdle.
>
> I'd personally be happier reverting to the old system. Sorry if I missed
> a discussion on this.
>
No worries. I'm certainly guilty of not always being able to keep up 
with the firehose myself. This work was done as part of MEP11 ( 
https://github.com/matplotlib/matplotlib/wiki/MEP11) 
<https://github.com/matplotlib/matplotlib/issues/2092>, and searching 
the mailing list with "MEP11" as a key should help you find the rest of 
the discussion. It was pretty unanimous to move to not including these 
dependencies -- I certainly understand that different communities and 
platforms have different expectations, though, and if we want to find a 
way to include the dependencies in the Mac installer, I'm not opposed to 
that, but I would like to find a way to do it that only affects that one 
particular use case and not all the others (i.e. something external to 
or at least optional within the current setup infrastructure).
Mike

On 05/29/2013 05:23 PM, Russell E. Owen wrote:
> In article <51A...@st...>,
> Michael Droettboom <md...@st...>
> wrote:
>
>> I am going to hold off one more day on making the release candidate.
>> There are three blocker bugs that were discovered over the weekend and
>> I'd like to give them a chance for review first:...
> Thanks for the update.
>
> The Mac version built fine, but I saw several warnings. The only one I'm
> worried about is use of a deprecated Numpy API:
>
> In file included from src/_backend_agg.cpp:12:
> In file included from src/_backend_agg.h:43:
> In file included from src/agg_py_path_iterator.h:7:
> In file included from
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/arrayobject.h:15:
> In file included from
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/ndarrayobject.h:17:
> In file included from
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/ndarraytypes.h:1728:
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: "Using
> deprecated NumPy API, disable it by
> #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
> #warning "Using deprecated NumPy API, disable it by #defining
> NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
>
>
> These look innocuous, but easy to fix:
>
> ./CXX/Python2/Objects.hxx:1133:23: warning: implicit conversion of NULL
> constant to 'int' [-Wnull-conversion]
> , offset( NULL )
> ~ ^~~~
>
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/npy_3kcompat.h:247:40: warning: conversion
> from string literal to 'char *' is
> deprecated [-Wdeprecated-writable-strings]
> return PyObject_CallFunction(open, "Os", filename, mode);
>
>
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/core/include/numpy/npy_3kcompat.h:255:37: warning: conversion
> from string literal to 'char *' is
> deprecated [-Wdeprecated-writable-strings]
> ret = PyObject_CallMethod(file, "close", NULL);
>
These are tricky, as we want to continue to support earlier versions of 
Numpy. (Officially, we support back to 1.4, though only 1.6 and later 
is getting regular testing). Last time I looked, there wasn't a good 
way to do this without a lot of #ifdefs that would just make the 
maintenance more complicated.
However, perhaps for the next major release we should consider dropping 
Numpy < 1.5 and fixing up these deprecation warnings.
Mike

Great news! Thank you Dr. Langtangen for arranging this, and Fernando 
and the rest of the NumFOCUS board for making it happen!
Cheers,
Mike
On 05/29/2013 04:02 PM, Fernando Perez wrote:
> Hi all,
>
> I just wanted to let you all know that Hans Petter Langtangen,
> well-known author of books on scientific Python and long-time champion
> of these tools at the University of Oslo for many years, has arranged
> for a donation of 10,000ドル to support matplotlib's development.
>
> Hans Petter is the Director of the Center for Biomedical Computing at
> Simula (http://home.simula.no/~hpl), where a number of projects use
> Python as key elements of their research, the Fenics platform being
> among the most well-known (http://fenicsproject.org).
>
> We have now confirmed that these funds have been transferred to the
> NumFOCUS donations account, where Michael and the rest of the team can
> make use of them.
>
> I wanted to publicly thank Hans Petter and Simula Labs for
> persistently jumping through the necessary hoops to make this
> possible, and to Leah, Travis and Anthony at NumFOCUS for managing the
> receiving side of things.
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Must be a problem with the upload. I'm reuploading it now. I'm not 
going to bother upping the version -- it's just the result of a failed 
transfer apparently.
Mike
On 05/29/2013 04:12 PM, Christoph Gohlke wrote:
> Sorry, but that tarball does not include setup.py and other files. It is
> only ~25 MB.
>
> Christoph
>
>
> On 5/29/2013 12:48 PM, Michael Droettboom wrote:
>> Ok, folks. 1.3.0rc2 is here:
>>
>> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc2/matplotlib-1.3.0rc2.tar.gz
>>
>>
>> Mike
>>
>>
>>
>> On 05/29/2013 03:41 PM, Michael Droettboom wrote:
>>> On 05/29/2013 03:30 PM, Christoph Gohlke wrote:
>>>> Removing the hardcoded paths works.
>>>>
>>>> I noticed two more build issues.
>>>>
>>>> 1) On Python 3.x I see the following errors/warnings, however the
>>>> build succeeds.
>>>>
>>>> ```
>>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\artist.py
>>>> line 1265: ParseError: bad token: type=55, value="'", context=('',
>>>> (1265, 38))
>>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>>> line 3344: TokenError: ('EOF in multi-line statement', (2, 0))
>>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>>> line 3345: ParseError: bad input: type=5, value=' ',
>>>> context=('\n\n<snip>\n\n', (3345, 0))
>>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>>> line 3346: ParseError: bad input: type=5, value=' ',
>>>> context=('\n\n<snip>\n\n', (3346, 0))
>>>> Can't parse docstring in
>>>> build\lib.win-amd64-3.2\matplotlib\backends\backend_agg.py line 322:
>>>> TokenError: ('EOF in multi-line statement', (2, 0))
>>>> ```
>>> While annoying, I think these are benign --- the 2to3 tool is tripping
>>> up on these docstrings. Overtime, the docstrings will get rewritten in
>>> numpydoc format and we *might* see these go away.
>>>
>>>> 2) On Python 2.6 with distribute-0.6.45, the build fails during
>>>> packaging. See <https://github.com/matplotlib/matplotlib/pull/2085>
>>> Good catch. Thanks.
>>>
>>> Mike
>>>> Christoph
>>>>
>>>>
>>>> On 5/29/2013 12:08 PM, Michael Droettboom wrote:
>>>>> It seems that in the setuptools way [TM] it is rather difficult to not
>>>>> include this folder. Does it work if you only remove those hardcoded
>>>>> paths? It should be easy for me to fix that by not having it search for
>>>>> system libraries when building a tarball.
>>>>>
>>>>> Mike
>>>>>
>>>>> On 05/29/2013 02:55 PM, Christoph Gohlke wrote:
>>>>>> Hi,
>>>>>>
>>>>>> minor issue: the tarball contains a lib\matplotlib.egg-info directory.
>>>>>> The SOURCES.txt contains absolute paths (/usr/src/CXX/...) and
>>>>>> therefore fails to build on my system. Deleting the
>>>>>> lib\matplotlib.egg-info folder works.
>>>>>>
>>>>>> Does the release announcement mention that Windows binaries won't
>>>>>> include required dependencies (pytz, dateutil, pyparsing, six) any
>>>>>> longer?
>>>>>>
>>>>>> Christoph
>>>>>>
>>>>>>
>>>>>> On 5/29/2013 11:41 AM, Michael Droettboom wrote:
>>>>>>> I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
>>>>>>>
>>>>>>> Once the binaries from Christoph and Russell have been uploaded, I'll
>>>>>>> make a broader announcement to get some testing of this in advance of
>>>>>>> the final release.
>>>>>>>
>>>>>>> The tarball is available here:
>>>>>>>
>>>>>>> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc1/matplotlib-1.3.0rc1.tar.gz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The documentation for this version is viewable here:
>>>>>>>
>>>>>>> http://matplotlib.org/1.3.0
>>>>>>>
>>>>>>> Thanks everyone for their hard work getting this out the door!
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>> ------------------------------------------------------------------------------
>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>> Get 100% visibility into your production application - at no cost.
>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>> Download for free and get started troubleshooting in minutes.
>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> ------------------------------------------------------------------------------
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On May 29, 2013, at 4:01 PM, Chris Barker - NOAA Federal <chr...@no...> wrote:
> On Wed, May 29, 2013 at 2:19 PM, Russell E. Owen <ro...@uw...> wrote:
> 
>> I guess we could serve the associated packages (pytz, dateutil and six),
>> or if they can be installed by pip, ask users to install those. But
>> users using binary installers may not even have pip available, so it's a
>> big initial hurdle.
> 
> If the binary installers are available (and easy to find), not such a
> big deal -- this is teh case with Christoph's repository for Windows,
> for instance.
> 
> Russell, have you been following the thread I started on the pythonmac
> list? We really need a way to deal better with binaries on the Mac,
> including dependency handling.
> 
> Note that supposedly the "wheel" format is coming (soon?), and after
> that support for binary wheels by pip.
> 
> Of course, none of that helps right now...
I have been following that thread with great interest. If such a repository becomes available I do intend to contribute to it.
For the record:
- I prefer static libraries
- The wheel format sounds very promising. But until we have it and until pip supports it, my suspicion is that it's not worth trying to automate dependency handling, and we should live with mpkg binary installers.
In the short term I'd be happier if matplotlib continued to support including dateutils, pytz and six. It is not ideal to include dependencies, but convenient and pragmatic. Failing that, i think we should ask users to install pip and use pip to install dateutils, pytz and six. I fear it would be too much work to provide binary installers for pytz, dateutils and six because we would need to make different packages for different versions of python (which feels silly for pure python packages!), keep them up to date, find somewhere to serve them...
In the long term, I hope wheel format will allow us to use pip to install matplotlib, in which case it will handle dependencies and we need not include them.
-- Russell

On Wed, May 29, 2013 at 2:19 PM, Russell E. Owen <ro...@uw...> wrote:
> I guess we could serve the associated packages (pytz, dateutil and six),
> or if they can be installed by pip, ask users to install those. But
> users using binary installers may not even have pip available, so it's a
> big initial hurdle.
If the binary installers are available (and easy to find), not such a
big deal -- this is teh case with Christoph's repository for Windows,
for instance.
Russell, have you been following the thread I started on the pythonmac
list? We really need a way to deal better with binaries on the Mac,
including dependency handling.
Note that supposedly the "wheel" format is coming (soon?), and after
that support for binary wheels by pip.
Of course, none of that helps right now...
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

In article <51A...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> I am going to hold off one more day on making the release candidate. 
> There are three blocker bugs that were discovered over the weekend and 
> I'd like to give them a chance for review first:...
Thanks for the update.
The Mac version built fine, but I saw several warnings. The only one I'm 
worried about is use of a deprecated Numpy API:
In file included from src/_backend_agg.cpp:12:
In file included from src/_backend_agg.h:43:
In file included from src/agg_py_path_iterator.h:7:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/arrayobject.h:15:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/ndarrayobject.h:17:
In file included from 
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/ndarraytypes.h:1728:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: "Using 
deprecated NumPy API, disable it by
 #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
#warning "Using deprecated NumPy API, disable it by #defining 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
These look innocuous, but easy to fix:
./CXX/Python2/Objects.hxx:1133:23: warning: implicit conversion of NULL 
constant to 'int' [-Wnull-conversion]
 , offset( NULL )
 ~ ^~~~
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_3kcompat.h:247:40: warning: conversion 
from string literal to 'char *' is
 deprecated [-Wdeprecated-writable-strings]
 return PyObject_CallFunction(open, "Os", filename, mode);
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/core/include/numpy/npy_3kcompat.h:255:37: warning: conversion 
from string literal to 'char *' is
 deprecated [-Wdeprecated-writable-strings]
 ret = PyObject_CallMethod(file, "close", NULL);

In article <51A...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
> 
> Once the binaries from Christoph and Russell have been uploaded, I'll 
> make a broader announcement to get some testing of this in advance of 
> the final release.
> 
> The tarball is available here:
> 
> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3
> .0rc1/matplotlib-1.3.0rc1.tar.gz
> 
> The documentation for this version is viewable here:
> 
> http://matplotlib.org/1.3.0
> 
> Thanks everyone for their hard work getting this out the door!
It looks like the ability to include pytz and other dependencies in 
binary distributions has been removed?
Is this really what we want? In the past we always included them. 
Excluding them certainly makes sense if using pip or a similar installer 
that can handle dependencies, but that is not the case for binaries.
I guess we could serve the associated packages (pytz, dateutil and six), 
or if they can be installed by pip, ask users to install those. But 
users using binary installers may not even have pip available, so it's a 
big initial hurdle.
I'd personally be happier reverting to the old system. Sorry if I missed 
a discussion on this.
-- Russell

Sorry, but that tarball does not include setup.py and other files. It is 
only ~25 MB.
Christoph
On 5/29/2013 12:48 PM, Michael Droettboom wrote:
> Ok, folks. 1.3.0rc2 is here:
>
> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc2/matplotlib-1.3.0rc2.tar.gz
>
>
> Mike
>
>
>
> On 05/29/2013 03:41 PM, Michael Droettboom wrote:
>> On 05/29/2013 03:30 PM, Christoph Gohlke wrote:
>>> Removing the hardcoded paths works.
>>>
>>> I noticed two more build issues.
>>>
>>> 1) On Python 3.x I see the following errors/warnings, however the
>>> build succeeds.
>>>
>>> ```
>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\artist.py
>>> line 1265: ParseError: bad token: type=55, value="'", context=('',
>>> (1265, 38))
>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>> line 3344: TokenError: ('EOF in multi-line statement', (2, 0))
>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>> line 3345: ParseError: bad input: type=5, value=' ',
>>> context=('\n\n<snip>\n\n', (3345, 0))
>>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>>> line 3346: ParseError: bad input: type=5, value=' ',
>>> context=('\n\n<snip>\n\n', (3346, 0))
>>> Can't parse docstring in
>>> build\lib.win-amd64-3.2\matplotlib\backends\backend_agg.py line 322:
>>> TokenError: ('EOF in multi-line statement', (2, 0))
>>> ```
>> While annoying, I think these are benign --- the 2to3 tool is tripping
>> up on these docstrings. Overtime, the docstrings will get rewritten in
>> numpydoc format and we *might* see these go away.
>>
>>> 2) On Python 2.6 with distribute-0.6.45, the build fails during
>>> packaging. See <https://github.com/matplotlib/matplotlib/pull/2085>
>> Good catch. Thanks.
>>
>> Mike
>>> Christoph
>>>
>>>
>>> On 5/29/2013 12:08 PM, Michael Droettboom wrote:
>>>> It seems that in the setuptools way [TM] it is rather difficult to not
>>>> include this folder. Does it work if you only remove those hardcoded
>>>> paths? It should be easy for me to fix that by not having it search for
>>>> system libraries when building a tarball.
>>>>
>>>> Mike
>>>>
>>>> On 05/29/2013 02:55 PM, Christoph Gohlke wrote:
>>>>> Hi,
>>>>>
>>>>> minor issue: the tarball contains a lib\matplotlib.egg-info directory.
>>>>> The SOURCES.txt contains absolute paths (/usr/src/CXX/...) and
>>>>> therefore fails to build on my system. Deleting the
>>>>> lib\matplotlib.egg-info folder works.
>>>>>
>>>>> Does the release announcement mention that Windows binaries won't
>>>>> include required dependencies (pytz, dateutil, pyparsing, six) any
>>>>> longer?
>>>>>
>>>>> Christoph
>>>>>
>>>>>
>>>>> On 5/29/2013 11:41 AM, Michael Droettboom wrote:
>>>>>> I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
>>>>>>
>>>>>> Once the binaries from Christoph and Russell have been uploaded, I'll
>>>>>> make a broader announcement to get some testing of this in advance of
>>>>>> the final release.
>>>>>>
>>>>>> The tarball is available here:
>>>>>>
>>>>>> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc1/matplotlib-1.3.0rc1.tar.gz
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The documentation for this version is viewable here:
>>>>>>
>>>>>> http://matplotlib.org/1.3.0
>>>>>>
>>>>>> Thanks everyone for their hard work getting this out the door!
>>>>>>
>>>>>> Mike
>>>>>>
>>
>> ------------------------------------------------------------------------------
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi all,
I just wanted to let you all know that Hans Petter Langtangen,
well-known author of books on scientific Python and long-time champion
of these tools at the University of Oslo for many years, has arranged
for a donation of 10,000ドル to support matplotlib's development.
Hans Petter is the Director of the Center for Biomedical Computing at
Simula (http://home.simula.no/~hpl), where a number of projects use
Python as key elements of their research, the Fenics platform being
among the most well-known (http://fenicsproject.org).
We have now confirmed that these funds have been transferred to the
NumFOCUS donations account, where Michael and the rest of the team can
make use of them.
I wanted to publicly thank Hans Petter and Simula Labs for
persistently jumping through the necessary hoops to make this
possible, and to Leah, Travis and Anthony at NumFOCUS for managing the
receiving side of things.
--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

Ok, folks. 1.3.0rc2 is here:
https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc2/matplotlib-1.3.0rc2.tar.gz
Mike
On 05/29/2013 03:41 PM, Michael Droettboom wrote:
> On 05/29/2013 03:30 PM, Christoph Gohlke wrote:
>> Removing the hardcoded paths works.
>>
>> I noticed two more build issues.
>>
>> 1) On Python 3.x I see the following errors/warnings, however the
>> build succeeds.
>>
>> ```
>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\artist.py
>> line 1265: ParseError: bad token: type=55, value="'", context=('',
>> (1265, 38))
>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>> line 3344: TokenError: ('EOF in multi-line statement', (2, 0))
>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>> line 3345: ParseError: bad input: type=5, value=' ',
>> context=('\n\n<snip>\n\n', (3345, 0))
>> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py
>> line 3346: ParseError: bad input: type=5, value=' ',
>> context=('\n\n<snip>\n\n', (3346, 0))
>> Can't parse docstring in
>> build\lib.win-amd64-3.2\matplotlib\backends\backend_agg.py line 322:
>> TokenError: ('EOF in multi-line statement', (2, 0))
>> ```
> While annoying, I think these are benign --- the 2to3 tool is tripping
> up on these docstrings. Overtime, the docstrings will get rewritten in
> numpydoc format and we *might* see these go away.
>
>> 2) On Python 2.6 with distribute-0.6.45, the build fails during
>> packaging. See <https://github.com/matplotlib/matplotlib/pull/2085>
> Good catch. Thanks.
>
> Mike
>> Christoph
>>
>>
>> On 5/29/2013 12:08 PM, Michael Droettboom wrote:
>>> It seems that in the setuptools way [TM] it is rather difficult to not
>>> include this folder. Does it work if you only remove those hardcoded
>>> paths? It should be easy for me to fix that by not having it search for
>>> system libraries when building a tarball.
>>>
>>> Mike
>>>
>>> On 05/29/2013 02:55 PM, Christoph Gohlke wrote:
>>>> Hi,
>>>>
>>>> minor issue: the tarball contains a lib\matplotlib.egg-info directory.
>>>> The SOURCES.txt contains absolute paths (/usr/src/CXX/...) and
>>>> therefore fails to build on my system. Deleting the
>>>> lib\matplotlib.egg-info folder works.
>>>>
>>>> Does the release announcement mention that Windows binaries won't
>>>> include required dependencies (pytz, dateutil, pyparsing, six) any
>>>> longer?
>>>>
>>>> Christoph
>>>>
>>>>
>>>> On 5/29/2013 11:41 AM, Michael Droettboom wrote:
>>>>> I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
>>>>>
>>>>> Once the binaries from Christoph and Russell have been uploaded, I'll
>>>>> make a broader announcement to get some testing of this in advance of
>>>>> the final release.
>>>>>
>>>>> The tarball is available here:
>>>>>
>>>>> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc1/matplotlib-1.3.0rc1.tar.gz
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The documentation for this version is viewable here:
>>>>>
>>>>> http://matplotlib.org/1.3.0
>>>>>
>>>>> Thanks everyone for their hard work getting this out the door!
>>>>>
>>>>> Mike
>>>>>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 05/29/2013 03:30 PM, Christoph Gohlke wrote:
> Removing the hardcoded paths works.
>
> I noticed two more build issues.
>
> 1) On Python 3.x I see the following errors/warnings, however the 
> build succeeds.
>
> ```
> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\artist.py 
> line 1265: ParseError: bad token: type=55, value="'", context=('', 
> (1265, 38))
> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py 
> line 3344: TokenError: ('EOF in multi-line statement', (2, 0))
> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py 
> line 3345: ParseError: bad input: type=5, value=' ', 
> context=('\n\n<snip>\n\n', (3345, 0))
> Can't parse docstring in build\lib.win-amd64-3.2\matplotlib\axes.py 
> line 3346: ParseError: bad input: type=5, value=' ', 
> context=('\n\n<snip>\n\n', (3346, 0))
> Can't parse docstring in 
> build\lib.win-amd64-3.2\matplotlib\backends\backend_agg.py line 322: 
> TokenError: ('EOF in multi-line statement', (2, 0))
> ```
While annoying, I think these are benign --- the 2to3 tool is tripping 
up on these docstrings. Overtime, the docstrings will get rewritten in 
numpydoc format and we *might* see these go away.
>
> 2) On Python 2.6 with distribute-0.6.45, the build fails during 
> packaging. See <https://github.com/matplotlib/matplotlib/pull/2085>
Good catch. Thanks.
Mike
>
> Christoph
>
>
> On 5/29/2013 12:08 PM, Michael Droettboom wrote:
>> It seems that in the setuptools way [TM] it is rather difficult to not
>> include this folder. Does it work if you only remove those hardcoded
>> paths? It should be easy for me to fix that by not having it search for
>> system libraries when building a tarball.
>>
>> Mike
>>
>> On 05/29/2013 02:55 PM, Christoph Gohlke wrote:
>>> Hi,
>>>
>>> minor issue: the tarball contains a lib\matplotlib.egg-info directory.
>>> The SOURCES.txt contains absolute paths (/usr/src/CXX/...) and
>>> therefore fails to build on my system. Deleting the
>>> lib\matplotlib.egg-info folder works.
>>>
>>> Does the release announcement mention that Windows binaries won't
>>> include required dependencies (pytz, dateutil, pyparsing, six) any
>>> longer?
>>>
>>> Christoph
>>>
>>>
>>> On 5/29/2013 11:41 AM, Michael Droettboom wrote:
>>>> I'm pleased to announce the tagging of matplotlib-1.3.0rc1.
>>>>
>>>> Once the binaries from Christoph and Russell have been uploaded, I'll
>>>> make a broader announcement to get some testing of this in advance of
>>>> the final release.
>>>>
>>>> The tarball is available here:
>>>>
>>>> https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.0rc1/matplotlib-1.3.0rc1.tar.gz 
>>>>
>>>>
>>>>
>>>>
>>>> The documentation for this version is viewable here:
>>>>
>>>> http://matplotlib.org/1.3.0
>>>>
>>>> Thanks everyone for their hard work getting this out the door!
>>>>
>>>> Mike
>>>>
>>