\left( and \right) fail to extend for small size

[davidmjones]

Hi!

When typesetting with STIX2 using LuaLaTeX (or XeTeX) and unicode-math I've found that in \small math text parentheses are not extensible anymore. The following example

\documentclass[a4paper,12pt]{article} \usepackage{unicode-math} \setmathfont{Stix Two Math} \begin{document} [ \left(\frac{x+y}{x-y}\right). ] \small [ \left(\frac{x+y}{x-y}\right). ] \end{document}

produces big parentheses for the first formula but small ones for the second one (see the attached PDF). brackets [] and braces {} work fine.

It seems like a bug in the STIX2Math font (other unicode math fonts I've tried don't show the faulty behaviour).

Reported by: sgolovan

Original Ticket: stixfonts/tracking/86

[davidmjones]

A small clarification: the bug seems to be present only if the font is loaded with script or script-script style enabled.

Original comment by: sgolovan

[davidmjones]

We appreciate the feedback. This fix will be considered for inclusion in the next release.

Original comment by: stipub

[davidmjones]

I can't reproduce the problem with xelatex. For lualatex it just appeared again on tex.sx https://tex.stackexchange.com/questions/380262/left-right-problem-with-stix-math-two-when-small-applied-to-the-group-luala. I could also reproduce the problem with context (https://www.mail-archive.com/ntg-context@ntg.nl/msg85444.html)

Imho the source of the problem is that stix2 contains parenleft.ssty, parenright.ssty, parenleft.ssty2 and parenright.ssty2 glyphs but these glyphs have no vvariants-list. The fontloader seems not fall back to the variants for the base glyphs (parenleft etc) in this case. I don't know if this a font bug or if the fontloader should handle this situation differently (like harfbuzz in xetex seems to do it).

Original comment by: u_fischer

[davidmjones]

For information, here is a plain TeX file that shows the bad behavior and that it depends on the ssty option being turned on. See https://tex.stackexchange.com/questions/380262/

\input ifxetex.sty

\ifxetex
  \font\extsymbolsA="STIX Two Math/OT:script=math;language=DFLT;"
  \font\extsymbolsB="STIX Two Math/OT:script=math;language=DFLT;+ssty=0;"
\else
  \input luaotfload.sty
  \font\extsymbolsA="STIX Two Math:mode=base;script=math;language=DFLT;"
  \font\extsymbolsB="STIX Two Math:mode=base;script=math;language=DFLT;+ssty=0;"
\fi

\Udelcode`(="3 `(
\Udelcode`)="3 `)

\textfont3=\extsymbolsA
$$
\left(a\over b\right)
$$

\textfont3=\extsymbolsB
$$
\left(a\over b\right)
$$

\bye

Original comment by: eg9

[davidmjones]

On the context mailing list Hans Hagen wrote that in his opinion it is a bug:

I don't know what harfbuzz does but the font definitely does some ssty mapping to rather simple glyphs with no extensible parts so basically it's a font bug. If xetex catches it, fine but it's still a bug.

He also wrote some code to get around it, but imho it would be better if the issue would be resolved in the font.

Original comment by: u_fischer

[tiroj]

I'm not sure how to understand the bug in terms of the font. Should we never map to .ssty variants for these characters, so that they can continue to expand using the regular growing forms? Or should we add growing forms of the .ssty and .ssty2 variants? [We've never tried the latter, and would need to test thoroughly to determine it works everywhere and whether the correct sequence is a) map to .ssty and then grow, or b) grow and then map to .ssty.