5

Consider the following example:

\documentclass{standalone}
\usepackage{unicode-math}
\setmathfont{TeX Gyre Termes Math}
\begin{document}
\(f\Bigl(\Bigr)\)
\end{document}

If you compile it with xelatex, you get

f() with sufficient space between f and the opening parenthesis

But if you compile it with lualatex, you get a narrower

f() with little space between f and the opening parenthesis

Definitely, the results differ, so at least one of the engines or unicode-math is wrong about the spacing between f and the left parenthesis. Subjectively, the output of xelatex is more pleasant than that of lualatex, so, I presume, lualatex (or the code inside unicode-math run by lualatex only) is the culprit. But, I'm unaware of the "official" specification of how it should be, so, all bets are off.

  1. How large is the distance between f and ( supposed to be for the most pleasant reading?

  2. Who is the culprit? (I.e., who deviates from the way it is supposed to be?)

  3. Is there any way to repair the culprit or at least to achieve independency of the engine used for compilation more or less automatically?

Weakly related: Change bounding box of math glyphs in LuaTeX . However, there, Ulrike said in her answer that "you are at the end of the math and luatex doesn't insert the italic correction at the boundary between math and text." Here, on the contrary, we are still inside math. If you insert \Uchar"200B or 🦆 right after f, you get more space for both engines, and the discrepancy remains. Moreover, it's far from automatic even if the discrepancy would have gone away.

EDIT: Concerning

This question already has an answer here: Change bounding box of math glyphs in LuaTeX

It doesn't. The answer from there doesn't fit here. Feel free to test it.

Crosspost: http://latex.org/forum/viewtopic.php?f=46&t=32655&p=109799

Improve this question
7
  • Yes, because of LuaTeX's lack of the italic correction, although, as you say, here we're in the middle of the formula. As stated in the answer, you can try \(f\Uchar"200B\Bigl(\Bigr)\) or \(f🦆\Bigl(\Bigr)\) to have the spacing fixed. However I must say that it's a pain to do that eveywhere... I'll retract my close vote. – Phelype Oleinik Jul 5 '19 at 16:37
  • Your question "Who is the culprit? (I.e., who deviates from the specification?)" presupposes that there is a specification. the OpenType Math table specification is somewhat vague and font authors have to interpret it to know what values to put into the dimensions in the table, and rendering engine authors need to interpret the values in the table to lay out the math and then tex macros like unicode-math need to interpret the differences between the engines to give a consistent cross engine interface. It's amazing anything comes out looking similar, less surprising that they sometimes differ. – David Carlisle Jul 5 '19 at 18:09
  • it was originally but it's now part of the OpenType standard but even where things are known to be vague and systems differ it isn't clear they can change, eg Unicode was deliberately vague about "script/caligraphic" fonts \mathcal/\mathscr Microsoft's Cambria Math font ended up with a different default than most others, which is a pain but probably not changeable given a decade of existing documents. "Clarifying" spacing rules would be similar even if you could isolate differences it doesn't mean that you can specify a single set of values without breaking existing code. – David Carlisle Jul 5 '19 at 18:35
  • blogs.msdn.microsoft.com/murrays/2016/02/05/… – David Carlisle Jul 5 '19 at 18:35
  • 1
    why ping Murray, he doesn't have write access to luatex or xetex sources and they are the systems that you want to act the same. there is always room for interpretation mapping tex concepts like the \mathord and \mathopen classses of f and ( and the layout rules in OpenType. – David Carlisle Jul 5 '19 at 19:00
6

What does the relevant specification actually say?

Italics correction can be used in the following situations:

  • When a run of slanted characters is followed by a straight character (such as an operator or a delimiter), the italics correction of the last glyph is added to its advance width.

(The OpenType MATH table specification, emphasis mine)

Now the TeX engine has to decide how to translate this to TeX concepts. XeTeX generally classifies \mathopen atoms as "delimiters" and therefore "straight characters", but LuaTeX only classifies TeX delimiters, (\left, \right, etc.) as "delimiters".

I tend to agree with XeTeX here.

To get consistant behaviour, you can add explicitly add the italic correction through \/, so in your example:

\documentclass{standalone}
\usepackage{unicode-math,ifluatex}
\setmathfont{TeX Gyre Termes Math}
\ifluatex
  \mathitalicsmode=1
\fi
\begin{document}
\(f\/\Bigl(\Bigr)\)
\end{document}

This can also be automated using the mlist_to_hlist callback.

Improve this answer
4
  • @MdAyq5 AFAICT mostly historical reasons. Earlier versions of the OpenType MATH specs did not include the part quoted above, so it was unclear when italic correction should be added. Later the default probably never changed to stay compatible. – Marcel Krüger Jul 5 '19 at 19:30
  • @MdAyq5 As documented, \mathitalicsmode=1 forces italic correction before "noads that represent some more complex structure". So basically it answers the question: What if a slanted character is not followed by a character at all. This isn't specified (the quote above only talks about slanted characters followed by straight characters). So the entire point behind \mathitalicsmode is that it is not clear what setting is "good". You have to decide for yourself, probably depending on the math font. – Marcel Krüger Jul 5 '19 at 20:50
  • 1
    @MdAyq5 Yes, but you can't change it inside a math formula. (To be precise, as usual the setting active at the end of the formula will apply to the entire formula.) – Marcel Krüger Jul 5 '19 at 21:02
  • @MarcelKrüger: The text you quoted in your answer is present in the very earliest version of the MATH table documentation even before it was part of the Unicode. The confusion has always been on the LuaTeX/ConTeXt side for no obvious reason. – Khaled Hosny Jul 8 '19 at 11:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy