5
\documentclass{article}
\usepackage{unicode-math}
\setmainfont{Georgia}
\setmathfont[Scale=MatchLowercase]{Cambria Math}
\begin{document}
n $n \sqrt[n]{n}$
\end{document}

The above code when typeset with XeTeX produces an error saying 'Dimension too large'. Removing [Scale=MatchLowercase] resolves it but I need the option for the combination of other text and math fonts I'm using.

This issue seems recent. The last time I typeset a XeTeX document that uses unicode-math and contains \sqrt[n]{n} was about a year ago and the issue wasn't present at the time. Is there something wrong with one of the latest versions of unicode-math, namely 0.8m or 0.8n?

Nevertheless, the output PDF file is fine. I'm not sure if I should be worried, but having to keep dismissing the error is inconvenient. As a workaround I'll use the notation ^{1/n} for now.

3

Update

As of unicode-math v0.8o (2019/03/04), this bug is fixed for normal Scale usage. The update includes a variant of Ulrike Fischer’s answer, and more crucially, a sloppier setup for font dimensions in fam 2 and 3.

The change from ScaleAgain = 1.00001 and ScaleAgain = 0.99999 to ScaleAgain = 1.0001 and ScaleAgain = 0.9999 effectively lowered the upper bound of the set B in Theorem 1 below. The set B now terminates at around k=10000, which is around Scale=0.153. This means, as long as the user requested Scale is above 0.153, then unicode-math would setup font dimensions correctly.

If the requested Scale is below 0.153, then the font dimension problem persists. But it was deemed that normal usage would never produce Scale=0.153 or lower, so we are safe for the most parts. See more detailed analysis here and here.


Old answers

Although I agree with Ulrike Fischer that this is a unicode-math bug, I’m afraid that I have to disagree with the claim that “\__um_fontdimen_to_percent:nN is broken”. Indeed, using \dim_to_decimal_in_sp:n is a great improvement, but it is not where the actual problem lies. I shall first present my solution and then try to discuss the root cause.

Note that the following solution is meant to be temporary until unicode-math fixes this in the next release.


Solution

For a relatively simple solution, you can use the new feature ScaleAgain to slightly distort the font size (it won’t be visible to the human eyes):

\documentclass{article}
\usepackage{unicode-math}% v0.8n, 2019/02/15
\setmainfont{Georgia}
\setmathfont[Scale=MatchLowercase,ScaleAgain=0.99999]{Cambria Math}
\begin{document}
n $n \sqrt[n]{n}$
\end{document}

ScaleAgain

In practice, you’ll have to try a range of ScaleAgain near 1 to be able to compile. Again, this shall be fixed in the next release of unicode-math.


A Theorem on the overflow behavior of unicode-math v0.8n

For those who are interested in the bizarre overflow behavior, here is a theorem, based on the two fixed ScaleAgain factors in unicode-math v0.8n.

First comes the visualizations on which Scale’s are safe and which may cause problem:

Near Scale=1:
scale1
Near Scale=1.2:
scale1.2
Near Scale=1.5:
scale1.5

All green line segments represent the safe Scale factors, while red line segments represent the problematic ones.

Here is the rigorous mathematical description:
Theorem

In particular, Scale=1.031369386, Scale=1.031374755, Scale=1.031384644 and Scale=1.031390014 all lead to ! Dimension too large. Near Scale=1.03138:
scale1.03138


Discussions

The x-heights of Georgia and Cambria Math are, respectively, 986/2048 and 956/2048. And Scale=MatchLowercase is correctly converted into Scale=1.03138 by fontspec. Now, if we were to apply the suggested re-definition of \__um_fontdimen_to_percent:nN when using Latin Modern Math, we would be surprise to find out that:

