Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Math font side bearing #273

Closed
RuixiZhang42 opened this issue Jun 7, 2019 · 4 comments
Closed

Math font side bearing #273

RuixiZhang42 opened this issue Jun 7, 2019 · 4 comments

Comments

@RuixiZhang42
Copy link

I complied https://github.com/alif-type/libertinus/blob/master/documentation/Math-Sample.tex with the v6.9 2019-05-27 CTAN update and noticed some side bearing issues.

There seems to be too much white space left to the letter j

issue01
Observed under both XeLaTeX and LuaLaTeX.

The pair ij does not match the pair ii and the result is quite uneven. Also notice the “hole” between the \not= and the j.

Weird spacing issue in superscript and weird accent placement

issue02
Observed under LuaLaTeX.

The right delimiter is colliding with the uppercase I and the \overline{I} looks very strange. These two issues do not appear under XeLaTeX. On another note, the problem with j also appears in this equation—j\in I skews to the right under the product sign and _j’s are too far away from their atom (applies to both XeLaTeX and LuaLaTeX).

@khaledhosny
Copy link
Contributor

The pair ij does not match the pair ii and the result is quite uneven. Also notice the “hole” between the \not= and the j.

The j has a non-negative left side bearing so it does not clash in situations like (j). You can see this with other math fonts, including Computer Modern:
image

The right delimiter is colliding with the uppercase I and the \overline{I} looks very strange. These two issues do not appear under XeLaTeX.

LuaTeX does not apply italic correction, that is a LuaTeX issue and I have no control over. There is a LuaTeX commands to control application of italic corrections that might help here, but I don’t remember them (try asking on https://tex.stackexchange.com).

On another note, the problem with j also appears in this equation—j\in I skews to the right under the product sign and _j’s are too far away from their atom (applies to both XeLaTeX and LuaLaTeX).

Same reason as the other j issue above.

@RuixiZhang42
Copy link
Author

@khaledhosny Thank you for the CM example! I admit I’ve glanced over the ii v.s. ij pairs in CM as they are very subtle. But MathTime Pro 2 seems to behave better. Here is an example using the lite version:

\documentclass{article}
\usepackage[lite,subscriptcorrection]{mtpro2}
\begin{document}
$ii\enskip ij\enskip ji\enskip
a_{ii}\enskip a_{ij}\enskip a_{ji}\enskip
(i)\enskip(j)\enskip
\fboxsep-\fboxrule\fbox{$i$}\enskip\fbox{$j$}$
\showoutput
\end{document}

ijpair

I realized that kerning is applied in math mode (thought it was disabled in math mode…), so that’s one possible solution.

The other possible solution is to create glyphs with narrower bounding boxes (which allow the strokes to stick out) and to use contextual substitution to get the current wider-bounding-box ones when combinations with brackets occur.

@khaledhosny
Copy link
Contributor

Kerning in math mode with OpenType fonts do not work in XeTeX, so that is only a partial solution. Any advanced OpenType feature like contextual substitution does not work either, not even in LuaTeX (what LuaTeX do in math mode is to map a subset OpenType features to old TeX kerning and ligature mechanisms so that is very limited).

@khaledhosny
Copy link
Contributor

I changed the italic j a bit to require smaller side bearing, I think this is the best compromise that works with different math engines.

alerque pushed a commit that referenced this issue Aug 18, 2020
Change the terminal ball of the j or require smaller left side bearing,
and also increase the right side bearing of the i a bit.

Fixes #273
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants