Here's what the image produced by the exact same script run under matplotlib 1.5.1 looks like:
Note how in matplotlib 1.5.1 the y axis label is drawn using the font I specify in the script (stixgeneral). Under matplotlib 2.0b1, the font is unconditionally set to the default matplotlib font no matter what I do.
This underlying issue is currently causing some labels in yt plots to be rendered with the incorrect font under matplotlib 2.0b1.
Spent a little bit of time digging into matplotlib internals. It's easiest to see a difference by looking at the render_glyph method of the Fonts object, defined in mathtext.py.
Under matplotlib 1.5.1, the call to _get_info inside render_glyph returns a font object with the following filename on my setup:
So it looks like the real issue is that mathtext used to be rendered in a serif computer modern font by default, but now defaults to a sans-serif DejaVuSans font.
Is there a way to modify the script I linked to in the issue description to pick out the computer modern font matplotlib used to use?
More precisely, is there a way to set the font used by matplotlib for mathtext rendering using the object-oriented interface? I don't think I can do this by setting rcparams, as suggested in the docs, since this is in the context of a library depending on matplotlib rather a user script making use of matplotlib.
I don't think I can do this by setting rcparams, as suggested in the docs, since this is in the context of a library depending on matplotlib rather a user script making use of matplotlib.
Indeed there's no way other than setting an rcParam at present. You can, however, use the rcParam context manager to change it to what you need and then automatically change it back.
I don't think I can do this by setting rcparams, as suggested in the docs,
since this is in the context of a library depending on matplotlib rather a
user script making use of matplotlib.
Indeed there's no way other than setting an rcParam at present. You can,
however, use the rcParam context manager to change it to what you need and
then automatically change it back.
Activity
ngoldbaum commented on May 31, 2016
Spent a little bit of time digging into matplotlib internals. It's easiest to see a difference by looking at the render_glyph method of the Fonts object, defined in mathtext.py.
Under matplotlib 1.5.1, the call to _get_info inside render_glyph returns a font object with the following filename on my setup:
/Users/goldbaum/Documents/matplotlib/lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf
While on matplotlib 2.0b1, it returns a font object with the following filename:
/Users/goldbaum/Documents/matplotlib/lib/matplotlib/mpl-data/fonts/ttf/DejaVuSans-Oblique.ttf
So it looks like the real issue is that mathtext used to be rendered in a serif computer modern font by default, but now defaults to a sans-serif DejaVuSans font.
Is there a way to modify the script I linked to in the issue description to pick out the computer modern font matplotlib used to use?
ngoldbaum commented on May 31, 2016
ping @zblz @mdboom since they appear to be the ones who have worked on these code paths in mathtext.
ngoldbaum commented on May 31, 2016
More precisely, is there a way to set the font used by matplotlib for mathtext rendering using the object-oriented interface? I don't think I can do this by setting rcparams, as suggested in the docs, since this is in the context of a library depending on matplotlib rather a user script making use of matplotlib.
ngoldbaum commented on Jun 1, 2016
I'm going to close this and open another issue with a feature request about controlling mathtext fonts via the OO API.
mdboom commented on Jun 1, 2016
Indeed there's no way other than setting an rcParam at present. You can, however, use the rcParam context manager to change it to what you need and then automatically change it back.
WeatherGod commented on Jun 1, 2016
IIRC, it is possible to pass in a dictionary to the context manager rather
than a style filename... right?
On Wed, Jun 1, 2016 at 8:32 AM, Michael Droettboom <notifications@github.com
mdboom commented on Jun 1, 2016
@WeatherGod: Yes.