Repository navigation
Vertical positioning in mathtext fraction rendering could be improved #18389
Description
Bug report
Bug summary
The positioning by mathtext of the numerator, denominator, and fraction bar are less than optimal.
Code for reproduction
from pylab import *
for usetex, y in [(False, .4), (True, .6)]:
figtext(.1, y, r"$\frac{1}{1}+\frac{x}{x}=\frac{y}{y}+\frac{t}{t}$", usetex=usetex)
figtext(.4, y, r"$\frac{1}{1}+\frac{x}{x}=\frac{y}{y}+\frac{t}{t}$", usetex=usetex, size=42)
ax = axes([0, 0, 1, 1])
ax.axhline(.65, lw=1)
ax.axhline(.56, lw=1)
ax.axhline(.455, lw=1)
ax.axhline(.355, lw=1)
show()Actual outcome
Expected outcome
I think the most commonly noticeable problem is that digits appearing in the denominator tend to bump into the fraction bar. I used to believe that that was due to a discretization problem (i.e. we need to draw the fraction bar over an integer number of pixels to avoid blurring, so if we were supposed to have e.g. 1.5 pixels above and 1.5 pixels below this could get rounded to 2 and 1), which would still be annoying but arguably a reasonable tradeoff against blurring; but actually, rendering at large sizes shows that this is not the case (at size 42 the spaces are still clearly unequal).
The other cases are a bit more artificial, but show other aspects of the problem:
- TeX puts a large-ish space above the
xin the denominator, likely to make denominators line up across fractions; the denominators are very "jagged" in the mathtext case. TeX also only slightly bumps the height of theynumerator to keep numerators nearly aligned without bumping into the fraction bar, whereas mathtext just pullsyup by its full descender. - TeX arranges for the fraction bars to clearly align with the
+sign and the center of the=, whereas mathtext's fraction bar is too low -- even though there's a comment inmathtext.pyexplicitly stating "Shift so the fraction line sits in the middle of the equals sign".
Matplotlib version
- Operating system: linux
- Matplotlib version: HEAD
- Matplotlib backend (
print(matplotlib.get_backend())): qt5agg - Python version: 38
- Jupyter version (if applicable):
- Other libraries:
Activity
timhoffm commentedon Sep 1, 2020
Guess without having checked the code: mathtext top-aligns the bounding box of the denominator.
QuLogic commentedon Sep 2, 2020
There are a couple of things for denominators at least, which I haven't all figured out.
For the descenders in the denominator (i.e.,
y), this is becausevlist.shift_amountuses thecden.height. Instead, usingcden.height + cden.depthmakes these consistent (though thetis a bit off now):The second problem is that in mathtext the height of the denominator is just the height of the character, but for consistency, TeX uses what I assume is the cap height. This appears to be fixable by adjusting the denominator height if it's less than xheight (see bottom row).
I haven't figured out the numerator stuff yet, but I guess it'd need similar tweaks with its depth. I guess that is the reason the third row appears unaligned, as the
yis in the wrong place.anntzer commentedon Sep 2, 2020
Actually I guess on TeX's side it may be worth doing an exegesis of http://brokestream.com/tex.pdf ("TeX the program"), specifically items 744-746? ("The numerator and denominator must be separated by a certain minimum clearance, called clr in the following program. The difference between clr and the actual clearance is 2delta.")
Also in your proposed fix the fraction bar of
y/yis now too low.QuLogic commentedon Sep 2, 2020
I think we do have the minimum clearance via the
Vboxs, though it should be 3*thickness, not 2? And if we do that, the rule appears to actually be in the middle of the equals sign like it's supposed to. Then handling the delta would take care of the descenders likey.Yes, I think my adjustment for things smaller than xheight but with descenders is not quite right. I didn't really confirm their meanings...
github-actions commentedon Aug 18, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
QuLogic commentedon Apr 10, 2026
The
text-overhaulbranch is now merged tomain.