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
@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?)
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.
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!
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))?
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?
Activity
timhoffm commented on May 11, 2019
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
anntzer commented on May 23, 2021
@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?)
timhoffm commented on May 24, 2021
Except for $A_{\tiny 1}$ all examples still appear to be shifted by 1px upwards.
anntzer commented on May 24, 2021
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.
kc9jud commented on Nov 16, 2021
This still seems to be a problem with more complex situations:
gives:

kc9jud commented on Nov 16, 2021
This looks to be an issue with superscripts -- I will open a new issue.
jklymak commented on Nov 16, 2021
Your example is helpful. Maybe add to #7075 which I think is the same thing (if more convoluted)
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!
anntzer commented on Jun 16, 2023
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))?
QuLogic commented on Jul 1, 2025
The wiggly baseline should be fixed by #30059; does it also fix the bbox issue originally reported?
anntzer commented on Sep 5, 2025
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?
tacaswell commented on May 15, 2026
This is what I get with current main, I am going to make the call that this is close enough: