matplotlib-users Mailing List for matplotlib (Page 1435)

Hi John,

Thankx for your reply. Well, i have tried the following:

step 1: done
step 2: done
step 3: i have added '/home/karthik/usr' to the basedir which is now

basedir = {
	  'win32' : bla bla
	  'linux2':
['/usr','/home/karthik/usr','/home/karthik/usr/include']

}

Now when i try installing matplotlib, i just get :
gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC -fPIC
-I/usr/include -I/home/karthik/usr/include
-I/home/karthik/usr/include/python/numarray/include -Isrc -Iagg2/include
-I/usr/include/python2.2 -c src/_image.cpp -o
build/temp.linux-i686-2.2/_image.o -DNUMARRAY
src/_image.cpp:8:35: numarray/arrayobject.h: No such file or directory
src/_image.cpp: In function `PyObject* _image_fromarray(PyObject*,
PyObject*)':
src/_image.cpp:555: `PyArrayObject' undeclared (first use this function)
src/_image.cpp:555: (Each undeclared identifier is reported only once for
each
   function it appears in.)
src/_image.cpp:555: `A' undeclared (first use this function)
src/_image.cpp:561: parse error before `)' token
src/_image.cpp: In function `void init_image()':
src/_image.cpp:671: `import_array' undeclared (first use this function)
error: command 'gcc' failed with exit status 1


Ofcourse, numarray/arrayobject.h is at
/home/karthik/usr/include/python/numarray

What should i do next ?

With warm regards

karthik

PS: the array image was numeric













-----------------------------------------------------------------------
Karthikesh Raju,		    email: ka...@ja...
Researcher,			    http://www.cis.hut.fi/karthik
Helsinki University of Technology,  Tel: +358-9-451 5389
Laboratory of Comp. & Info. Sc.,    Fax: +358-9-451 3277
Department of Computer Sc.,
P.O Box 5400, FIN 02015 HUT,
Espoo, FINLAND
-----------------------------------------------------------------------

On Thu, 13 May 2004, John Hunter wrote:

