matplotlib-users Mailing List for matplotlib (Page 127)

Hi,
I am trying to produce a set of plots using grispec. There should be an images shown in each of the axes (using imshow) except in one of the axes, where I want to show/plot some text. However, the text seems to be too long to be displayed in one line. Is there a way to print it in something like a text box? 

I created a minimal example (see below)

I can not / do not want to make a string variable with three quotation marks (docstring), because I am reading the text from a bigger ascii file.

Thanks for your help!


import matplotlib.pyplot as plt
import matplotlib.gridspec as gridspec


def main():
    """
    goal is to show justified text in one axes of matplotlib
    there are two examples I found on stackoverflow. But I am not sure how they could be applicable here
    http://stackoverflow.com/questions/5777576/is-there-a-way-of-drawing-a-caption-box-in-matplotlib
    http://stackoverflow.com/questions/4018860/text-box-in-matplotlib
    """
    plt.close('all')
    fig = plt.figure(figsize=(5, 10))
    plt.subplots_adjust(left=0.1, right=0.9, top=0.95, bottom=0.1)

    n_rows = 5
    outer_grid = gridspec.GridSpec(n_rows, 2 )# ,wspace=0.0, hspace=0.0
    
    lst_files = [ 'circle.png'
                , 'circle.png'
                , 'circle.png'
                , 'circle.png'
                , 'text'
                , 'circle.png'
                , 'circle.png'
                , 'circle.png'
                , 'circle.png']

    for cur_map_id, cur_map_file in enumerate(lst_files):
        
        cur_row = (cur_map_id % n_rows)
        if cur_map_id / n_rows == 0:
            cur_column = 0
        else:
            cur_column = 1
    
        # preparation: no axes
        ax = plt.subplot(outer_grid[cur_row, cur_column], frameon=False)
        ax.axes.get_yaxis().set_visible(False)
        ax.axes.get_xaxis().set_visible(False)
    
        # fix for the fact that the fourth entry is text and not in tmp_lst_imgs
        if cur_map_id > 4: 
            cur_map_id = cur_map_id - 1
        
        # the actual plotting
        if cur_map_file == 'text':
            lorem = 'Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.'
            ax.text(0.05, 0.9, lorem, size=6)
        else:
            print cur_map_id
            im = plt.imread(cur_map_file)
            ax.imshow(im)
        ax.set_title(cur_map_file, size=6)
        fig.add_subplot(ax)
        
    plt.savefig('blah.png', dpi=300)
    print "done!"
    
if __name__ == '__main__':
    main() 

Hi,

I wrote a short routine to look through a set of images that result from
slightly different processing of the same data.  I want to compare three
different images and be able to zoom them all in the same way and then
move onto the next set of three.  The best way that I've found to do
that so far involves using mpl_toolkits.axes_grid1.ImageGrid.  It all
works fine.  I found that to get the most image on screen at once, using
the tight_layout=True argument to plt.figure gives excellent results.
My one question is that I get the following warning:

WARNING: This figure includes Axes that are not compatible with
tight_layout, so its results might be incorrect. [matplotlib.figure]

As I say, the results are good, so it's not really a problem, but I do
wonder about the source of the warngin -- and whether re-using the code
in a different way in the future could lead to problems.  So, my
question is: what is the problem pointed to by the warning and how could
I avoid it (while still getting the same good results)?

Regards,
Jon
-- 
______________________________________________________________
Jonathan D. Slavin              Harvard-Smithsonian CfA
js...@cf...         60 Garden Street, MS 83
phone: (617) 496-7981           Cambridge, MA 02138-1516
 cell: (781) 363-0035           USA
______________________________________________________________

Hi all,

I discovered recently that basmap does not draw the coastline contours
properly for some choice of map boundaries. Specifically,

from mpl_toolkits.basemap import Basemap
map =
Basemap(projection='cyl',llcrnrlat=-22.,urcrnrlat=22.,llcrnrlon=78.,urcrnrlon=168.,resolution='l')
map.drawcoastlines()

results in the coastline of continental Asia not being drawn (see
attachment bad_contours.png). On the other hand, even subtly changing
the latitude boundaries, to

map =
Basemap(projection='cyl',llcrnrlat=-22.001,urcrnrlat=22.001,llcrnrlon=78.,urcrnrlon=168.,resolution='l')

results in all the coastlines being drawn (see attachment
good_contours.png). I presume this is a bug?

Here is my system info:

Operating system: Linux 3.2.0-41-generic #66-Ubuntu SMP Thu Apr 25
03:27:11 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Matplotlib version: 1.1.0

Where I obtained matplotlib: SourceForge

Customizations to matplotlibrc: none

Thanks,

Sourish

I want to increase the default setting of saved matplotlib graphs, so I
created a file ~/.matplotlib/matplotlibrc containing the line

savefigdpi : 300

I then created a test notebook containing a single cell with the contents

import numpy as np
import matplotlib.pyplot as plt
x = np.array([1,2,3])
y = np.array([4,5,6])
plt.plot(x,y)
plt.savefig('d0.png')
plt.savefig('d300.png',dpi=300)


When I run this within the notebook, the two png files are created fine,
but have different sizes. When I run the same code from the command line
(after saving the same commands to a script file testplot.py), using

ipython testplot.py

the two graphs have the same size, as desired. Does matplotlib ignore the
contents of ~/.matplotlib/matplotlibrc when called from an Ipython
notebook?

By the way, this is using matplotlib 1.2.0 and Ipython 0.13.2, if it makes
any difference.

Thanks for any help.

Richard Stanton

The default backend is macosx but using it leads to the error I mentioned:

Traceback (most recent call last):
   File "./fftest.py", line 24, in <module>
     ani.save('animation.avi')
   File "/Library/Python/2.6/site-packages/matplotlib/animation.py",  
line 615, in save
     writer.grab_frame()
   File "/Library/Python/2.6/site-packages/matplotlib/animation.py",  
line 199, in grab_frame
     dpi=self.dpi)
   File "/Library/Python/2.6/site-packages/matplotlib/figure.py", line  
1370, in savefig
     self.canvas.print_figure(*args, **kwargs)
   File  
