font problems after compiling 0.80 from source on os x

Community matplotlib-users
1

I believe I have got all the prerequisites, but it might not be so...

old Powerbook, 400 MHz, 10.3.9.

zlib, libpng, tk_inter, freetype 2.1.9, wx-2.6-mac-unicode, standard Apple Python 2.3, updated to MacPython, Numeric.

matplotlib compiled & installed apparently fine. No warnings that I could see.

Fairly drastic problem occurs when I do
import from pylab *
in the python shell.

1. get stream of warnings about type 1 fonts...
e.g.
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py:465: UserWarning: Could not open font file /Users/agn/Library/Fonts/Euclid Math Two
   warnings.warn("Could not open font file %s"%fpath)
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py:465: UserWarning: Could not open font file /Library/Fonts/EucliSymIta
  Think I can understand why this might be, as neither TT or X11.

One only of the .dfonts in /System/Library/Fonts fails--
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py:465: UserWarning: Could not open font file /System/Library/Fonts/LastResort.dfont
   warnings.warn("Could not open font file %s"%fpath)
  -- no warnings from rest of .dfonts.

2. More seriously, loading from pylab fails with FontManager error:

raceback (most recent call last):
   File "/usr/local/bin/ipython", line 28, in ?
     IPython.Shell.start().mainloop()
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/IPython/Shell.py", line 809, in start
     return shell()
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/IPython/Shell.py", line 740, in __init__
     IPShell.__init__(self,argv,user_ns,debug,shell_class=MatplotlibShell)
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/IPython/Shell.py", line 54, in __init__
     shell_class=shell_class)
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/IPython/ipmaker.py", line 85, in make_IPython
     IP = shell_class('__IP',user_ns=user_ns,**kw)
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/IPython/Shell.py", line 493, in __init__
     user_ns,b2 = self._matplotlib_config(name)
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/IPython/Shell.py", line 373, in _matplotlib_config
     from matplotlib import backends
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/backends/__init__.py", line 19, in ?
     globals(),locals(),[backend_name])
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/backends/backend_tkagg.py", line 9, in ?
     from backend_agg import FigureCanvasAgg
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py", line 82, in ?
     from matplotlib.figure import Figure
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/figure.py", line 3, in ?
     from axes import Axes, Subplot, PolarSubplot, PolarAxes
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/axes.py", line 12, in ?
     from axis import XAxis, YAxis
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/axis.py", line 20, in ?
     from font_manager import FontProperties
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 991, in ?
     fontManager = FontManager()
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 835, in __init__
     rebuild()
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 828, in rebuild
     self.ttfdict = createFontDict(self.ttffiles)
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 467, in createFontDict
     prop = ttfFontProperty(font)
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 347, in ttfFontProperty
     size = str(float(font.get_fontsize()))
AttributeError: get_fontsize

Anybody have any idea of what I have missed doing?

Regards, George Nurser.

2

I believe I have got all the prerequisites, but it might not be so...

old Powerbook, 400 MHz, 10.3.9.

zlib, libpng, tk_inter, freetype 2.1.9, wx-2.6-mac-unicode, standard
Apple Python 2.3, updated to MacPython, Numeric.

matplotlib compiled & installed apparently fine. No warnings that I
could see.

Fairly drastic problem occurs when I do
import from pylab *
in the python shell.

[...]

Anybody have any idea of what I have missed doing?

I just upgraded wxPython a couple days ago, and got error messages about not
finding wxpython 2.4 or 2.5. Can anyone say whether the wx backend and
IPython are compatible with the new wxpython release?

···

On Thursday 05 May 2005 6:55 pm, George Nurser wrote:

--
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd55@...163...

3

Darren Dale wrote:

I just upgraded wxPython a couple days ago, and got error messages about not finding wxpython 2.4 or 2.5. Can anyone say whether the wx backend and IPython are compatible with the new wxpython release?

