Re: [matplotlib-devel] New font manager.

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