"/Library/Python/2.6/site-packages/matplotlib/backend_bases.py", line  
2015, in print_figure
     print_method = self._get_print_method(format)
   File  
"/Library/Python/2.6/site-packages/matplotlib/backend_bases.py", line  
1956, in _get_print_method
     '%s.' % (format, ', '.join(formats)))
ValueError: Format "rgba" is not supported.
Supported formats: bmp, emf, eps, gif, jpeg, jpg, pdf, pgf, png, ps,  
raw, rgba, svg, svgz, tif, tiff.

The above error does not occur if I switch to agg.

Also using the ffmpeg command

ffmpeg -f image2 -i t%d.jpg video.avi

on a few images gives the following output, where I put !! next to the  
lines which are suppressed by including -loglevel quiet

FFmpeg version SVN-r26402, Copyright (c) 2000-2011 the FFmpeg developers
   built on May  2 2013 23:13:41 with llvm_gcc 4.2.1 (Based on Apple  
Inc. build 5658) (LLVM build 2336.9.00)
   configuration: --enable-libmp3lame --enable-shared --disable-mmx  
--arch=x86_64
   libavutil     50.36. 0 / 50.36. 0
   libavcore      0.16. 1 /  0.16. 1
   libavcodec    52.108. 0 / 52.108. 0
   libavformat   52.93. 0 / 52.93. 0
   libavdevice   52. 2. 3 / 52. 2. 3
   libavfilter    1.74. 0 /  1.74. 0
   libswscale     0.12. 0 /  0.12. 0
Input #0, image2, from 't%d.jpg':
   Duration: 00:00:00.12, start: 0.000000, bitrate: N/A
     Stream #0.0: Video: mjpeg, yuvj422p, 4272x2848, 25 tbr, 25 tbn, 25 tbc
File 'video.avi' already exists. Overwrite ? [y/N] y
!![buffer @ 0x7fff094014b0] w:4272 h:2848 pixfmt:yuvj422p
!![ffsink @ 0x7fff094016d0] auto-inserting filter 'auto-inserted  
scaler 0' between the filter 'src' and the filter 'out'
!![scale @ 0x7fff094018f0] w:4272 h:2848 fmt:yuvj422p -> w:4272 h:2848  
fmt:yuv420p flags:0x4
!!Output #0, avi, to 'video.avi':
!!  Metadata:
!!    ISFT            : Lavf52.93.0
!!    Stream #0.0: Video: mpeg4, yuv420p, 4272x2848, q=2-31, 200 kb/s,  
25 tbn, 25 tbc
Stream mapping:
   Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=    3 fps=  2 q=4.0 Lsize=     524kB time=0.12 bitrate=35781.7kbits/s
video:519kB audio:0kB global headers:0kB muxing overhead 1.083673%

Quoting Tony Yu <ts...@gm...>:

> On Mon, May 6, 2013 at 7:09 AM, Colin McAuliffe <cj...@co...>wrote:
>
>> Hi Tony, thanks for the reply.
>>
>> I was using 1.2.0 and just upgraded to 1.2.1 but the problem persists. I
>> ran the example code from the link and it hangs after 350-400 frames. Also,
>> I got an error when running the code as it is posted and had to add:
>>
>> import matplotlib
>> matplotlib.use("Agg")
>>
>> to get it to work. Is this an incorrect setting I'm using?
>>
>> Colin
>
>
> Hmm, that's strange: Your problem sounds too similar to be a different bug.
> Could you copy the error message you got? It might be a clue. Also, what
> backend are you running?
>
>>>> import matplotlib.pyplot as plt
>>>> print plt.rcParams['backend']
>
> Another possibility (longshot) is that your version of `ffmpeg` may not
> respect the `-loglevel quiet` flag being passed to suppress output. Maybe
> you could try running an `ffmpeg` command with and without that flag to see
> if it works.
>
> -Tony
>



-- 
Colin McAuliffe
PhD Candidate
Columbia University
Department of Civil Engineering and Engineering Mechanics

On Mon, May 6, 2013 at 6:27 PM, Michael Droettboom <md...@st...> wrote:
> Well, we could try a different approach.  matplotlib will use pkg-config to
> find its dependencies, if available.
>
> If you can get your local libpng to include a libpng.pc (i.e. a pkg-config
> information file) and then add your local pkg-config path (probably
> /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/pkgconfig)
> to the PKG_CONFIG_PATH environment variable, it should pick up the right
> name for the library as well.

It works!! Thanks a lot. Here I found the same answer as well:

http://stackoverflow.com/questions/16227285/unable-to-import-matplotlib-png-pylab

>  If you get that working, you may be able to
> avoid setting CFLAGS and LDFLAGS explicitly and the Makefile modifications.

Indeed. I definitely don't need Python Makefile modifications and here
is my polished install script now:

export PKG_CONFIG_PATH="$PNG/lib/pkgconfig:$FREETYPE/lib/pkgconfig"
export LDFLAGS="-L$PNG/lib -Wl,-rpath=$PNG/lib"
$PYTHON/bin/python setup.py install

As you can see, I still need to setup the rpath, but that is to be expected.

For the record, here is how _png.o and _png.so end up compiled and linked:

gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall
-I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include
-I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
-I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
-fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1
-I/usr/local/include -I/usr/include
-I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include/libpng16
-I/usr/local/include -I/usr/include -I.
-I/home/ondrej/repos/python-hpcmp2/opt/numpy/hpbc/lib/python2.7/site-packages/numpy/core/include
-I. -I/home/ondrej/repos/python-hpcmp2/opt/python/llzf/include/python2.7
-c src/_png.cpp -o build/temp.linux-x86_64-2.7/src/_png.o



