matplotlib-users Mailing List for matplotlib

Here's some (incomplete) code snippets I used to place an extra 
x-axis below the normal one. I hope this helps. I agree that more 
axes can always be added at an arbitrary offset, although I did not 
try that.

import numpy as N
import matplotlib
matplotlib.use("TkAgg")
import pylab as PLT
from matplotlib.font_manager import FontProperties # For setting 
legend font props.


     f1 = PLT.figure(1, figsize=(7.5,4.0))
     ax1 = f1.add_axes([0.2, 0.25, 0.6, 0.6]) # This is "normal" axis
     PLT.hold(False)
     ax1.set_autoscale_on(False) # So that I can turn off autoscaling
     PLT.plot(lt, drift, '-', linewidth=3, label=legtext)

     # This axis is LT. Set the ticks manually.
     xticks = N.array([5.0, 8.0, 11.0, 14.0, 17.0, 20.0])
     ax1.set_xticks(xticks.tolist())
     ax1.set_autoscale_on(False) # So that I can turn off autoscaling

     # Now manually create the second axis (UT) slightly below
     PLT.hold(False)
     ax2 = f1.add_axes([0.2, 0.15, 0.6, 0.6], frameon=False)
     ax2.set_yticks([])
     # Apply offset to get UT scale for second axis
     ax2.set_xlim([xticks[0]+offset, xticks[len(xticks)-1]+offset])
     ax2.set_xticks((xticks+offset).tolist())
     # Make tick lines invisible
     xtl = PLT.getp(ax2, 'xticklines')
     PLT.setp(xtl, 'visible', False)
     # Label the X ticks for first (LT) and second (UT) axes
     PLT.text(1.1, -0.1, 'LT', transform=ax1.transAxes)
     PLT.text(1.1, -0.25, 'UT', transform=ax1.transAxes)

-Tony

-- 
Tony Mannucci
Supervisor, Ionospheric and Atmospheric Remote Sensing Group
  Mail-Stop 138-308,                     Tel > (818) 354-1699
  Jet Propulsion Laboratory,              Fax > (818) 393-5115
  California Institute of Technology,     Email > Ton...@jp...
  4800 Oak Grove Drive,                   http://genesis.jpl.nasa.gov
  Pasadena, CA 91109

> On 10/5/07, James Boyle <bo...@ll...> wrote:
> > I wish to plot 3 lines on a single graph - each line requires a=20
> > separate y scaling but shares a common x.
> > The case for 2 such lines is handled by twinx as in the=20
> two_scales.py=20
> > example.
> >
> > I have not found an example of 3 lines ( or greater). In=20
> the case of=20
> > more than 2 scales the y axis scale would have to float, to=20
> the right=20
> > or left of the y axes defined for the first 2 lines.
>=20
> This is on the wish list, but is currently unsupported.
>=20
> JDH

Hmmm, unsupported, but working. See attached.  Maybe I've misunderstood,
though.

Anyway, I'm not complete sure of your context, but this plot was
generated in code, rather than using pylab.  I don't use pylab and I
don't know if there's an analogue to what I'll describe below.

Unfortunately the code used to generate this particular chart is much
more than what you're looking for (our current matplotlib based "plot"
object is currently 1500 lines of code on top of MPL).  It does,
however, allow me to plot a line on any of 4 independent "y" axes, and 2
"x" axes (and a bunch of other bells and whistles).

The underlying structure creates a "master" figure (X1Y1) and then
subsequent figures overlaid on top (ie in the same location by using
axes.get_position()).  Each subsequent figure uses an appropriate
"sharex=3D" in the call figure.add_axes(...).  Also significant are to
turn the frame off (frameon=3DFalse), and assign a label to each figure
(label=3D'myLabel') so that MPL doesn't try to combine figures for you.

In principle, I don't see why this can't be done for an arbitrary number
of subfigures, but practically, the plot start getting cluttered and
confusing pretty quickly.

I can't post the code, but if you have some more questions, I can try to
help!

Cheers,
Anthony.

> On 10/5/07, James Boyle <bo...@ll...> wrote:
>> I wish to plot 3 lines on a single graph - each line requires a 
>> separate y scaling but shares a common x.  I have not 
>> found an example of 3 lines ( or greater).


