matplotlib-devel Mailing List for matplotlib

Works great!
On Mar 30, 2004, at 3:34 PM, Paul Barrett wrote:
> Andrew Straw wrote:
>> Hi,
>> Any hints on this one before I go deeper?
>> Here are the last few lines of the traceback I get with the PS 
>> backend using the latest CVS. I get no such error with the TkAgg 
>> backend.
>> File 
>> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
>> python2.3/site-packages/matplotlib/text.py", line 77, in _draw
>> renderer.draw_text(gc, x, y, self)
>> File 
>> "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
>> python2.3/site-packages/matplotlib/backends/backend_ps.py", line 142, 
>> in draw_text
>> l,b,w,h = font.get_str_bbox(text)
>> AttributeError: get_str_bbox
>
> I've made improvements to the new font manager that should fix this 
> problem. They should now be in CVS. Please give it a test.
>
> -- Paul

Andrew Straw wrote:
> Hi,
> 
> Any hints on this one before I go deeper?
> 
> Here are the last few lines of the traceback I get with the PS backend 
> using the latest CVS. I get no such error with the TkAgg backend.
> 
> File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/site-packages/matplotlib/text.py", line 77, in _draw
> renderer.draw_text(gc, x, y, self)
> File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/site-packages/matplotlib/backends/backend_ps.py", line 142, 
> in draw_text
> l,b,w,h = font.get_str_bbox(text)
> AttributeError: get_str_bbox
I've made improvements to the new font manager that should fix this problem. 
They should now be in CVS. Please give it a test.
 -- 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 used:
