Erro 'Dimensão muito grande' quando \setmathfont tem a opção Scale=MatchLowercase

Question

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

O código acima, quando digitado com XeTeX, produz um erro dizendo 'Dimensão muito grande'. A remoção [Scale=MatchLowercase]resolve, mas preciso da opção de combinação de outras fontes de texto e matemática que estou usando.

Este problema parece recente. A última vez que escrevi um documento XeTeX que usa unicode-mathe contém \sqrt[n]{n}foi há cerca de um ano e o problema não estava presente na época. Há algo de errado comuma das versões mais recentesde unicode-math, ou seja, 0,8m ou 0,8n?

No entanto, o arquivo PDF de saída está bom. Não tenho certeza se devo me preocupar, mas ter que descartar o erro é inconveniente. Como solução alternativa, usarei a notação ^{1/n}por enquanto.

Answer 1

Atualizar

A partir da unicode-math v0.8o (04/03/2019), esse bug foi corrigido para Scaleuso normal. A atualização incluiuma variante da resposta de Ulrike Fischere, mais crucialmente,uma configuração mais desleixada para dimensões de fonte nas famílias 2 e 3.

A mudança de ScaleAgain = 1.00001e ScaleAgain = 0.99999para ScaleAgain = 1.0001e ScaleAgain = 0.9999efetivamenteabaixadoo limite superior do conjunto Bno Teorema 1 abaixo. O conjunto Bagora termina em torno de  k=10000, que é em torno de Scale=0.153. Isto significa que, desde que o usuário solicitado Scalesejaacima 0,153, então unicode-mathconfiguraria as dimensões da fonte corretamente.

Se o solicitado Scaleestiver abaixo de 0,153, o problema de dimensão da fonte persiste. Mas foi considerado que o uso normal nunca produziria Scale=0.153ou diminuiria, por isso estamos seguros na maior parte. Veja análise mais detalhadaaquieaqui.

---

Respostas antigas

Embora eu concorde com Ulrike Fischer que isso é um unicode-mathbug, temo ter que discordar da afirmação de que “ \__um_fontdimen_to_percent:nNestá quebrado”. Na verdade, usar \dim_to_decimal_in_sp:né uma grande melhoria, mas énãoonde reside o verdadeiro problema. Apresentarei primeiro a minha solução e depois tentarei discutir a causa raiz.

Observe que a solução a seguir deve ser temporária até que unicode-mathisso seja corrigido na próxima versão.

---

Solução

Para uma solução relativamente simples, você pode usar o novo recurso ScaleAgainpara distorcer levemente o tamanho da fonte (não será visível aos olhos humanos):

\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}

Na prática, você terá que tentar um intervalo ScaleAgainpróximo de 1 para poder compilar. Novamente, isso será corrigido na próxima versão do unicode-math.

---

Um teorema sobre o comportamento de overflow de unicode-math v0.8n

Para aqueles que estão interessados ​​no comportamento bizarro do overflow, aqui está um teorema, baseado nos dois ScaleAgainfatores fixos em unicode-math v0.8n.

Primeiro vêm as visualizações sobre quais Scalesão seguros e quais podem causar problemas:

Aproximar Scale=1:

Aproximar Scale=1.2:

Aproximar Scale=1.5:

Todosverdesegmentos de linha representam os Scalefatores seguros, enquantovermelhosegmentos de linha representam os problemáticos.

Aqui está a descrição matemática rigorosa:

Em particular , Scale=1.031369386, Scale=1.031374755eScale=1.031384644Scale=1.031390014 tudo leva a ! Dimension too large. Aproximar Scale=1.03138:

---

Discussões

As alturas x de Georgia e Cambria Math são, respectivamente, 986/2048e 956/2048. E Scale=MatchLowercaseé corretamente convertido em Scale=1.03138by fontspec. Agora, se aplicássemos osugeriu redefinição de\__um_fontdimen_to_percent:nNao usar o Latin Modern Math, ficaríamos surpresos ao descobrir que:

\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}

ainda produz o ! Dimension too large.erro.

Ainda mais estranho, se usarmos um fator de escala de  1.03137ou  1.03139, então seu exemplo Georgia + Cambria Math será compilado com êxito, assim como meu exemplo Latin Modern Math (com ou sem a redefinição de \__um_fontdimen_to_percent:nN).

A causa raiz do problema é o novo recurso ScaleAgaindo fontspec, que visa resolver um problema antigo (consultePosicionamento sobrescrito usando unicode-math com escalaeA opção de escala não funciona totalmente com LuaLaTeX). Ah, e também o fato de que o TeX “não é bom em matemática”.

Para configurar corretamente as dimensões da fonte herdada relacionada à matemática, unicode-mathé necessário carregar a mesma fonte matemáticatrês vezes. Mas o TeX não permitiria que a mesma fonte fosse carregada duas vezes no mesmo tamanho, então unicode-mathé necessário carregar a fonte em tamanhos ligeiramente diferentes na segunda e na terceira vez. Esses tamanhos ligeiramente diferentes são obtidos porcomposiçãoo fator de escala anterior. Este foi o principal motivo que ScaleAgainfoi introduzido em  fontspec, unicode-mathpodendo ser feito ScaleAgain=1.00001pela 2ª e ScaleAgain=0.99999pela 3ª vez. Comomeu comentárioapontado, às vezes unicode-mathnão conseguirá distinguir os três tamanhos devido à aritmética binária do TeX.

Seu exemplo foi “azarado” o suficiente para ter Scale=1.03138, o que se traduz em Round( 1.03138 * 2^16 ) = 67593. Depois ScaleAgain=1.00001, o TeX vê 1.03139, o que se traduz em Round( 1.03139 * 2^16 ) = 67593. Portanto, o TeX pensa que a segunda família e a primeira família são a mesma fonte e passa a sobrescrever os fontdimen sob as instruções de unicode-math. Isso causa o estouro, porque os novos fontdimens não são mais porcentagens menores que um, mas agora comprimentos físicos que podem ficar bastante grandes.

Com \setmathfont[Scale=MatchLowercase,ScaleAgain=0.99999]{Cambria Math}, estamos basicamente tentando evitar que o TeX carregue acidentalmente a fonte matemática do mesmo tamanho.

Answer 2

Imho, a definição de \__um_fontdimen_to_percent:nNestá com defeito, deveria ser usada \dim_to_decimal_in_spem vez de\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}