Comparing between the Tex and mathtext, It looks like the superscript is
slightly too high as well.

On Thu, Aug 6, 2015 at 12:44 PM, Victor Zabalzanotifications@github.com
wrote:

As mentioned in#4872#4872,
I found that sub/super blocks in mathtext have slightly too much space
after them, even after@mdboomhttps://github.com/mdboom fix in#4401
#4401. As initial
reference, this a TeX rendering of a bunch of sub/superscripts (with E and
5 because they are box-like and separation differences are easier to spot):
[image: subsup_test_tex]
https://cloud.githubusercontent.com/assets/576258/9117283/05c01816-3c61-11e5-821a-484d800f4378.png

The current master renders it as follows:
[image: subsup_test_mpl_master]
https://cloud.githubusercontent.com/assets/576258/9117307/209ab696-3c61-11e5-8317-91bbc0f47877.png

And with the modifications of this PR, it looks like this:
[image: subsup_test_mpl]
https://cloud.githubusercontent.com/assets/576258/9117316/2b5a300c-3c61-11e5-85d0-3a157af8d0c7.png

Summary of changes:

• Additional kerning of -0.1 em after sub/super blocks.
• Superscripts are shifted away from nucleus by 0.15 em when nucleus
  is slanted.
• When there is both sub and superscript and nucleus is slanted,
  superscripts are only shifted an aditional 0.15 em (down from >0.20 em)
• Subscripts are shifted down 0.25 x-height instead of 0.5 when there
  is no superscript.

Regression images coming soon!

You can view, comment on, or merge this pull request online at:

#4873
Commit Summary

• first attempt
• finetuning with cm TeX

File Changes

• M lib/matplotlib/mathtext.py
  https://github.com/matplotlib/matplotlib/pull/4873/files#diff-0 (21)

Patch Links:

• https://github.com/matplotlib/matplotlib/pull/4873.patch
• https://github.com/matplotlib/matplotlib/pull/4873.diff

—
Reply to this email directly or view it on GitHub
#4873.

Well, it seems that reducing the space after the sub/subscript is not that simple after all: it works well with numbers, but for slanted characters:

TeX, of course, handles these beautifully. I'll try to see where the difference in spacing comes from.

@WeatherGod: indeed it is, I'll try to match that as well.

Trying to see why$a_{ji}$ was being rendered with too little kerning, I found that the current master renders$a_{i}$ and$a_i$ differently. After much blood and tears in the depths ofmathtext.py, I think it is because calling.shrink() on aChar object results in different kerning that calling it on aHlist object. The groups between{ } are parsed asHlist objects, whereas the characters in$a_i$ are parsed asChar. The current master shrinks and then converts into a Hlist, and I have changed it so that evereything is anHlist before shrinking, so there is better consistency. To showcase this, I made a plot with two lines that only differ by (unnecesary) braces:

r'$x_kx^py^{p-2} \quad d_i^jb_jc_kd \quad x^j_i E^0 E^0_u$',r'${x}_{k}{x}^{p}{y}^{p-2} \quad {d}_{i}^{j}{b}_{j}{c}_{k}{d} \quad {x}^{j}_{i}{E}^{0}{E}^0_u$',

Current master renders them clearly different:

And with the changes mentioned they are consistent with each other:

I have also finetuned the supsuper spacings to match Computer Modern on TeX. Here is the reference TeX rendering (with text.usetex=True):

And with this PR:

Compared to the current master:

However, not all is rosy, because the same parameters that work for CM fail miserably when using stixsans or stix as mathtext.fontset, so I will try to do a dict that sets them based on the fontset. See for stix (note the superscripts in particular):

@zblz Thank you for taking this on!

So I think I've got it under control now for CM, stix and stixsans fontsets. There were a few challenges with integrals (also related to theChar vsHlist issue above), but they look good now and I have added a couple of tests for them. I will amend the baseline images shortly and then the PR can be properly reviewed.

This is how a sample looks with this PR in cm:
edit:outdated, see images further below

To be compared with theusetex=True rendering:
edit:outdated, see images further below