g++ -pthread -shared -L/usr/lib/x86_64-linux-gnu
-L/lib/x86_64-linux-gnu
-L/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/lib
-L/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-Wl,-rpath=/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-I/home/ondrej/repos/python-hpcmp2/opt/png/qhle/include
-I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
-I/home/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
build/temp.linux-x86_64-2.7/src/_png.o
build/temp.linux-x86_64-2.7/src/mplutils.o
build/temp.linux-x86_64-2.7/CXX/cxx_extensions.o
build/temp.linux-x86_64-2.7/CXX/IndirectPythonInterface.o
build/temp.linux-x86_64-2.7/CXX/cxxsupport.o
build/temp.linux-x86_64-2.7/CXX/cxxextensions.o
-L/home/ondrej/repos/python-hpcmp2/opt/png/qhle/lib -L/usr/local/lib
-L/usr/lib -lpng16 -lz -lstdc++ -lm -o
build/lib.linux-x86_64-2.7/matplotlib/_png.so


I think that this looks good. If I need to ever remove the
-L/usr/lib/x86_64-linux-gnu parts, then I just fix the Python package.

Ondrej

On Mon, May 6, 2013 at 7:09 AM, Colin McAuliffe <cj...@co...>wrote:

> Hi Tony, thanks for the reply.
>
> I was using 1.2.0 and just upgraded to 1.2.1 but the problem persists. I
> ran the example code from the link and it hangs after 350-400 frames. Also,
> I got an error when running the code as it is posted and had to add:
>
> import matplotlib
> matplotlib.use("Agg")
>
> to get it to work. Is this an incorrect setting I'm using?
>
> Colin


Hmm, that's strange: Your problem sounds too similar to be a different bug.
Could you copy the error message you got? It might be a clue. Also, what
backend are you running?

>>> import matplotlib.pyplot as plt
>>> print plt.rcParams['backend']

Another possibility (longshot) is that your version of `ffmpeg` may not
respect the `-loglevel quiet` flag being passed to suppress output. Maybe
you could try running an `ffmpeg` command with and without that flag to see
if it works.

-Tony

Well, we could try a different approach.  matplotlib will use pkg-config 
to find its dependencies, if available.

If you can get your local libpng to include a libpng.pc (i.e. a 
pkg-config information file) and then add your local pkg-config path 
(probably
/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/pkgconfig) 
to the PKG_CONFIG_PATH environment variable, it should pick up the right 
name for the library as well.  If you get that working, you may be able 
to avoid setting CFLAGS and LDFLAGS explicitly and the Makefile 
modifications.

Mike



On 05/06/2013 06:53 PM, Ondřej Čertík wrote:
> On Mon, May 6, 2013 at 3:53 PM, Michael Droettboom <md...@st...> wrote:
>> My understanding is that distutils builds up the commandline arguments for
>> gcc in this order:
>>
>>    1) From Python's Makefile.
>>    2) From environment variables
>>    3) From whatever was added by the setup.py script
>>
>> It looks like you have some extra stuff in (1), namely
>>
>> -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
>>
>> You can find the Python Makefile that is being used to source this
>> information here:
>>
>>>>> from distutils import sysconfig
>>>>> sysconfig.get_makefile_filename()
> This gives:
>
> In [1]: from distutils import sysconfig
>
> In [2]: sysconfig.get_makefile_filename()
> Out[2]: '/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/python2.7/config/Makefile'
>
>
>
>> You can edit that file, though obviously that's a bit of a hack.
> It contains the lines:
>
> CPPFLAGS=   -I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
> LDFLAGS=    -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
>
>
> So indeed this is causing it. I think this comes from building our own
> Python, which I do with:
>
> ----------------------
>
> #!/bin/bash
>
> set -e
>
> export arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH)
> export LDFLAGS="-L/usr/lib/$arch -L/lib/$arch"
> export CFLAGS="-I/usr/include/$arch"
> export CPPFLAGS="-I/usr/include/$arch"
> # Fix for #21:
> export HAS_HG="no"
> ./configure --prefix=${PYTHONHPC_PREFIX}
>
> ---------------------------
>
> And this is a bit of a hack too, Ubuntu specific etc. I think I should
> start fixing things here.
>
> It just wouldn't occur to me, that remains of how I built Python would
> bite me later when building
> matplotlib.
>
> So to test if modifying the Python makefile fixes it, I did:
>
> --- Makefile.old    2013-05-06 16:26:25.426440205 -0600
> +++ Makefile    2013-05-06 16:27:05.282439550 -0600
> @@ -73,8 +73,8 @@
>   # Both CPPFLAGS and LDFLAGS need to contain the shell's value for setup.py to
>   # be able to build extension modules using the directories specified in the
>   # environment variables
> -CPPFLAGS=    -I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
> -LDFLAGS=    -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
> +CPPFLAGS=    -I. -IInclude -I$(srcdir)/Include
> +LDFLAGS=
>   LDLAST=
>   SGI_ABI=
>   CCSHARED=    -fPIC
>
> but mpl build system still shows the system one. The _png.so is built with:
>
> [matplotlib] g++ -pthread -shared
> -L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/lib
> -L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
> -Wl,-rpath=/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
> -I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/include
> -I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
> -I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
> build/temp.linux-x86_64-2.7/src/_png.o
> build/temp.linux-x86_64-2.7/src/mplutils.o
> build/temp.linux-x86_64-2.7/CXX/IndirectPythonInterface.o
> build/temp.linux-x86_64-2.7/CXX/cxxsupport.o
> build/temp.linux-x86_64-2.7/CXX/cxx_extensions.o
> build/temp.linux-x86_64-2.7/CXX/cxxextensions.o -L/usr/local/lib
> -L/usr/lib -lpng12 -lz -lstdc++ -lm -o
> build/lib.linux-x86_64-2.7/matplotlib/_png.so
>
> Which in my opinion looks good -- my own version of PNG is offered
> first on the gcc command line. But the -lpng12 part spoils it --- that
> forces gcc to use the systemone, because my own version is newer.
>
>
> So I think that part of the problem gets fixed by modifying the Python
> Makefile, but the other part of the problem is how to force distutils
> to look for my PNG version before the systemwide. Any ideas?
>
> Maybe it is something that is added by the mpl setup.py script.
>
>> I've run into this problem before, and there doesn't seem to be any good way
>> around it -- i.e. there doesn't seem to be a way to insert local environment
>> variables in front of the global Python configuration.  Reason number #47
>> why distutils is a poor build system for C/C++ code.
> This is amazingly broken.
>
> Ondrej

