matplotlib-devel Mailing List for matplotlib (Page 549)

>>>>> "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

>>>>> "Martin" == Martin Kuemmel <mku...@es...> writes:
 Martin> Hi John, I dont know whether you are the person to write
 Martin> to, but I simply try. I am trying to install matplotlib
 Martin> on:
 Martin> SunOS st13 5.8 Generic_108528-21 sun4u sparc
 Martin> SUNW,Sun-Blade-1500
 Martin> with gcc 3.3.2.
 Martin> In principle it works, and with the PS-backend it gives
 Martin> results. I would like to install the agg-backend, but did
 Martin> not manage to do so. I just installed the
 Martin> freetype2-library, and to include it at its position I
 Martin> changed the code in 'setupext.py', module
 Martin> 'add_agg_flags(module)', line 94 to;
 Martin> module.include_dirs.extend(
 Martin> ['/ecfsoft/pyraf1.1/include/freetype2',] )
 Martin> module.include_dirs.extend( ['/ecfsoft/pyraf1.1/include',]
 Martin> )
 Martin> i am still not at home, and I get the error messages:
 Martin> Text relocation remains referenced against symbol offset
 Martin> in file <unknown> 0x40
 Martin> /ecfsoft/pyraf1.1/lib/libz.a(deflate.o) <unknown> 0x4c
 Martin> /ecfsoft/pyraf1.1/lib/libz.a(deflate.o) <unknown> 0x58
 Martin> /ecfsoft/pyraf1.1/lib/libz.a(deflate.o)
 Martin> It seems not to include the libz correctly, but this
 Martin> library exists also at '/ecfsoft/pyraf1.1/include' and
 Martin> '/ecfsoft/pyraf1.1/lib'.
 Martin> What can I do?
 Martin> Cheers and thanks in advance, Martin
 Martin> P.S.: Please forward this mail to the appropriate person,
 Martin> or give me its email address
Hi Martin,
We are very interested in getting a build that works properly under
Solaris so thanks for writing and offering to be the crash test dummy.
I CCd this email to the matplotlib development list since some folks
there know a bit about solaris. You may want to consider joining the
user or development mailing list for future questions -
http://sourceforge.net/mail/?group_id=80706
I suggest you try working with the latest matplotlib snapshot
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.52c.tar.gz
which has a somewhat improved setupext.py (it also includes basic
image support with the imshow command). Usually to get freetype you
need the dir that includes ft2build.h and the freetype2 include dir in
your include_path.
But it looks like you are getting a link error rather than an include
error. I just posted
 "Text relocation remains referenced against symbol offset" 
into google and got this result
http://mailman.cs.uchicago.edu/pipermail/swig/2002-April/004435.html.
That post suggests you need the linker flags -Wl,-G
Search google groups with the same error message and you'll get lots
of threads that look helpful.
When you get this working if you can post a modified setupext.py as
well as any additional dependencies and build instructions, that would
be great.
JDH

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?
JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> 2 points:
 Andrew> 1) Is there any reason why the Patch class doesn't have
 Andrew> get_xdata() and get_ydata() methods? 1b) If not, can we
 Andrew> add them and let Axes.add_patch(patch) call
 Andrew> "self.xaxis.datalim.update(patch.get_xdata())" ?
I removed this one day when I was trying to improve the painfully slow
pcolor code. The way patches were getting their xlimits was slow.
After spending some time with the profiler, I opted to set the axes
limits manually for scatter and pcolor rather than pay the additional
performance hit in add_patch. This makes the code a little more
difficult to maintain.
Perhaps better than get_xdata is get_xlim. What is the natural xdata
for a circle characterized by a center and radius? xlim is clear. I
added this for Polygon and modified the fill command to use it, and
will add it to the other patch commands and use it in add_patch in due
time. Or feel free to take the lead :-)
 Andrew> 2) I think there's still a Polygon facecolor bug. John, I
 Andrew> thought you fixed the Polygon facecolor bug -- my
 Andrew> patches.py code matches the bugfix you emailed the list,
 Andrew> but I still don't get the facecolor with the PS, GTK or
 Andrew> Agg backends.
The problem was that you didn't set fill=True in the Polygon
constructor. I added this and it works great. Here is my fill_demo
code - if you have something more impressive for the examples dir send
it along.
 from matplotlib.matlab import *
 t = arange(0.0, 1.01, 0.01)
 s = sin(2*2*pi*t)
 fill(t, s*exp(-5*t), 'r')
 grid(True)
 show()
