GeezerVison

In the future, it may make sense to only use the glyph names (using FT2Font.get_name_index instead of FT2Font.get_char_index), and not have a mapping to character codes in our code. Unfortunately, TruetypeFonts._get_glyph expects a font+character code, so this would be a much larger refactor than this bugfix.

I don't remember the exact semantics of _get_glyph off the top of my head, but from a quick look at it, did you mean "returns" instead of "expects" (emphasis mine in the quote above)?

In the future, it may make sense to only use the glyph names (using FT2Font.get_name_index instead of FT2Font.get_char_index), and not have a mapping to character codes in our code. Unfortunately, TruetypeFonts._get_glyph expects a font+character code, so this would be a much larger refactor than this bugfix.

I don't remember the exact semantics of _get_glyph off the top of my head, but from a quick look at it, did you mean "returns" instead of "expects" (emphasis mine in the quote above)?

Right yes. In fact, I meant that its callers expect the character codes (they use FT2Font.load_char, not FT2Font.load_glyph), though I actually found an unrelated bug there: 6c7b9d0 that I tacked on to #29816.

After a bit of checking, I've found that for 12pt@100dpi, the multi-sized glyphs are 20, 30, 40, and 50 pixels, with regular text size being 16.671875 pixels (if available). So the text in the tests should look for an interior of 8.915625, 18.320833333333333, 25.156041666666667, 32.16734375, 42.03599479166666, which should hit all sizes of glyphs.

Also, removed the regular sized braces {} because they seem to be the same glyph as the first 'big' size.

I like the new implementation a lot, it's very clear (well, relative to the complexity of the task).
Only a few minor points:

• Perhaps use \__parenleftbig__ instead of \parenleftbig to make it clearer that this is an internal (intermediate) construct that's not a valid mathtext string. There's precedent in doing so for \__sqrt__.
• Perhaps start adding some code that interprets Char("\__foo__") as performing a (cached) glyph name lookup if we want to move towards using glyph names instead of glyph indices? (Note that \__sqrt__ will also need a change.)

I guess it would be OK to test only one of the output formats, as we only care that the right glyphs are selected?

Do we have anything for that yet? There's lightweight_math_tests, but it only checks DejaVu Sans, which is not the font we really want to check here.

There's svgastext?

Since FreeType and the related PRs are merged in the text-overhaul branch, I've rebased this PR onto it. I've also moved the tests to svgastext.

Image changes are in a separate last commit so they can be stripped before merging.

Rebased without test images (which were moved to the text-overhaul-figures branch) in preparation for merging.