On Mon, May 6, 2013 at 3:53 PM, Michael Droettboom <md...@st...> wrote:
> My understanding is that distutils builds up the commandline arguments for
> gcc in this order:
>
>   1) From Python's Makefile.
>   2) From environment variables
>   3) From whatever was added by the setup.py script
>
> It looks like you have some extra stuff in (1), namely
>
> -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
>
> You can find the Python Makefile that is being used to source this
> information here:
>
>>>> from distutils import sysconfig
>>>> sysconfig.get_makefile_filename()

This gives:

In [1]: from distutils import sysconfig

In [2]: sysconfig.get_makefile_filename()
Out[2]: '/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/profile/eoul/lib/python2.7/config/Makefile'



>
> You can edit that file, though obviously that's a bit of a hack.

It contains the lines:

CPPFLAGS=   -I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
LDFLAGS=    -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu


So indeed this is causing it. I think this comes from building our own
Python, which I do with:

----------------------

#!/bin/bash

set -e

export arch=$(dpkg-architecture -qDEB_HOST_MULTIARCH)
export LDFLAGS="-L/usr/lib/$arch -L/lib/$arch"
export CFLAGS="-I/usr/include/$arch"
export CPPFLAGS="-I/usr/include/$arch"
# Fix for #21:
export HAS_HG="no"
./configure --prefix=${PYTHONHPC_PREFIX}

---------------------------

And this is a bit of a hack too, Ubuntu specific etc. I think I should
start fixing things here.

It just wouldn't occur to me, that remains of how I built Python would
bite me later when building
matplotlib.

So to test if modifying the Python makefile fixes it, I did:

--- Makefile.old    2013-05-06 16:26:25.426440205 -0600
+++ Makefile    2013-05-06 16:27:05.282439550 -0600
@@ -73,8 +73,8 @@
 # Both CPPFLAGS and LDFLAGS need to contain the shell's value for setup.py to
 # be able to build extension modules using the directories specified in the
 # environment variables
-CPPFLAGS=    -I. -IInclude -I$(srcdir)/Include -I/usr/include/x86_64-linux-gnu
-LDFLAGS=    -L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu
+CPPFLAGS=    -I. -IInclude -I$(srcdir)/Include
+LDFLAGS=
 LDLAST=
 SGI_ABI=
 CCSHARED=    -fPIC

but mpl build system still shows the system one. The _png.so is built with:

[matplotlib] g++ -pthread -shared
-L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/lib
-L/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-Wl,-rpath=/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/include
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include
-I/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/freetype/lfqj/include/freetype2
build/temp.linux-x86_64-2.7/src/_png.o
build/temp.linux-x86_64-2.7/src/mplutils.o
build/temp.linux-x86_64-2.7/CXX/IndirectPythonInterface.o
build/temp.linux-x86_64-2.7/CXX/cxxsupport.o
build/temp.linux-x86_64-2.7/CXX/cxx_extensions.o
build/temp.linux-x86_64-2.7/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/lib -lpng12 -lz -lstdc++ -lm -o
build/lib.linux-x86_64-2.7/matplotlib/_png.so

Which in my opinion looks good -- my own version of PNG is offered
first on the gcc command line. But the -lpng12 part spoils it --- that
forces gcc to use the systemone, because my own version is newer.


So I think that part of the problem gets fixed by modifying the Python
Makefile, but the other part of the problem is how to force distutils
to look for my PNG version before the systemwide. Any ideas?

Maybe it is something that is added by the mpl setup.py script.

>
> I've run into this problem before, and there doesn't seem to be any good way
> around it -- i.e. there doesn't seem to be a way to insert local environment
> variables in front of the global Python configuration.  Reason number #47
> why distutils is a poor build system for C/C++ code.

This is amazingly broken.

Ondrej

My understanding is that distutils builds up the commandline arguments 
for gcc in this order:

   1) From Python's Makefile.
   2) From environment variables
   3) From whatever was added by the setup.py script

It looks like you have some extra stuff in (1), namely

-L/usr/lib/x86_64-linux-gnu -L/lib/x86_64-linux-gnu

You can find the Python Makefile that is being used to source this 
information here:

 >>> from distutils import sysconfig
 >>> sysconfig.get_makefile_filename()

You can edit that file, though obviously that's a bit of a hack.

I've run into this problem before, and there doesn't seem to be any good 
way around it -- i.e. there doesn't seem to be a way to insert local 
environment variables in front of the global Python configuration.  
Reason number #47 why distutils is a poor build system for C/C++ code.

Mike


