Skip to content

'mathtext.fontset' is only available as an rcParam, should be carried along with text object #7107

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
FaustinCarter opened this issue Sep 13, 2016 · 4 comments
Labels
Difficulty: Hard https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues topic: text/mathtext
Milestone

Comments

@FaustinCarter
Copy link

Matplotlib version 1.5.1
Installed via Anaconda

Issue: When formatting labels (or any text object), one may specify a fontdict dictionary of options. This fontdict supersedes the rcParams and ensures that the text object is always rendered correctly. However, if the text object includes math between dollar signs (i.e. '$a=5$') and the matplotlib.mathtext.Parser is used to render the math, the font-face for the rendered math is specifiable only in the rcParams. This makes it impossible to specify an explicit font face for math within a text object, as whenever that object renders, the math font will always be set by the 'mathtext.fontset' rcParam. This is especially problematic when using matplotlib in interactive mode (i.e. IPython), as every time the text object is rendered, the math font face will change appearance based on the current rcParam value, but all of the other font attributes will continue to be set by the associated fontdict.

This may not seem like a big deal, but imagine a developer releases a function to a user that returns a figure object with math in the labels. The developer has chosen to use a sans-serif face for the math, and so changes the rcParams (as this is currently the only handle). Now any future plots the user generates during that interactive session (or in the same script) will silently use the modified rcParam, rather than the users' chosen default, contrary to expectations.

Suggested fix: add a mathdict arg to text objects, which would be analogous to the fontdict arg, but for all the mathtext rcParams, and pass that to the mathtext parser.

@tacaswell tacaswell added this to the 2.0 (style change major release) milestone Sep 14, 2016
@tacaswell
Copy link
Member

@FaustinCarter Thank you for the very clear explanation of the problem.

Related to #7005 as it relates to when rcParams are bound to an artist (at creation time or draw time).

@FaustinCarter
Copy link
Author

@tacaswell Thanks for the quick reply. Looking forward to the new release!

@NelleV NelleV added the Difficulty: Medium https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues label Oct 10, 2016
@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.0 (style change major release) Dec 4, 2016
@tacaswell tacaswell added Difficulty: Hard https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues and removed Difficulty: Medium https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues labels Dec 4, 2016
@tacaswell
Copy link
Member

This is not as easy as I thought it would be. The instance of MathTextParser is owned by the renderer and eventually called from draw_text or draw_tex by Text.text. The right thing to do here is to extend the arguments to the text-related renderer calls to optionally pass the extra parameters through, change the API in MathTextParser.parse to optionally take in the properties, and fix all of the backends we ship, and advertise this change wide enough for third-party backends to be aware they may need to update.

attn @mdboom

QuLogic added a commit to QuLogic/matplotlib that referenced this issue Mar 19, 2017
See matplotlib#7911 for why these tests are flaky and matplotlib#7107 for why they are not
so easy to fix.
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Mar 19, 2017
See matplotlib#7911 for why these tests are flaky and matplotlib#7107 for why they are not
so easy to fix.
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Mar 24, 2017
See matplotlib#7911 for why these tests are flaky and matplotlib#7107 for why they are not
so easy to fix.
dstansby pushed a commit to dstansby/matplotlib that referenced this issue Apr 12, 2017
See matplotlib#7911 for why these tests are flaky and matplotlib#7107 for why they are not
so easy to fix.
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Apr 17, 2017
See matplotlib#7911 for why these tests are flaky and matplotlib#7107 for why they are not
so easy to fix.
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Apr 21, 2017
See matplotlib#7911 for why these tests are flaky and matplotlib#7107 for why they are not
so easy to fix.
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Apr 23, 2017
See matplotlib#7911 for why these tests are flaky and matplotlib#7107 for why they are not
so easy to fix.
QuLogic added a commit to QuLogic/matplotlib that referenced this issue Apr 28, 2017
See matplotlib#7911 for why these tests are flaky and matplotlib#7107 for why they are not
so easy to fix.
@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@anntzer
Copy link
Contributor

anntzer commented Feb 19, 2022

Closed by #18145.

@anntzer anntzer closed this as completed Feb 19, 2022
@QuLogic QuLogic modified the milestones: needs sorting, v3.4.0 Feb 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Difficulty: Hard https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues topic: text/mathtext
Projects
None yet
Development

No branches or pull requests

5 participants