matplotlib-devel Mailing List for matplotlib

From: "John Hunter" <jdh...@ac...>
> >>>>> "Gary" == Gary Pajer <pa...@in...> writes:
>
> Gary> I've been using the cvs version on Mandrake, but I'll need
> Gary> to be working in WinXP and using the "embedded TkAgg"
> Gary> facility. I looked into compiling on WinXP, but that looks
> Gary> like something I'd like to avoid.
>
> Gary> Is it too much to ask for an upgrade to the Windows
> Gary> installer? Alternatively, tell me that compiling is not as
> Gary> bad as it looks, and that it actually goes rather smoothly.
>
> setupext.py points you to
> http://matplotlib.sourceforge.net/win32_static.tar.gz which is
> required. There is a README in that dir that contains detailed build
> instructions.
>
> If this proves too much of a pain, I'm sure Todd or I could provide a
> build for you in the not-too-distant future.
Yes, I've seen the pointer along with the word "masochist", and the
instructions.
If 0.53 is coming in a few weeks, I'll wait. I have enough to do fixing OSX
X11.
-thanks, gary

On Apr 12, 2004, at 6:33 PM, Daishi Harada wrote:
> On mac os x, I was going to use fink for the dependencies, and so
> I modified setupext.py as follows:
>
> (snipped diff output)
>
> Do most of the users of matplotlib on os x not use fink?
Because I often build extensions for others, I try to stay away from 
fink as much as possible in this step. Not because I don't like it, 
but because I'm reluctant to require yet another dependency. For 
someone without fink, it's probably easier to just install freetype 
than fink and freetype. Furthermore, I think it should be possible to 
compile matplotlib against the a static freetype library that gets 
installed directly with matplotlib, thus not relying on any external 
dependency.
I think I can share some of the credit/blame Mac OS X-specific build 
stuff, and I certainly didn't want to make fink a requirement.
For the fink-inclined, I think the best thing to do is to make 
fink-based matplotlib distribution which is built against the other 
fink stuff.
> The stumper
> for me is that I have been unable to build scipy/numpy for the python
> that is bundled with os x - has anyone been successful with this?
> (is this process documented anywhere?)
I have an old build that just worked from mid-2003, and I haven't had 
much success in the few times I've tried to update since then. Sorry, 
I can't be much help here. But why do you include numpy in your 
statement? There's no problem with this one. I think it's even 
included with the PackageManager stuff, and I'd be surprised if fink 
didn't include it, too.

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:
 Gary> I've been using the cvs version on Mandrake, but I'll need
 Gary> to be working in WinXP and using the "embedded TkAgg"
 Gary> facility. I looked into compiling on WinXP, but that looks
 Gary> like something I'd like to avoid.
 Gary> Is it too much to ask for an upgrade to the Windows
 Gary> installer? Alternatively, tell me that compiling is not as
 Gary> bad as it looks, and that it actually goes rather smoothly.
setupext.py points you to
http://matplotlib.sourceforge.net/win32_static.tar.gz which is
required. There is a README in that dir that contains detailed build
instructions.
If this proves too much of a pain, I'm sure Todd or I could provide a
build for you in the not-too-distant future.
Paul, do you have an estimate on when the remaining font issues (eg
the font size setting problem) will be cleared up? I think we're due
for the 0.53 release.
JDH

Hi John,
I'm trying to finish off the basic features of the font manager module, so we 
can get the next release out. I'm currently working on the fonts_demo.py 
example, which has brought to light some deficiencies in the basic 
implementation of font_manager. I would like to get your opinion on the 
following issues:
1. Currently, the relative font size strings ('smaller' and 'larger') are not 
implemented. This is because these sizes depend on the parent font size: a 
feature which is not yet implemented. Note that the font_manager only has a 
default_size, which is used by the absolute font size strings (xx-small, 
x-small, small, medium, etc.).
For this to work, it would seem that each FontProperties instance would need a 
pointer to its parent FontProperties instance. When get_size_in_points() is 
called, it would asks its parent font what size it is in order to determine its 
absolute size. If the parent is also a relative size, then the parent would ask 
its parent what size it is, etc. This would handle the case where set_size() is 
called twice using a relative font size.
What do you think of this approach? It has its problems, mainly with the 
possibility of circular references, but checks for such situations could be 
added in later. If this feature (of relative font sizes) isn't that important, 
then we could defer it until after the release.
2. The above problem has also highlighted an issue with the current font manager 
design. Currently, the fontManager class has attributes of default_size and 
default_weight that are set at initialization. If we pulled these attributes 
out of the class and replaced them with a default FontProperties instance, then 
this instance could be used as the root parent FontProperties instance. What do 
you think?
Also, since there is often only one instance of the fontManager class, this 
class could be eliminated and be replace with some initialization code and a 
findfont() function, unless you think that several instances of this class might 
be used in future versions of matplotlib.
3. Finally, Perry and I were discussing how one might use Traits in matplotlib. 
 The Traits module is being used in the Chaco plotting package for checking the 
type and value of class attributes, such as the color and size of fonts or the 
color and width of lines. (See the Chaco page at the ScyPy web site for an 
overview.) It would appear that matplotlib's rcParams has a similar purpose, 
though on a more limited scale than Traits. I think it should still be possible 
to have the matplotlibrc file for customization, and to feed this information to 
the Traits module on start up. Traits may not be able to handle the link 
attribute problem discussed above, but this can probably be implemented 
separately if necessary.
Note that all these issues are not critical and could be deferred until after 
the release.
Cheers,
Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

I've been using the cvs version on Mandrake, but I'll need to be working in
WinXP and using the "embedded TkAgg" facility. I looked into compiling on
WinXP, but that looks like something I'd like to avoid.
Is it too much to ask for an upgrade to the Windows installer?
Alternatively, tell me that compiling is not as bad as it looks, and that it
actually goes rather smoothly.
Thanks,
Gary

Great timing. I've just been struggling with the os x build, and had gotten
as far as the fontweight problem. A warning about X11 on 10.2.8: My Apple
X11 beta system was working perfectly, but I decided to fix it anyway and
upgrade to a newer Xfree86 X11. This causes some kind of compatibility
problem with freetype, and numerous headaches for me, not yet solved.
Attempts to back up to the Apple beta have failed. I have other ideas, but
that's not for this list.
On os x I use the fink python exclusively. The reason is that I use Vpython
which has been ported only to the fink python system. Until I "fixed" it,
everything worked perfectly smoothly. I use the fink scipy. I seem to
remember that someone has gotten the cvs compiled; check the scipy archives.
On Mandrake 10.0 cvs compiles smoothly.
-gary