On Fri, 5 Oct 2007, John Hunter wrote:
> This is on the wish list, but is currently unsupported. 


If you just need an EPS or PDF, you can use PyX:
http://pyx.sourceforge.net/gallery/graphs/manyaxes.html

hth,
Alan Isaac

On 10/5/07, James Boyle <bo...@ll...> wrote:
> I wish to plot 3 lines on a single graph - each line requires a
> separate y scaling but shares a common x.
> The case for 2 such lines is handled by twinx as in the two_scales.py
> example.
>
> I have not found an example of 3 lines ( or greater). In the case of
> more than 2 scales the y axis scale would have to float, to the right
> or left of the y axes defined for the first 2 lines.

This is on the wish list, but is currently unsupported.

JDH

I wish to plot 3 lines on a single graph - each line requires a  
separate y scaling but shares a common x.
The case for 2 such lines is handled by twinx as in the two_scales.py  
example.

I have not found an example of 3 lines ( or greater). In the case of  
more than 2 scales the y axis scale would have to float, to the right  
or left of the y axes defined for the first 2 lines.

Thanks for any help.

---Jim

The short answer to your two messages is that pcolor and contour 
required gridded data in 2D arrays, and it looks like you are supplying 
1D arrays.  Look at the differences between what you have below and what 
is in the pcolor_demo that you started with.  Meshgrid is generating 2D 
arrays for X and Y so that Z is also 2D.  There are other ways of doing 
it, and for a Cartesian grid, X and Y don't actually have to be 
2D--although I find that there is now a bug in svn such that 1D x and y 
don't work.  I will fix that.  But in any case, Z *must* be a 2D array.

If the data you really want to plot are not already on a grid, then you 
will need to use a gridding routine, which is not included in mpl.

Eric


yadin Bocuma Rivas wrote:
> I i have tree lists of values
> list x of 100... values
> list y of 100.. values
> list mag of 100.. values
> list x and y are coordiantes of points
> and list Mag is magnitude of something at that point
> 
> how can i plot this quantities using pcolor
> 
> from __future__ import division
> from matplotlib.patches import Patch
> from pylab import *
> 
> def func3(x,y):
>     return (1- x/2 + x**5 + y**3)*exp(-x**2-y**2)
> 
> 
> # make these smaller to increase the resolution
> dx, dy = 0.5, 0.5
> 
> X = arange(-3.0, 3.0001, dx)
> 
> Y = arange(-3.0, 3.0001, dy)
> 
> Mag= X**2+Y**2
> 
> pcolor(X, Y, Mag, shading='flat')
> colorbar()
> axis([-3,3,-3,3])
> savefig('pcolor_demo')
> show()
> 
> 
> ------------------------------------------------------------------------
> 
> ¡Sé un mejor ambientalista!
> Encuentra consejos para cuidar el lugar donde vivimos en:
> http://telemundo.yahoo.com/promos/mejorambientalista.html
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,

I just encountered something odd.
I have (with import numpy as n and import pylab as pl) :
>>> x = n.arange(0, 2*n.pi, n.pi/30)
>>> z = n.array([n.cos(x), n.sin(x)]).T
If I draw a boxplot on z :
>>> pl.boxplot(z)
the values z are modified.
Is this a feature or a bug ?

Matthieu

I i have tree lists of values=0Alist x of 100... values=0Alist y of 100.. v=
alues=0Alist mag of 100.. values=0Alist x and y are coordiantes of points =
=0Aand list Mag is magnitude of something at that point=0A=0Ahow can i plot=
 this quantities using pcolor=0A=0Afrom __future__ import division=0Afrom m=
atplotlib.patches import Patch=0Afrom pylab import *=0A=0Adef func3(x,y):=
=0A    return (1- x/2 + x**5 + y**3)*exp(-x**2-y**2)=0A=0A=0A# make these s=
maller to increase the resolution=0Adx, dy =3D 0.5, 0.5=0A=0AX =3D arange(-=
3.0, 3.0001, dx)=0A=0AY =3D arange(-3.0, 3.0001, dy)=0A=0AMag=3D X**2+Y**2=
=0A=0Apcolor(X, Y, Mag, shading=3D'flat')=0Acolorbar()=0Aaxis([-3,3,-3,3])=
=0Asavefig('pcolor_demo')=0Ashow()=0A=0A=0A=0A=0A      ____________________=
________________________________________________________________=0A=A1S=E9 =
un mejor besador!=0AComparte todo lo que sabes sobre besos.                =
      =0Ahttp://telemundo.yahoo.com/promos/mejorbesador.html

