In the future, it may make sense to only use the glyph names (usingFT2Font.get_name_index instead ofFT2Font.get_char_index), and not have a mapping to character codes in our code. Unfortunately,TruetypeFonts._get_glyphexpects 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 (usingFT2Font.get_name_index instead ofFT2Font.get_char_index), and not have a mapping to character codes in our code. Unfortunately,TruetypeFonts._get_glyphexpects 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 itscallers expect the character codes (they useFT2Font.load_char, notFT2Font.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 interpretsChar("\__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'slightweight_math_tests, but it only checks DejaVu Sans, which is not the font we really want to check here.

There's svgastext?