GeezerVison

do we want to keep the old dvipng-based codepath?

What is the consequence of not doing that? Font output depending on installed FreeType version?

It seems like the bonding boxes are a bit off in the new one? The top part of \frac{1}{2}\pi seems to be rendered outside of the box?

rcParams["text.latex.use_dvipng"]? Which maybe should be True for one release? (But must be set to False to use xelatex etc.)

The top part of \frac{1}{2}\pi seems to be rendered outside of the box?

But in most cases, the "new" bounding boxes look "better"!

do we want to keep the old dvipng-based codepath?

What is the consequence of not doing that? Font output depending on installed FreeType version?

It would, although I don't think this is really a problem (there's just 3 usetex baseline images which would now need to get the same treatment as all other baseline images with text, so that only very slightly makes things worse in that aspect). The main reason to keep the old path would be for strict backcompat if anyone really cares. Also, there's the somewhat obscure case of #20469, where dvipng was providing extra support for an otherwise unsupported font type, but this was already broken for other output formats anyways, and if/when we merge {xe,lua}tex support, users will be able to use TrueType versions of the concrete math font which will just work everywhere. (Plus, if someone wants to implement pk font support per #20469 (comment), that's still an option.)

It seems like the bonding boxes are a bit off in the new one? The top part of \frac{1}{2}\pi seems to be rendered outside of the box?

I did notice that, probably needs a more careful investigation. But I also suspect this may be related to how exactly we draw the bbox (which itself has nonzero thickness). Even if we arrange for it to have exactly 1-px width, we'd probably want it to be drawn immediately outside the outermost inked pixels, which means that the height/width would likely be 1-px bigger than the text extents, and I don't think we do any of that...

rcParams["text.latex.use_dvipng"]? Which maybe should be True for one release? (But must be set to False to use xelatex etc.)

Deprecating a rcParam is a bit annoying, hence the suggestion to fold into text.latex.engine.

Baseline images change slightly, for the better or the worse.

Shall we target the text-overhaul branch then? Likely wouldn't need the old dvipng code if it lands at the same time.

Sure, that works too.

Some bits of glyph positioning seem a bit off:

import matplotlib.pyplot as plt

plt.rcParams['mathtext.fontset'] = 'cm'

texts = [
    (0.8, r'$\frac{\$100.00}{xy}$'),
    (0.5, r'$\frac{X}{\frac{X}{Y}}$'),
    (0.3, r'$\overline{\omega}^x \frac{1}{2}_0^x$'),
]

fig = plt.figure(figsize=(3, 3))

for y, t in texts:
    fig.text(0.2, y, t, verticalalignment='center', fontsize=24)
    fig.text(0.5, y, t, verticalalignment='center', usetex=True, fontsize=24)

plt.show()

The issue occurred because text.index calls get_font() (to resolve glyph indices), which would undo the call to FT_Set_Transform... fixed, and added a comment, but I guess this suggests either get_font() shouldn't reset the transform, or text.index should switch from being a property to being a real method call (e.g. resolve_index()), to make the side-effect clearer. However that doesn't need to happen in this PR.

Also need to update the rcParams type stubs.

done

I should just drop the second commit?

Thanks, copy-edited. (Side question for @timhoffm: What's the policy for multiline rcParams descriptions in rcsetup.py? e.g. here for text.latex.engine I would like to be able to do a bullet list.)
@QuLogic Should I drop the second commit (baselines update) or should I let you do it?

I can take care of dropping the commit.