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

a bug that latex expression with subscripts exceeds bbox · Issue #14177 · matplotlib/matplotlib · GitHub

Repository navigation

a bug that latex expression with subscripts exceeds bbox  #14177

Closed

Description

Bug report

the background box for a text object that is composed via latex with subscript can not be covered by the box if letting the padding of the box be equal to 0

ax.annotate(r'$A_{\tiny 1}$', xy=(0.5,0.5), bbox=dict(boxstyle='round,pad=0', fc='w', ec='none'))

Expected outcome : the text has a white background as small as possible and include all of the text

Actual outcome : the text always exceeds the bbox unless using a bigger padding that is ugly

Matplotlib version

  • Operating system: windows 10 x64
  • Matplotlib version: 3.0.2
  • Matplotlib backend (print(matplotlib.get_backend())): tkagg
  • Python version: 3.7.0
  • Jupyter version (if applicable):
  • Other libraries:

Activity

  1. timhoffm commented on May 11, 2019

    Member

    Example

    import matplotlib.pyplot as plt
    
    kw = dict(
        fontsize=40,
        bbox=dict(boxstyle='round,pad=0', fc='lightsteelblue', ec='none')
    )
    
    plt.axhline(y=0.7)
    plt.annotate('A', xy=(0.3, 0.7), **kw)
    plt.annotate(r'$A$', xy=(0.4, 0.7), **kw)
    plt.annotate(r'$A_{\tiny 1}$', xy=(0.5, 0.7), **kw)
    plt.annotate(r'$A_{\tiny 1j}$', xy=(0.65, 0.7), **kw)
    
    plt.axhline(y=0.4)
    plt.annotate('A', xy=(0.3, 0.4), va='bottom', **kw)
    plt.annotate(r'$A$', xy=(0.4, 0.4), va='bottom', **kw)
    plt.annotate(r'$A_{1}$', xy=(0.5, 0.4), va='bottom', **kw)
    plt.annotate(r'$A_{1j}$', xy=(0.65, 0.4), va='bottom', **kw)
    

    Observations

    • Having subscripts in LaTeX shifts the text upwards, but doesn't change the size of the bbox.
    • Interestingly though, the box gets higher, if I use 1j instead of 1 as a subscript.
    • Verticalalignment (bottom or baseline (the default)) results in the same positioning of the box, no matter what text is used.
  2. anntzer commented on May 23, 2021

    Contributor

    @timhoffm's example now gives

    so it seems like the baseline case has been fixed (possibly by #16476). The "bottom" alignment case remains, but I suspect that can be fixed "relatively" easily because the dvi parser knows the descent of each glyph, so should be able to return the text's bbox. (Although it seems like "bottom" alignment has the big space below even in the non-usetex, non-mathtext case?)

  3. timhoffm commented on May 24, 2021

    Member

    Except for $A_{\tiny 1}$ all examples still appear to be shifted by 1px upwards.

  4. anntzer commented on May 24, 2021

    Contributor

    My (non-verified) guess is that the 1px shift is related to the "wiggly baseline" mentioned in #5414, which basically arises because mathtext/usetex texts (which are basically prerendered as bitmaps first) use their top-right corner as reference point, but there's some rounding associated with it if the text object gets antialiased past the top limit, which (handwavingly) leads to the baseline wiggling; instead, these bitmaps should use the baseline as reference y to avoid the problem.

  5. kc9jud commented on Nov 16, 2021

    This still seems to be a problem with more complex situations:

    import matplotlib.pyplot as plt
    
    kw = dict(
        usetex=True,
        fontsize=40,
        bbox=dict(boxstyle='round,pad=0', fc='lightsteelblue', ec='none')
    )
    
    plt.axhline(y=0.7)
    plt.annotate('A \n B', xy=(0.4, 0.7), **kw)
    plt.annotate(r'$A$' ' \n ' r'$B$', xy=(0.5, 0.7), **kw)
    plt.annotate(r'$A_{\tiny 1}$' ' \n ' r'$B_{\tiny 1}$', xy=(0.6, 0.7), **kw)
    plt.annotate(r'$A_{\tiny 1j}$' ' \n ' r'$A_{\tiny 1j}$', xy=(0.8, 0.7), **kw)
    
    plt.axhline(y=0.3)
    plt.annotate('A \n B', xy=(0.4, 0.3), va='bottom', **kw)
    plt.annotate(r'$A$' ' \n ' r'$B$', xy=(0.5, 0.3), va='bottom', **kw)
    plt.annotate(r'$A_{1}$' ' \n ' r'$B_{\tiny 1}$', xy=(0.6, 0.3), va='bottom', **kw)
    plt.annotate(r'$A_{1j}$' ' \n ' r'$A_{\tiny 1j}$', xy=(0.8, 0.3), va='bottom', **kw)
    
    plt.annotate(r'$^6\mathrm{He}$ $0^+$' ' \n ' r'$n0p_{3/2}$', xy=(0.05, 0.3), va='bottom', **kw)
    
    plt.show()

    gives:

  6. kc9jud commented on Nov 16, 2021

    This looks to be an issue with superscripts -- I will open a new issue.

  7. jklymak commented on Nov 16, 2021

    Member

    Your example is helpful. Maybe add to #7075 which I think is the same thing (if more convoluted)

  8. github-actions commented on Jun 16, 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!

  9. anntzer commented on Jun 16, 2023

    Contributor

    Haven't checked but almost likely still valid as no work has been done on these aspects, and will likely be stalled until the image comparison framework is fixed as any change to the wiggly baselines will involve regen'ing many, many reference images (#21653 (comment))?

  10. added
    keepItems to be ignored by the “Stale” Github Action
    and removed
    status: inactiveMarked by the “Stale” Github Action
    on Jun 16, 2023
  11. QuLogic commented on Jul 1, 2025

    Member

    The wiggly baseline should be fixed by #30059; does it also fix the bbox issue originally reported?

  12. anntzer commented on Sep 5, 2025

    Contributor

    The non-mathtext "A" is also properly aligned at the top now (with or without #30059); the second and fourth cases of the first line still appear one pixel too high:

    My (rather uncertain) guess is that this is related to the precision of the tfm metrics and I had suggested a fix at #21653 (comment) (but that'd require a bit of work).

    On the other hand we should probably also try to get something like #21653 (comment) into the text-overhaul branch, I think?

  13. tacaswell commented on May 15, 2026

    Member

    This is what I get with current main, I am going to make the call that this is close enough:

  14. added this to the v3.11.0 milestone on May 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    keepItems to be ignored by the “Stale” Github Actiontopic: text/usetex

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL