You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Vertical alignment of tick labels with usetex=True #6323
the vertical alignment of tick labels is incorrect. For negative ticks, the tick labels are quite visibly lower than the positive marks. See the screenshot for an example.
A minimal working example:
from matplotlib import pyplot as plt
plt.close('all')
# import seaborn as sns
# sns.set_context("poster", font_scale=2)
The screenshot uses seaborn, as using its font properties exaggerates the error, but it is also visible without seaborn on close inspection.
In constructing this MWE, I discovered that the problem goes away if I reverse the order of the two plots, or if I set plt.rc('text', usetex=False) before plt.show().
I installed python 2.7.11 and matplotlib 1.5.1 via anaconda. I'm using the Qt4Agg backend, interactively.
the vertical alignment of tick labels is incorrect. For negative ticks,
the tick labels are quite visibly lower than the positive marks. See the
screenshot for an example.
A minimal working example:
from matplotlib import pyplot as plt
plt.close('all')
The screenshot uses seaborn, as using its font properties exaggerates the
error, but it is also visible without seaborn on close inspection.
In constructing this MWE, I discovered that the problem goes away if I
reverse the order of the two plots, or if I set plt.rc('text',
usetex=False) before plt.show().
I installed python 2.7.11 and matplotlib 1.5.1 via anaconda. I'm using the
Qt4Agg backend, interactively.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #6323
This causes LaTeX to affect a vertical shift in the positive labels as well (this is therefore not a fix but a workaround). The trailing \phantom{} calls are necessary to maintain the horizontal alignment of the tick labels.
Use mplcairo's approach, which is to not use dvipng at all for conversion but instead extract the glyphs one by one from the dvi file and re-render them using ft2font (we already have code to do that for the pdf/ps backends).
Instead of relying on the tfm metrics, use the pfb font which pdftex.map points to (the mapping is documented as "the most prominent use of pdftex.map" by the pdftex user manual), and extract the metrics from it.
The advantage of the first two solutions is that (I think) this would allow us to get rid of the Tfm and possibly Vf classes, as we would be able to rely on freetype to get glyph metrics.
Activity
WeatherGod commentedon Apr 21, 2016
attn: @mdboom. I am a bit disconcerted that the 2 and 4 (positive and
negative) in the left panel isn't lined up right, either, I think.
On Thu, Apr 21, 2016 at 6:48 AM, KeithWM notifications@github.com wrote:
mdboom commentedon Apr 25, 2016
TeX is returning bogus descender values for the negative sign. Haven't quite figured out why yet.
Fix matplotlib#6323: Fix vertical alignment of TeX text
Kojoley commentedon Jan 4, 2017
It is still the case

aseyffert commentedon Jan 28, 2020
A temporary workaround is to use LaTeX's
\phantom{}command; e.g, for a plot with xticks at[-2, -1, 0, 1, 2]you can manually set the xticklabels as:ax.set_xticklabels([r'$-2$', r'$-1$', r'$\phantom{-}0\phantom{-}$', r'$\phantom{-}1\phantom{-}$', r'$\phantom{-}2\phantom{-}$'])This causes LaTeX to affect a vertical shift in the positive labels as well (this is therefore not a fix but a workaround). The trailing
\phantom{}calls are necessary to maintain the horizontal alignment of the tick labels.anntzer commentedon Jan 29, 2020
I looked a bit into this and as it turns out it is intentionally that the minus sign has a nonzero descent: https://tex.stackexchange.com/questions/526103/why-does-cmsy10-tfm-give-the-minus-sign-a-positive-depth/ (thanks tex.stackexchange). Essentially, the tfm metrics are used (especially) to alignment of math formulae, rather than to determine rasterization bboxes, which is what we need here.
There are a few solutions here:
The advantage of the first two solutions is that (I think) this would allow us to get rid of the Tfm and possibly Vf classes, as we would be able to rely on freetype to get glyph metrics.