>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
Edin> Hi all, I have modified mathtext so it can use the fonts
Edin> based on rcParams. The new class is defined as follows:
Edin> class MyUnicodeFonts(UnicodeFonts): prop =3D FontProperties()
Edin> prop.set_family('serif') rmfile =3D fontManager.findfont(prop)
Edin> prop.set_family('fantasy') calfile =3D
Edin> fontManager.findfont(prop)
Edin> prop.set_family('monospace') ttfile =3D
Edin> fontManager.findfont(prop)
Edin> prop.set_family('serif') prop.set_style('italic') itfile
Edin> =3D fontManager.findfont(prop) filenamesd =3D { 'rm' : rmfile,
Edin> 'it' : itfile, 'cal' : calfile, 'tt' : ttfile,
Edin> }
Edin> Is this OK?
One downside of this approach is that it generates a lot of warnings
on every script because the calls like
prop =3D FontProperties()
prop.set_family('serif')
rmfile =3D fontManager.findfont(prop)
are done on import of the mathtext module, rather than on class
initialization. You might do something like
class MyUnicodeFonts(UnicodeFonts):
_initialized =3D False
def __init__(self):
if not MyUnicodeFonts._initialized:
prop =3D FontProperties()
prop.set_family('serif')
self.rmfile =3D fontManager.findfont(prop)
prop.set_family('fantasy')
self.calfile =3D fontManager.findfont(prop)
prop.set_family('monospace')
self.ttfile =3D fontManager.findfont(prop)
prop.set_family('serif')
prop.set_style('italic')
self.itfile =3D fontManager.findfont(prop)
self.filenamesd =3D { 'rm' : self.rmfile,
'it' : self.itfile,
'cal' : self.calfile,
'tt' : self.ttfile,
}
MyUnicodeFonts._initialized =3D True
This defers the initialization until it is needed, and importantly
prevents users (like me) from getting warnings on *every* matplotlib
script (regardless of whether I use mathtext), like
/usr/lib/python2.4/site-packages/matplotlib/font_manager.py:987:
UserWarning: Could not match fantasy, normal, normal. Returning
/usr/lib/python2.4/site-packages/matplotlib/mpl-data/Vera.ttf
warnings.warn('Could not match %s, %s, %s. Returning %s' % (name,
style, variant, self.defaultFont))
/usr/lib/python2.4/site-packages/matplotlib/font_manager.py:987:
UserWarning: Could not match serif, italic, normal. Returning
/usr/lib/python2.4/site-packages/matplotlib/mpl-data/Vera.ttf
warnings.warn('Could not match %s, %s, %s. Returning %s' % (name,
style, variant, self.defaultFont))
Edin> Now all the backends can work with the new mathtext, and on
Edin> all platforms, and I haven't introduced a single bug.=20
A bold claim -- are you willing to back that up, as Knuth does, with
an offer of a financial reward for any bugs found?
Edin> this now be commited to the svn?
It is committed (svn revision 2535), with the changes I suggested
above. I also added you as a developer, so you should get a fresh svn
developer checkout and you can commit directly. Be sure to modify the
CHANGELOG and API_CHANGES with your commits.
As you may know, you should avoid naming things like MyClass. So for
your next patch, how about making the proposed rc changes that will
allow the users to select bakoma or some other set of mathtext fonts,
and rename MyUnicodeFonts.
Also, please provide some example code showing how to use mathtext on
an arbitrary backend (non Agg, non PS). Me thinks there may be a bit
more work yet to be done, but you are definitely on the right track.
Edin> I was wondering if it could be added to the matplotlibrc a
Edin> key-value pair like "mathtext.usebakoma :True" or something,
Edin> so someone who wants to try out the new mathtext can easily
Edin> do so?
This looks OK for testing purposes -- we may want something more
generic going forward.
Edin> Also John, will I now begin to work on adding new
Edin> features/TeX commands to mathtext?
Well, let's get the rc and backend configuration issues settled, and
also see if we can find a good set of free unicode fonts that are
superior to bakoma that we could ship.
Thanks!
JDH