"C-x v a" from emacs with some success in the past.
Of course this is no help at all if you're not using emacs.
>From the emacs help:
C-x v a runs the command vc-update-change-log
 which is an interactive compiled Lisp function in `vc'.
(vc-update-change-log &rest ARGS)
 
Find change log file and add entries from recent version control logs.
Normally, find log entries for all registered files in the default
directory.
 
With prefix arg of C-u, only find log entries for the current buffer's
file.
 
With any numeric prefix arg, find log entries for all currently visited
files that are under version control. This puts all the entries in the
log for the default directory, which may not be appropriate.
 
>From a program, any ARGS are assumed to be filenames for which
log entries should be gathered.
John
On Mon, 2004年03月29日 at 15:56, John Hunter wrote:
> Steve Chaplin rightly pointed out on matplotlib-users that the
> CHANGELOG is not being updated. So I'm going to make a renewed effort
> to do this, and I urge others who make CVS commits to do the same.
> 
> Is there a good way to automate this, so that the -m messages with
> commits automatically get added to the CHANGELOG, or some other trick?
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Steve Chaplin rightly pointed out on matplotlib-users that the
CHANGELOG is not being updated. So I'm going to make a renewed effort
to do this, and I urge others who make CVS commits to do the same.
Is there a good way to automate this, so that the -m messages with
commits automatically get added to the CHANGELOG, or some other trick?
JDH

On Sat, 2004年03月27日 at 16:22, John Hunter wrote:
> I just updated the image module to work with Numeric or numarray (now
> that matplotlib is the recommended 2D plotting package on the numarray
> homepage!). Changes in CVS.
> 
> The code uses the Numeric compatibility layer of numarray, but I am
> unsure how to best handle the decision of which one to build with.
> Whichever arrayobject.h you include (Numeric or numarray), the code
> works with either kind of array, so that is not the issue. But there
> will be those who want to build with numarray and vice-versa, so my
> question is how to best support this.
> 
> Here is what I am currently doing in setup.py:
> 
> # build the image support module - requires agg and Numeric or
> # numarray. You can build the image module with either Numeric or
> # numarray. Whichever way you build it, the code will work with
> # both Numeric or numarray arrays, but you will get the best
> # performance if you build with the type of array you use most
> #BUILD_IMAGE = 0 # no image support
> #BUILD_IMAGE = 'Numeric' # use Numeric 
> BUILD_IMAGE = 'numarray' # use numarray 
> 
> and then setting a precompiler macro in setupext.py which determines
> which header is used.
> 
> Another possibility is to look for a matplotlibrc file at build time
> and build according to the numerix setting. I think this is a nice
> solution but adds an extra later of complexity.
> 
> The additional (and perhaps most important) question is how to handle
> the win32 build vis-a-vis Numeric/numarray?
> 
> I ran some very rough profiling numbers. image_demo.py and
> image_demo_na.py are identical except the latter defines
> rcParams['numerix'] = 'numarray'. 
> 
> # build with Numeric
> hunter:> time python image_demo.py -dAgg
> 0.460u 0.070s 0:00.61 86.8% 0+0k 0+0io 5040pf+0w
> hunter:> time python image_demo_na.py -dAgg 
> 2.550u 0.080s 0:02.79 94.2% 0+0k 0+0io 5211pf+0w
> 
> # build with numarray
> hunter:> time python image_demo.py -dAgg
> 0.560u 0.140s 0:00.78 89.7% 0+0k 0+0io 5226pf+0w
> hunter:> time python image_demo_na.py -dAgg 
> 0.540u 0.120s 0:00.72 91.6% 0+0k 0+0io 5197pf+0w
> 
> The basic result is that numarray users pay a heavy performance price
> if the image module is built with Numeric, but if built with numarray
> both types of arrays perform comparably (and are performance
> competitive with the pure numeric case)
I'll try to find out why there's a difference here.
> 
> Finally, if any of you stsci folks on the list have a nice color image
> of the heavens you could produce with imshow, that would make a
> stellar screenshot for the website :-)
Perry probably has ideas about more appropriate images for this
application, but here is one of the coolest images I know of. (check it
out even if you don't want a jpeg):
http://imgsrc.hubblesite.org/hu/db/2004/07/images/m/formats/full_jpg.jpg
I believe the deepest optical image ever taken, The Deepest. It's
called the Hubble Ultra Deep Field (HUDF). Almost everything in the
picture are galaxies. The picture itself represents a very small region
of sky. Each little spec is billions of suns. 
Regards,
Todd
> 
> JDH
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Todd Miller <jm...@st...>

Hi,
Any hints on this one before I go deeper?
Here are the last few lines of the traceback I get with the PS backend 
using the latest CVS. I get no such error with the TkAgg backend.
 File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/matplotlib/text.py", line 77, in _draw
 renderer.draw_text(gc, x, y, self)
 File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/matplotlib/backends/backend_ps.py", line 142, 
in draw_text
 l,b,w,h = font.get_str_bbox(text)
AttributeError: get_str_bbox
Cheers!
Andrew

I just updated the image module to work with Numeric or numarray (now
that matplotlib is the recommended 2D plotting package on the numarray
homepage!). Changes in CVS.
The code uses the Numeric compatibility layer of numarray, but I am
unsure how to best handle the decision of which one to build with.
Whichever arrayobject.h you include (Numeric or numarray), the code
works with either kind of array, so that is not the issue. But there
will be those who want to build with numarray and vice-versa, so my
question is how to best support this.
Here is what I am currently doing in setup.py:
 # build the image support module - requires agg and Numeric or
 # numarray. You can build the image module with either Numeric or
 # numarray. Whichever way you build it, the code will work with
 # both Numeric or numarray arrays, but you will get the best
 # performance if you build with the type of array you use most
 #BUILD_IMAGE = 0 # no image support
 #BUILD_IMAGE = 'Numeric' # use Numeric 
 BUILD_IMAGE = 'numarray' # use numarray 
and then setting a precompiler macro in setupext.py which determines
which header is used.
Another possibility is to look for a matplotlibrc file at build time
and build according to the numerix setting. I think this is a nice
solution but adds an extra later of complexity.
 
The additional (and perhaps most important) question is how to handle
the win32 build vis-a-vis Numeric/numarray?
I ran some very rough profiling numbers. image_demo.py and
image_demo_na.py are identical except the latter defines
rcParams['numerix'] = 'numarray'. 
 # build with Numeric
 hunter:> time python image_demo.py -dAgg
 0.460u 0.070s 0:00.61 86.8% 0+0k 0+0io 5040pf+0w
 hunter:> time python image_demo_na.py -dAgg 
 2.550u 0.080s 0:02.79 94.2% 0+0k 0+0io 5211pf+0w
 # build with numarray
 hunter:> time python image_demo.py -dAgg
 0.560u 0.140s 0:00.78 89.7% 0+0k 0+0io 5226pf+0w
 hunter:> time python image_demo_na.py -dAgg 
 0.540u 0.120s 0:00.72 91.6% 0+0k 0+0io 5197pf+0w
The basic result is that numarray users pay a heavy performance price
if the image module is built with Numeric, but if built with numarray
both types of arrays perform comparably (and are performance
competitive with the pure numeric case)
Finally, if any of you stsci folks on the list have a nice color image
of the heavens you could produce with imshow, that would make a
stellar screenshot for the website :-)
JDH

I submitted an admin request at the sourceforge site and they kindly
removed the FontTools and ttfquery dirs from CVS. You can 
 > rm -rf FontTool* ttfquery
from your CVS tree.
CVS is finally back in good shape now; you can build from a fresh
checkout with no copying dirs around, etc....
JDH

John Hunter writes:
> Just to summarize then to make sure we're all on the same page
> 
> * family lists will be moved to matplotlibrc and so will be user
> configurable. This list can be overriden on a per-script basis
> using the method in
> http://matplotlib.sourceforge.net/faq.html#CUSTOM
> 
> * text.fontname and the other text.font* attributes in the config
> file and in matplotlib.__init__ are deprecated and should warn.
> The warning should point to the appropriate web page for
> instruction. You should use family lists rather than fontnames for
> general/global preferences. However, Text.set_fontname is
> preserved and moves the named font to the head of the list
> appropriate list using some kind of dictionary that maps names to
> families. 
> 
> This should satisfy Perry's concern about specifying a specific
> font for use in a specific place. If the font is in your system
> path and the finder algorithm is working properly this font will be
> used. There is one significant caveat to this, which is that it
> may be difficult or impossible to specify a complete dictionary
> from names to families. Or, are you reasonably certain you can
> build this on the fly Paul using font properties from FT2Font?
> 
> * font.family must be one of sans-serif, serif, monospace, cursive or
> fantasy. Anything else should raise
> 
> * Paul, I think when you do the documentation, some discussion of
> what the different families look like, what the classic examples of
> each are Eg "Courier is an example of Monospace", and a text
> screenshot along the lines of examples/alignment_test.py showing an
> example from each of the families would be very helpful to users.
> All of this could go into htdocs/fonts.html.template and/or
> tutorial.html.template.
> 
All the above sounds good to me.
Perry

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> I was thinking that we might want to use set_fontname() to
 Paul> find the font family and also add the specified font to the
 Paul> beginning of the list, so that it will all certainly be
 Paul> used. Otherwise, that font may be near the bottom of the
 Paul> list and not actually get used.
Just to summarize then to make sure we're all on the same page
 * family lists will be moved to matplotlibrc and so will be user
 configurable. This list can be overriden on a per-script basis
 using the method in
 http://matplotlib.sourceforge.net/faq.html#CUSTOM
 * text.fontname and the other text.font* attributes in the config
 file and in matplotlib.__init__ are deprecated and should warn.
 The warning should point to the appropriate web page for
 instruction. You should use family lists rather than fontnames for
 general/global preferences. However, Text.set_fontname is
 preserved and moves the named font to the head of the list
 appropriate list using some kind of dictionary that maps names to
 families. 
 This should satisfy Perry's concern about specifying a specific
 font for use in a specific place. If the font is in your system
 path and the finder algorithm is working properly this font will be
 used. There is one significant caveat to this, which is that it
 may be difficult or impossible to specify a complete dictionary
 from names to families. Or, are you reasonably certain you can
 build this on the fly Paul using font properties from FT2Font?
 * font.family must be one of sans-serif, serif, monospace, cursive or
 fantasy. Anything else should raise
 * Paul, I think when you do the documentation, some discussion of
 what the different families look like, what the classic examples of
 each are Eg "Courier is an example of Monospace", and a text
 screenshot along the lines of examples/alignment_test.py showing an
 example from each of the families would be very helpful to users.
 All of this could go into htdocs/fonts.html.template and/or
 tutorial.html.template.
Remaining question:
 * Should we add a fontfile attribute to FontProperties which defaults
 to None but if not None but can be a string like 'somefile.ttf'.
 FontManager.findfont would do something like
 if prop.fontfile is not None:
 for path in fontPaths:
 fullpath = os.path.join(path, prop.fontfile):
 if os.path.exists(fullpath): return fullpath
 raise something # somefile.ttf is not on system
 This would be for users who absolutely positively want a font from
 some ttf file and don't want to mess with the rest. If we really
 trust the mechanisms in set_fontname, the finder algorithm and the
 name->family dictionary, this shouldn't be necessary. But we may
 not fully trust all of these mechanisms and it might be nice for
 people who don't want to mess with understanding fonts, families,
 and the rest. 
Anything else?
JDH

> Todd, perhaps instead of a
> platform based typedef we need some tk version macro or something
> since he's also bumping into this on linux. May be time for a google
> :-)
I think I hacked around this in a way not likely to break: rather than
fixing the signature of PyAggImagePhoto, I changed the call to
Tcl_CreateCommand to cast PyAggImagePhoto to the right thing. I am
hopeful, but not certain, that this will work and saves us the trouble
of identifying at what version of Tcl/Tk this change occured. I think
this hack is OK because the interface being changed looks so critical
that I'm surprised they even tweaked it. I already committed it after
testing it on Linux (not really enough, I know). I'll try Windows later
today.
Regards,
Todd
> 
> Gary, it's an easy fix for you. Search src/_tkagg.cpp for this
> section of the code (around line 32)
> 
> #ifdef WIN32
> #define argv_t const char
> #else
> #define argv_t char
> #endif
> 
> and just delete it all and replace it with
> 
> #define argv_t const char
> 
> Let us know how it goes from there.
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Todd Miller <jm...@st...>

>>>>> "Gary" == Gary <pa...@in...> writes:
 Gary> I'm trying to build from cvs. It builds fine unless I try
 Gary> I'm on Mandrake 10.0 which uses gcc 3.3.2 I apologize if
 Gary> I've made some obvious omission. I'm no c wizard (that's
 Gary> why I want matplotlib!).
There are apparently 2 versions of tk headers out there, some which
use char** and some which use const char** in this function. We've
already seen platform differences on win32, apple and linux which
we're trying to typedef appropriately. Todd, perhaps instead of a
platform based typedef we need some tk version macro or something
since he's also bumping into this on linux. May be time for a google
:-)
Gary, it's an easy fix for you. Search src/_tkagg.cpp for this
section of the code (around line 32)
#ifdef WIN32
#define argv_t const char
#else
#define argv_t char
#endif
and just delete it all and replace it with
#define argv_t const char
Let us know how it goes from there.
JDH

I'm trying to build from cvs. It builds fine unless I try to build TkAgg:
------------------------
building 'matplotlib.backends._tkagg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fomit-frame-pointer -pipe 
-march=i586 -mcpu=pentiumpro -g -fPIC -I/usr/lib/tcl8.4/../../include 
-I/usr/include -Isrc -Iagg2/include -I/usr/include -I/usr/include/freetype2 
-I/usr/include/python2.3 -c src/_tkagg.cpp -o 
build/temp.linux-i686-2.3/src/_tkagg.o
src/_tkagg.cpp: In function `PyObject* _tkinit(PyObject*, PyObject*)':
src/_tkagg.cpp:134: error: invalid conversion from `int (*)(void*, 
Tcl_Interp*, int, char**)' to `int (*)(void*, Tcl_Interp*, int, const 
char**)'
error: command 'gcc' failed with exit status 1
-------------------------
I'm on Mandrake 10.0 which uses gcc 3.3.2
I apologize if I've made some obvious omission.
I'm no c wizard (that's why I want matplotlib!).
-gary