The same sample also looks good for stix and stixsans:
edit:outdated, see images further below

@tacaswell,@mdboom : I think this is now complete, it would be great if you could review it at some point.

Looking at the issue list, this PR will fix the issue with spacing after superscripts reported in#4333.

I have also added the sub/supercript parameters for Arev Sans, which is checked for by looking at

rcParams['mathtext.fontset'] == 'custom'rcParams['mathtext.rm'] == 'sans'rcParams['font.sans-serif'][0].lower() == 'arev sans'

This could be useful for users using it and if#4636 is accepted.

Thanks! I'm happy to merge this once Travis passes.

hold on. The second to last line has some spacing issues. The "f" and "2"
and "9" (both as a superscript and as a regular numeral) are much too close.

On Mon, Aug 24, 2015 at 10:45 AM, Michael Droettboom <
notifications@github.com> wrote:

Thanks! I'm happy to merge this once Travis passes.

—
Reply to this email directly or view it on GitHub
#4873 (comment)
.

Also, the "prime" symbol in that line is much too close, especially when
the "f" is italic.

On Mon, Aug 24, 2015 at 10:49 AM, Benjamin Rootben.v.root@gmail.com
wrote:

hold on. The second to last line has some spacing issues. The "f" and "2"
and "9" (both as a superscript and as a regular numeral) are much too close.

On Mon, Aug 24, 2015 at 10:45 AM, Michael Droettboom <
notifications@github.com> wrote:

Thanks! I'm happy to merge this once Travis passes.

—
Reply to this email directly or view it on GitHub
#4873 (comment)
.

Also, our mathtext might be parsing something slightly differently than
LaTeX is. In that same line, LaTeX sees the prime symbol as being on its
own and positions it as if it was a normal piece of text (nice and big),
but everywhere else, it is some sort of weird, scraggly looking superscript.

On Mon, Aug 24, 2015 at 10:49 AM, Benjamin Rootben.v.root@gmail.com
wrote:

Also, the "prime" symbol in that line is much too close, especially when
the "f" is italic.

On Mon, Aug 24, 2015 at 10:49 AM, Benjamin Rootben.v.root@gmail.com
wrote:

hold on. The second to last line has some spacing issues. The "f" and "2"
and "9" (both as a superscript and as a regular numeral) are much too close.

On Mon, Aug 24, 2015 at 10:45 AM, Michael Droettboom <
notifications@github.com> wrote:

Thanks! I'm happy to merge this once Travis passes.

—
Reply to this email directly or view it on GitHub
#4873 (comment)
.

@WeatherGod: Yes, the kerning for the f is particularly tight, but it is tight everywhere, as you mention for the regular f and numerals 2 and 9 (and that's why I added them to that line), so it is not an issue with the sub/super script. I tried to minimize it for cm, where it looks pretty good, but did not manage for stix of stixsans. Maybe the kerning for the f should be slightly widened elsewhere to match TeX. I added a modification of the superscript kerning that takes into account how much the last character rises above the x-height to try and mitigate this, but it is tricky: if it is correct for the italic f, it is too wide for, e.g.,$E^0$ (which is already slightly wider than tex), so I tried to reach a compromise.

The prime issue only happens for stix and stixsans, where it seems to match$\prime$ to an already superscripted prime, as opposed to a nice and big prime for TeX and cm. This I also believe is outside the scope of this PR, but should definitely be fixed so they are consistent.

I fixed a test failure intest_axes that came from having no nucleus inside mathtext (e.g.,a$^2$). I added a test in mathtext so it can be caught by running only thetest_mathtext tests. There were also a couple of superscripts in other tests that were failing because I had not replaced the baseline images. Should be fine now.

I agree that the stix issues with the prime symbol and some of the other miscellaneous spacing is a separate issue from this PR, and indeed this PR makes things no worse than it was before in that regard.

Ok, well, let's create some issue tickets for those so that we don't forget to fix them. This is great work@zblz!

Ok, I created issue#4987 to track the issues I noted above. Great work!

Mike, I have not reviewed a single line of code here (I wouldn't know what any of it means anyway). So, I'll leave merging this up to you?