On 05/06/2013 05:03 PM, Ondřej Čertík wrote:
> On Mon, May 6, 2013 at 7:18 AM, Michael Droettboom <md...@st...> wrote:
>> On 05/03/2013 02:41 PM, Ondřej Čertík wrote:
>>> Hi,
>>>
>>> As part of building matplotlib for the one python based distribution [1],
>>> I want to always link against our own version of libpng, even if there
>>> is some other systemwide version available. I am on linux (Ubuntu).
>>>
>>> Currently, here is what I am doing:
>>>
>>> CFLAGS="-I$PNG/include -I$FREETYPE/include
>>> -I$FREETYPE/include/freetype2" LDFLAGS="-L$FREETYPE/lib -L$PNG/lib
>>> -Wl,-rpath=$PNG/lib" $PYTHON/bin/python setup.py build
>>> $PYTHON/bin/python setup.py install
>> This *should* work. Can you provide a full build log of a clean build?
> Sure:
>
> https://gist.github.com/certik/5528134
>
> The build was produced by the "build.sh" script, also in the gist.
>
> On the line 48 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L48)
> you can see where our own PNG lib is:
>
> [matplotlib] lrwxrwxrwx 1 ondrej cnls 11 May  3 11:48
> /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng.so
> -> libpng16.so
> [matplotlib] lrwxrwxrwx 1 ondrej cnls 18 May  3 11:48
> /auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng16.so
> -> libpng16.so.16.2.0
>
> as printed by the line 5 in build.sh:
>
> echo "Our PNG library:"
> ls -l $PNG/lib/libpng*.so
>
>
> The actual mpl build starts at the line 52
> (https://gist.github.com/certik/5528134#file-mpl_log-txt-L52). As you
> can see, it found the systemwide PNG lib:
>
> [matplotlib] OPTIONAL BACKEND DEPENDENCIES
> [matplotlib]                 libpng: 1.2.46
>
> and just to verify this, at the line 2636
> (https://gist.github.com/certik/5528134#file-mpl_log-txt-L2636) I
> print:
>
> echo "The linked PNG library:"
> ldd $PYTHON/lib/python2.7/site-packages/matplotlib/_png.so
>
> which gives:
>
> [matplotlib] The linked PNG library:
> [matplotlib] linux-vdso.so.1 => (0x00007fffd8bc1000)
> [matplotlib] libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
> (0x00007f1fd0c0a000)
> [matplotlib] libstdc++.so.6 =>
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1fd090a000)
> [matplotlib] libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x00007f1fd06f3000)
> [matplotlib] libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f1fd04d6000)
> [matplotlib] libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1fd0117000)
> [matplotlib] libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1fcfeff000)
> [matplotlib] libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1fcfc03000)
> [matplotlib] /lib64/ld-linux-x86-64.so.2 (0x00007f1fd107e000)
>
> So the systemwide png /lib/x86_64-linux-gnu/libpng12.so.0 is linked instead:
>
> ondrej@kittiwake:~$ ls -l /lib/x86_64-linux-gnu/libpng12.so.0
> lrwxrwxrwx 1 root root 18 Apr  5  2012
> /lib/x86_64-linux-gnu/libpng12.so.0 -> libpng12.so.0.46.0
>
> as you can see, it is exactly the one as advertised by the mpl build
> info above. So the mpl build seems consistent,
> and the bug is that it finds the systemwide version before our own version.
>
> Ondrej

On Mon, May 6, 2013 at 7:18 AM, Michael Droettboom <md...@st...> wrote:
> On 05/03/2013 02:41 PM, Ondřej Čertík wrote:
>> Hi,
>>
>> As part of building matplotlib for the one python based distribution [1],
>> I want to always link against our own version of libpng, even if there
>> is some other systemwide version available. I am on linux (Ubuntu).
>>
>> Currently, here is what I am doing:
>>
>> CFLAGS="-I$PNG/include -I$FREETYPE/include
>> -I$FREETYPE/include/freetype2" LDFLAGS="-L$FREETYPE/lib -L$PNG/lib
>> -Wl,-rpath=$PNG/lib" $PYTHON/bin/python setup.py build
>> $PYTHON/bin/python setup.py install
> This *should* work. Can you provide a full build log of a clean build?

Sure:

https://gist.github.com/certik/5528134

The build was produced by the "build.sh" script, also in the gist.

On the line 48 (https://gist.github.com/certik/5528134#file-mpl_log-txt-L48)
you can see where our own PNG lib is:

[matplotlib] lrwxrwxrwx 1 ondrej cnls 11 May  3 11:48
/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng.so
-> libpng16.so
[matplotlib] lrwxrwxrwx 1 ondrej cnls 18 May  3 11:48
/auto/nest/nest/u/ondrej/repos/python-hpcmp2/opt/png/qhle/lib/libpng16.so
-> libpng16.so.16.2.0

as printed by the line 5 in build.sh:

echo "Our PNG library:"
ls -l $PNG/lib/libpng*.so


The actual mpl build starts at the line 52
(https://gist.github.com/certik/5528134#file-mpl_log-txt-L52). As you
can see, it found the systemwide PNG lib:

[matplotlib] OPTIONAL BACKEND DEPENDENCIES
[matplotlib]                 libpng: 1.2.46

and just to verify this, at the line 2636
(https://gist.github.com/certik/5528134#file-mpl_log-txt-L2636) I
print:

echo "The linked PNG library:"
ldd $PYTHON/lib/python2.7/site-packages/matplotlib/_png.so

which gives:

[matplotlib] The linked PNG library:
[matplotlib] linux-vdso.so.1 => (0x00007fffd8bc1000)
[matplotlib] libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
(0x00007f1fd0c0a000)
[matplotlib] libstdc++.so.6 =>
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1fd090a000)
[matplotlib] libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f1fd06f3000)
[matplotlib] libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f1fd04d6000)
[matplotlib] libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1fd0117000)
[matplotlib] libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1fcfeff000)
[matplotlib] libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1fcfc03000)
[matplotlib] /lib64/ld-linux-x86-64.so.2 (0x00007f1fd107e000)

So the systemwide png /lib/x86_64-linux-gnu/libpng12.so.0 is linked instead:

ondrej@kittiwake:~$ ls -l /lib/x86_64-linux-gnu/libpng12.so.0
lrwxrwxrwx 1 root root 18 Apr  5  2012
/lib/x86_64-linux-gnu/libpng12.so.0 -> libpng12.so.0.46.0

as you can see, it is exactly the one as advertised by the mpl build
info above. So the mpl build seems consistent,
and the bug is that it finds the systemwide version before our own version.

Ondrej

On 05/03/2013 02:41 PM, Ondřej Čertík wrote:
> Hi,
>
> As part of building matplotlib for the one python based distribution [1],
> I want to always link against our own version of libpng, even if there
> is some other systemwide version available. I am on linux (Ubuntu).
>
> Currently, here is what I am doing:
>
> CFLAGS="-I$PNG/include -I$FREETYPE/include
> -I$FREETYPE/include/freetype2" LDFLAGS="-L$FREETYPE/lib -L$PNG/lib
> -Wl,-rpath=$PNG/lib" $PYTHON/bin/python setup.py build
> $PYTHON/bin/python setup.py install
This *should* work. Can you provide a full build log of a clean build?

Mike

 Dear Python users,

I am having difficulty with numerically scaling to match line coordinates vs grid cell size coordinates. I want to calculate the following function: F =  distance_of_crossed_line x intersected_cell_value
The problem here is that when I calculate crossed_line_length in line coordinates that will unmatch vs grid coordinate, which is also another x,y with step e.g., dx=dy=2.5 each grid size. I want to do numerical calculation , say, F(distance, intersected_grid_value) function where, intersected_grid_value - values in intersected grid, distance - intersected_line_length (given below or can be found  http://stackoverflow.com/questions/16377826/distance-for-each-intersected-points-of-a-line-in-increased-order-in-2d-coordina )

import numpy as np
import scipy as sp

def distance_of_crossed_line(x0, x1, y0, y1):
       # slope
       m = (y1 - y0) / (x1 - x0)
       # Boundary of the selected points
       x_ceil = np.ceil(min(x0, x1))
       x_floor = np.floor(max(x0, x1))
       y_ceil = np.ceil(min(y0, y1))
       y_floor = np.floor(max(y0, y1))
       # calculate all intersected x coordinate
       x = np.arange(x_ceil, x_floor + 1)
       y = m * (x - x0) + y0
       ax = zip(x, y)
       # calculate all intersected y coordinate
       y = np.arange(y_ceil, y_floor + 1)
       x = (y - y0) / m + x0
       ax.extend(zip(x, y))
       ax.append((x0, y0))
       ax.append((x1, y1))
       ax.sort()

       # Transpose
       ax = np.array(ax).T
       # Calculate difference of intersections in X
       dist_x = np.diff(ax[0])
       # Calculate difference of intersections in Y
       dist_y = np.diff(ax[1])
       return np.sqrt(dist_x**2 + dist_y**2)

# PLEASE, note that line points are different from 2D array axis. they should be matched with each other. 
# 2D array.
d_array = np.array[[4.5, 4.5, 4.5, 3.4, 2.5],[ 3.9, 4.5, 5.2, 4.5, 3.4],[3.9, 3.9, 2.5, 2.2, 1.9]]

# Two sample points as a line
x = np.array([ -80, -40 ])
y = np.array([ 60, 55 ])

# The problem: 
F = intersected_line_length * array_grid_values_where_line_crossed_area
* It is not necessary for me to overlay lines onto grid cells properly, JUST, I need to calculate numerically accurate F function Thanks for the answer and guidance in advance,

-- 
Bakhtiyor Zokhidov

Hi Tony, thanks for the reply.

I was using 1.2.0 and just upgraded to 1.2.1 but the problem persists.  
I ran the example code from the link and it hangs after 350-400  
frames. Also, I got an error when running the code as it is posted and  
had to add:

import matplotlib
matplotlib.use("Agg")

to get it to work. Is this an incorrect setting I'm using?

Colin

Quoting Tony Yu <ts...@gm...>:

> On Sun, May 5, 2013 at 7:12 PM, Colin McAuliffe <cj...@co...>wrote:
>
>> Hello all,
>>
>> I'm having an issue with FuncAnimation with ffmpeg. For a small number
>> of frames everything works fine, but for some reason with more than
>> 600 frames the program hangs indefinitely. Is there some kind of frame
>> limit for FuncAmimation or is there a mistake in the arguements I am
>> passing?
>>
>
> Hi Colin,
>
> Which version of Matplotlib are you running? This sounds similar to a bug
> addressed by the following change:
>
> https://github.com/matplotlib/matplotlib/pull/989
>
> This change has already made it into the current release (v1.2).
>
> Best,
> -Tony
>



-- 
Colin McAuliffe
PhD Candidate
Columbia University
Department of Civil Engineering and Engineering Mechanics

On Sun, May 5, 2013 at 7:12 PM, Colin McAuliffe <cj...@co...>wrote:

> Hello all,
>
> I'm having an issue with FuncAnimation with ffmpeg. For a small number
> of frames everything works fine, but for some reason with more than
> 600 frames the program hangs indefinitely. Is there some kind of frame
> limit for FuncAmimation or is there a mistake in the arguements I am
> passing?
>

Hi Colin,

Which version of Matplotlib are you running? This sounds similar to a bug
addressed by the following change:

https://github.com/matplotlib/matplotlib/pull/989

This change has already made it into the current release (v1.2).

Best,
-Tony

Hello all,

I'm having an issue with FuncAnimation with ffmpeg. For a small number  
of frames everything works fine, but for some reason with more than  
600 frames the program hangs indefinitely. Is there some kind of frame  
limit for FuncAmimation or is there a mistake in the arguements I am  
passing?

ani = ani.FuncAnimation(fig, animate,np.range(1,700),  
interval=25,blit=True, init_func=init)

Thanks and all the best
Colin



-- 
Colin McAuliffe
PhD Candidate
Columbia University
Department of Civil Engineering and Engineering Mechanics

On Fri, May 3, 2013 at 12:41 PM, Ondřej Čertík <ond...@gm...> wrote:
> Hi,
>
> As part of building matplotlib for the one python based distribution [1],

I meant to say "for one python distribution", not "the one"...

Ondrej

Hi,

As part of building matplotlib for the one python based distribution [1],
I want to always link against our own version of libpng, even if there
is some other systemwide version available. I am on linux (Ubuntu).

Currently, here is what I am doing:

CFLAGS="-I$PNG/include -I$FREETYPE/include
-I$FREETYPE/include/freetype2" LDFLAGS="-L$FREETYPE/lib -L$PNG/lib
-Wl,-rpath=$PNG/lib" $PYTHON/bin/python setup.py build
$PYTHON/bin/python setup.py install

Where $PNG and $FREETYPE points to our own versions. On a computer
with no systemwide version of png, this works great. Question:

1) If I don't specify the -rpath option, then libpng.so will fail to
be found at runtime. Is there any other recommended way to go around
this? I don't want to use LD_LIBRARY_PATH.

On a computer with systemwide version available, unfortunately the
systemwide version gets picked up instead. I think it's because of
this:

pkg-config --libs --cflags libpng
-I/usr/include/libpng12  -lpng12

so matplotlib simply calls this (right?) and uses the systemwide
version. Question:

2) How do I force matplotlib to use my own version instead?


I would highly appreciate any input, especially on 2). We have our own
issue open for this at [2] if you are interested for the background.
The merged mpl PR [3] is a little related, but doesn't answer my
questions.

Thanks,
Ondrej


[1] https://github.com/hashdist/python-hpcmp2/

[2] https://github.com/hashdist/python-hpcmp2/issues/53

[3] https://github.com/matplotlib/matplotlib/pull/1884

H, I'm using sfmath, too. I actually wrote a helper function to switch fonts. The preambles are the result of long-term trial and error. Normally, my preambles include some more custom commands which I left out here because they would be distracting. I always wondered why matplotlib doesn't do this kind of font switching out of the box.

def setfont(font=font_default,unicode=True):
    r"""
    Set Matplotlibs rcParams to use LaTeX for font rendering.
    Revert all changes by calling rcdefault() from matplotlib.
    
    Parameters:
    -----------
    font: string
        "Helvetica"
        "Times"
        "Computer Modern"
    
    usetex: Boolean
        Use unicode. Default: False.    
    """
    
    # Use TeX for all figure text!
    plt.rc('text', usetex=True)

    font = font.lower().replace(" ","")
    if font == 'times':
        # Times
        font = {'family':'serif', 'serif':['Times']}
        preamble  = r"""
                       \usepackage{color}
                       \usepackage{mathptmx}
                    """
    elif font == 'helvetica':
        # Helvetica
        # set serif, too. Otherwise setting to times and then
        # Helvetica causes an error.
        font = {'family':'sans-serif','sans-serif':['Helvetica'],
                'serif':['cm10']}
        preamble  = r"""
                       \usepackage{color}
                       \usepackage[tx]{sfmath}
                       \usepackage{helvet}
                    """
    else:
        # Computer modern serif
        font = {'family':'serif', 'serif':['cm10']}
        preamble  = r"""
                       \usepackage{color}
                    """
    
    if unicode:
        # Unicode for Tex
        #preamble =  r"""\usepackage[utf8]{inputenc}""" + preamble
        # inputenc should be set automatically
        plt.rcParams['text.latex.unicode']=True
    
    #print font, preamble
    plt.rc('font',**font)
    plt.rcParams['text.latex.preamble'] = preamble


Am 03.05.2013 um 16:08 schrieb Juergen Hasch <py...@el...>:

