FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

sub/superscripts should be moved further from the baseline following large delimiters · Issue #18086 · matplotlib/matplotlib · GitHub

Repository navigation

sub/superscripts should be moved further from the baseline following large delimiters #18086

Closed

Description

Bug report

Bug summary

Matplotlib's mathtext appears not to take the size of the preceding glyph into account when positioning sub/superscripts.

Code for reproduction

from pylab import *
figtext(.4, .5, r"$\left[\frac{x}{y}\right]^2_n$")
figtext(.5, .5, r"$\left[\frac{x}{y}\right]^2_n$", usetex=True)

Actual outcome


Note that the baseline of the 2 is even lower than the baseline of the x in the mathtext case.

Expected outcome

Something approaching the usetex case.

Matplotlib version

  • Operating system: linux
  • Matplotlib version: master
  • Matplotlib backend (print(matplotlib.get_backend())): qt5agg
  • Python version: 38
  • Jupyter version (if applicable):
  • Other libraries:

Activity

  1. tfpf commented on Nov 29, 2021

    Contributor

    I tried my hand at this, but really couldn't really gain a foothold. In the process, I found some things. Maybe these are already known to some people, but I thought I'd document them here for someone else who might consider working on this issue.

    The main problem is that the amount by which the subscript is shifted down and that by which the superscript is shifted up are not dependent on the height of the nucleus (the expression the sub- and superscript are attached to)--they are calculated only from some font constants, as this example indicates. Notice that the sub- and superscript are shifted by the same amounts, irrespective of whether the nucleus is s/r (a fraction) or (s/r) (also a fraction) or x (not a fraction).

    import matplotlib.pyplot as plt
    plt.figure().text(.1, .5, r'$\left(\dfrac{s}{r}\right)_i^3 x_i^3 \dfrac{s}{r}_i^3$', size=50)
    plt.show()
    

    In theory, this should be easy to fix. If the nucleus is a fraction, move the subscript down by nucleus.depth, and the superscript up by nucleus.height - superscript.height. (The result won't exactly resemble what LaTeX gives us, but might be good enough.) But we don't have the nucleus if it is a fraction!

    More specifically, for x_i^3, the subsuper function in _mathtext.py receives the tokens x, _, i, ^ and 3. But for \left(\dfrac{s}{r}\right)_i^3, it receives an Hlist (basically, the constructed nucleus, (s/r)) in one call, and the tokens _, i, ^ and 3 in the next call. Which means that when the time comes to shift the sub- and superscript, the nucleus is unavailable.

    I initially tried to store the height and depth of each nucleus encountered in a new class variable--fairly sure that new nuclei are created here. That fixed the above example, but broke things like \dfrac{(x-y)^2}{2}, since not all things returned by that line are nuclei. I couldn't quite figure out the logic for detecting what is a nucleus and what isn't.

    If somebody has any good ideas ...

  2. anntzer commented on Nov 29, 2021

    ContributorAuthor

    Thank you for investigating this. It may be worth trying to figure out in the TeXbook the exact algorithm used by TeX (similarly to what was done in #18389 (comment))?

  3. tfpf commented on Nov 30, 2021

    Contributor

    From a quick reading of some relevant parts of the book (sections 687, 690, 696 and 742), it looks like the algorithms do indeed use the nucleus in some way to correctly position the subscripts and superscripts. Section 751 details the calculation of shift_down and shift_up; I dare say the calculation for subscripts and superscripts for fractions should be similar. One thing is certain: we definitely need the nucleus height (and depth, too, I think).

    The subsuper function does not receive the nucleus along with the subscript and superscript, though. So, perhaps implementing the algorithm described in the book won't help? I can think of two alternatives: find out a way to detect and store the information of all nuclei encountered (I tried this, but couldn't make it work), or rework what arguments are passed to this function (and make the necessary changes in the function body itself).

  4. QuLogic commented on Dec 3, 2021

    Member

    The subsuper function does not receive the nucleus along with the subscript and superscript, though.

    Doesn't it? I see a nucleus in the function, though it does appear to be optional for some cases.

    nucleus = None

  5. tfpf commented on Dec 3, 2021

    Contributor

    Exactly. When the nucleus is a fraction, this function is called multiple times. Once with an Hbox of the fraction. And once with the sub- and superscript, with the nucleus being an empty Hbox. (At least, that's my understanding.)

    ETA I see now; I said that wrong. What I meant was: The subsuper function does not receive the nucleus along with the subscript and superscript when the nucleus is a fraction.

  6. github-actions commented on Aug 14, 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!

  7. added
    keepItems to be ignored by the “Stale” Github Action
    and removed
    status: inactiveMarked by the “Stale” Github Action
    on Aug 15, 2023
  8. anntzer commented on Aug 15, 2023

    ContributorAuthor

    @devRD pinging you here, just in case this may be of interest for you :)

  9. mendenmh commented on Apr 29, 2024

    This is still a problem. I didn't notice the very old report of it here, and duplicated it in #28149, which I subsequently closed, since this is the same.

  10. tfpf commented on May 5, 2024

    Contributor

    @mendenmh I gave this a shot in #22852. Even got a working solution. But couldn't fix the tests in a satisfactory way! For one, it is extremely hard to review all image comparison tests. Not to mention the fact that the hinting mysteriously changed between tests and normal runs. You're welcome to try if you have any ideas!

  11. mendenmh commented on May 6, 2024

  12. added this to the v3.11.0 milestone on Jan 28, 2026
  13. moved this from Waiting for other PR to In Progress in Font and text overhaulon Jan 28, 2026
  14. removed
    keepItems to be ignored by the “Stale” Github Action
    on Apr 10, 2026
  15. QuLogic commented on Apr 10, 2026

    Member

    The text-overhaul branch is now merged to main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


    Back | FazBrowse Home | New Git URL