Overhaul the STIX Two Math MATH table

[davidmjones]

Review and improve the MATH table, especially but not restricted to the MathKern table (especially as it applies to attachment of superscripts and subscripts) and MathTopAccentAttachment table (which controls attachment of math accents to base characters) and the MathConstants (e.g., fractionNumeratorShiftUp, fractionDenominatorShiftDown, stackTopShiftUp).

Related issues:

• 127

• 183

• 180

• 165

• 159

• 135

• 134

• 86

[firai]

In the process of reviewing/overhauling the MATH table, can you also consider reviewing/changing the following specifically? I can resubmit these as separate issues if preferred. (All screen caps produced with STIX Two Math v2.12 b168a and MS Word 16, as printed to PDF.)

1. Decrease the kerning for:

   • before and after lower case f,
   • before lower case j,
   • before lower case p, and
   • before lower case y. Note that the kerning shown below is the same in both MS Word and XeLaTeX, but the excessive space affects MS Word more so than *-TeX since it's not possible to add negative spaces in Word math regions as far as I know.

2. Unify the vertical space between bar accents and the parent letter for MS Word. I also personally feel that the amount of vertical space between bars and the parent letter (particularly lower case letters) isn't quite enough for body sizes, but I understand that it might have been a design decision.

3. Stretch bars and hats for lower case w, and bars for a number of upper case letters. (See screen cap above.) This may also apply to other accents, but I haven't tested them yet since I don't personally don't use those nearly as much.

4. Consider reducing the height difference between stretched hats and unstretched hats. The stretched hats look somewhat out of whack when placed anywhere near unstretched hats.

[tiroj]

(1) : the math alphanumeric characters do not have typical spacing and no general kerning. They are spaced to work as individual elements in math equations—subject to the special spacing and cut-in kerning models of the MS MATH table model. The problem here is that the italics correction property in that model is only available to the upper right quadrant of a glyph, which means that for any descending slanted glyph the lower left quadrant spacing has to be built into the basic sidebearing settings, otherwise the descender may collide with delimiters or other nearby shapes.

We’ll definitely review this in the v2.20 MATH table work to see if we can determine a better approach.

(2) : This is really odd. I am unsure why the bar height is jumping around so much. Will definitely review and see if I can find the data point that determines what the math handler does.

(3) : Yes, will review. Can’t remember offhand if this is a MATH table setting or something that the handler does algorithmically.

(4) : Noted, and agreed.

[matteocoder]

Another spacing issue that was first reported here affects the placement of the root index: both numbers and letters appear too close to the root symbol and in some cases they tent do overlap as shown by this MWE:

% LuaHBTeX 1.13.2
\documentclass{article}
\usepackage{unicode-math}
\setmainfont{STIX Two Text}
\setmathfont{STIX Two Math}
\begin{document}
\[
\sqrt[a]{3}
\sqrt[b]{3}
\sqrt[c]{3}
\sqrt[d]{3}
\sqrt[e]{3}
\sqrt[f]{3}
\sqrt[g]{3}
\sqrt[h]{3}
\sqrt[i]{3}
\sqrt[j]{3}
\sqrt[k]{3}
\sqrt[l]{3}
\sqrt[m]{3}
\sqrt[n]{3}
\sqrt[o]{3}
\sqrt[p]{3}
\sqrt[q]{3}
\sqrt[r]{3}
\sqrt[s]{3}
\sqrt[t]{3}
\sqrt[u]{3}
\sqrt[v]{3}
\sqrt[w]{3}
\sqrt[x]{3}
\sqrt[y]{3}
\sqrt[z]{3}
\]
\[
\sqrt[0]{3}
\sqrt[1]{3}
\sqrt[2]{3}
\sqrt[3]{3}
\sqrt[4]{3}
\sqrt[5]{3}
\sqrt[6]{3}
\sqrt[7]{3}
\sqrt[8]{3}
\sqrt[9]{3}
\sqrt[10]{3}
\sqrt[100]{3}
\]
\end{document}

Compared to Latin Modern Math, the index appears to be a bit too skewed to the left as well: Latin modern

STIX Two

These tests were made with STIX Two Text and Math 2.12 available in TeX Live 2021.

[tiroj]

The issue with position of radical degree has also been reported here as Issue 206.

The trouble we are having resolving this issue is that in the MS MATH table editor everything looks fine, but we are seeing very inconsistent results in different environments, both with regard to scaling and positioning of the radical degree index. [See various images in that other issue.] So I don’t actually know how to ‘fix’ the issue at the font level (although one thought I have that would improve the TeX Live 2021 outcome you illustrate would be to simply shorten the left tick of the radical sign glyph slightly).

[davidmjones]

The trouble we are having resolving this issue is that in the MS MATH table editor everything looks fine, but we are seeing very inconsistent results in different environments, both with regard to scaling and positioning of the radical degree index.

We were able to resolve a similar inconsistency with the implementation of the MathKern table because the kerning algorithm is spelled out in reasonable detail at https://docs.microsoft.com/en-us/typography/opentype/spec/math#mathkerninfo-table. I can't find anything as explicit for typesetting radicals, which makes it hard to figure out what the Unicode-aware TeX engines are doing wrong. @tiroj : Maybe we can get our friends at Microsoft to give us some hints about the right way to do these calculations?