hi i have been trying  to use pcolor and/or contour to make a contor map
or intensity map
i want to do an intensity or contour map of an electric field 
i have an array (or list) of points [x,y] and for each point i have the respective value of the electric field (in another list) 
 
i have tried the examples in matplotlib  but they are different because they use meshgrid
and from the points calculated in the mesh get values and plot...
in my case i want to plot directly...each poin (x,z) its magnitude(E_fiel_Mag)
i do not think i need to use meshgrid any more how can i do my plot?
below is my code...pls help me!!!

#!/usr/bin/env python

# This example demonstrates how to use a constraint polygon in
# Delaunay triangulation.

from scipy import*
from pylab import*

read_file= open ('W:/Serio/necfile.out','r')

L =read_file.readlines()
                
fieldlist =[]
f = 0
for line in L:
        f=f+1
        if 'NEAR ELECTRIC FIELDS'in line:

                rpoints = 3
                phipoints = 3
                tetapoints = 1
                
                for line in range (f+3,f+4+rpoints*phipoints*tetapoints):
                        fieldlist.append(L[line])
                        
Ex = [];Ey = [];Ez = []
x1 =[];y1=[];z1=[]
Exphase=[]; Eyphase=[]; Ezphase=[]
                
for i in range(len(fieldlist)-1):
       
        splitlines= fieldlist[i].split()
        
        x1.append(float(splitlines[0]))     #here we pick up the x,y,x coordinates of the points
        y1.append(float(splitlines[1]))     #where the manitude has been calculated
        z1.append(float(splitlines[2]))

        Ex.append(float(splitlines[3]))     #pick up the e-filed magnitudes
        Ey.append(float(splitlines[5]))     #u append as floats instead os string for later calculations
        Ez.append(float(splitlines[7]))

        Exphase.append(float(splitlines[4])) # pick up the phases just in case they are needed
        Eyphase.append(float(splitlines[6]))
        Ezphase.append(float(splitlines[8]))
read_file.close()        
                

# i want to see if i can calculate the magnitude of the electric field

E_field_Mag = []
for i in range(len(Ex)):
    E_Magnitude = sqrt((Ex[i])**2 + (Ey[i])**2+(Ez[i])**2)
    E_field_Mag.append(E_Magnitude)
    
#E_field_Mag = array(E_field_Mag)

#y values are  zero
#X,Z = meshgrid(x1, z1)

pcolor(x1,y1,E_field_Mag)










----- Mensaje original ----
De: "mat...@li..." <mat...@li...>
Para: mat...@li...
Enviado: domingo, 30
 de septiembre, 2007 12:53:11
Asunto: Matplotlib-users Digest, Vol 16, Issue 32

Send Matplotlib-users mailing list submissions to
    mat...@li...

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.sourceforge.net/lists/listinfo/matplotlib-users
or, via email, send a message with subject or body 'help' to
    mat...@li...

You can reach the person managing the list at
    mat...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Matplotlib-users digest..."


Today's Topics:

   1. Re: NameError: global name '__loader__' is not
 defined
      (Eric Firing)
   2. Re: plot cdf (Alan G Isaac)
   3. Re: edgecolor with usetex=True,    usedistiller='pdf' (Darren Dale)
   4. Re: Problem with tick labels in scripts (John Hunter)
   5. Using special characters (David Loyall)
   6. Re: matplotlib - representation of nan values in    2D
      (Dirk Zickermann)


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

Message: 1
Date: Thu, 27 Sep 2007 14:46:13 -1000
From: Eric Firing <ef...@ha...>
Subject: Re: [Matplotlib-users] NameError: global name '__loader__' is
    not defined
To: Hal Huntley <ha...@so...>
Cc: mat...@li...
Message-ID: <46F...@ha...>
Content-Type:
 text/plain; charset=ISO-8859-1; format=flowed