John Hunter wrote:
> 
> How about this:
> 
> What if all the family lists from font_manager are moved to
> matplotlib.__init__.defaultParams and hence .matplotlibrc 
> 
> 
> font.family : sans-serif 
> font.style : normal
> font.variant : normal
> font.weight : normal
> font.size : small
> font.sans_serif : Lucida Grande, Verdana, Geneva, Lucida, Arial, Helvetica, Bitstream Vera Sans, sans-serif
> font.monospace : Andale Mono, Bitstream Vera Sans Mono, Nimbus Mono L, Courier New, Courier, Fixed, Terminal, monospace
> and so on
> 
> (we'll need a new converter func in matplotlib.__init__: comma_sep_strs)
> 
> Users can then order them as they see fit.
> 
> We *require* that font.family be one of serif, sans_serif, cursive,
> fantasy, or monospace. (Is this overly restrictive?)
Seems reasonable to me.
> Thus users who want courier move courier up higher in font.monospace
> in their rc file; ditto for vera.
> 
> Does this work? I think I was a little slow to catch on because you
> intended font family lists to be user configurable but the
> configuration interface doesn't exist yet - it's essentially hardcoded
> in font_manager (is this right, or am I still confused?)
Yes, that's correct. You can modify the family lists via 
text.set_font_properties(), but that's probably not very easy for a user to do 
at this point.
> As for deprecation, we can build a reverse dictionary mapping names to
> one of the allowed font families. On calls to text.set_fontname, we
> issue a deprecation warning and then set the appropriate font family
> where possible. In due time, we remove fontname.
I was thinking that we might want to use set_fontname() to find the font family 
and also add the specified font to the beginning of the list, so that it will 
all certainly be used. Otherwise, that font may be near the bottom of the list 
and not actually get used.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

John Hunter writes:
> What if all the family lists from font_manager are moved to
> matplotlib.__init__.defaultParams and hence .matplotlibrc 
> 
> 
> font.family : sans-serif 
> font.style : normal
> font.variant : normal
> font.weight : normal
> font.size : small
> font.sans_serif : Lucida Grande, Verdana, Geneva, Lucida, 
> Arial, Helvetica, Bitstream Vera Sans, sans-serif
> font.monospace : Andale Mono, Bitstream Vera Sans Mono, 
> Nimbus Mono L, Courier New, Courier, Fixed, Terminal, monospace
> and so on
> 
> (we'll need a new converter func in matplotlib.__init__: comma_sep_strs)
> 
> Users can then order them as they see fit.
> 
> We *require* that font.family be one of serif, sans_serif, cursive,
> fantasy, or monospace. (Is this overly restrictive?)
> 
> Thus users who want courier move courier up higher in font.monospace
> in their rc file; ditto for vera.
> 
My 2 cents: I like requiring the choices to be restricted to those
you've mentioned (or some differently named equivalent), but I 
don't know if I would force changing the configuration file as
being the only way to change the search order. I like the restriction
since it enforces a normally very portable approach that will
prevent the user from being burned on platform dependencies.
On the other hand, it would be nice to give them some means in their
code of bypassing that. How about providing a different interface
(perhaps a bit awkward to use to discourage its casual use) to
allow selection of fonts by specific name. But the normal means
of selecting fonts would only accept the standard supported family
names. Is there any problem in taking this approach? The more
specific approach should be something that is very clear that
is not portable (grepping on a file for any such instances of
the keyword or method, depending on how it is implemented, will
show if any such nonportable uses exist.
There may be times that someone wants to use a special font for a
very specific location on the plot and they don't care if isn't
available everywhere (at least, not for the deadline they need to
get this plot ready for--they are willing to suffer later for their
sin).
But maybe I misunderstand the issue.
Perry

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> Yes, the current behaviour is to fail silently. Let me know
 Paul> if you want this changed.
Let's just put a debug flag in the file so that when we get a user
question about "why isn't my font being found?" on matplotlib-users,
we can advise them to set that flag. At a couple of critical points
(eg the return value of findfont and any failure point), we can print
if debug.
 Paul> In this case the user or developer should provide his own
 Paul> font family list, e.g. ['Vera', 'sans-serif']. If Vera is
 Paul> always supplied with the application, then it will be found
 Paul> first, before the default 'sans-serif'. However, in the
 Paul> case where, for some reason, it could not be found, the
 Paul> default font will be used.
I think you are finally getting through my skull :-).
How about this:
What if all the family lists from font_manager are moved to
matplotlib.__init__.defaultParams and hence .matplotlibrc 
 font.family : sans-serif 
 font.style : normal
 font.variant : normal
 font.weight : normal
 font.size : small
 font.sans_serif : Lucida Grande, Verdana, Geneva, Lucida, Arial, Helvetica, Bitstream Vera Sans, sans-serif
 font.monospace : Andale Mono, Bitstream Vera Sans Mono, Nimbus Mono L, Courier New, Courier, Fixed, Terminal, monospace
 and so on
(we'll need a new converter func in matplotlib.__init__: comma_sep_strs)
Users can then order them as they see fit.
We *require* that font.family be one of serif, sans_serif, cursive,
fantasy, or monospace. (Is this overly restrictive?)
Thus users who want courier move courier up higher in font.monospace
in their rc file; ditto for vera.
Does this work? I think I was a little slow to catch on because you
intended font family lists to be user configurable but the
configuration interface doesn't exist yet - it's essentially hardcoded
in font_manager (is this right, or am I still confused?)
As for deprecation, we can build a reverse dictionary mapping names to
one of the allowed font families. On calls to text.set_fontname, we
issue a deprecation warning and then set the appropriate font family
where possible. In due time, we remove fontname.
Am I starting to get on the right track here?
JDH

John Hunter wrote:
> 
> I did a little more experimenting; I think some of the problems I was
> having yesterday were from residual effects of text.fontname. To
> clarify and simplify, I removed text.fontname from matplotlibrc and
> matplotlib.__init__ rcParams. The ttf_microsoft fonts referred to
> below are in the ttf.tar file referred to earlier; the results below
> show my matplotlibrc entry and the filename returned by findfont
> 
> # ok, verdana san serif
> font.family : san-serif /home/jdhunter/src/ttf_microsoft/verdana.ttf
> 
> # ok this is a serif font
> font.family : serif /usr/X11R6/lib/X11/fonts/TTF/luxirr.ttf
> 
> # what's happening here? fail silently? cour.ttf is in ttf_microsoft
> font.family : Courier /home/jdhunter/src/ttf_microsoft/verdana.ttf
Yes, the current behaviour is to fail silently. Let me know if you want this 
changed.
You are correct that Courier is one of the available fonts. However, the actual 
font name (from the font file) is 'Courier New'. The list of fonts that I have 
suggested for font family has both names listed, 'Courier New' and 'Courier', 
for this reason. From my reading of the CSS1 document there is no easy way to 
distinguish between different font families, except by an explicit list of font 
names.
> I think the ability to define a family and let the system choose the
> best match is good, but there are cases where this may not be
> desirable.
> 
> * If you are an application developer and want your app to look just
> the same across platforms, you may distribute it with a font file
> and you want to make sure that file is chosen. 
In this case the user or developer should provide his own font family list, e.g. 
['Vera', 'sans-serif']. If Vera is always supplied with the application, then 
it will be found first, before the default 'sans-serif'. However, in the case 
where, for some reason, it could not be found, the default font will be used.
> * The majority of users will probably be more familiar with the names
> Courier and Times than with font families monospace and serif.
> Should we provide a mechanism so that users can specify fonts this
> way? Eg, you may know you have Courier on your system and you
> don't care about portability. Is there a way in the current setup,
> for example, a user who wants to specify Courier?
Courier and Times are listed in the sans-serif font family. However, they are 
currently not very high on the list though.
I suppose there are two ways to handle this. One is to expose the font families 
that comes with matplotlib. The user can then just say use the 'sans-serif' 
font family for my text. The second way is to use set_fontname() to prepend the 
specified font to the font family, so that it is always found first during the 
search.
> For the first of these two cases, one idea is to allow a user to
> specify a filename
> 
> font.family = Vera.ttf # search path for Vera.ttf
> 
> Users who distribute apps with matplotlib and want a guaranteed font
> (such as myself!) can use one of the fonts that are distributed with
> matplotlib and rely on the normal environment vars (MATPLOTLIBDATA and
> TTFPATH) to provide the dirs those fonts will reside in. Since no
> legitimate family name or font name will match the pattern *.ttf, we
> can safely do this. What do you think? If this is not sufficiently
> elegant, we could consider font.file as an additional attribute which
> defaults to None.
As previously noted all files found in TTFPATH are prepended to the list of 
system fonts, so they should be accessible. I think that the issue is the use 
of a personal version of the font family that specifies your prefered fonts, so 
that they are searched first. I would think that the font.family variable in 
matplotlibrc could be used to override those supplied by the application at 
start-up. Interactively, font family can be changed by supplying a list of font 
names to FontProperties.set_fontfamily().
The font family list that I have supplied is only a suggestion, so you may want 
to change it at this point.
> For the second of the two cases, I'm not sure....
> 
> So fontname plays no legitimate role anymore?
Not currently, but it can, as I suggest above.
> On an unrelated note, I don't think we need any of fontname,
> fontstyle, fontangle, fontvariant or fontweight in the Text __init__
> method, but we should preserve the getters and setters as discussed
> earlier for user interface compatibity (the __init__ function is not
> in the user interface but the text methods are).
Good, I change that.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> I'll make sure to describe this issue in the documentation.
 Paul> However, in reply to your comment, it is my opinion that the
 Paul> fontname attribute should be depricated in favor of
 Paul> fontfamily, which is a list of named fonts. The font
 Paul> manager has a preliminary list of recommended font families
 Paul> that the user can use. Vera is one of the named fonts in
 Paul> the 'sans' family, though not high on the list, since there
 Paul> are potentlially nicer fonts that can be used.
 Paul> The font manager prepends the list of fonts indicated by
 Paul> TTFPATH to the list of system fonts that it finds. So if
 Paul> Vera is in TTFPATH, then it should be available. If not,
 Paul> then I'll look into it.
Vera is in the path since it's in my matplotlib data dir.
 Paul> Please let me know what changes you would like to this
 Paul> module. In the mean time, I'll continue to make
 Paul> modifications.
I did a little more experimenting; I think some of the problems I was
having yesterday were from residual effects of text.fontname. To
clarify and simplify, I removed text.fontname from matplotlibrc and
matplotlib.__init__ rcParams. The ttf_microsoft fonts referred to
below are in the ttf.tar file referred to earlier; the results below
show my matplotlibrc entry and the filename returned by findfont
 # ok, verdana san serif
 font.family : san-serif /home/jdhunter/src/ttf_microsoft/verdana.ttf
 # ok this is a serif font
 font.family : serif /usr/X11R6/lib/X11/fonts/TTF/luxirr.ttf
 # what's happening here? fail silently? cour.ttf is in ttf_microsoft
 font.family : Courier /home/jdhunter/src/ttf_microsoft/verdana.ttf
I think the ability to define a family and let the system choose the
best match is good, but there are cases where this may not be
desirable.
 * If you are an application developer and want your app to look just
 the same across platforms, you may distribute it with a font file
 and you want to make sure that file is chosen. 
 * The majority of users will probably be more familiar with the names
 Courier and Times than with font families monospace and serif.
 Should we provide a mechanism so that users can specify fonts this
 way? Eg, you may know you have Courier on your system and you
 don't care about portability. Is there a way in the current setup,
 for example, a user who wants to specify Courier?
For the first of these two cases, one idea is to allow a user to
specify a filename
 font.family = Vera.ttf # search path for Vera.ttf
Users who distribute apps with matplotlib and want a guaranteed font
(such as myself!) can use one of the fonts that are distributed with
matplotlib and rely on the normal environment vars (MATPLOTLIBDATA and
TTFPATH) to provide the dirs those fonts will reside in. Since no
legitimate family name or font name will match the pattern *.ttf, we
can safely do this. What do you think? If this is not sufficiently
elegant, we could consider font.file as an additional attribute which
defaults to None.
For the second of the two cases, I'm not sure....
So fontname plays no legitimate role anymore?
On an unrelated note, I don't think we need any of fontname,
fontstyle, fontangle, fontvariant or fontweight in the Text __init__
method, but we should preserve the getters and setters as discussed
earlier for user interface compatibity (the __init__ function is not
in the user interface but the text methods are).
JDH

John Hunter wrote:
> 
> I printed out the code so I'll take it home and give it a close
> reading tonight. Here are a few things I noticed while poking around
> 
> * we should cite the ttfquery license since some of font_manager code
> appears to be borrowed from it. I added license/LICENSE_TTFQUERY
> to CVS so you can just refer to that file in the font_manager
> header
I had thought about this and will add it to my to-do list.
> * the default file .matplotlibrc in the matplotlib root dir needs to
> be updated with the properties you added to rcParams. With
> comments and commented examples would be most useful. I noticed
> that in the rc params in matplotlib.__init__.py you specify default
> sizes in points rather than relative sizes - what's the logic here?
In my previous message, the active word is 'basic'. I just wanted to get some 
code in that worked, so you could evaluate and comment on it. Also, I thought 
it best to make a minimal set of changes initially, since this module affects so 
many other modules. A large set of changes might have caused lots of problems. 
In future, I should be able to make more modifications to one or two files at a 
time.
I haven't had a chance to go through all the code yet to make sure it is all 
consistent. So the short answer is: I left it as is, because it worked. :) 
This is on my list of things to-do.
> * Could you write some tutorial and/or user documentation? The two
> most important files are htdocs/fonts.html.template and
> htdocs/backends.html.template. Also, a blurb for "what's new" for
> the next release would be great. It might also be nice to have
> something along the lines of a FAQ "Hey my fonts have changed, how
> can I get the old ones back?" in htdocs/faqs.html.template
Yes, the user docs are also on my to-do list, but I'll also add the tutorial and 
FAQ documentation.
> * It does not appear you are cacheing the results anywhere. On my
> modern linux system with not so many fonts, I don't notice any
> performance hit. I wonder if this might be a problem for a win32
> user with lots of ttf files and a not so speedy computer.
The issue of cacheing the most recently used fonts had crossed my mind. I'll 
look into it, particularly for Windows systems.
> * I have some concern about the finder algorithm, at least in
> combination with setting a default font in matplotlibrc. Eg, if I
> untar the following dir on my linux system (which contains a lot of
> ttf fonts) http://nitace.bsd.uchicago.edu:8080/files/share/ttf.tar
> and then point to them with my TTFPATH, and set 
> text.fontname : Vera in matplotlibrc, I don't get Vera. 
> This may be answered by the FAQ above :-)
I'll make sure to describe this issue in the documentation. However, in reply 
to your comment, it is my opinion that the fontname attribute should be 
depricated in favor of fontfamily, which is a list of named fonts. The font 
manager has a preliminary list of recommended font families that the user can 
use. Vera is one of the named fonts in the 'sans' family, though not high on 
the list, since there are potentlially nicer fonts that can be used.
The font manager prepends the list of fonts indicated by TTFPATH to the list of 
system fonts that it finds. So if Vera is in TTFPATH, then it should be 
available. If not, then I'll look into it.
Please let me know what changes you would like to this module. In the mean 
time, I'll continue to make modifications.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
First of all, amazing work. It's very impressive that you made so
many changes from the frontend to the backend to the config file and
everything still works!
 Paul> I've committed a new font manager to CVS. It is based on
 Paul> the W3C Cascading Style Sheet, Level 1 (CSS1) design. It is
 Paul> still rather basic, but does seem to work for most of the
 Paul> backends. Therefore, FontTools, ttfquery, and
 Paul> ttf_font_manager are no longer needed by matplotlib.
Excellent to hear - that was a maintenance nightmare. I'll put in an
admin request to finally get those dir trees purged from CVS.
BTW, I added the agg2 tree to CVS so you should be able to build
matplotlib cleanly with a CVS checkout. No need to copy files and
dirs anymore. I also remove gtkgd, which was never more than a
proof-of-concept backend.
 Paul> The font manager currently handle only TrueType fonts, but
 Paul> should be generalizable to other font types.
 Paul> The text object now has a fontproperties attribute which
 Paul> describes the basic aspects of the font, such as family,
 Paul> style, weight and size. This attribute replaces the
 Paul> fontname, fontangle, fontweight, and fontsize attributes.
 Paul> In future, I would suggest using font name sizes, such as
 Paul> small, medium, and large, to specify font sizes, instead of
 Paul> point sizes. This should make it easier for font sizes to
 Paul> be consistent across backends. It will also make it easier
 Paul> to change all the fonts just by changing the default font
 Paul> size that is associated with the medium font name. The
 Paul> default value for this is 12.
 Paul> The other interface issue to be aware of is the font family.
 Paul> This is a list of font names in order of decreasing
 Paul> priority. This should make it easier to match similar fonts
 Paul> across the various platforms.
I printed out the code so I'll take it home and give it a close
reading tonight. Here are a few things I noticed while poking around
 * we should cite the ttfquery license since some of font_manager code
 appears to be borrowed from it. I added license/LICENSE_TTFQUERY
 to CVS so you can just refer to that file in the font_manager
 header
 * the default file .matplotlibrc in the matplotlib root dir needs to
 be updated with the properties you added to rcParams. With
 comments and commented examples would be most useful. I noticed
 that in the rc params in matplotlib.__init__.py you specify default
 sizes in points rather than relative sizes - what's the logic here?
 * Could you write some tutorial and/or user documentation? The two
 most important files are htdocs/fonts.html.template and
 htdocs/backends.html.template. Also, a blurb for "what's new" for
 the next release would be great. It might also be nice to have
 something along the lines of a FAQ "Hey my fonts have changed, how
 can I get the old ones back?" in htdocs/faqs.html.template
 * It does not appear you are cacheing the results anywhere. On my
 modern linux system with not so many fonts, I don't notice any
 performance hit. I wonder if this might be a problem for a win32
 user with lots of ttf files and a not so speedy computer.
 * I have some concern about the finder algorithm, at least in
 combination with setting a default font in matplotlibrc. Eg, if I
 untar the following dir on my linux system (which contains a lot of
 ttf fonts) http://nitace.bsd.uchicago.edu:8080/files/share/ttf.tar
 and then point to them with my TTFPATH, and set 
 text.fontname : Vera in matplotlibrc, I don't get Vera. 
 This may be answered by the FAQ above :-)