On the ipython side, no idea. I don't use wx myself much, so I can't say (and I can't upgrade right now to test, sorry).

f

4

Darren,

I just upgraded wxPython a couple days ago, and got error
messages about not finding wxpython 2.4 or 2.5. Can anyone say
whether the wx backend and IPython are compatible with the new
wxpython release?

The wx backend from matplotlib 0.80 works fine for me with
wxPython 2.6.0.0 on OS X 10.3.9.

I also get messages about not finding wxpython 2.4 or 2.5 from
Ipython, and on Mac OS X also have Ipython hang when started
with 'ipython -wthread -pylab' or 'ipython -pylab', probably
because it's using 'python' not 'pythonw'. I haven't tracked it
down beyond that.

--Matt

5

Matt Newville wrote:

Darren,

I just upgraded wxPython a couple days ago, and got error
messages about not finding wxpython 2.4 or 2.5. Can anyone say
whether the wx backend and IPython are compatible with the new
wxpython release?

The wx backend from matplotlib 0.80 works fine for me with
wxPython 2.6.0.0 on OS X 10.3.9.

I also get messages about not finding wxpython 2.4 or 2.5 from
Ipython, and on Mac OS X also have Ipython hang when started
with 'ipython -wthread -pylab' or 'ipython -pylab', probably
because it's using 'python' not 'pythonw'. I haven't tracked it
down beyond that.

Could you try to change in IPython/Shell.py, the line (around line 555):

     if ver[:3] == '2.5':
         import wx

to

     if ver[:3] >= '2.5':
         import wx

and let me know if it works again? In that case, I'll make that change before the bugfix .14 release.

Cheers,

f

6

Fernando,

Thank you, this solves it.

···

On Friday 06 May 2005 12:19 am, Fernando Perez wrote:

Matt Newville wrote:
> Darren,
>
>>I just upgraded wxPython a couple days ago, and got error
>>messages about not finding wxpython 2.4 or 2.5. Can anyone say
>>whether the wx backend and IPython are compatible with the new
>>wxpython release?
>
> The wx backend from matplotlib 0.80 works fine for me with
> wxPython 2.6.0.0 on OS X 10.3.9.
>
> I also get messages about not finding wxpython 2.4 or 2.5 from
> Ipython, and on Mac OS X also have Ipython hang when started
> with 'ipython -wthread -pylab' or 'ipython -pylab', probably
> because it's using 'python' not 'pythonw'. I haven't tracked it
> down beyond that.

Could you try to change in IPython/Shell.py, the line (around line 555):

     if ver[:3] == '2.5':
         import wx

to

     if ver[:3] >= '2.5':
         import wx

and let me know if it works again? In that case, I'll make that change
before the bugfix .14 release.

--
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd55@...163...

7

Fernando, Darren,

For me, on Mac OS X changing IPython/Shell.py to
     if ver[:3] >= '2.5':

does suppress the warning about the version of wx. But 'ipython
-pylab' still hangs on startup with a message that the program
should be run with 'pythonw', not 'python'. This was from a
clean install with
~> sudo pythonw setup.py install

This installs ipython into

/System/Library/Frameworks/Python.framework/Versions/2.3/bin/ipython

which is not typically in the shells PATH.

The shebang line for the ipython script reads

#!/System/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python

Changing that to

#!/usr/bin/env pythonw

makes 'ipython -pylab' run fine.

Maybe you want to make Mac installs put ipython in /usr/bin and
point to pythonw (which is admittedly just a bash wrapper around
/System/Library/..../Python.app/Contents/MacOS/Python)??

Hope that helps,

--Matt

8

The problem I have seems more fundamental than Darren's.

Even if I start pythonw, and then do from pylab import *, I still get the warning messages about being unable to open the type 1 fonts,
System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py:465: UserWarning: Could not open font file /Users/agn/Library/Fonts/GillSanBol
   warnings.warn("Could not open font file %s"%fpath)
  etc...

and then the program crash in font_manager.py with

Traceback (most recent call last):
...............
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/axis.py", line 20, in ?
     from font_manager import FontProperties
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 991, in ?
     fontManager = FontManager()
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 835, in __init__
     rebuild()
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 828, in rebuild
     self.ttfdict = createFontDict(self.ttffiles)
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 467, in createFontDict
     prop = ttfFontProperty(font)
   File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/matplotlib/font_manager.py", line 347, in ttfFontProperty
     size = str(float(font.get_fontsize()))
AttributeError: get_fontsize

George Nurser.

9

Matt Newville wrote:

Fernando, Darren,

For me, on Mac OS X changing IPython/Shell.py to if ver[:3] >= '2.5':

does suppress the warning about the version of wx. But 'ipython
-pylab' still hangs on startup with a message that the program
should be run with 'pythonw', not 'python'. This was from a
clean install with
~> sudo pythonw setup.py install

This installs ipython into
/System/Library/Frameworks/Python.framework/Versions/2.3/bin/ipython

which is not typically in the shells PATH.

The shebang line for the ipython script reads

#!/System/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python

Changing that to

#!/usr/bin/env pythonw

makes 'ipython -pylab' run fine.

Maybe you want to make Mac installs put ipython in /usr/bin and
point to pythonw (which is admittedly just a bash wrapper around
/System/Library/..../Python.app/Contents/MacOS/Python)??

Mmh, the problem is that I don't know how to achieve this in a clean, distutils-based way. I can't go changing the shebang line by hand, since I don't know where things will end up, and as far as I know there is no way to force this kind of behavior onto distutils. Do you know any such incantation to achieve the desired result?

f

10

Fernando Perez wrote:

Matt Newville wrote:

Maybe you want to make Mac installs put ipython in /usr/bin

/usr/local/bin, please.

and
point to pythonw (which is admittedly just a bash wrapper around
/System/Library/..../Python.app/Contents/MacOS/Python)??

Mmh, the problem is that I don't know how to achieve this in a clean, distutils-based way. I can't go changing the shebang line by hand, since I don't know where things will end up, and as far as I know there is no way to force this kind of behavior onto distutils.

FWIW, with the semi-official 2.4.1 framework build, I always get an appropriate

#!/usr/bin/env /usr/local/bin/pythonw2.4

···

--
Robert Kern
rkern@...376...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

11

Robert Kern wrote:

Fernando Perez wrote:

Matt Newville wrote:

Maybe you want to make Mac installs put ipython in /usr/bin

/usr/local/bin, please.

Well, the point is that I don't want to make it go _anywhere_ in particular. I want to let distutils do what it's supposed to do, so that relocation commands (--home, --prefix) work correctly, for example, or that installs with non-standard pythons also work as they should. Which is why I'm resisting hard-coding _any_ paths in there, unless I can be convinced that the solution is a clean one across the board, addressing all these issues.

cheers,

f

12

Fernando Perez wrote:

Robert Kern wrote:

Fernando Perez wrote:

Matt Newville wrote:

Maybe you want to make Mac installs put ipython in /usr/bin

/usr/local/bin, please.

Well, the point is that I don't want to make it go _anywhere_ in particular. I want to let distutils do what it's supposed to do, so that relocation commands (--home, --prefix) work correctly, for example, or that installs with non-standard pythons also work as they should. Which is why I'm resisting hard-coding _any_ paths in there, unless I can be convinced that the solution is a clean one across the board, addressing all these issues.

Yes, that was more advice directed to Matt and anyone else actually installing on OS X than it was to you.

/usr/bin = Apple
/usr/local/bin = Anybody else

···

--
Robert Kern
rkern@...376...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

13

Robert Kern wrote:

/usr/bin = Apple
/usr/local/bin = Anybody else

For completeness' sake, that's the same rule for EVERY *nix (replacing "Apple" with whatever OS vendor your using)

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

14

Chris Barker wrote:

Robert Kern wrote:

/usr/bin = Apple
/usr/local/bin = Anybody else

For completeness' sake, that's the same rule for EVERY *nix

Maybe I'm way out of line here, but I have my systems set up so that /usr/local is, confusingly enough, centrally mounted from an NFS server, as is /opt. So things like platform-specific builds of ATLAS and the corresponding numarray/numpy/scipy builds have to go in /usr/lib. I manage all this with RPM per the handy scripts Fernando posted some time ago.

15

not to beat a dead horse, but....

Stephen Walton wrote:

Chris Barker wrote:

Robert Kern wrote:

/usr/bin = Apple
/usr/local/bin = Anybody else

For completeness' sake, that's the same rule for EVERY *nix

Maybe I'm way out of line here,

Well, I'm not going to say anyone is out of line, and of course we all have our specific needs, but I don't think you're following the standard.

but I have my systems set up so that /usr/local is, confusingly enough, centrally mounted from an NFS server,

the word "local" is weird. I don't think it has anything do do with the physical location of the filesystem in question.

My understanding is that "local" means local to your system (or network), rather than part of the OS Vendor's setup.

So things like platform-specific builds of ATLAS and the corresponding numarray/numpy/scipy builds have to go in /usr/lib.

the platform specific issue is supposed to be handles by the difference between <whatever>lib/ and <whatever>share. share is supposed to have the platform independent portions, and lib the platform dependent versions.

On heterogeneous file systems, there is supposed to be a:

/usr/local/libPlatform1
/usr/local/libPlatform2
/usr/local/libPlatform3

etc, and appropriate linking is used so that the right one is used on each platform.

Of course, now that I think about it, Python doesn't do this, putting nothing in share, while all the *.py and *.pyc files could be there.

Having said this, I just found out last night that trying to install the wxPython rpms into a python in /usr/local/ is a pain!

I never really "got" any of this until I read:

http://www.pathname.com/fhs/pub/fhs-2.3.html

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...