As noted in #18039 I don't think this implementation is satisfactory; for example STIXGeneral is only provided by matplotlib on my computer and therefore trying to display in with this mechanism (which uses the browser's OS integration to lookup the font) silently renders a different font instead. I guess(?) a strategy may be to use something like https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face to explicitly specify a local font path instead.

@anntzer Thank you for the review! I agree, the prior implementation will not render the correct font. I updated the PR to load the font using font-face and updated tests. Can you take another look?

Does this actually render the right font e.g. from a jupyter notebook? From local testing it doesn't seem so?

I think it would be better to render to make a temporary Figure and put a base64 encodeding png (or a svg with the paths embeded) in the html repr (and also add _repr_png_).

@ambi7 Thank you for working on this! I hope you are not discouraged by the initial feedback.

Does this actually render the right font e.g. from a jupyter notebook? From local testing it doesn't seem so?

Yes, font-face was having issues loading fonts from file when rendering from a jupyter notebook. I took @tacaswell suggestion and rendered the font via a png image. Looks like it is now rendering the right font from a jupyter notebook by using a temporary Figure

I like png as well here, but @timhoffm didn't (#18039 (comment)).

@timhoffm Any additional comments in regards to this implementation?

I can see the argument for images, that decouple the font rendering from the display.

So, this seems the defensive and sane approach. Still I'd like to see HiDPI-support for the rendered images, but that doesn't have to be necessarily part of this PR.

Cleared @anntzer 's review because it was of the "ask the browser to render it" implementation.

Thanks @ambi7!