Many thanks!
John Hunter

I've committed a new font manager to CVS. It is based on the W3C Cascading 
Style Sheet, Level 1 (CSS1) design. It is still rather basic, but does seem to 
work for most of the backends. Therefore, FontTools, ttfquery, and 
ttf_font_manager are no longer needed by matplotlib.
The font manager currently handle only TrueType fonts, but should be 
generalizable to other font types.
The text object now has a fontproperties attribute which describes the basic 
aspects of the font, such as family, style, weight and size. This attribute 
replaces the fontname, fontangle, fontweight, and fontsize attributes.
In future, I would suggest using font name sizes, such as small, medium, and 
large, to specify font sizes, instead of point sizes. This should make it 
easier for font sizes to be consistent across backends. It will also make it 
easier to change all the fonts just by changing the default font size that is 
associated with the medium font name. The default value for this is 12.
The other interface issue to be aware of is the font family. This is a list of 
font names in order of decreasing priority. This should make it easier to match 
similar fonts across the various platforms.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Now, my question is, can we set edgecolor=None on a patch
 Andrew> and have it not draw the edges of the patch? Or whatever
 Andrew> is the most matlab-compatible way, assuming one can do
 Andrew> this in matlab. Or, perhaps by analogy to fill=True we
 Andrew> could have stroke=True as well. Perhaps this is already
 Andrew> "in there"--if so, what do I do?
