SourceForge logo
SourceForge logo
Menu

matplotlib-devel — matplotlib developers

You can subscribe to this list here.

2003 Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
(1)
Nov
(33)
Dec
(20)
2004 Jan
(7)
Feb
(44)
Mar
(51)
Apr
(43)
May
(43)
Jun
(36)
Jul
(61)
Aug
(44)
Sep
(25)
Oct
(82)
Nov
(97)
Dec
(47)
2005 Jan
(77)
Feb
(143)
Mar
(42)
Apr
(31)
May
(93)
Jun
(93)
Jul
(35)
Aug
(78)
Sep
(56)
Oct
(44)
Nov
(72)
Dec
(75)
2006 Jan
(116)
Feb
(99)
Mar
(181)
Apr
(171)
May
(112)
Jun
(86)
Jul
(91)
Aug
(111)
Sep
(77)
Oct
(72)
Nov
(57)
Dec
(51)
2007 Jan
(64)
Feb
(116)
Mar
(70)
Apr
(74)
May
(53)
Jun
(40)
Jul
(519)
Aug
(151)
Sep
(132)
Oct
(74)
Nov
(282)
Dec
(190)
2008 Jan
(141)
Feb
(67)
Mar
(69)
Apr
(96)
May
(227)
Jun
(404)
Jul
(399)
Aug
(96)
Sep
(120)
Oct
(205)
Nov
(126)
Dec
(261)
2009 Jan
(136)
Feb
(136)
Mar
(119)
Apr
(124)
May
(155)
Jun
(98)
Jul
(136)
Aug
(292)
Sep
(174)
Oct
(126)
Nov
(126)
Dec
(79)
2010 Jan
(109)
Feb
(83)
Mar
(139)
Apr
(91)
May
(79)
Jun
(164)
Jul
(184)
Aug
(146)
Sep
(163)
Oct
(128)
Nov
(70)
Dec
(73)
2011 Jan
(235)
Feb
(165)
Mar
(147)
Apr
(86)
May
(74)
Jun
(118)
Jul
(65)
Aug
(75)
Sep
(162)
Oct
(94)
Nov
(48)
Dec
(44)
2012 Jan
(49)
Feb
(40)
Mar
(88)
Apr
(35)
May
(52)
Jun
(69)
Jul
(90)
Aug
(123)
Sep
(112)
Oct
(120)
Nov
(105)
Dec
(116)
2013 Jan
(76)
Feb
(26)
Mar
(78)
Apr
(43)
May
(61)
Jun
(53)
Jul
(147)
Aug
(85)
Sep
(83)
Oct
(122)
Nov
(18)
Dec
(27)
2014 Jan
(58)
Feb
(25)
Mar
(49)
Apr
(17)
May
(29)
Jun
(39)
Jul
(53)
Aug
(52)
Sep
(35)
Oct
(47)
Nov
(110)
Dec
(27)
2015 Jan
(50)
Feb
(93)
Mar
(96)
Apr
(30)
May
(55)
Jun
(83)
Jul
(44)
Aug
(8)
Sep
(5)
Oct
Nov
(1)
Dec
(1)
2016 Jan
Feb
Mar
(1)
Apr
May
Jun
(2)
Jul
Aug
(3)
Sep
(1)
Oct
(3)
Nov
Dec
2017 Jan
Feb
(5)
Mar
Apr
May
Jun
Jul
(3)
Aug
Sep
(7)
Oct
Nov
Dec
2018 Jan
Feb
Mar
Apr
May
Jun
Jul
(2)
Aug
Sep
Oct
Nov
Dec
S M T W T F S



1
(4)
2
(7)
3
(4)
4
5
(2)
6
(4)
7
8
(2)
9
(12)
10
(11)
11
(1)
12
(4)
13
(12)
14
(13)
15
(6)
16
(10)
17
(5)
18
(1)
19
(1)
20
(8)
21
(5)
22
(7)
23
(2)
24
(1)
25
26
27
(2)
28
(2)
29
(6)
30
(13)
31
(6)

Showing 2 results of 2

From: Michael D. <md...@st...> - 2007年08月23日 13:26:17
Darren Dale wrote:
> On Wednesday 22 August 2007 4:20:08 pm Michael Droettboom wrote:
>> Darren Dale wrote:
>>> 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.
> 
> Right: 
> 
> mathtext.it : serif-12:italic # use the default serif, 12 pt italic
> or
> mathtext.it : times:italic # use the times italic font, default size
> 
> Could this syntax be adopted, even without fontconfig? Then if we decided to 
> use fontconfig in the future, the disruption would not be too great.
Sure, it's certainly an easy enough format to support.
Of course, the matching algorithm used by font_manager.py is different 
from fontconfig. font_manager.py essentially looks for an exact match 
or falls back to a single default. fontconfig does a nearest neighbor 
search, so often finds a better alternative. So even if they use the 
same syntax, the results will be different (in some side cases) if we 
ever move over to fontconfig. (There are pros and cons to using 
fontconfig already discussed on this list. I'm not really advocating 
for or against it myself.)
Still, IMHO, it's worth supporting this syntax now even though users may 
need to change their font specifiers later -- those changes should be 
more minor than if we go with
#mathtext.it.family : 'serif'
#mathtext.it.style : 'oblique'
now.
If we go this way, it would also be worthwhile to support this syntax 
internally (anywhere a FontProperties object is currently accepted it 
could alternatively be a fontconfig string.)
Cheers,
Mike
From: Darren D. <dd...@co...> - 2007年08月23日 11:52:25
On Wednesday 22 August 2007 4:20:08 pm Michael Droettboom wrote:
> 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.
Right: 
mathtext.it : serif-12:italic # use the default serif, 12 pt italic
or
mathtext.it : times:italic # use the times italic font, default size
Could this syntax be adopted, even without fontconfig? Then if we decided to 
use fontconfig in the future, the disruption would not be too great.
Darren 

Showing 2 results of 2

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /