New font manager.

Yes, the current behaviour is to fail silently. Let me know

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

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

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

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