>> 
>> The solution I use when I want all sans-serif out of TeX is to use the cmbright package, which can be turned on by adding:
>> 
>> rc('text.latex', preamble=r'\usepackage{cmbright}')
>> 
>> That may require installing the cmbright LaTeX package if you don't already have it.
> 
> I am using the sfmath package for this purpose.
> 
> There is a nice comparision of the different approaches to get sans-serif math fonts at the bottom of the sfmath page: 
> http://dtrx.de/od/tex/sfmath.html
> 
> 
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Some output using the different settings in the functions I just sent. As you can see the only problem are greek letters and some math symbols. It may be possible to improve this situation using xetex (http://matplotlib.org/users/pgf.html), but I did not try this out yet.



Am 03.05.2013 um 17:38 schrieb Felix Patzelt <fe...@ne...>:

> H, I'm using sfmath, too. I actually wrote a helper function to switch fonts. The preambles are the result of long-term trial and error. Normally, my preambles include some more custom commands which I left out here because they would be distracting. I always wondered why matplotlib doesn't do this kind of font switching out of the box.
> 
> def setfont(font=font_default,unicode=True):
>    r"""
>    Set Matplotlibs rcParams to use LaTeX for font rendering.
>    Revert all changes by calling rcdefault() from matplotlib.
> 
>    Parameters:
>    -----------
>    font: string
>        "Helvetica"
>        "Times"
>        "Computer Modern"
> 
>    usetex: Boolean
>        Use unicode. Default: False.    
>    """
> 
>    # Use TeX for all figure text!
>    plt.rc('text', usetex=True)
> 
>    font = font.lower().replace(" ","")
>    if font == 'times':
>        # Times
>        font = {'family':'serif', 'serif':['Times']}
>        preamble  = r"""
>                       \usepackage{color}
>                       \usepackage{mathptmx}
>                    """
>    elif font == 'helvetica':
>        # Helvetica
>        # set serif, too. Otherwise setting to times and then
>        # Helvetica causes an error.
>        font = {'family':'sans-serif','sans-serif':['Helvetica'],
>                'serif':['cm10']}
>        preamble  = r"""
>                       \usepackage{color}
>                       \usepackage[tx]{sfmath}
>                       \usepackage{helvet}
>                    """
>    else:
>        # Computer modern serif
>        font = {'family':'serif', 'serif':['cm10']}
>        preamble  = r"""
>                       \usepackage{color}
>                    """
> 
>    if unicode:
>        # Unicode for Tex
>        #preamble =  r"""\usepackage[utf8]{inputenc}""" + preamble
>        # inputenc should be set automatically
>        plt.rcParams['text.latex.unicode']=True
> 
>    #print font, preamble
>    plt.rc('font',**font)
>    plt.rcParams['text.latex.preamble'] = preamble
> 
> 
> Am 03.05.2013 um 16:08 schrieb Juergen Hasch <py...@el...>:
> 
>>> 
>>> The solution I use when I want all sans-serif out of TeX is to use the cmbright package, which can be turned on by adding:
>>> 
>>> rc('text.latex', preamble=r'\usepackage{cmbright}')
>>> 
>>> That may require installing the cmbright LaTeX package if you don't already have it.
>> 
>> I am using the sfmath package for this purpose.
>> 
>> There is a nice comparision of the different approaches to get sans-serif math fonts at the bottom of the sfmath page: 
>> http://dtrx.de/od/tex/sfmath.html
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>> It's a free troubleshooting tool designed for production
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap2
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

On Fri, May 3, 2013 at 6:17 AM, Michael Droettboom <md...@st...> wrote:

>  On 05/02/2013 03:16 PM, Paul Hobson wrote
>
>  I now see that this was more of TeX issue than an MPL configuration
> issue. Your help prompted me to find this solution (similar to yours):
>     mpl.rcParams['text.latex.preamble'] = [
>        r'\usepackage{siunitx}',   # i need upright \micro symbols, but you
> need...
>        r'\sisetup{detect-all}',   # ...this to force siunitx to actually
> use your fonts
>        r'\usepackage{helvet}',    # set the normal font here
>        r'\usepackage{sansmath}',  # load up the sansmath so that math ->
> helvet
>        r'\sansmath']  # <- tricky! -- gotta actually tell tex to use!
>
>
> Wow.  That's some serious TeX voodoo magic!  Want to work that into an
> example that we could include in the docs?
>
> Cheers,
> Mike
>

Gladly. I'll try to find time to cook up PR building off of the existing
example over the weekend.
-paul

>
> The solution I use when I want all sans-serif out of TeX is to use the cmbright package, which can be turned on by adding:
>
> rc('text.latex', preamble=r'\usepackage{cmbright}')
>
> That may require installing the cmbright LaTeX package if you don't already have it.

I am using the sfmath package for this purpose.

There is a nice comparision of the different approaches to get sans-serif math fonts at the bottom of the sfmath page: 
http://dtrx.de/od/tex/sfmath.html

Mike,

On 03/05/2013 15:14, Michael Droettboom wrote:
> FWIW: Matplotlib uses the older buffer interface because that is what 
> the older version of wx used (as well as other GUI toolkits).  It 
> would be nice to move to the new memoryview objects, but all of the 
> GUI frameworks will need to move in tandem...
agg.bufferNEW_rgba or something along those lines and then GUI 
frameworks could move when they want/can, or would that create to big of 
an overhead on MPL side.

Werner

On 05/02/2013 03:16 PM, Paul Hobson wrote:
>
> On Thu, May 2, 2013 at 11:19 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     I think the confusion here stems from the fact that you're mixing
>     TeX and non-TeX font commands.
>
>     This turns on TeX mode, so all of the text is rendered with an
>     external TeX installation:
>
>     rc('text', usetex=True)
>
>     In this line, setting it to sans-serif will get passed along to
>     TeX, but a specific ttf font name can not be used by TeX, so the
>     second part (involving Helvetica) is ignored.  And setting the
>     default body text in TeX does not (by default) change the math
>     font.  This is (unfortunately standard TeX behavior).
>
>     rc('font',**{'family':'sans-serif','sans-serif':['Helvetica']})
>
>     This affects the font set used by matplotlib's internal mathtext
>     renderer, and has no effect on TeX:
>
>     rc('mathtext', fontset='stixsans')
>
>     The solution I use when I want all sans-serif out of TeX is to use
>     the cmbright package, which can be turned on by adding:
>
>     rc('text.latex', preamble=r'\usepackage{cmbright}')
>
>     That may require installing the cmbright LaTeX package if you
>     don't already have it.
>
>     I know all this stuff is confusing, but providing a flat interface
>     over both the internal text rendering and the TeX rendering isn't
>     really possible -- they have different views of the world -- and
>     I'm actually not sure it's desirable.  Though I wonder if we
>     couldn't make it more obvious (somehow) when the user is mixing
>     configuration that applies to the different contexts.
>
>     Mike
>
>
> Mike,
>
> Thanks for the guidance. I know this stuff is complicated and the work 
> everyone has put into it to make it work is fantastic.
>
> I now see that this was more of TeX issue than an MPL configuration 
> issue. Your help prompted me to find this solution (similar to yours):
> mpl.rcParams['text.latex.preamble'] = [
>        r'\usepackage{siunitx}',   # i need upright \micro symbols, but 
> you need...
>        r'\sisetup{detect-all}',   # ...this to force siunitx to 
> actually use your fonts
>        r'\usepackage{helvet}',    # set the normal font here
>        r'\usepackage{sansmath}',  # load up the sansmath so that math 
> -> helvet
>        r'\sansmath']  # <- tricky! -- gotta actually tell tex to use!

Wow.  That's some serious TeX voodoo magic!  Want to work that into an 
example that we could include in the docs?

Cheers,
Mike

FWIW: Matplotlib uses the older buffer interface because that is what 
the older version of wx used (as well as other GUI toolkits).  It would 
be nice to move to the new memoryview objects, but all of the GUI 
frameworks will need to move in tandem...

Mike

On 04/27/2013 06:23 PM, Werner F. Bruhin wrote:
> Hi Michael,
>
> On 26/04/2013 14:40, Michael Droettboom wrote:
>> On 04/26/2013 02:57 AM, Werner F. Bruhin wrote:
>>> Hi,
>>>
>>> Anyone can provide some info on what "agg.buffer_rgba" returns and 
>>> maybe
>>> even some suggestion on how to resolve this issue in the wxagg backend.
>> It returns a Python buffer object on Python 2, though on Python 3 it is
>> a memoryview, since buffer was deprecated.  Perhaps wx is also doing
>> something different depending on the version of Python.
> As of Phoenix 2.9.5.81-r73873 matplot works with Phoenix, here is 
> Robin Dunn's comment to the change he did on Phoenix with regards to 
> the buffer handling.
>
> Quote
>
> The new buffer APIs go as far back as 2.6, IIRC, and the memoryview 
> and bytearray object types are available in 2.7 in addition to 3.x and 
> that I what I'm using in Phoenix.  I would have expected MPL to do so 
> also since numpy is an integral part of MPL and the new buffer 
> interface was basically designed for and by numpy...
>
> Anyway, while double checking all this I realized that it would not be 
> hard for me to accept old or new buffer objects for source buffers 
> (I'll still use memoryviews or bytearrays when on the producer side of 
> things) so try again after the next snapshot build.  My unittests with 
> array.arrrays started working after the change so I expect that MPL's 
> rgba buffer should work too.
>
> EndQuote
>
> Enclosed is the patch for backend_wx.py and for embedding_in_wx5.py 
> which I used for testing, in the later I use wxversion.select to force 
> selection of a particular version - I think the distribution should 
> still just use ensureMinimal.
>
> FYI, documentation for wxPython Phoenix are here:
> http://wxpython.org/Phoenix/docs/html/index.html
>
> And snapshots can be found here:
> http://wxpython.org/Phoenix/snapshot-builds/
>
> I tested only on Python 2.7.2 on Windows 7.
>
> Werner
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users