Darren Dale wrote:
> On Wednesday 22 August 2007 03:09:30 pm Michael Droettboom wrote:
>> I realize it's hacky. The most obvious alternative is to expect a
>> dictionary here, e.g.:
>>
>> rm = { 'family': ['serif'], 'style': 'oblique' }
>>
>> But that's less like the FontProperties constructor.
>
> Why do you say that? Here is the constructor:
>
> def __init__(self,
> family = None,
> style = None,
> variant= None,
> weight = None,
> stretch= None,
> size = None,
> fname = None,
> ):
>
> wouldnt FontProperties(**rm) work?
Sure. I just meant that
rm = { 'family': ['serif'], 'style': 'oblique' }
is syntactically different from
rm = FontProperties(['serif'], style='oblique')
>> My goal was to
>> make specifying fonts as similar as possible to the FontProperties
>> object so the user doesn't have to learn a new syntax. Is there a
>> better way to do this with Traits? Can the user specify the arguments
>> (with keyword arguments) to a constructor?
>
> I think this is getting a little out of hand, isnt it?:
>
> #mathtext.cal : ['cursive']
> #mathtext.rm : ['serif']
> #mathtext.tt : ['monospace']
> #mathtext.it : ['serif'], style='oblique'
> #mathtext.bf : ['serif'], weight='bold'
> #mathtext.sf : ['sans-serif']
>
> That means we have comma-separated strings for lists of fonts, but
> bracket-enclosed comma-separated quoted strings for mathtext properties.
Well, they are different beasts. The former only specifies a choice of
families. The latter specifies a specific font. I didn't intend to
invent something new for mathtext -- there were no other instances where
a full set of font properties was required to specify a font. (Sure
font.* is a sort of example of that, but it includes other things as
well...)
> If you want all that flexibility, why not do it in the usual way:
>
> #mathtext.it.family : 'serif'
> #mathtext.it.style : 'oblique'
That seems reasonable. I think I had a mental block around this because
of the verbosity (and seeing a font specification as a single unit), but
it does seem to fit in much better with the existing options (i.e. a
subset of font.*).
*IF* fontconfig is ever adopted, we could use fontconfig patterns as an
alternative, which are at least some kind of standard.
> But is that much flexibility needed?
The flexibility is certainly needed, and came directly out of a request
on matplotlib-user. There are cases where you want the variable names
(the 'it' font in TeX parlance) to be in an upright serif font. So you
can't hardcode either the family or the style. And there is no way
(AFAIK) to go from a given serif font to its companion sans-serif font,
so when changing to a new font "collection", each one will have to be
specified individually.
Cheers,
Mike
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