Changes are in CVS.
Thanks!
JDH

G'day!
I've implemented a mostly-matlab-compatible "fill" command. I attach 
it for your pleasure and hopeful inclusion into matplotlib. (This is 
an extension of our previous email discussion and involved me going and 
using matlab for a bit to get a feel for their API.)
2 points:
1) Is there any reason why the Patch class doesn't have get_xdata() and 
get_ydata() methods?
1b) If not, can we add them and let Axes.add_patch(patch) call 
"self.xaxis.datalim.update(patch.get_xdata())" ?
2) I think there's still a Polygon facecolor bug. John, I thought you 
fixed the Polygon facecolor bug -- my patches.py code matches the 
bugfix you emailed the list, but I still don't get the facecolor with 
the PS, GTK or Agg backends.
Cheers!
Andrew

On Tuesday, March 16, 2004, at 02:28 AM, John Hunter wrote:
> I've added image support in CVS along the lines discussed last week.
Great! A quick test shows that the demos work fine over here.
A quick note:
I had to add the following files to my CVS checkout from the tarball 
you provided. Could you add these to the CVS distribution? (If it's 
not SF's CVS servers being flakey?)
src/_image.h
src/_image.cpp
matplotlib/image.py
postinstall.py

I've added image support in CVS along the lines discussed last week.
Currently only array loading (floats) is supported with
 imshow(X)
 
 If X is MxN, assume luminance (grayscale)
 If X is MxNx3, assume RGB
 If X is MxNx4, assume RGBA
but I'll work on adding PNG and colormaps in the
not-too-distant-future, as well as supporting more pixel formats. You
must use one of the *Agg backends. I'll add some helper methods to
make the scaled image data accessible by GTK and WX in the near
future.
See examples/image_demo.py.
It would also be nice to have a "frompil" method that could load the
image from a pil instance to get all the pil loaders for free. I
don't know how hard this would be.
You can set the interpolation method and whether or not aspect ratio
is preserved with
 im = imshow(A)
 im.set_aspect('preserve') # free is default; not constrained
 im.set_interpolation('bicubic') # bilinear default; see image module for others
You can also set the data extent of the image if you want to plot
lines, etc over your image. See examples/image_demo2.py. Currently
data extent with aspect ratio preserved is broken.
After playing around with some examples, there are a few things that
have become higher priorities.
 * update navigation controls. The asymmetric x and y zooms don't
 make a lot of sense for images. I plan to write a new toolbar with
 symmetric zooms, "hand" pan, and zoom to rectangle as discussed
 before. I'll try and write this in a way that the various GUI
 backends can subclass without too much additional work,
 * figure resize - on GTK and Tk at least, the ability to resize the
 figure is too limited. TkAgg, for example, always preserves the
 figure aspect ratio and GTK won't let you get smaller than the
 initial dimensions. It would be nice to allow more freedom here.
Let me know how it goes... Here's a snapshot or the sdist:
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.52c.tar.gz
JDH

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> Just to make sure that I have this straight, the Text class
 Paul> should look like this:
 Paul> def __init__(self, ..., font, ...): ...
Yep
 Paul> If so, do you planning on changing get_fontxxxx() for
 Paul> get_font()?
No. you should have a get_font, an also get_fontxxxx that forwards
the call to the font object for backwards compatability.
 Paul> I should be able to do most of it.
Awesome! 
JDH

John Hunter wrote:
> 
> I think font handling should be factored out of the Text class into a
> dedicated class. 
> 
> class Font:
> 
> pass
> 
> class Text(dpi, bbox, font, etc...):
> pass
Just to make sure that I have this straight, the Text class should look like this:
 def __init__(self, ..., font, ...):
 ...
 self._color = color
 self._text = text
 self._verticalalignment = verticalalignment
 self._horizontalalignment = horizontalalignment
 self._rotation = rotation
 self._font = font
instead of this:
 def __init__(self, ...):
 ...
 self._color = color
 self._text = text
 self._verticalalignment = verticalalignment
 self._horizontalalignment = horizontalalignment
 self._rotation = rotation
 self._fontname = fontname
 self._fontsize = fontsize
 self._fontweight = fontweight
 self._fontangle = fontangle
If so, do you planning on changing get_fontxxxx() for get_font()?
> 
> For user API compatibility, the critical thing is to preserve the
> getters and setters of Text, since the following is legal code
> 
> t = title('hi mom', fontname='Courier', fontsize=12)
> 
> which calls text.set_fontname and text.fontsize under the hood.
> 
> But the setters and getters can just forward the call to the new font
> instance as necessary.
OK.
> Vis-a-vis backends:
> 
> PS: As far as the finder algorithm is concerned, it would be nice if
> it was sufficiently generic that backend_ps could use it too. If
> you define an API that the algorithm needs vis-a-vis font
> properties, we modify the AFM and FT2Font classes to provide
> these.
Yes, this is my intention.
> Division of labor: if you want to make the required changes to
> text.Text, ttf_font_finder and (optionally) matplotlibrc I'm all for
> it. Once you have a prototype, I can help with all the text
> instantiators if you like, or you can do this too. Whichever way, I
> can definitely help with the backend ports once the above issues are
> resolved.
I should be able to do most of it.
 -- 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> As a final suggestion, we could have the Text object
 Paul> initialize the fontfamily attribute to a sans-serif font
 Paul> list, e.g. the one given above, since that seems to be a
 Paul> popular font family for many users.
I think all of the suggestions are good ones. I wasn't aware of the
CSS standards, but GTK (which provided the matplotlib font model) is
very close to it, including the use of xxlarge, etc.
 Paul> Please let me know what you think about this suggestion and
 Paul> if you have any changes to the design.
I think font handling should be factored out of the Text class into a
dedicated class. 
class Font:
 pass
class Text(dpi, bbox, font, etc...):
 pass
AFAIK, noone is directly instantiating Text instances in their code so
I don't think we'll have many API complaints. Then the respective
font finders (ttf and afm) can use the font instance in combination
with the CSS algorithm to find the fonts. 
This won't be too hard on the backends since most of them are already
using the font finders to get the ttf or afm filenames, so most of
these changes will be insulated except for changing the arguments of a
few functional calls. The major overhaul will be in matplotlib.text
and in the classes that instantiate text (Axis, Axes, Figure). I like
the idea of using relative sizes in all these classes.
For user API compatibility, the critical thing is to preserve the
getters and setters of Text, since the following is legal code
 t = title('hi mom', fontname='Courier', fontsize=12)
which calls text.set_fontname and text.fontsize under the hood.
But the setters and getters can just forward the call to the new font
instance as necessary.
Vis-a-vis backends:
 GTKAgg, Agg, TkAgg, GD, Paint: no problems here as they all use
 ttf_font_finder
 PS: As far as the finder algorithm is concerned, it would be nice if
 it was sufficiently generic that backend_ps could use it too. If
 you define an API that the algorithm needs vis-a-vis font
 properties, we modify the AFM and FT2Font classes to provide
 these.
 GTK: I think with minor changes we can make GTK play nicely with any
 ttf font on the system. I have to do a little more research.
 If not, the GTK font setup is so close to the CSS one that I can
 do the mapping pretty easily.
 WX: There is a standard set of WX fonts. I'm not sure how to map the
 generic ideas you put forth to the concrete fonts wx knows about,
 other than extending the fontnames dictionary to handle as many
 of the typical font names as possible and/or having users set the
 wx fontnames in matplotlibrc.
 
 It would also help to provide some helper functions which map
 numeric font weights to one of normal|bold|heavy|etc and the
 string font sizes to points (eg 'medium'->12pt) for the backends
 that don't know about these newfangled options.
 That way in backend_wx we could do
 s = font.get_weight_as_string()
 weight = self.fontweights[s] # this dict already exists in WX and GTK
 size = font.get_size_in_points()
 ...etc...
 In addition, Jeremy has indicated an interest in implementing
 WXAgg backend, which would get the new font handling for free.
Division of labor: if you want to make the required changes to
text.Text, ttf_font_finder and (optionally) matplotlibrc I'm all for
it. Once you have a prototype, I can help with all the text
instantiators if you like, or you can do this too. Whichever way, I
can definitely help with the backend ports once the above issues are
resolved.
I've already been planning to refactor the backend text API, that
would have required a font instance anyway. For all the other
attributes (lines, rectangles, etc), the backends don't know about the
matplotlib objects. eg, we say draw_line(x1,y1, x2,y2), not
draw_line(lineObject). But I am currently passing a text instance in
to draw_text. 
I realized this was a problem when I wanted to fix newline handling
across backends. The best way to do this is for the Text class to
split strings on newlines, do the layout in the front end, and then
call draw_text(x,y,s,font) for all the newline split strings in the
original string. Likewise, most of the text layout stuff like
alignment that is currently done in the backend should be moved to the
Text class. So I'll work on these changes in parallel.
JDH