Unfortunately, the backend design doesn't accomodate this so nicely.
The workaround is to set the edge and the face color to be the same.
You pay a performance hit but otherwise *it works*.
To do it right will require, but will require some extra work. 
A typical signature is:
 def draw_rectangle(self, gcEdge, rgbFace, x, y, width, height):
The gc contains extra information in addition to color that the
backend may optionally use in drawing the polygon: alpha, line
thickness, dash style. This is why facecolor and edgecolor are set
differently in the current framework. 
I'm not sure what the cleanest design is to overcome this; it would
definitely require changing all the draw patch methods of all the
backends. 
Setting gcEdge to None is probably the easiest but you would lose
alpha information in doing so that we may want to use in drawing
filled polygons/rectangles.
An alternative is to simply remove the gc and explicitly pass the
required properties.
This brings up my next big matplotlib project - handling large
quantities of polygon data efficiently. I would like to define all
the properties that are required for polygon drawing so that we can
provide optional backend methods like draw_rectangles and
draw_ellipses which could be implemented more efficiently than the
current methods.
I've always found the gcEdge and rgbFace a bit hackish for polygons
and wanted to clean this up at least for the polygon collection code.
So what is needed to fully specify a 2D polygon?
 * vertices 
 * edge thickness
 * edge dashes, eg a dashed rectangle surrounding a region
 * edge color: rgb or none for invisible
 * face color: rgb or none for invisible
 * alpha