Hal Huntley wrote:
> Thanks to Eric Firing and Christopher Barker for input on trying to
> resolve the problem.  Christopher said:
> %%%
> You might try just:
> 
> easy_install numpy
> 
> easy_install matplotlib.
> %%%
> 
> 
> I did that and now the problem moved and I get:
> ===
>>>> from pylab import *
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File
>   "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/pylab.py", line 1, in ?
>     from matplotlib.pylab import *
>   File
>   "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/pylab.py", line 222, in ?
>    
 new_figure_manager, draw_if_interactive, show = pylab_setup()
>   File
>   "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/backends/__init__.py", line 24, in pylab_setup
>     globals(),locals(),[backend_name])
>   File
>   "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/backends/backend_gtkagg.py", line 10, in ?
>     from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK,
>     FigureCanvasGTK,\
>   File
>   "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/backends/backend_gtk.py", line 21, in ?
>     from matplotlib.backends.backend_gdk import RendererGDK, FigureCanvasGDK
>   File
>  
 "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/backends/backend_gdk.py", line 35, in ?
>     from matplotlib.backends._ns_backend_gdk import pixbuf_get_pixels_array
> ImportError: No module named _ns_backend_gdkd4
> ===

Is it a rotten egg?

> 
> Googling around has indicated that the X11 stuff wasn't available when the
> numpy and matplotlib were made. The gtk files and "-devel" seem to be there
> when I do an "rpm -qa".  I went and got a new numpy from source and did
> "python setup.py install".  It is interesting that when I get in to python
> now, I can do:
> 
>>>> import gtk
>>>> import numpy
>>>> import matplotlib
> 
> and they all just return the prompt, indicating, I thought, that the
> programs were installed ok.  
>
 
> Here is the naive question ->  Is there something wrong, then with a
> "from pylab import *"? The user is trying to do that. 

No, that should work fine.  I don't know how the egg-based 
matplotlib/pylab should work with the installed-from-source numpy, 
though.  If the versions are compatible, then I expect it would work.

You gave a traceback resulting from "from pylab import *" after 
installing the two eggs, correct?  If so, what was the result after you 
installed numpy from source?  I would expect no difference, because the 
problem reported in the traceback is a missing matplotlib module, not a 
missing numpy module.

Or did you mean that you installed matplotlib from source?  That would 
make more sense, and certainly should work if all the right header files 
and libraries are present.

If you installed matplotlib from
 source, what do you get from
ls /usr/lib/python2.4/site-packages/matplotlib/backends/*.so

Another diagnostic would be to delete the build directory from the 
matplotlib source tree (assuming you are now building matplotlib from 
source), and save the output from the "python setup.py build" command. 
This should make it clear whether the necessary headers really were found.

Eric



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

Message: 2
Date: Fri, 28 Sep 2007 00:18:13 -0400
From: Alan G Isaac <ai...@am...>
Subject: Re: [Matplotlib-users] plot cdf
To: mat...@li...
Message-ID: <Mah...@am...>
Content-Type: TEXT/PLAIN; CHARSET=UTF-8

After thinking it over, I did not go for
Robert or David's cool numpy tricks, but
I'll append a simple object in case someone
else wants to do more.

Cheers,
Alan
 Isaac

class EmpiricalCDF(object):
    '''Empirical cdf.
    First point will be (xmin,0).
    Last point will be (xmax,1).
    '''
    def __init__(self, data, sortdata=True):
        if sortdata:
            data = N.sort(data)
        self.data = data
        self.nobs = len(data)
    def gen_xp(self):
        data, nobs = self.data, self.nobs
        prob = N.linspace(0, 1, nobs+1)
        xsteps = ( data[(idx)//2] for idx in xrange(2*nobs)
 )
        psteps = ( prob[(idx+1)//2] for idx in xrange(2*nobs) )
        return xsteps, psteps
    def get_steps(self):
        '''Return: 2-tuple of arrays,
        the data values and corresponding cumulative 
        probabilities.
        '''
        xsteps, psteps = self.gen_xp()
        return N.fromiter(xsteps,'f'), N.fromiter(psteps,'f')






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

Message: 3
Date: Fri, 28 Sep 2007 08:23:17 -0400
From: Darren Dale <dd...@co...>
Subject: Re: [Matplotlib-users] edgecolor with
 usetex=True,
    usedistiller='pdf'
To: "John Hunter" <jd...@gm...>
Cc: matplotlib-users <mat...@li...>,    Eric
    Firing <ef...@ha...>
Message-ID: <200...@co...>
Content-Type: text/plain;  charset="iso-8859-1"

On Friday 28 September 2007 07:36:23 am John Hunter wrote:
> On 9/27/07, Darren Dale <dd...@co...> wrote:
> > Hi Eric, John,
> >
> > Have either of you been following this thread?
>
> I am now :-)
>
> As Eric suggests, None is overloaded vis-a-vis color handling, because
> for mpl properties it generally means do the default as defined by rc.
>  For colors people often want to use None for "no color" which is why
> we added support for the string "None".  Does
 this work in your use
> case Tom?

The above exchange was off-list, we're back on now. I think that would be what 
Tom is looking for, but it doesnt work:

In [1]: plot([1,2])
Out[1]: [<matplotlib.lines.Line2D instance at 0x710cb0>]

In [2]: savefig('dsd.png', facecolor='None', edgecolor='None')
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/home/darren/<ipython console> in <module>()

/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py in savefig(*args, 
**kwargs)
    272 def savefig(*args, **kwargs):
    273     fig = gcf()
-->
 274     return fig.savefig(*args, **kwargs)
    275 if Figure.savefig.__doc__ is not None:
    276     savefig.__doc__ = dedent(Figure.savefig.__doc__)

/usr/lib64/python2.5/site-packages/matplotlib/figure.py in savefig(self, 
*args, **kwargs)
    768                 kwargs[key] = rcParams['savefig.%s'%key]
    769
--> 770         self.canvas.print_figure(*args, **kwargs)
    771
    772     def colorbar(self, mappable, cax=None, **kw):

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py in 
print_figure(self, *args,
 **kwargs)
    153         self.update(l, self.renderer.height-t, w, h)
    154
    155     def print_figure(self, *args, **kwargs):
--> 156         FigureCanvasAgg.print_figure(self, *args, **kwargs)
    157         self.draw()

/usr/lib64/python2.5/site-packages/matplotlib/backend_bases.py in 
print_figure(self, filename, dpi, facecolor, edgecolor, orientation, format, 
**kwargs)
   1194                 edgecolor=edgecolor,
   1195                 orientation=orientation,
->
 1196                 **kwargs)
   1197         finally:
   1198             self.figure.dpi.set(origDPI)

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py in 
print_png(self, filename, *args, **kwargs)
    415
    416     def print_png(self, filename, *args, **kwargs):
--> 417         self.draw()
    418         self.get_renderer()._renderer.write_png(str(filename))
    419

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py in
 
draw(self)
    140         if DEBUG: print "FigureCanvasQtAgg.draw", self
    141         self.replot = True
--> 142         FigureCanvasAgg.draw(self)
    143         self.update()
    144

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py in 
draw(self)
    377
    378         self.renderer = self.get_renderer()
--> 379         self.figure.draw(self.renderer)
    380
    381     def get_renderer(self):

/usr/lib64/python2.5/site-packages/matplotlib/figure.py in
 draw(self, 
renderer)
    586         self.transFigure.freeze()  # eval the lazy objects
    587
--> 588         if self.frameon: self.figurePatch.draw(renderer)
    589
    590         for p in self.patches: p.draw(renderer)

/usr/lib64/python2.5/site-packages/matplotlib/patches.py in draw(self, 
renderer)
    198         #renderer.open_group('patch')
    199         gc = renderer.new_gc()
--> 200         gc.set_foreground(self._edgecolor)
    201        
 gc.set_linewidth(self._linewidth)
    202         gc.set_alpha(self._alpha)

/usr/lib64/python2.5/site-packages/matplotlib/backend_bases.py in 
set_foreground(self, fg, isRGB)
    617             self._rgb = fg
    618         else:
--> 619             self._rgb = colors.colorConverter.to_rgb(fg)
    620
    621     def set_graylevel(self, frac):

/usr/lib64/python2.5/site-packages/matplotlib/colors.py in to_rgb(self, arg)
    277
    278         except (KeyError, ValueError, TypeError), exc:
-->
 279             raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % 
(str(arg), exc))
    280             # Error messages could be improved by handling TypeError
    281             # separately; but this should be rare and not too hard

ValueError: to_rgb: Invalid rgb arg "None"
invalid literal for float(): None



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

Message: 4
Date: Fri, 28 Sep 2007 07:41:35 -0500
From: "John Hunter" <jd...@gm...>
Subject: Re: [Matplotlib-users] Problem with tick labels in scripts
To: "Charles Seaton" <cs...@st...>
Cc:
 mat...@li...
Message-ID:
    <88e...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

On 9/27/07, Charles Seaton <cs...@st...> wrote:

> I am having the same problem as Eugen, and the suggested solution of using
> a.xaxis.get_major_locator().refresh()
> to force the creation of the full set of ticklabels doesn't seem to work for
> me.

matplotlib creates a prototypical tick (the prototick) and then
creates new ones on as as needed basis, copying properties from the
prototick.  Of course, position is one of the properties that cannot
be copied, which is why you are having trouble in your example.
Fortunately, there is an easy solution.

Call ax.xaxis.get_major_ticks() and access the label attribute:

for tick in ax.xaxis.get_major_ticks():
  
 label = tick.label1

Axis.get_major_ticks  will force a call to the locator and update the
tick list.  The Axes methods like get_xticklabels are just working on
the existing tick list rather than calling the get_major_ticks method
which is why you are not getting the full list.  This is a bug.  I
just made changes in svn so that all the accessor methods
(ax.get_xticklines, ax.get_yticklabels, and friends) all trigger a
call to axis.get_major_ticks rather so they should give the same
results going forward.


JDH


FYI, the Tick attributes are:

      tick1line  : a Line2D instance
      tick2line  : a Line2D instance
      gridline   : a Line2D instance
      label1     : a Text
 instance
      label2     : a Text instance
      gridOn     : a boolean which determines whether to draw the tickline
      tick1On    : a boolean which determines whether to draw the 1st tickline
      tick2On    : a boolean which determines whether to draw the 2nd tickline
      label1On   : a boolean which determines whether to draw tick label
      label2On   : a boolean which determines whether to draw tick label



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

Message: 5
Date: Sat, 29 Sep 2007 21:50:02 -0500
From: "David Loyall" <dav...@th...>
Subject: [Matplotlib-users] Using special characters
To:
 mat...@li...
Message-ID:
    <957...@ma...>
Content-Type: text/plain; charset=UTF-8

Hello.

I've been having trouble getting Unicode characters to render.  I just
get a box in the title of my figure, rather than the character I need.

Here is my code:
#!/usr/bin/env python
from pylab import *
plot([1,2,3,4])
title(u"\u0251")
savefig("test.eps")
savefig("test.png")
show()

That character is LATIN SMALL LETTER ALPHA.  It's used in the
International Phonetic Alphabet.

I'm on Linux and I'm using matplotlib 0.90.1-2 (debian package
version).  I have a few TTF fonts in my system that contain that
glyph.  One is 'Arial Unicode MS', which I copied from my windows
machine.

As you can see, I will need to generate an EPS that renders
 the
character...  That EPS file will be imported into MS Word on a Windows
PC and printed.

I will happily use any solution that allows me to use that character
in the final product... :)  It doesn't have to be unicode..

I believe that my fonts are configured correctly on this Linux
system--I can use the Arial Unicode MS font in Open Office.  However,
I'm not sure that MPL is finding them.

When I point the TTFPATH environment variable a directory that only
contains ARIALUNI.TTF, I get gibberish for all characters in my
figure.

When I use ~/.matplotlib/matplotlibrc to list Arial Unicode MS as the
only font in the san-serif family, I don't observe any change in the
text in the figure.

...I did successfully instantiate an FT2FONT object out of my
ARIALUNI.TTF file, but, I didn't know what to do with it at that
point.

Help?

Cheers,
--Dave
 Loyall
Omaha, Nebraska, USA



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

Message: 6
Date: Sun, 30 Sep 2007 12:53:06 +0200
From: "Dirk Zickermann" <dir...@go...>
Subject: Re: [Matplotlib-users] matplotlib - representation of nan
    values in    2D
To: Mat...@li...
Message-ID:
    <511...@ma...>
Content-Type: text/plain; charset="iso-8859-1"

Dear  all,
thanks for your help. this is what I was looking for!
Dirk


2007/9/26, Eric Firing <ef...@ha...>:
>
> David Huard wrote:
> > Hi Dirk,
> >
> > If you haven't already done so, look at the numpy.ma <http://numpy.ma/>
> > module. It provides a masked array object that
 deals gracefully with
> > missing values. To the best of my knowledge, most matplotlib functions
> > understand masked arrays and deal with it accordingly, exception made of
> > those requiring a full matrix (such as contour). Take a look at
>
> contour handles masked arrays correctly, as far as I know; contourf has
> some bugs in its masked array handling, but depending on the type and
> distribution of voids, it may still be good enough.
>
> pcolor and image have no problems with masked arrays.
>
> Eric
>
> > examples/image_masked.py. Also, in the Basemap toolkit, there is at
> > least one example showing how to plot a masked array on a map.
> >
> > Cheers,
> >
> > David
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
>
 Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-------------- next part --------------
An HTML attachment was scrubbed...

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

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

_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


End of Matplotlib-users Digest, Vol 16, Issue 32
************************************************








      ____________________________________________________________________________________
¡Sé un mejor asador!
Aprende todo sobre asados.                      
http://telemundo.yahoo.com/promos/mejorasador.html

gr...@bi... wrote:
> Thanks again Eric,
> 
> Your examples are exactly what I was after.

Glad to hear it!

> My colleague was hypothesizing that there's probably a less-than instead of a less-than-or-equal somewhere, if it is a bug.
> 

That was part of it, but it was a little more subtle. I have tweaked the 
automatic level generation routine so that it now does what one might 
reasonably expect.  Specifying levels explicitly is still better when 
you can do it; the number-of-levels method is really only for quick and 
dirty exploratory work, when you don't care too much which levels are 
chosen and you don't know in advance what the data interval will be.

Eric

Thanks again Eric,

Your examples are exactly what I was after.
My colleague was hypothesizing that there's probably a less-than instead of a less-than-or-equal somewhere, if it is a bug.

regards,
Gary

---- Eric Firing <ef...@ha...> wrote: 
> gr...@bi... wrote:
> > Thanks Eric.
> > 
> > However, when I specify the same number of levels as suggested, contourf divides this example into three regions, with a diagonal 'stripe' instead of a clean boundary, so I guess I'm asking whether it's possible to trick contourf into generating a single boundary between the two regions such that it matches that found by contour?
> > 
> Now I see the problem; this is something of a corner case, but it may be 
> pointing to a bug.
> 
> Where do you really want the line to fall?
> 
> Do you need to specify the number of contours instead of specifying the 
>   actual levels (boundaries)? Are you actually dealing with zeros and 
> ones as in the example?  If so, you probably want
> 
> contour(a, [0.5])
> contourf(a, [-1, 0.5, 2], colors=('w', 'k'), extend='neither')
> 
> or
> 
> contourf(a, [0.5, 2], colors=('k',), extend='neither')
> In this case you are saying "color everything between 0.5 and 2, and 
> nothing else".
> 
> Specifying one contour instead of giving the levels is yielding 0.6; 
> this is a consequence of using the MaxNLocator by default to auto-select 
> the levels.
> 
> > For the moment, a suitable workaround seems to be to do
> > 
> > contourf(a,1,colors=('w','k'))
> > 
> > where the background colour is white. This generates what I'm after.
> > 
> > I notice also that linewidths is mentioned in the docstring under Obsolete:, but it seems to do nothing, so it should probably be removed from the docstring.
> 
> I will fix the docstring.  Thanks.
> 
> Eric
> > 
> > thanks again,
> > Gary
> > 
> > ---- Eric Firing <ef...@ha...> wrote: 
> >> Gary Ruben wrote:
> >>> I'm notice that contourf behaves differently to contour by default in 
> >>> where it decides to position contours. For example, using pylab, if you try
> >>>
> >>> a=tri(10)
> >>> contourf(a,0)
> >>> contour(a,1)
> >>>
> >>> I'd have expected the contours to line up, but they don't. Is there a 
> >>> way to get contourf to place its contours at the same position as contour?
> >> Specify the same number of levels:
> >>
> >> contourf(a,1)
> >> contour(a,1)
> >>
> >>
> >> That takes care of this simple case.  There are other cases, however, 
> >> where contour and contourf simply don't agree; contouring is ambiguous, 
> >> and only part of the algorithm is shared between contour and contourf. 
> >> For well-behaved datasets this is normally not a problem, but it becomes 
> >> obvious if you contour a random array.
> >>
> >> Eric
> > 
> 

gr...@bi... wrote:
> Thanks Eric.
> 
> However, when I specify the same number of levels as suggested, contourf divides this example into three regions, with a diagonal 'stripe' instead of a clean boundary, so I guess I'm asking whether it's possible to trick contourf into generating a single boundary between the two regions such that it matches that found by contour?
> 
Now I see the problem; this is something of a corner case, but it may be 
pointing to a bug.

Where do you really want the line to fall?

Do you need to specify the number of contours instead of specifying the 
  actual levels (boundaries)? Are you actually dealing with zeros and 
ones as in the example?  If so, you probably want

contour(a, [0.5])
contourf(a, [-1, 0.5, 2], colors=('w', 'k'), extend='neither')

or

contourf(a, [0.5, 2], colors=('k',), extend='neither')
In this case you are saying "color everything between 0.5 and 2, and 
nothing else".

Specifying one contour instead of giving the levels is yielding 0.6; 
this is a consequence of using the MaxNLocator by default to auto-select 
the levels.

> For the moment, a suitable workaround seems to be to do
> 
> contourf(a,1,colors=('w','k'))
> 
> where the background colour is white. This generates what I'm after.
> 
> I notice also that linewidths is mentioned in the docstring under Obsolete:, but it seems to do nothing, so it should probably be removed from the docstring.

I will fix the docstring.  Thanks.

Eric
> 
> thanks again,
> Gary
> 
> ---- Eric Firing <ef...@ha...> wrote: 
>> Gary Ruben wrote:
>>> I'm notice that contourf behaves differently to contour by default in 
>>> where it decides to position contours. For example, using pylab, if you try
>>>
>>> a=tri(10)
>>> contourf(a,0)
>>> contour(a,1)
>>>
>>> I'd have expected the contours to line up, but they don't. Is there a 
>>> way to get contourf to place its contours at the same position as contour?
>> Specify the same number of levels:
>>
>> contourf(a,1)
>> contour(a,1)
>>
>>
>> That takes care of this simple case.  There are other cases, however, 
>> where contour and contourf simply don't agree; contouring is ambiguous, 
>> and only part of the algorithm is shared between contour and contourf. 
>> For well-behaved datasets this is normally not a problem, but it becomes 
>> obvious if you contour a random array.
>>
>> Eric
> 

Thanks Eric.

However, when I specify the same number of levels as suggested, contourf divides this example into three regions, with a diagonal 'stripe' instead of a clean boundary, so I guess I'm asking whether it's possible to trick contourf into generating a single boundary between the two regions such that it matches that found by contour?

For the moment, a suitable workaround seems to be to do

contourf(a,1,colors=('w','k'))

where the background colour is white. This generates what I'm after.

I notice also that linewidths is mentioned in the docstring under Obsolete:, but it seems to do nothing, so it should probably be removed from the docstring.

thanks again,
Gary

---- Eric Firing <ef...@ha...> wrote: 
> Gary Ruben wrote:
> > I'm notice that contourf behaves differently to contour by default in 
> > where it decides to position contours. For example, using pylab, if you try
> > 
> > a=tri(10)
> > contourf(a,0)
> > contour(a,1)
> > 
> > I'd have expected the contours to line up, but they don't. Is there a 
> > way to get contourf to place its contours at the same position as contour?
> 
> Specify the same number of levels:
> 
> contourf(a,1)
> contour(a,1)
> 
> 
> That takes care of this simple case.  There are other cases, however, 
> where contour and contourf simply don't agree; contouring is ambiguous, 
> and only part of the algorithm is shared between contour and contourf. 
> For well-behaved datasets this is normally not a problem, but it becomes 
> obvious if you contour a random array.
> 
> Eric