\documentclass{article}
\usepackage{unicode-math}% v0.8n, 2019/02/15
% https://tex.stackexchange.com/a/475802, by Ulrike Fischer:
\ExplSyntaxOn
\cs_set:Nn \__um_fontdimen_to_percent:nN
  {
    \fp_eval:n { \dim_to_decimal_in_sp:n { \fontdimen #1 #2 } / 100 }
  }
\ExplSyntaxOff

\newcommand*\tempscale{1.03138}% Also fails at 1.02, 1.05, 1.07
\setmathfont[Scale=\tempscale]{latinmodern-math.otf}

\begin{document}
n $n \sqrt[n]{n}$
\end{document}

still produces the ! Dimension too large. error.

Even more strangely, if we instead use a scale factor of either 1.03137 or 1.03139, then your Georgia + Cambria Math example compiles successfully, and so does my Latin Modern Math example (with or without the re-definition of \__um_fontdimen_to_percent:nN).

The root cause of the problem is the new feature ScaleAgain from fontspec, which is meant to solve a long standing problem (see Superscript placement using unicode-math with scaling and Scale option doesn't fully work with LuaLaTeX). Oh, and also the fact that TeX is “not good at math”.

To setup the math-related legacy font dimensions correctly, unicode-math must load the same math font three times. But TeX wouldn’t allow the same font to be loaded twice at the same size, so unicode-math has to load the font at slightly different sizes for the 2nd and the 3rd times. These slightly different sizes are obtained by compounding the previous scale factor. This was the main reason that ScaleAgain was introduced in fontspec, so unicode-math can do ScaleAgain=1.00001 for the 2nd time and ScaleAgain=0.99999 for the 3rd time. As my comment pointed out, sometimes unicode-math will fail to distinguish the three sizes due to TeX’s binary arithmetic.

Your example was “unlucky” enough to have Scale=1.03138, which translates to Round( 1.03138 * 2^16 ) = 67593. After ScaleAgain=1.00001, TeX sees 1.03139, which translates to Round( 1.03139 * 2^16 ) = 67593. So TeX thinks that the second family and the first family are the same font, and proceeds to overwrite fontdimen’s under the instruction of unicode-math. This causes the overflow, because the new fontdimen’s are no longer percentages which are less than one, but are now physical lengths which can get quite large.

With \setmathfont[Scale=MatchLowercase,ScaleAgain=0.99999]{Cambria Math}, we are basically trying to prevent TeX from loading the math font at the same size accidentally.

  • \__um_fontdimen_to_percent:nN is broken. Multiplying a dimension by 65536 is simply a very bad idea - it will overflow even if the dimension is only 1pt large. Imho your ScaleAgain workaround is only hiding the problem - something in the math is wrong when unicode-math is trying to insert a kern. – Ulrike Fischer Feb 21 at 11:53
  • @UlrikeFischer I fully agree with your improvement for \__um_fontdimen_to_percent:nN. But, on the contrary, your \dim_to_decimal_in_sp:n actually hides the bug even more IMHO. See, \setmathfont[Scale=0.7]{latinmodern-math.otf} is not supposed to work, either, but your improvement let it through. I continued my discussion here. – Ruixi Zhang Feb 21 at 16:58
  • My compliments: many details and very nice. – Sebastiano Mar 7 at 13:07
8

Imho the definition of \__um_fontdimen_to_percent:nN is faulty, it should use \dim_to_decimal_in_sp instead of \dim_to_decimal:n

\documentclass{article}
\usepackage{unicode-math}
\ExplSyntaxOn
\cs_set:Nn \__um_fontdimen_to_percent:nN
  {
    \fp_eval:n { \dim_to_decimal_in_sp:n {  \fontdimen #1 #2 } / 100 }
  }
\ExplSyntaxOff
\setmainfont{Georgia}
\setmathfont[Scale=MatchLowercase]{Cambria Math}

\begin{document}
n $n \sqrt[n]{n}$
\end{document}
  • Thank you. I think I'll leave it to you to add an issue to github.com/wspr/unicode-math/issues along with the suggested fix. – Taiki Feb 20 at 10:26
  • 2
    No, you found the bug so you should add the issue. I already spent enough time in finding the relevant code piece. – Ulrike Fischer Feb 20 at 10:28
  • OK. Done: github.com/wspr/unicode-math/issues/515 – Taiki Feb 20 at 10:43
  • 1
    For information : this is not XeTeX-specific ; also arise with LuaLaTeX (only with beamer, in my setup) and the above does fix it. – ysalmon Feb 20 at 14:33
  • 1
    Oh dear! This posted solution is not bullet-proof: It still breaks down if I use \setmathfont[Scale=1.031380753]{latinmodern-math.otf}. See the continued discussions on GitHub. – Ruixi Zhang Feb 20 at 23:19

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.