Spacing/kerning issue with \sfrac and LuaLaTeX

[ArchangeGabriel]

Consider the following code:

\documentclass{standalone}

\usepackage{xfrac}
\usepackage{esdiff}
\usepackage{unicode-math}
\setmathfont{Garamond-Math.otf}

\begin{document}
$\sfrac{\partial S}{\partial r }$ soit $\sfrac{\partial S}{\partial r }$
\end{document}

Rendering is OK with XeLaTeX, but not with LuaLaTeX. Both work OK with other fonts.

[ArchangeGabriel]

Using \fbox to check the output seems to point towards the r going outside of the box.

[ArchangeGabriel]

Code with boxes, same preamble:

\setlength{\fboxsep}{0pt}
\setlength{\fboxrule}{.2pt}

\begin{document}
\fbox{$\sfrac{\partial S}{\partial r }$} \fbox{soit} \fbox{$\sfrac{\partial S}{\partial r }$}
\end{document}

test.pdf

[YuanshengZhao]

Thank you for the comment. This is actually a known issue (written in readme) that the font is sometimes not working with LuaTeX. But IMHO this is more of a problem associated with unicode-math with LuaTeX. Consider the following

\showoutput
\begin{document}
$T$
\end{document}

with XeTeX, one get something like this:

......\mathon
......\TU/XITSMath(1)/m/n/10 glyph#2491
......\kern1.6
......\mathoff

while the result with LuaTeX is

......\mathon
......\TU/XITSMath(1)/m/n/10 �
......\mathoff

the kern of 1.6 is in fact the italic correction of the glyph. The fact is that LuaTeX will not add this kern after a "block" (fraction, sub/super script, end of equation, etc.), while XeTeX will. If the last glyph has negative right bearing, the problem happens, regardless of the font.

I am not sure how to deal with this automatically (forcing LuaTex to add this kern will solve the problem; manually, one may add some space after the equation). From the aspect of the font, absorbing part of italic correction into the width of the glyph will partly solve the problem, but italic correction is meant to placing the sub/super script right and not on the glyph being out of bounds. Also notice that Xe/LuaTeX do not have very good handling of math kerning like MS Word, so italic correction is perhaps the only way to place the script well.

[ArchangeGabriel]

OK, maybe we should get @wspr involved there then.

[ArchangeGabriel]

For the past month, I’ve been encountering lots of cases where the spacing is wrong, at least with LuaLaTeX. I’ve haven’t re-tested with XeLaTeX recently for my main document, however I’ve also encountered the issue while typesetting my matplotlib graphics with lualatex, where the digits for the ticks were not properly aligned, while it worked OK using other fonts or xelatex (switching back to xelatex there is OK though, or using \setmathfont[range=up/{num}]{EBGaramond-Regular.otf} as a workaround works fine too).

Since I’m not knowledgeable enough in the underlying packages/systems, I can’t tell whether that’s LuaLaTeX fault, unicode-math one or the font, but it seems strange to me that every other math font works OK but not this one. I guess @wspr could tell, but no answer from him here.

Also tagging @u-fischer that once asked me the issues I had with migrating from XeLaTeX to LuaLaTeX, because this is definitively one for me.

[u-fischer]

yes, luatex doesn't insert the italic correction at the boundary of math and text. This is different to xetex, but not necessarly wrong: if e.g. after the math is a period the space is with xetex too large.

If you want to force that the kern is inserted you will have to add an invisible char (directly after the r). See here https://tex.stackexchange.com/a/484673/2388.

Also glyphs can stick outside their bounding box and standalone can not recognize such effects. With all engines it can happen with some fonts or chars that you need to add manual spaces or a border.

Also notice that Xe/LuaTeX do not have very good handling of math kerning like MS Word, so italic correction is perhaps the only way to place the script well.

The fontloader in lualatex does know about mathkerns, but it is difficult to test if this works correctly, as the support in the math fonts is quite unclear.

[YuanshengZhao]

It is because the different mathinfo that causes the digits and upright letters in the font here has some different behavior from others fonts. However, considering that upright letters will not be used as variables very often, I have decided to use "normal mode". The problem with digits will be solved after a few commits (it will take some time as I am working on another improvement currently).

[ArchangeGabriel]

Thanks @u-fischer for this workaround. Seems to work great. :)

@YuanshengZhao For digits I suppose you’re right, but I must say that upright letters are used as variables. Especially since math-style=upright and math-style=french exists, and I’m currently trying the second one after having recently discovered it (and I’m writing in french, so…). So maybe fixing digits only? Though I don’t know exactly what the issue is and what the fix looks like actually, so I’ll let you handle that. Anyway, it’s definitively okay to fix that later since there is a workaround. ;)

By the way thank you for developing this font, I had a lot of issues with Neo Euler and its author abandoned it, and now finally there is a new nice pairing font for EB Garamond. :)

[YuanshengZhao]

Please check the latest version (not in branch master).

The previous problem is that I used italic correction to adjust the position of super/subscripts of all glyphs. In order to keep the space, the width of glyphs is deducted by the italic correction, which caused the incorrect width of numbers, etc in LuaTeX. Now I put these in Math Kern.

[ArchangeGabriel]

I’ve downloaded the latest version here, but the issue does not seems fixed. See the y-ticks label on the attached plot. accretion_rate.pdf

[ArchangeGabriel]

Version with my above workaround for comparison: accretion_rate.pdf

[ArchangeGabriel]

I’ve also tried to recompile my whole manuscript with the new version, but I don’t see a lot of changes. Could LuaLaTeX be using the older file?

I still have a lot of places where the kerning is wrong, especially this case:

\documentclass{standalone}

\usepackage{fontspec}
\defaultfontfeatures[EBGaramond]{Ligatures=TeX,Numbers={Lining,Monospaced,Proportional}}
\setmainfont[
    Extension      = .otf,
    UprightFont    = *-Regular,
    ItalicFont     = *-Italic,
    BoldFont       = *-Bold,
    BoldItalicFont = *-BoldItalic
]{EBGaramond}

\usepackage[math-style=french]{unicode-math}
\setmathfont{Garamond-Math.otf}

\begin{document}

2π\textit{ft}

$2πft$

\end{document}

test.pdf

[YuanshengZhao]

For the issue with digits, I guess you are using windows and have installed the font in the system. On windows, you should first uninstall the font. If you just install and replace, the original font file still exists and it is likely that TeX will use that file. If this is the case, you need to

• uninstall font
• delete all font file with names Garamond-Math* in the font folder (C:\windows\fonts if the font is installed for all users)
• install the new font file

For the spacing of ft, it is the feature of ALL math font that the spacing is different with text. Usually, f, j and y will become wilder, because

• Jaxtaposition of math symbols often means multiplication of variables, rather than forming a word
• math symbols should not bumping into each other: f^x, |f| and others
• In math modes, there should not be any kernings. see https://tex.stackexchange.com/questions/115324/math-mode-kerning-spacing-of-letters and other related posts on SE

[ArchangeGabriel]

No, I’m on Linux. I’ve put the font under /usr/local/share/texmf/fonts/opentype/public/garamond-math/Garamond-Math.otf, removed luaotfload cache and ran updmap. I’ll write a matplotlib test case for you to reproduce the issue ASAP.

Different spacing, yes. But here it looks to be too much, especially between the f and the t. If you trace straight vertical lines to separate the letters, there is only one position possible between the π and the f. But tons of them between the other two.

[ArchangeGabriel]

I’ve compared the rendering to LM: test.pdf

In LM the spacing between π and f looks too big to me, but between f and t it seems much more reasonable. In Garamond-Maths, both looks a bit too big, but the second one especially. But it might be a matter of taste, so I’ll let you decide. ;) BRB with a matplotlib case though.

[ArchangeGabriel]

So this should exhibits the issue with matplotlib:

import numpy as np
import matplotlib.pyplot as plt

import matplotlib.backend_bases
matplotlib.backend_bases.register_backend('pdf', 'matplotlib.backends.backend_pgf')

plt.rcParams['savefig.format'] = 'pdf'
plt.rcParams['text.usetex'] = True
plt.rcParams['font.family'] = 'serif'
plt.rcParams['pgf.texsystem'] = 'lualatex'
plt.rcParams['pgf.rcfonts'] = False
plt.rcParams['pgf.preamble'] = r'\usepackage{unicode-math}\setmathfont{Garamond-Math.otf}'

