Repository navigation
[Bug]: mathtext not always rendering combining accents in the same way #23257
Description
Bug summary
In the reference figure https://github.com/matplotlib/matplotlib/blob/main/lib/matplotlib/tests/baseline_images/test_mathtext/mathtext_dejavuserif_00.pdf
the dot above the s is differently positioned. Not clear why as the expressions are \dot s and \dot{s} respectively. This doesn't happen to all fonts (maybe only this?).
It also happens in the svg image, although not as clear. Looking at the source, the x-position difference between the accent and character is 54.4 for the left and 57.5 for the right.
Code for reproduction
import matplotlib.pyplot
plt.text(0.5, 0.5, r'$\dot s + \dot{s}$')
plt.savefig('sdot.pdf')
plt.savefig('sdot.svg')Actual outcome
Different rendering
Expected outcome
Identical rendering
Additional information
No response
Operating system
No response
Matplotlib Version
3.6.0.dev2642+g25292618a9.d20220612
Matplotlib Backend
No response
Python version
No response
Jupyter version
No response
Installation
git checkout
Activity
tfpf commented on Jul 7, 2022
It looks like this happens with all fonts. I don't think it's specific to the SVG and PDF backends, since the differences in rendering are visible in the plot window. (I am using the GTK3Agg backend.)
import matplotlib.pyplot as plt fig = plt.figure() for (i, fontset) in zip([.1, .3, .5, .7, .9], ['cm', 'dejavusans', 'dejavuserif', 'stix', 'stixsans']): plt.rc('mathtext', fontset=fontset) fig.text(i, 0.5, r'$\dot s$', ha='center', va='center', size=250, alpha=0.5, color='red') fig.text(i, 0.5, r'$\dot{s}$', ha='center', va='center', size=250, alpha=0.5, color='green') plt.show()The root of the problem is the difference in the way s and {s} are treated. The former is a symbol (which gets converted into a Char), whereas the latter is a group (which gets inserted into an Hlist).
matplotlib/lib/matplotlib/_mathtext.py
Lines 2122 to 2124 in c936ef5
By default, an Hlist adds kerning to characters, so {s} is actually rendered with some additional space after it. The dot is then centred above the Hlist. That's why it is displaced to the right.
anntzer commented on Jul 7, 2022
Good catch. The behavior of \dot{s} would seem to be in error, no?
oscargus commented on Jul 7, 2022
I think that it is an error, yes. At least https://www.ctan.org/pkg/comprehensive writes with {} around the character for accents. (And I always was under the impression that it is the same, but indeed a less authoritative source...)
Indeed a good catch @tfpf !
tfpf commented on Jul 8, 2022
I agree with oscargus. LaTeX does not add that extra space at the end, so the behaviour of \dot{s} is incorrect. However, LaTeX's behaviour resembles that of \dot{s}, probably because it shifts the accent when the character is italicised. Which might be the purpose of sym.width / 4.0 in the accent function.
matplotlib/lib/matplotlib/_mathtext.py
Line 2067 in c936ef5
The italic correction messes up the placement (which isn't obvious unless the text under the accent is long), while the extra space at the end is responsible for the difference between s and {s}.
I should add that the point about the italic correction has already been noted in #19299.
oscargus commented on Jul 8, 2022
I think that #23189 actually solves this (and explains one of the failing tests). One can probably make a simpler patch that just handles this, something like:
if it is expected that #23189 will take a long time to get ready (I think that it is probably worthwhile to spend the effort there if we are still planning to "break" how the accents are rendered...).
tfpf commented on Jul 8, 2022
This works well! However, if the group contains another group nested inside it (e.g. \dot{{s}}), the placement of the dot will again be off.
oscargus commented on Jul 8, 2022
Yeah, you are right. Probably better to do something like:
github-actions commented on Dec 15, 2025
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 Feb 3, 2026
Looks like something worth revisiting now that raqm is in, as we could perhaps now render all (nonwide) accents as combining characters. See also some early work on this at #23189.
Tagging as part of text-overhaul (as it logically belongs together), but I don't think it's worth blocking the merge of text-overhaul into main with this -- changing this will only break the test images that contain accents, which should be relatively few.