Re: [matplotlib-devel] Font installation stuff

2007-08-22 Thread Andrew Jaffe


Hi All-

FYI, I am seeing the same problem on intel OSX 10.4.10

Andrew



Eric Firing wrote:
> Rob, Mike,
> 
> What this implies to me is that either there is a problem with the code 
> that is generating afmdict (and I did not change that code, I just 
> caused it to be invoked when the fontManager instance is created.), or 
> there is a problem with some .afm files on Rob's machine.
> 
> I really don't know how to troubleshoot it beyond this.
> 
> (As a separate issue, I probably I should change font_manager.py so that 
> if the rcParams value below was changed since the cache was made, it 
> will be rebuilt with the new value.)
> 
> Eric
> 
> Rob Hetland wrote:
>> On Aug 14, 2007, at 1:55 PM, Eric Firing wrote:
>>
>>> rcParams['pdf.use14corefonts']
>> Indeed, reversing this value fixes the problem.
>>
>> My value had been set to False.
>>  pdf.use14corefonts :  True
>> in the mplrc file works with the latest revision.
>>
>> -r
>>
>> 
>> Rob Hetland, Associate Professor
>> Dept. of Oceanography, Texas A&M University
>> http://pong.tamu.edu/~rob
>> phone: 979-458-0096, fax: 979-845-6331
>>
>>
>>
>> -
>> 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
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> -
> 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/



-
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


Re: [matplotlib-devel] patch: Error Bars, upper and lower limits

2007-08-22 Thread Eric Firing
Manuel Metz wrote:
> Hello,
> I have attached a patch that adds the ability to draw upper/lower limits 
> indicators for errorbars. New keyword args had to be introduced to the 
> errorbar command, and I also had to add new plot styles. I chose 
> 'y','Y','z' and 'Z' as new linestyles for arrowheads pointing up,down, 
> left, right (see lines.py).
> 
> An example and its output is also attached.
> 
> Eric: I know, I don't use masked array in this patch ;_) . The reason 
> was that errorbar() also doesn't use them, and a did not want to 
> completely change that function but just add the new feature. Switching 
> to masked arrays should be straight forward, I think :-)

OK, thanks.  I don't think that masked array support is needed for 
errorbar plots; certainly it is not high priority.

I will look at your patch later this week; I am pretty thoroughly tied 
up right now.

Eric

-
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


[matplotlib-devel] config with traits

2007-08-22 Thread Darren Dale
I am trying to work out some way to make rcdefaults() work with the traited 
config. Along the way, I discovered this in mplconfig:

class mathtext(TConfig):
cal = T.Trait("['cursive']", mplT.FontPropertiesHandler())
rm = T.Trait("['serif']", mplT.FontPropertiesHandler())
tt = T.Trait("['monospace']", mplT.FontPropertiesHandler())
it = T.Trait("['serif'], style='oblique'", 
mplT.FontPropertiesHandler())
bf = T.Trait("['serif'], weight='bold'", mplT.FontPropertiesHandler())
sf = T.Trait("['sans-serif']", mplT.FontPropertiesHandler())
use_cm = T.true
fallback_to_cm = T.true

I dont think that will work. One of the highlights of the new config files is 
that when a file says:

[mathtext]
rm = ['serif', 'sans-serif']

you actually get a list, not a string, to pass to 
mplT.FontPropertiesHandler().  I discovered the code by trying to do this:

rcParams.update(rcParamsDefault)

Another thing about T.Trait to keep in mind:

T.Trait("['cursive']", mplT.FontPropertiesHandler())
"['cursive']" is the default value and is *not validated*. Nor is it 
necessarily an allowed value. For example:

 T.Trait('small', 'medium', 'large') 
'small' is the default value, but any future attempt to set that trait 
to 'small' will fail. Only items following the default are allowed.

 T.Trait('small', 'small', 'medium', 'large') 
Now 'small' is a valid setting.

Darren

-
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


Re: [matplotlib-devel] config with traits

2007-08-22 Thread Michael Droettboom
This was an attempt to do a direct translation from what I had in the 
"classic" rcsetup.py.  (The previous version in mplconfig.py was 
semantically incorrect.)  I had tested this with settings in my 
matplotlib.conf, but didn't realise that the default wasn't validated 
(and thus not interpreted into a FontPropertiesProxy object).

Darren Dale wrote:
> I am trying to work out some way to make rcdefaults() work with the traited 
> config. Along the way, I discovered this in mplconfig:
> 
> class mathtext(TConfig):
> cal = T.Trait("['cursive']", mplT.FontPropertiesHandler())
> rm = T.Trait("['serif']", mplT.FontPropertiesHandler())
> tt = T.Trait("['monospace']", mplT.FontPropertiesHandler())
> it = T.Trait("['serif'], style='oblique'", 
> mplT.FontPropertiesHandler())
> bf = T.Trait("['serif'], weight='bold'", mplT.FontPropertiesHandler())
> sf = T.Trait("['sans-serif']", mplT.FontPropertiesHandler())
> use_cm = T.true
> fallback_to_cm = T.true
> 
> I dont think that will work. One of the highlights of the new config files is 
> that when a file says:
> 
> [mathtext]
> rm = ['serif', 'sans-serif']
> 
> you actually get a list, not a string, to pass to 
> mplT.FontPropertiesHandler().

Right.  But it works like:

rm = "['serif', 'sans-serif']"

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

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


Re: [matplotlib-devel] config with traits

2007-08-22 Thread Michael Droettboom
I've committed a fix so this at least works.  (We can change how the 
trait is specified later if necessary.)  The validation is not as tight 
as it should be, yet.

I think I've passed through this bug onto another one, though:

Traceback (most recent call last):
   File "", line 1, in 
   File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/config/mplconfig.py", 
line 469, in update
 self[key] = arg[key]
   File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/config/mplconfig.py", 
line 454, in __setitem__
 See rcParams.keys() for a list of valid parameters.'%key)
KeyError: 'text.fontangle is not a valid rc parameter.See 
rcParams.keys() for a list of valid parameters.'

It seems that unlike the regular string choice traits, the custom Trait 
handlers *are* called with the default value when initialized.  Is that 
something to be relied on?  (Other parts of mplconfig, such as the 
colors, depend on this).

Cheers,
Mike

Michael Droettboom wrote:
> This was an attempt to do a direct translation from what I had in the 
> "classic" rcsetup.py.  (The previous version in mplconfig.py was 
> semantically incorrect.)  I had tested this with settings in my 
> matplotlib.conf, but didn't realise that the default wasn't validated 
> (and thus not interpreted into a FontPropertiesProxy object).
> 
> Darren Dale wrote:
>> I am trying to work out some way to make rcdefaults() work with the traited 
>> config. Along the way, I discovered this in mplconfig:
>>
>> class mathtext(TConfig):
>> cal = T.Trait("['cursive']", mplT.FontPropertiesHandler())
>> rm = T.Trait("['serif']", mplT.FontPropertiesHandler())
>> tt = T.Trait("['monospace']", mplT.FontPropertiesHandler())
>> it = T.Trait("['serif'], style='oblique'", 
>> mplT.FontPropertiesHandler())
>> bf = T.Trait("['serif'], weight='bold'", 
>> mplT.FontPropertiesHandler())
>> sf = T.Trait("['sans-serif']", mplT.FontPropertiesHandler())
>> use_cm = T.true
>> fallback_to_cm = T.true
>>
>> I dont think that will work. One of the highlights of the new config files 
>> is 
>> that when a file says:
>>
>> [mathtext]
>> rm = ['serif', 'sans-serif']
>>
>> you actually get a list, not a string, to pass to 
>> mplT.FontPropertiesHandler().
> 
> Right.  But it works like:
> 
> rm = "['serif', 'sans-serif']"
> 
> 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.  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?
> 
> 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


-
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


Re: [matplotlib-devel] config with traits

2007-08-22 Thread Darren Dale
On Wednesday 22 August 2007 03:09:30 pm Michael Droettboom wrote:
> This was an attempt to do a direct translation from what I had in the
> "classic" rcsetup.py.  (The previous version in mplconfig.py was
> semantically incorrect.)  I had tested this with settings in my
> matplotlib.conf, but didn't realise that the default wasn't validated
> (and thus not interpreted into a FontPropertiesProxy object).
>
> Darren Dale wrote:
> > I am trying to work out some way to make rcdefaults() work with the
> > traited config. Along the way, I discovered this in mplconfig:
> >
> > class mathtext(TConfig):
> > cal = T.Trait("['cursive']", mplT.FontPropertiesHandler())
> > rm = T.Trait("['serif']", mplT.FontPropertiesHandler())
> > tt = T.Trait("['monospace']", mplT.FontPropertiesHandler())
> > it = T.Trait("['serif'], style='oblique'",
> > mplT.FontPropertiesHandler())
> > bf = T.Trait("['serif'], weight='bold'",
> > mplT.FontPropertiesHandler()) sf = T.Trait("['sans-serif']",
> > mplT.FontPropertiesHandler()) use_cm = T.true
> > fallback_to_cm = T.true
> >
> > I dont think that will work. One of the highlights of the new config
> > files is that when a file says:
> >
> > [mathtext]
> > rm = ['serif', 'sans-serif']
> >
> > you actually get a list, not a string, to pass to
> > mplT.FontPropertiesHandler().
>
> Right.  But it works like:
>
> rm = "['serif', 'sans-serif']"
>
> 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?

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

If you want all that flexibility, why not do it in the usual way:

#mathtext.it.family  : 'serif'
#mathtext.it.style : 'oblique'

But is that much flexibility needed?

Darren

-
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


Re: [matplotlib-devel] config with traits

2007-08-22 Thread Michael Droettboom
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