matplotlib-devel Mailing List for matplotlib

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