Anything else?
I was thinking about a signature along the lines of 
 # good for drawing a polygon map of a country
 draw_polygons(N, verts, widths, dashes, edges, faces, alphas, trans):
 
Any of these args can be an N length sequence or a 1 length sequence.
If the sequence is length one, the backend just uses the 0th index for
all the polygons.
 verts: a list like [p1, p2, p3] where p1 = ( (x1,y1), (x2,y2), ...)
 and so on
 widths: the edge thickness
 dashes: a list like [d1,d2,d3] where d1 = ( inkon1, inkoff1,
 inkoff1, inkoff2). This may be overkill; in 99.9999% of the
 cases as single dash style is all anyone will want. Perhaps
 best to do away with dashes altogether for polygon
 collections.
 edges : a list of [rgb1, rgb2, ...]
 faces : a list of [rgb1, rgb2, ...]
 alphas: a list of [alpha1, alpha2, ...]
 trans: a six-tuple, postscript/agg style transformation vector.
The last arg violates the current design in which backends don't have
to worry about transformations. But doing the transformations of
verts in python incurs a performance penalty that obviates the purpose
of the function so it seems worth it.
draw_polygons really isn't ideally suited to a scatter or pcolor
though. In those cases you would spend a lot of time in python
constructing your polygons vertices when you really only need one
shape placed at a many locations, possibly scaled.
 # good for drawing a polygon map of a country
 draw_identical(N, path, offsets, scales, widths, 
 dashes, edges, faces, alphas, trans):
 path : is a sequence of rlineto's defining the shape of the polygon
 offsets : a sequence of [(x1,y1), (x2,y2), ...] for the path
 scales : a sequence of scales for each path; [scale1, scale2,
 scale3, ...] or [ (sx1, sy2), (sx2, sy2), ...] allowing
 the x and y directions to scale independently
 other args are the same
This seems a bit cumbersome. I'm trying to think of the fewest
functions that will handle at least
 * pcolor with rectangles
 * scatters with markers of arbitrary shape and possibly varying
 sizes
 * maps, eg, map of voting by county in the US.
Thoughts?
JDH

On Tuesday, March 16, 2004, at 10:52 PM, John Hunter wrote:
>
> Changes are in CVS.
Great! (Too bad SF's CVS servers are way behind for anonymous 
checkouts--it's driving me nuts! I had to piece together a recent CVS 
checkout by downloading the CVSROOT tarball...)
Now, my question is, can we set edgecolor=None on a patch and have it 
not draw the edges of the patch? Or whatever is the most 
matlab-compatible way, assuming one can do this in matlab. Or, perhaps 
by analogy to fill=True we could have stroke=True as well. Perhaps 
this is already "in there"--if so, what do I do?
Keep up the great work!
Andrew

On Tuesday, March 16, 2004, at 11:32 PM, John Hunter wrote:
>
> On OS X 10.3, I can run TkAgg fine, interactive works great from the
> prompt, etc. However, when I on the figure window to move it or click
> on a navigation button etc, I get a "SetFrontProcess failed, -606"
> message and the desired action does not happen. I am running under
> X11, launching python from an xterm.
>
> Do you get this Andrew? Any ideas?
Yes.
Short answer: use "pythonw" not "python"
Long anser: The OS X Cocoa WindowServer (I'm paraphrasing the proper 
terms, which I'm sure are slightly different) requires something like 
any application that wants to open a GUI window must be clicked or 
equivalent. Since that's not the way python generally works, pythonw 
for OS X was modified to do some black magic (LaunchServices??) to get 
around this requirement. This stuff is not in the normal python 
executable. For this reason, I have my trusty ipython shell using 
pythonw on OS X. There doesn't seem to be any problem running non-Tk 
apps with pythonw.
FYI, pygame has something that will print a complaint if it's not run 
with pythonw. We could look under the hood and figure out how it's 
done there...

What's new in matplotlib-0.52
Image support
 Basic image support. Images can be specified by Numeric float arrays
 imshow(X)
 If X is MxN, assume luminance (grayscale)
 If X is MxNx3, assume RGB
 If X is MxNx4, assume RGBA
 imshow(X, cmap) # plot X using colormap; see examples/pcolor_demo2.py
 see help(imshow) and the image_demo*.py examples in the matplotlib
 src distribution. Set BUILD_IMAGE in setup.py for image
 support. Currently available on Agg, GTKAgg, TkAgg and GTK
 backends. win32 GTK users should use GTKAgg unless your pygtk is
 compiled with Numeric support.
 The pseudocolor images generated with imshow are 8 million times
 faster than pcolors.
Figure legends
 In addition to adding legends to the axes with the legend command,
 you can place legends anywhere in the figure with figlegend
fill command
 Andrew Straw wrote a fill command to plot filled polygons. See
 fill_demo.py
Make 2D spectrograms with specgram. 
 Requires image support; see specgram_demo.py 
Bugfixes and minor improvements
 * Tk : Fixed a close figure bug in interactive mode
 * GTK : Much improved mathtext performance thanks to patch by
 Trevor Blackwell
 * All : Fixed a bug that showed up in successive calls to plot
 with just one plot argument
Downloads at
https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=224080