After some discussion in our GSoC meeting, this is probably the reverse of the way to fix the issue. It appears that the raster output is shifted up when it shouldn't be (i.e., if it's a regular fraction, then all text is on the baseline, but with the test case from#23763,all text is moved up (disregarding the missing shift for the patched fraction.)) The vector output remains on the baseline for both versions.

Possibly, the raster output needs the correct width, height, and depth to view a similar output to the vector image. The current dimensions for vector are given as:

Applying the same calculations to the raster gives the following output, which is still shifted upwards and cuts off the end of the denominator text.

Hrule.png	Hrule.svg

A few pointers from the above images:

1. The fraction appears to be askew as well compared to theusetex=True version and could be related toissue #18389
2. Thethickness of theHrule seems to be different than the TeX version.
3. The fraction gets misaligned from the center of the= sign.

The raster output being cut off might be caused due to theshifted calculation:

So updatingfor ox, oy, info in shifted.glyphs: to fetchox,oy fromself.glyphs kind of fixes the issue here.

Hrule.png	Hrule.svg

I also tinkered around with the_genfrac function to check whether removing additional spacing improves the alignment of the images when rendering fractions.

Hrule.png	Hrule.svg

@anntzer@oscargus Any insights on how to proceed with this?

Additionally, with the above edits the#23763 example ofhrule rendering, theHrule seems to disappear completely in the raster output.

Hrule.png	Hrule.svg

I'll have limited access to a dev machine for a few days, but can look into it after.

I haven't looked in depth into what's happening here, but 1) skipping the int-casting (via np.ceil) for vector output would seem normal, but can (likely?) cause shifts wrt. raster output; 2) perhaps#15339 (comment) and (the last part of)#15339 (comment) may be relevant?