@anntzer This should about do it. Seems mpl ships only with DejaVu Sans/STIX so I couldn't test a real figure against an incomplete font that would have to get substituted.

Unsure what's failing the docs though

@geib7592 Can you please comment on this PR? Thanks!

Looking a bit below, it appears that DejaVuFonts (the actual default) already implements its own fallback solution, which goes to stix, not not cm. If you set mathtext.fallback, does that also override the fallback for dejavu?

I guess this suggests that the proper solution may instead to make mathtext.fontset accept a list of fonts, falling back from one to the next (so e.g. mathtext.fontset: dejavusans, stix or custom, cm or whatnot -- where custom is again defined by mathtext.{cal,rm,tt,it,bf,sf}).

Looking a bit below, it appears that DejaVuFonts (the actual default) already implements its own fallback solution, which goes to stix, not not cm. If you set mathtext.fallback, does that also override the fallback for dejavu?

I guess this suggests that the proper solution may instead to make mathtext.fontset accept a list of fonts, falling back from one to the next (so e.g. mathtext.fontset: dejavusans, stix or custom, cm or whatnot -- where custom is again defined by mathtext.{cal,rm,tt,it,bf,sf}).

IIUC fallback_to_cm only came to effect when using a math.text = custom and the behaviour should not be changed in this PR.

I agree it would be nicer to have a fallback list, but that seems like it would require major code changes, meanwhile the functionality in this PR (or the original PR indeed) is good enough.

Though it could be easily extended to also so StixSansFonts.

Hello, it's me from #8619. I'm excited to see someone working on this issue. It seems that since matplotlib ships with stix and dejavu sans, adding a fallback to dajavu sans (and stix sans) could be another (very similar) PR, and in my opinion, it would be worthwhile for flexibility in using custom sans-serif fonts.

Allowing a custom fallback font is likely more work, but would be useful for cases I pointed out in #8619. (@anntzer, your suggestion for having mathtext.fontset be a list seems to preclude the future possibility of having a custom fallback font)

I think @anntzer also suggested I add my two cents about why this PR is important. Since posting the feature request in 2017, I've thought a fair amount about how to typeset publication-quality scientific figures. Currently, I don't think any free (or even non-free) software does it perfectly, and it's an area where, with a few well chosen tweaks, matplotlib could really excel.

For example, major scientific publishing companies like Nature and Science explicitly prefer Helvetica for the text of their figures. For Greek letters and mathematical symbols, they use a similarly weighted serif font used in their main text. This PR as it stands really helps move in the right direction; the example in #11644 shows how to use Helvetica with a fallback to stix, which gets closer to Nature's guideline.

I'd love to see more development toward industry standard design principles in the future with similar tweaks to the mathtext and latex engines. If the matplotlib devs are interested, I'd be happy to discuss and get more involved.

Thanks for all your work!

I'm fine with not doing the most general approach; I just want the various fallback options and their interaction to be properly documented (e.g. whether mathtext.fallback affects dejavu fallback as well).

your suggestion for having mathtext.fontset be a list seems to preclude the future possibility of having a custom fallback font

why?

Maybe I misunderstood, but right now custom mathfont requires mathtext.fontset=custom, so if you also wanted a custom fallback, you'd need a second custom setting, like allowing mathtext.{cal,rm,tt,it,bf,sf} to be lists too, where missing characters are sourced down the list.

Ah yes, you want to fallback from one custom font to another one...
I guess making all of mathtext.cal/rm/... lists too would work indeed? (not that it has to be done in this PR)

If you look a bit below, class DejaVuFonts has

class DejaVuFonts(UnicodeFonts):
    use_cmex = False

    def __init__(self, *args, **kwargs):
        # This must come first so the backend's owner is set correctly
        if isinstance(self, DejaVuSerifFonts):
            self.cm_fallback = StixFonts(*args, **kwargs)
        else:
            self.cm_fallback = StixSansFonts(*args, **kwargs)
        self.bakoma = BakomaFonts(*args, **kwargs)
        TruetypeFonts.__init__(self, *args, **kwargs)

(the point I was mentioning above)

I'm actually now a bit confused by why DejaVuFonts inherits from UnicodeFonts but calls TruetypeFonts.__init__ in its __init__, and am not even sure anymore that DejaVuFonts.cm_fallback is ever used?

I think we all agree that what we want is a fallback list for math as well. However, since that's major surgery, especially since the default fonts have a bunch of no-warnings/no-docs fallback which should likely be overhauled, we should open this as a new issue for a new PR.

This PR bring major improvement in just being able to have a sans-serif math fallback for custom fonts. Fulfilling most of what was requested in the 3 separate issues #8619, #11644 and #16492

Re some details, I added the option to explicitly ask for stixsans but actually have trouble finding characters that would be missing in a default font (say Arial) and would be different between stix and stixsans, which seem to differ for regular alphabet chars, but not so much for math symbols. (Basically I can't test is)

Otherwise, if we can agree on this functionality I'll update the tut/whats_new etc...

I think you can add a test by picking some math strings that include a character that's not present in e.g. dejavusans but present in cm/stix/stixsans, and then saving a svg file with that string and rcParams["svg.fonttype"] = None, with fallback configured to cm/stix/stixsans/nofallback, which will saves the individual glyphs; you can then check that fallback correctly occurred (or not, if not falling back).

Ok, I did the SVG check and the fallbacks work fine, the issue is just that some of the math characters are the same for both stix/stixsans e.g.("#STIXGeneral-Regular-10938") In reality it looks like it won't matter if the math fallback is stix or stixsans

It's fine if the test doesn't cover all cases, it would still be an improvement over the current situation.

@anntzer that should be it

A test (per #16509 (comment)) would be nice.

lgtm, can you please squash?

phew I'm just gonna drop this here when I inevitably need it again https://blog.appsignal.com/2016/09/27/git-rebasing-strategies.html

looks like you got it to work :)

what's failing the codecov?

It's not failing?

flake8 is unhappy though

./lib/matplotlib/rcsetup.py:443:25: E128 continuation line under-indented for visual indent
2390./lib/matplotlib/rcsetup.py:444:25: E128 continuation line under-indented for visual indent
23912     E128 continuation line under-indented for visual indent

It's not failing?

somehow it's transient?

Now it's back.
It's pretty flaky anyways (they likely have some race conditions against when the CI run finishes), so we don't overly worry about it.

@anntzer what about the codecov

it's fine.