Skip to content

Vertical positioning in mathtext fraction rendering could be improved #18389

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
anntzer opened this issue Sep 1, 2020 · 5 comments
Open

Vertical positioning in mathtext fraction rendering could be improved #18389

anntzer opened this issue Sep 1, 2020 · 5 comments
Labels
keep Items to be ignored by the “Stale” Github Action topic: text/mathtext

Comments

@anntzer
Copy link
Contributor

anntzer commented Sep 1, 2020 •
edited
Loading

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

test

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 x in 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 the y numerator to keep numerators nearly aligned without bumping into the fraction bar, whereas mathtext just pulls y up 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 in mathtext.py explicitly 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:
@timhoffm
Copy link
Member

timhoffm commented Sep 1, 2020

Guess without having checked the code: mathtext top-aligns the bounding box of the denominator.

grafik

@QuLogic
Copy link
Member

QuLogic commented Sep 2, 2020 •
edited
Loading

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 because vlist.shift_amount uses the cden.height. Instead, using cden.height + cden.depth makes these consistent (though the t is a bit off now):
Figure_1

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).
Figure_1

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 y is in the wrong place.

@anntzer
Copy link
Contributor Author

anntzer commented Sep 2, 2020 •
edited
Loading

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/y is now too low.

@QuLogic
Copy link
Member

QuLogic commented Sep 2, 2020

("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.")

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 like y.

Also in your proposed fix the fraction bar of y/y is now too low.

Yes, I think my adjustment for things smaller than xheight but with descenders is not quite right. I didn't really confirm their meanings...

@QuLogic QuLogic mentioned this issue Jul 20, 2021
Closed
2 tasks
@jklymak jklymak linked a pull request Nov 26, 2021 that will close this issue
Align vinculum of fractions using minus sign instead of equals sign #20627
Closed
2 tasks
@anntzer anntzer mentioned this issue Nov 29, 2021
Open
@tfpf tfpf mentioned this issue Jan 9, 2022
Open
@tfpf tfpf mentioned this issue Apr 15, 2022
Closed
3 tasks
@devRD devRD mentioned this issue Jul 28, 2023
Draft
5 tasks
@github-actions
Copy link

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!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Aug 18, 2023
@ksunden ksunden added keep Items to be ignored by the “Stale” Github Action and removed status: inactive Marked by the “Stale” Github Action labels Aug 18, 2023
@QuLogic QuLogic mentioned this issue Apr 28, 2025
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
keep Items to be ignored by the “Stale” Github Action topic: text/mathtext
Projects
None yet
Milestone
No milestone
4 participants
@QuLogic @anntzer @ksunden @timhoffm