plt.plot()
plt.yticks(np.linspace(0,1.0,11))
plt.savefig('matplotlib.pdf')

[YuanshengZhao]

In fact, I do not like the spacing being too large either. What I am considering is that things like f^0 and [f] should not blow up. The spacing can be shrunk by a little, like this: This is the limiting value that f^0 does not blow up. I will try this further, if it works, I will give an update. The spacing is a tough thing. Because without normal kerning, definitely some pairs will go wrong. (Another example is VA, which in text there is a large negative kerning between them). It seems that some manual adjustment is always necessary at the present. For matplotlib, the current versions works on my computer (Windows 10). I replaced the font file in ...\texmf-dist\fonts\opentype\public.

[ArchangeGabriel]

Looks way better like this! Glad you agree that too much spacing is disgraceful. :)

OK for matplotlib, so there might be a caching/font selection issue. I’ll do it your way and overwrite the TeX Live file, will just need to think about overwriting it again when TeX Live 2019 will land in ArchLinux. I’ll tell you if it fixes the issue for me.

[ArchangeGabriel]

Small update: overwriting the font worked, so this is indeed fixed, thank you! Looking forward for further development of this font. :)

[ArchangeGabriel]

@YuanshengZhao New version from https://github.com/YuanshengZhao/Garamond-Math/issues/13#issuecomment-490120886 that includes the commits fixing the f spacing is really nice. :)

[ArchangeGabriel]

I’ve found a new case that looks a bit strange, $mₑc²$: test.pdf

The e subscript is too far from the m and too close to the c.

[wspr]

@ArchangeGabriel — Just to make sure this isn’t a unicode-math issue, do you get the same result with $m_e c^2$ ?

[ArchangeGabriel]

@wspr Yes, I do.

[YuanshengZhao]

The main reson is that the italic correction of e is not inserted, at present, you can add the "duck" after script to fix this. Two more points:

• The SpaceAfterScript of the font is a a little bit too small, which should be fixed.
  • XeTeX seems to handle this differently, as there is no difference when I change this value.
• Subscript of italic letters is simiar to the case of VA, which has some problem without kerning. This can be handled with math kern of the script letter. But I am not sure how to do this, as this may lead to some inconsistencies, i.e. x_{ff} may looks wired.

[YuanshengZhao]

@u-fischer My knowledge gets outdated very quickly. I remembered that months ago LuaTeX has some issue with math kern. Now it seems this (at least some of them) has been fixed. (in texlive 2019, linux. I could not update tex for some time because 2018 is locked). Thank you!

[ArchangeGabriel]

@YuanshengZhao Indeed, this makes it harder to use the nice unicode-math input feature since $mₑ<200b>c²$ does not work and I have to fallback to $m_{e<200b>}c²$ instead, but that’s OK since having an <200b> or a there already makes the formula less readable.

However as you pointed out (your second bullet point above), even with the correction this remain wrong because the e stays closer to the c than to the m (and is to far from the m in any case, the tip of the m does not align with the leftmost part of the e, which would likely be more pleasant I think). I don’t have a solution though, since I definitively don’t have enough knowledge of this kind of things.

[YuanshengZhao]

Now the <200b> is not necessary. For the position of _e, it is just visual effect that e is too far from m: I do not mean that there is no need to adjust this. But I found no way at present, when considering g_e should not blow up. (The Math Kern in TeX seems to be hight independent, which is the main issue to add TopLeftVertex). I will improve this when I found some way. (IMO, the effect at present is, though not perfect, fair.) You can try this build: Garamond-Math.zip

[ArchangeGabriel]

@YuanshengZhao Thanks, looks quite good now. Of course they are new edge cases like $r_\textrm{sh}$, but this is a good trade-off for me, especially since all those textrm subscript I have are defined in macros since I use them often, so I’ve just add some negative math kerning in their definition.

I see the issue with m and subscripts, and it’s indeed quite OK now. :) But if you ever happen to find a way to enhance it towards perfection, that would be quite welcome. ;)