> >>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes:
>
> Since you are facing multiple issues, let's try and get the simplest
> build working and then add stuff in.  First though, it would be
> helpful if you told me what devel rpms you needed to install so I
> recommend  these on the web page to other users.  BTW, the two pages
> most relevant for you with installation information are
> http://matplotlib.sf.net/installing.html and
> http://matplotlib.sf.net/backends.html.  Make sure you give these a
> good read.
>
> From reading your email, I see that you are installing everything to
> your home dir, is that right?
>
> Step 1: start with a clean matplotlib src tree.  I don't want to try
>   and work with the one where you have hardcoded information in the
>   code because then I don't know what is going on.  Just untar the
>   tar.gz file in a new dir and start cleanly
>
> Step 2: Edit setup.py and turn all the BUILD flags off, except for
>   BUILD_FT2FONT.  Let's try and get a working base install and then deal
>   with getting the extension code compiled.
>
> Step 3: Edit setupext.py and add any non-standard base dirs in which
>   you have installed stuff (eg /home/you/usr, /home/you/usr/local') to
>   the basedirs dictionary at the top of that file.  Your platform is
>   linux2.
>
> Step 4: Install matplotlib with > python setup.py install
>
> Step 5: If the build doesn't finish cleanly (the only reason I can
>   think it would fail is if you don't get ft2font built properly.
>   This package requires lib freetype so make you have the freetype and
>   freetype-devel libs installed.  It also requires libz so make sure
>   you have zlib and zlib-devel installed.  If you have installed these
>   to a nonstandard place, make sure you add the basedir to setupext
>   basedirs.
>
> Step 6: OK, I'm assuming you have a clean install at this point.  If
>   you installed with a non-standard prefix, you need to set your
>   MATPLOTLIBDATA environment variable.  This data should point to the
>   dir that contains, for example, all the Vera*.ttf files.  Eg,
>   /your/install/prefix/share/matplotlib.  If you add this to your rc
>   file, make sure you resource your rc or open a new shell.
>
> Step 7: At this point, if you have numarray and pygtk installed
> (1.99.16 or later), you should be able to import matplotlib.  Open up
> python shell and make sure you can do
>
>    >>> import pygtk
>    >>> pygtk.require('2.0')
>    >>> import gtk
>    >>> import numarray
>    >>> import matplotlib
>
>   If not, let us know what error you are getting.  You should now be
>   able to run python simple_plot.py -dGTK
>
>
> Step 8: Edit setup.py and add the other build flags back in.  You can
>   set the ones you want to build to 'auto', which will try and build
>   an extension if the python dependencies are found.  If you still
>   have problems with arrayobject.h, let me know.  You can add the
>   include path to that file in the build_image method in setupext.py
>   by doing
>
>       module.include_dirs.append('/your/path/to/numerix/headers')
>
>   ie, /home/karthik/usr/include/python/numarray
>
>
> We do want to improve the build process for people who have stuff in
> non-default locations, and it would be very helpful for us if you tell
> us explicitly what you had to add and change in the steps above so we
> can incorporate as much as possible into the default.
>
> Good luck!
> JDH
>
>

>>>>> "Nils" == Nils Wagner <nw...@me...> writes:

    Nils> Dear experts, I am going to install matplotlib (latest cvs)
    Nils> on SuSe 9.1

    Nils> The result of python setup.py build is

    Nils> ld: cannot find -lgobject-2.0

    Nils> locate libgobject gives

    Nils> /opt/gnome/lib/libgobject-2.0.a
    Nils> /opt/gnome/lib/libgobject-2.0.la
    Nils> /opt/gnome/lib/libgobject-2.0.so
    Nils> /opt/gnome/lib/libgobject-2.0.so.0
    Nils> /opt/gnome/lib/libgobject-2.0.so.0.200.3

    Nils> What can I do to circumvent the problem ?

matplotlib uses pkg-config in setupext.py to locate the gtk libs,
flags, etc, and it's supposed to work, damn it!  I am not sure why it
is failing in your case.  I'd be interested to see your output of

  > pkg-config --libs pygtk-2.0
  > pkg-config --libs gtk+-2.0

I think you need to do 2 things

  * add /opt/gnome to your list of base dirs in setupext.py.  Is your
    sys.platform 'sunos5'?  If so, add it to the sunos5 list in the
    basedir dictionary.  Also, please let me know what final settings
    work for you in that file and I can add it to the default config.

  * In setupext.py method add_pygtk_flags, paste in the line

      add_base_flags(module) 

    at or near the top of that function

Hope this helps,
JDH

Dear experts,

I am going to install matplotlib (latest cvs) on SuSe 9.1

The result of python setup.py build is

ld: cannot find -lgobject-2.0

locate libgobject gives

/opt/gnome/lib/libgobject-2.0.a
/opt/gnome/lib/libgobject-2.0.la
/opt/gnome/lib/libgobject-2.0.so
/opt/gnome/lib/libgobject-2.0.so.0
/opt/gnome/lib/libgobject-2.0.so.0.200.3

What can I do to circumvent the problem ?

Thanks in advance.

                     Nils

>>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes:

Since you are facing multiple issues, let's try and get the simplest
build working and then add stuff in.  First though, it would be
helpful if you told me what devel rpms you needed to install so I
recommend  these on the web page to other users.  BTW, the two pages
most relevant for you with installation information are
http://matplotlib.sf.net/installing.html and
http://matplotlib.sf.net/backends.html.  Make sure you give these a
good read.

From reading your email, I see that you are installing everything to
your home dir, is that right?

Step 1: start with a clean matplotlib src tree.  I don't want to try
  and work with the one where you have hardcoded information in the
  code because then I don't know what is going on.  Just untar the
  tar.gz file in a new dir and start cleanly

Step 2: Edit setup.py and turn all the BUILD flags off, except for
  BUILD_FT2FONT.  Let's try and get a working base install and then deal
  with getting the extension code compiled.

Step 3: Edit setupext.py and add any non-standard base dirs in which
  you have installed stuff (eg /home/you/usr, /home/you/usr/local') to
  the basedirs dictionary at the top of that file.  Your platform is
  linux2.

Step 4: Install matplotlib with > python setup.py install

Step 5: If the build doesn't finish cleanly (the only reason I can
  think it would fail is if you don't get ft2font built properly.
  This package requires lib freetype so make you have the freetype and
  freetype-devel libs installed.  It also requires libz so make sure
  you have zlib and zlib-devel installed.  If you have installed these
  to a nonstandard place, make sure you add the basedir to setupext
  basedirs.

Step 6: OK, I'm assuming you have a clean install at this point.  If
  you installed with a non-standard prefix, you need to set your
  MATPLOTLIBDATA environment variable.  This data should point to the
  dir that contains, for example, all the Vera*.ttf files.  Eg,
  /your/install/prefix/share/matplotlib.  If you add this to your rc
  file, make sure you resource your rc or open a new shell.

Step 7: At this point, if you have numarray and pygtk installed
(1.99.16 or later), you should be able to import matplotlib.  Open up
python shell and make sure you can do

   >>> import pygtk
   >>> pygtk.require('2.0')
   >>> import gtk
   >>> import numarray
   >>> import matplotlib

  If not, let us know what error you are getting.  You should now be
  able to run python simple_plot.py -dGTK

  
Step 8: Edit setup.py and add the other build flags back in.  You can
  set the ones you want to build to 'auto', which will try and build
  an extension if the python dependencies are found.  If you still
  have problems with arrayobject.h, let me know.  You can add the
  include path to that file in the build_image method in setupext.py
  by doing

      module.include_dirs.append('/your/path/to/numerix/headers')
    
  ie, /home/karthik/usr/include/python/numarray


We do want to improve the build process for people who have stuff in
non-default locations, and it would be very helpful for us if you tell
us explicitly what you had to add and change in the steps above so we
can incorporate as much as possible into the default.

Good luck!
JDH

>>>>> "Jean-Baptiste" =3D=3D Jean-Baptiste Cazier <jc...@de...> wri=
tes:

    Jean-Baptiste> S=E6ll !  I would like to be able to move my
    Jean-Baptiste> Figure.legend Because the optimal position of the
    Jean-Baptiste> legend on my figure is not always the same, I added
    Jean-Baptiste> a button to the navigation toolbar to give the suer
    Jean-Baptiste> a chance to choose the position of the legend I
    Jean-Baptiste> knwo that I can get a handle on my first legend
    Jean-Baptiste> drawing, but how can I just modify its location ?
    Jean-Baptiste> Is there a move_location method for the
    Jean-Baptiste> Figure.legend ?

There is currently no "move to" location, but there is an offset
method where you can supply a deltxa, deltay in relative sizes, in
your case fractions of the figure width and height.   So if you wanted
to move the legend 5% of the figure width to the right and 10% of the
figure height up, you can call

  leg._offset(0.05, 0.10)

The leading underscore means that this method was intended for
internal use, and may change in future releases, but you can try it
and see if it works for you.  If it does, I can probably make it
a public method for the next release.

As always you'll need to call canvas.draw after setting the new legend
location.
=20

JDH

S=E6ll !

I would like to be able to move my Figure.legend
Because the optimal position of the legend on my figure is not always the s=
ame, I added a button to the navigation toolbar to give the suer a chance t=
o choose the position of the legend
I knwo that I can get a handle on my first legend drawing, but how can I ju=
st modify its location ?
Is there a move_location method for the Figure.legend ?


Thanks

Jean-Baptiste

--=20
-----------------------------
Jea...@de...

Department of Statistics
deCODE genetics     Sturlugata,8
570 2993          101 Reykjav=EDk

Z-order is something I hadn't given thought to before John started this thread, but I think that since change may be in the wind, the errorbar z-order is probably wrong at the moment and should probably be changed so that the plot-line is in front of the errorbars. What do others think?

Gary

----- Original Message -----
From: John Hunter <jdh...@ac...>
Date: Wed, 12 May 2004 10:57:16 -0500
To: mat...@li...
Subject: [Matplotlib-users] who's in front

> 
> Earlier the subject of how to draw ticks and grids for image data was
> brought up.  The problem was that images obscure the ticks.  This can
> be fixed by drawing the ticks after the rest of the axes.  The
> question I am considering now is whether the grids should also be
> drawn last.  This applies to image and non image axes.  If, on a line
> plot or bar plot, should the grids be in front of or behind your data?
> 
> Another possibility would be to put the grids in front with a semi
> transparent alpha, so you could see your data through them.  Of
> course, on backends like postscript which don't have an alpha channel,
> this wouldn't work.
> 
> Any preferences?
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Hi,

i am trying to get matplotlib working. This seems to be as of now the best
that i have found but i cant install it at work. We have a RH9 system, and
matplotlib required a lot of development packages and updates. After all
the installation (which it says is successful), when i try to import
matplotlib or run the examples:

(i am using ipython so i can do run xyz.py)

> run bar_stacked.py

----> RuntimeError: Could not find the matplotlib data files

the path was not working so i manually set the path at the __init__.py
file to path = '/home/karthik/usr/share/matplotlib'

Then when i try it again

> run bar_stacked.py

----> from matplotlib import rcParams

ImportError: cannot import name rcParams

On the third attempt:

> run bar_stacked.py

----> ind = arange(N)
NameError: name 'arange' is not defined

the numerix package was numarray, and while installation the _image.cpp
file had problems with "arrayobject.h", it couldnt find it, i manually set
the path as
#include "/home/karthik/usr/include/python/numarray/arrayobject.h"

How do i proceed now?

With warm regards
karthik


-----------------------------------------------------------------------
Karthikesh Raju,		    email: ka...@ja...
Researcher,			    http://www.cis.hut.fi/karthik
Helsinki University of Technology,  Tel: +358-9-451 5389
Laboratory of Comp. & Info. Sc.,    Fax: +358-9-451 3277
Department of Computer Sc.,
P.O Box 5400, FIN 02015 HUT,
Espoo, FINLAND
-----------------------------------------------------------------------

Perry Greenfield wrote:
> John Hunter wrote:
> 
>>And what's your opinion about ticks for lines and polys: front or
>>back?
>>
> 
> I guess I would say this is a, ahem, borderline issue [sorry].
> But I probably would prefer ticks on top since they are on the
> border and usually small (unlike grid lines). I'd be interested
> to hear if people think otherwise. (The principle I'm applying ist
> that I would be able to see grids around data since they span
> everything, but that isn't necessarily true for ticks, and 
> obscuring a tick (especially possible with a lot of noisy data
> points) would be more annoying).

My inclination would be to treat ticks the same as grid lines for graphs, hence 
in back.  My feeling is that the data should not be obscured.  I occasionally 
run across this problem in PS plots and can usually depend on using the tick 
mark on the opposite side (i.e. the top or right) for measurement.

Of course, if the tick marks are on the outside of the graph, then this isn't a 
problem.

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

Perry Greenfield wrote:

>John Hunter wrote:
>
>  
>
>>Earlier the subject of how to draw ticks and grids for image data was
>>brought up.  The problem was that images obscure the ticks.  This can
>>be fixed by drawing the ticks after the rest of the axes.  The
>>question I am considering now is whether the grids should also be
>>drawn last.  This applies to image and non image axes.  If, on a line
>>plot or bar plot, should the grids be in front of or behind your data?
>>
>>Another possibility would be to put the grids in front with a semi
>>transparent alpha, so you could see your data through them.  Of
>>course, on backends like postscript which don't have an alpha channel,
>>this wouldn't work.
>>
>>Any preferences?
>>
>>    
>>
>For images the grid should definitely be drawn after the image
>is displayed (I'm having trouble thinking of anything that
>shouldn't be done over an image). For line plots, grids
>should go behind the data imho.
>  
>
I agree.

I have little preference about tics for lines, but perhaps like the grid 
- behind might be better.

Peter

John Hunter wrote:
> 
> And what's your opinion about ticks for lines and polys: front or
> back?
> 
I guess I would say this is a, ahem, borderline issue [sorry].
But I probably would prefer ticks on top since they are on the
border and usually small (unlike grid lines). I'd be interested
to hear if people think otherwise. (The principle I'm applying ist
that I would be able to see grids around data since they span
everything, but that isn't necessarily true for ticks, and 
obscuring a tick (especially possible with a lot of noisy data
points) would be more annoying).

Perry

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
    Perry> For images the grid should definitely be drawn after the
    Perry> image is displayed (I'm having trouble thinking of anything
    Perry> that shouldn't be done over an image). For line plots,
    Perry> grids should go behind the data imho.

And what's your opinion about ticks for lines and polys: front or
back?

JDH

John Hunter wrote:

> Earlier the subject of how to draw ticks and grids for image data was
> brought up.  The problem was that images obscure the ticks.  This can
> be fixed by drawing the ticks after the rest of the axes.  The
> question I am considering now is whether the grids should also be
> drawn last.  This applies to image and non image axes.  If, on a line
> plot or bar plot, should the grids be in front of or behind your data?
> 
> Another possibility would be to put the grids in front with a semi
> transparent alpha, so you could see your data through them.  Of
> course, on backends like postscript which don't have an alpha channel,
> this wouldn't work.
> 
> Any preferences?
> 
For images the grid should definitely be drawn after the image
is displayed (I'm having trouble thinking of anything that
shouldn't be done over an image). For line plots, grids
should go behind the data imho.

Perry

Earlier the subject of how to draw ticks and grids for image data was
brought up.  The problem was that images obscure the ticks.  This can
be fixed by drawing the ticks after the rest of the axes.  The
question I am considering now is whether the grids should also be
drawn last.  This applies to image and non image axes.  If, on a line
plot or bar plot, should the grids be in front of or behind your data?

Another possibility would be to put the grids in front with a semi
transparent alpha, so you could see your data through them.  Of
course, on backends like postscript which don't have an alpha channel,
this wouldn't work.

Any preferences?

JDH

>>>>> "Jim" == Jim Benson <jb...@se...> writes:
    Jim> a.legend(('aLabel'), 'upper center')

    Jim>             a.set_xlim(xRangeList) a.set_ylim(yRangeList)

    Jim>         # End of: for yList in yLists:
        
    Jim>         self.toolbar.update()

    Jim> The aLabel gets printed like: a L a b e l

That's because ('a label') is a string and not a tuple.  I should test
for this and raise, since it gets me too sometimes. The legend code is
iterating over the string effectively making each character a
separate legend entry.  You need ('a label',); note the comma makes it
a length 1 tuple of strings.


    Jim> I would really like to specify that the legend appear off of
    Jim> the plot...say to the left of the y axis tick marks...any
    Jim> hints here?

fig.legend works just like ax.legend, where fig is a Figure instance.
(figlegend in the matlab interface).  The placement commands are the
same, eg 'upper right', but this is in the upper right of the figure
rather than the axes.  You can add as many legends as you want this
way.  You have to pass it the lines or rectangles (also as a tuple)
that you want to make the legend for, because unlike axes legends, it
can't use introspection to guess which lines you want to make a legend
for - well, it could but it doesn't.

Note if you want to resize the axes so that is doesn't overlap the
legend you create, you may want to use Axes rather than subplot, in
which you can supply an explicit left, bottom, width, height tuple for
the axes dimensions, as in axes_demo.py.


JDH

Hi,

  This evening i played a bit with trying to add 
a legend to a plot widget that i have.
Here is the relevant test code snippet 
(based on the example: embedding_in_wx.py)

class PlotFigure(wxFrame):

    def plotMultiYData(self, xList, yLists, xRangeList, yRangeList):

        a = self.figmgr.add_subplot(111)
        
        x = self.__listToFloatArray(xList)

        for yList in yLists:

            y = self.__listToFloatArray(yList)

            a.plot(x,y, marker='o', markersize=4.0)
            a.legend(('aLabel'), 'upper center')

            a.set_xlim(xRangeList)
            a.set_ylim(yRangeList)

        # End of: for yList in yLists:
        
        self.toolbar.update()

The aLabel gets printed like:
     a
     L
     a
     b
     e
     l

and the first plot associates with the first 'a'
the second with the 'L' etc. Clearly at the moment
i'm only trying to apply a legend to the first plot.
Once i get that sorted out i would expect
('legend1', legend2') to work for 2 plots etc.

Anyone want to give me a hint as to what i'm doing wrong here?

I would really like to specify that the legend appear 
off of the plot...say to the left of the y axis tick 
marks...any hints here?

Thanks,

Jim

Perry Greenfield wrote:

>I'm wondering about whether the convention that matplotlib 
>adopts for image display is the the standard expected for
>science and engineering. When an image is displayed,
>index 0,0 appears at the top left. While that is the standard
>conventions for most computer graphics, it isn't in astronomy 
>(we usually expect it to be bottom left). Are there others
>that expect the way it behaves now?
>  
>
OpenGL also has 0,0 at the lower left, so that's what I've come to 
expect.  In fact, I'm not sure that an upper left origin "is the 
standard convention for most computer graphics."  I certainly vote for 
positive values increasing upward and rightward...

>While I'm at it, does anyone else need to display images as
>raw pixel dumps (every pixel in the image matches the
>display pixel) without trying to match axes? This is very
>common in astronomy (I understand that this is effectively
>not really using matplotlib to do graphics, but rather as
>a simple image display window, but this is something
>astronomers are used to doing for data inspection, and
>it would be nice to be able to do this within matplotlib as it
>is for IDL). My guess is that a raw image display function
>would be figure-oriented (as opposed to axes-oriented as it
>is for the current one).
>  
>
It sounds like a fine idea, but I'm personally in no need of this 
ability right now.

I'm wondering about whether the convention that matplotlib 
adopts for image display is the the standard expected for
science and engineering. When an image is displayed,
index 0,0 appears at the top left. While that is the standard
conventions for most computer graphics, it isn't in astronomy 
(we usually expect it to be bottom left). Are there others
that expect the way it behaves now? 

While I'm at it, does anyone else need to display images as
raw pixel dumps (every pixel in the image matches the
display pixel) without trying to match axes? This is very
common in astronomy (I understand that this is effectively
not really using matplotlib to do graphics, but rather as
a simple image display window, but this is something
astronomers are used to doing for data inspection, and
it would be nice to be able to do this within matplotlib as it
is for IDL). My guess is that a raw image display function
would be figure-oriented (as opposed to axes-oriented as it
is for the current one).

Perry

>>>>> "Kuzminski," == Kuzminski, Stefan R <SKu...@fa...> writes:

    Kuzminski> I got it to go on Solaris, but I keep hitting a seg
    Kuzminski> fault on the creation of the FT2Font object around
    Kuzminski> line 261 in backend_agg.py.  It ran when I put a print
    Kuzminski> in before the creation of the FT2Font object.  That's
    Kuzminski> right.  Something spooky like that means to me that
    Kuzminski> there is a bug in ft2font.c where some variable is not
    Kuzminski> initialized correctly and the extra print leaves the
    Kuzminski> right patch of initialized memory so it runs.  Only
    Kuzminski> way to really nail something like that is with a
    Kuzminski> Purify or Valgrind like tool.

Thanks for the additional information.  This one is a little harder
for me to debug since I can't replicate it.  I recently rewrote the
agg backend using cxx which is really nice, and a hell of a lot easier
than doing the extension code by hand.  I may do the same for
ft2font.

In the meantime, if you have some free time to either run a debugger
or just insert some sporadic prints in newFT2FontObject that would
help narrow where the segfault is occurring.

Something like


static FT2FontObject *
newFT2FontObject(PyObject *args)
{
  int error;
  char* facefile;
  printf("initializing\n");
  if (! _initLib) { 
    error = FT_Init_FreeType( &_ft2Library ); //initialize library 

    if (error) {
      PyErr_SetString(PyExc_RuntimeError, 
		      "Could not find initialize the freetype2 library");
      return NULL;
    }
    _initLib = 1;

  }

  printf("parsing args\n");  
  if (!PyArg_ParseTuple(args, "s:FT2Font", &facefile))
    return NULL;

  
  printf("creating object\n");  
  FT2FontObject *self;
  self = PyObject_New(FT2FontObject, &FT2Font_Type);
  self->image.buffer = NULL;
  self->text = NULL;
  self->num_glyphs = 0;
  FT2Font_clear(self);

  printf("new face\n");  
  error = FT_New_Face( _ft2Library, facefile, 0, &self->face );
  if (error == FT_Err_Unknown_File_Format ) {
    
    set_error(PyExc_RuntimeError,
	      "Could not load facefile %s; Unknown_File_Format", facefile);
    return NULL;
  }
  else if (error == FT_Err_Cannot_Open_Resource) {
    
    set_error(PyExc_RuntimeError,
	      "Could not open facefile %s; Cannot_Open_Resource", facefile);
    return NULL;
  }
  else if (error == FT_Err_Invalid_File_Format) {
    
    set_error(PyExc_RuntimeError,
	      "Could not open facefile %s; Invalid_File_Format", facefile);
    return NULL;
  }
  else if (error) {
    set_error(PyExc_RuntimeError,
	      "Could not load face file %s; freetype error code %d", facefile, error);
    return NULL;

  }
  printf("setting size\n");  
  // set a default fontsize 12 pt at 72dpi
  error = FT_Set_Char_Size( self->face, 12 * 64, 0, 72, 72 );
  if (error) {
    PyErr_SetString(PyExc_RuntimeError, 
		    "Could not set the fontsize");
    return NULL;
  }
  

  printf("initing dict\n");  
  if (self == NULL)
    return NULL;
  self->x_attr = NULL;

  printf("getting ps name\n");    
  // set some face props as attributes
  const char*  ps_name;
  ps_name = FT_Get_Postscript_Name( self->face );
  if ( ps_name == NULL )
    ps_name = "UNAVAILABLE";

  printf("setting attributes\n");        
  SETATTR(self, FT2Font_setattr, "postscript_name", PyString_FromString, ps_name);
  SETATTR(self, FT2Font_setattr, "num_faces",       PyInt_FromLong,      self->face->num_faces);
  SETATTR(self, FT2Font_setattr, "family_name",     PyString_FromString, self->face->family_name);
  SETATTR(self, FT2Font_setattr, "style_name",      PyString_FromString, self->face->style_name);
  SETATTR(self, FT2Font_setattr, "face_flags",      PyInt_FromLong,      self->face->face_flags);
  SETATTR(self, FT2Font_setattr, "style_flags",     PyInt_FromLong,      self->face->style_flags);
  SETATTR(self, FT2Font_setattr, "num_glyphs",      PyInt_FromLong,      self->face->num_glyphs);
  SETATTR(self, FT2Font_setattr, "num_fixed_sizes", PyInt_FromLong,      self->face->num_fixed_sizes);
  SETATTR(self, FT2Font_setattr, "num_charmaps",    PyInt_FromLong,      self->face->num_charmaps);


  printf("checking scalable\n");        
  int scalable;
  scalable = FT_IS_SCALABLE( self->face );
  SETATTR(self, FT2Font_setattr, "scalable", PyInt_FromLong, scalable);

  if (scalable) {
    SETATTR(self, FT2Font_setattr, "units_per_EM", PyInt_FromLong, self->face->units_per_EM);

  printf("building bbox\n");        
    PyObject *bbox = Py_BuildValue
      ("(llll)", 
       self->face->bbox.xMin, self->face->bbox.yMin, 
       self->face->bbox.xMax, self->face->bbox.yMax );
    SETATTR_PYOBJ(self, FT2Font_setattr, "bbox",  bbox);
    SETATTR(self, FT2Font_setattr, "ascender",            PyInt_FromLong, self->face->ascender);
    SETATTR(self, FT2Font_setattr, "descender",           PyInt_FromLong, self->face->descender);
    SETATTR(self, FT2Font_setattr, "height",              PyInt_FromLong, self->face->height);
    SETATTR(self, FT2Font_setattr, "max_advance_width",   PyInt_FromLong, self->face->max_advance_width);
    SETATTR(self, FT2Font_setattr, "max_advance_height",  PyInt_FromLong, self->face->max_advance_height);
    SETATTR(self, FT2Font_setattr, "underline_position",  PyInt_FromLong, self->face->underline_position);
    SETATTR(self, FT2Font_setattr, "underline_thickness", PyInt_FromLong, self->face->underline_thickness);
    
  }
  printf("made it!\n");        
  return self;
}

small bug..  line 237 in text.py, needs a str() around the 'legal' tuple
in the exception.

=20

bigger potential bug..

=20

I got it to go on Solaris, but I keep hitting a seg fault on the
creation of the FT2Font object around line 261 in backend_agg.py.  It
ran when I put a print in before the creation of the FT2Font object.
That's right.  Something spooky like that means to me that there is a
bug in ft2font.c where some variable is not initialized correctly and
the extra print leaves the right patch of initialized memory so it runs.
Only way to really nail something like that is with a Purify or Valgrind
like tool.=20

=20

S

I installed freetype-2.1.8, libpng-1.2.5 and zlib.  I can compile and
install fine, but I get a segmentation fault when I try to run a simple
example.  I tracked it down a bit and it's happening on import when
creating the fonts, in font_manager.py line 384..

               font =3D ft2font.FT2Font(fname)

It processes timesi.ttf ok, but any of the other fonts in
share/matplotlib cause a segmentation fault.  I don't have a
.matplotlibrc, is there something in there that I should have set?

thanks,
S=20

-----Original Message-----
From: John Hunter [mailto:jdh...@ni...]=20
Sent: Friday, May 07, 2004 6:42 AM
To: Kuzminski, Stefan R
Cc: mat...@li...
Subject: Re: [Matplotlib-users] solaris compilation

>>>>> "Kuzminski," =3D=3D Kuzminski, Stefan R <SKu...@fa...>
writes:

    Kuzminski> I'm trying to install 0.53.1 on solaris and am getting
    Kuzminski> this compile error.  Looks like it needs the file
    Kuzminski> ft2build.h, but I don't see it anywhere..

You need to make sure a recent version of freetype (we recommend 2.1.7
or later) is installed on your system (and zlib and png for that
matter).  If it is installed, you need to make sure you add the base
install dir to your basedir list in setupext.py.  Eg if it is
installed to /some/dir/freetype2 you need to add /some/dir to
basedir['sunos5'] in that file; (I'm assuming sys.platform returns
'sunos5').

Where do the GNU tools for solaris go by default; something like
/freeware?  I'm referring to the collection from
http://wwws.sun.com/software/solaris/freeware/download.html. I can't
recall but whatever the base install dir is, we should add this dir to
the default sunos5 basedir list.

Finally, please submit back the required changes you made to
seteupext.py (if any) so we can fix this.

Hell, you got gdmodule compiled on win32; matplotlib on solaris should
be a cake walk :-)

Thanks,
John Hunter

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> On Sat, 2004-05-08 at 20:47, John Hunter wrote:
    >> ax = subplot(111)
    >> 
    >> #your plot here for tick in ax.xaxis.get_minor_ticks():
    >> tick.label1.set_y(-0.1)
    >> 

    Steve> Thanks for the advice, but I tried this and the tick labels
    Steve> disappeared completely. I then tried tick.label1.set_y(0.0)
    Steve> which I would expect to leave the labels at the same place,
    Steve> but the labels disappeared also.

Doh!  There's a reason I try to never post untested code.  I wrongly
assumed the location were in relative axes coords but they are not.  I
use reference values (matplotlib.transforms.RRef - think mutable
floats or a c pointer to a float) in some instances to specify
locations.  I define binary operations on these so I can specify
locations like 3 points to the left of the x axis minimum, and have
these locations update automagically under figure resizes and dpi
changes - see http://matplotlib.sf.net/matplotlib.transforms.html.

This is what I do for x tick label locations - they are specified in
number of points below the minimum of the axes bounding rectangle.
Here is how to properly change that location (tested this time!)

from matplotlib.transforms import RRef
from matplotlib.matlab import *
ax = subplot(111)

plot([1,2,3])

points = 20
for tick in ax.xaxis.get_major_ticks():
    y = ax.bbox.y.get_refmin() - ax.dpi*RRef(points/72.0)
    tick.label1.set_y(y)
show()

ax.bbox.y.get_refmin(), ax.dpi and RRef(points/72.0) are all RRefs, as
is y.  

A word of warning.  I'm totally rewriting the transform architecture
from the ground up as we speak, so whatever you do here is likely to
change with the next release.  Of course there will be an analogous
way to do it and if you remind me I'll let you know what it is - or
you can check the code in XAxis.py to see how it specifies tick
locations.  In any case there will be release notes detailing the
changes.

    Steve> I had a look at matplotlib.dates and found what looks like
    Steve> a problem/limitation.  This is my understanding, which may
    Steve> be completely wrong.  The python 'time' module (and
    Steve> epochtime) limits years to 1970-2038.  The 'egenix' and
    Steve> python 'datetime' modules support a much larger range of
    Steve> years ('datetime supports years from 1-9999).

    Steve> matplotlib.dates converter classes supports 'epochtime',
    Steve> 'datetime' and 'egenix' date formats. However, internally
    Steve> it uses epochtime for all dates and so limits all years to
    Steve> the range 1970-2038, even though 'datetime' and 'egeinx'
    Steve> themselves support much more that this.

    Steve> I think there is a lot of data available before 1970 that
    Steve> people might like to plot. Taking stock data as an example,
    Steve> Yahoo has data going back to 1962 for some companies.

Absolutely right.  It ought to use datetime for everything if
python2.3 is available.  It's not a top priority for me right now
since I'm up to my elbows with the new transformation code, optimized
line and patch collection drawing, porting mathtext to PS and handling
newline separated strings, but I agree it is an important fix; I added
it to the priorities list.

JDH

On Sat, 2004-05-08 at 20:47, John Hunter wrote:
> ax = subplot(111)
> 
> #your plot here
> for tick in ax.xaxis.get_minor_ticks():
>     tick.label1.set_y(-0.1)
> 

Thanks for the advice, but I tried this and the tick labels disappeared
completely. I then tried
	tick.label1.set_y(0.0)
which I would expect to leave the labels at the same place, but the
labels disappeared also.


I had a look at matplotlib.dates and found what looks like a
problem/limitation.
This is my understanding, which may be completely wrong.
The python 'time' module (and epochtime) limits years to 1970-2038.
The 'egenix' and python 'datetime' modules support a much larger range
of years ('datetime supports years from 1-9999).

matplotlib.dates converter classes supports 'epochtime', 'datetime' and
'egenix' date formats. However, internally it uses epochtime for all
dates and so limits all years to the range 1970-2038, even though
'datetime' and 'egeinx' themselves support much more that this.

I think there is a lot of data available before 1970 that people might
like to plot. Taking stock data as an example, Yahoo has data going back
to 1962 for some companies.

Regards
Steve

>>>>> "Al" == Al Schapira <a.d...@wo...> writes:

    Al> One way to avoid having the minor ticklabels collide with the
    Al> major ones is to put them on separate lines as illustrated in
    Al> the original post.  Supporting multi-line text (embedded '\n's
    Al> in ticklabels) would permit this.  All you would have to do is
    Al> begin the minor ticklabels with one or more '\n's.  How is
    Al> this coming along?

I've laid the groundwork for it, by factoring the text instances out
of the backends.  Now the backends just are asked to draw plain old
strings at a given location, size, rotation etc.  Before they were
asked to draw matplotlib text instances, which means if the string
contained new lines and the backend couldn't handle them, you were
hosed.  Under the new framework, the Text class will newline split the
strings, and layout the separate strings.  This will buy you newline
separated strings on all backends with rotation for those that support
arbitrary rotation (gd, agg, ps)

So the short answer is: it's close.  Depending on how the other things
that I'm working on go, maybe next week, maybe a little later.

JDH

One way to avoid having the minor ticklabels collide with the major ones
is to put them on separate lines as illustrated in the original post.
Supporting multi-line text (embedded '\n's in ticklabels) would permit
this.  All you would have to do is begin the minor ticklabels with one
or more '\n's.  How is this coming along?

	-Al

On Sat, 2004-05-08 at 08:47, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> John, I've just started using the new tick locating,
>     Steve> formatting and date plotting and noticed if you want to
>     Steve> show day of month, month and year its quite easy to end up
>     Steve> with major and minor tick labels overwriting each other.
>     Steve> Is there a way to draw the major tick label underneath the
>     Steve> minor tick label so they're not competing for the same
>     Steve> space?
> 
> There are a few ways to go here.  First of all, with no change to the
> code, you can set the tick positions of the minor tick labels as
> follow.  I'm just winging this code so apologies if there is a minor
> mistake somewhere
> 
> ax = subplot(111)
> 
> #your plot here
> for tick in ax.xaxis.get_minor_ticks():
>     tick.label1.set_y(-0.1)
> 
> Note that the y coord of the x tick label is in axes coordinates,
> where 0 is the bottom and 1 is the top of the axes, so -0.1 is 10%
> below the bottom of the axes.  label1 and label2 are the bottom and
> top label text.Text instances (this is a recent feature to support
> left/right labeling or top/bottom tick labeling) so you can call any
> of the Text methods on them.
> 
> Note this code only affects the current ticks, so if you were doing
> interactive navigation and zoomed out, thereby creating new minor
> ticks, the new minor ticks would have their default locations (but I
> can fix this fairly easily by updating the copy properties function
> that transfers old tick properties to new ones when ticks are created
> during interaction).
> 
> There is an additional consideration.  Currently, the tick drawing
> code will skip a minor tick if a major tick has already been drawn at
> that exact location.  In axis.py there is a line in the axis drawing
> code that reads
> 
>             if seen.has_key(loc): continue
> 
> where seen is a dict that has a key if the tick location loc was drawn
> by the major tick drawing code.  We could add an attribute, something
> like forceDraw, to the tick and modify this code so that you could do
> 
>             if not tick.forceDraw and seen.has_key(loc): continue
> 
> and in your code
> 
> for tick in ax.xaxis.get_minor_ticks():
>     tick.forceDraw = True
>     tick.label1.set_y(-0.1)
> 
> Let me know how this works for you.
> 
> We could automate this a bit if you think it's worthwhile, eg by
> setting a 'draw under' flag for the minor ticks, getting the bounding
> boxes of the major ticks in the axis drawing code, and setting the
> offsets automagically.  This would have the dual advantages of working
> in the presence of changes in font size, interaction, etc.  The
> question is whether it's sufficiently common to justify the extra work
> or if the manual control approach above suffices.  If you want to add
> this feature, I can get you some additional pointers to code showing
> how to get the bounding box of all the major tick labels and using
> this to control the positioning of the minor tick labels.
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users