So would this fix the weird uneven baseline that seems to happen in some (all?) mathtext test images?

Not right now, but I have a plan...

Basically the origin of the uneven baselines, I think, is that draw_glyph_to_bitmap specifies the top right corner of the glyph, but that can be a fractional value (FreeType gives glyph sizes in (1/64)px) and then there is some roundoff when actually copying the glyph outline to the FT2Image which leads to the baseline being unaligned.

I think best would be to fix the mathtext logic to position glyphs by baseline/right position and adjust draw_glyph_to_bitmap accordingly; alternatively we can "reverse-engineer" the values that need to be sent to draw_glyph_to_bitmap to fix that roundoff.

I was just digging through this code in an attempt to understand #15313. If you are thinking about it all and understand it, can you add a few comments for posterity?

Yes, I need to write up something...

This also mostly fixes #18899, but the example at #18899 actually shows that the glyphs are also cut in the horizontal direction:

The bottom left corner of the x and the right edges of the digits (using mathtext) are clearly cut with this PR :/

I think another problem is that draw_text_to_bitmap doesn't support subpixel positioning, there seems to be some story related to sub_offset at the C level and old commits from @mdboom mentioning links with the wiggly baseline problem...

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.

Should likely be kept and put in in some form once the baseline image machinery is revamped.

Is this still relevant after all the refactors and changes in the text-overhaul branch?

Indeed, this has been fixed by the direct-rendering mechanism.