☰

Error 'Dimensión demasiado grande' cuando \setmathfont tiene la opción Scale=MatchLowercase

tag-icon • tag-icon xetex unicode-math bugs
Error 'Dimensión demasiado grande' cuando \setmathfont tiene la opción Scale=MatchLowercase 
\documentclass{article}
\usepackage{unicode-math}
\setmainfont{Georgia}
\setmathfont[Scale=MatchLowercase]{Cambria Math}
\begin{document}
n $n \sqrt[n]{n}$
\end{document}

El código anterior, cuando se compone con XeTeX, produce un error que dice "Dimensión demasiado grande". Quitarlo [Scale=MatchLowercase]lo resuelve, pero necesito la opción para la combinación de otras fuentes de texto y matemáticas que estoy usando.

Este problema parece reciente. La última vez que compuse un documento XeTeX que usa unicode-mathy contiene \sqrt[n]{n}fue hace aproximadamente un año y el problema no estaba presente en ese momento. ¿Hay algo malo conuna de las últimas versionesde unicode-math, es decir, 0,8 mo 0,8 n?

Sin embargo, el archivo PDF de salida está bien. No estoy seguro de si debería preocuparme, pero tener que seguir descartando el error es un inconveniente. Como solución alternativa, usaré la notación ^{1/n}por ahora.

Respuesta1

Actualizar

A partir de unicode-math la versión 0.8o (04/03/2019), este error se solucionó para Scaleel uso normal. La actualización incluyeuna variante de la respuesta de Ulrike Fischery, lo que es más importante,una configuración más descuidada para las dimensiones de fuente en las familias 2 y 3.

El cambio desde ScaleAgain = 1.00001y ScaleAgain = 0.99999hacia ScaleAgain = 1.0001y ScaleAgain = 0.9999efectivamentebajadoel límite superior del conjunto Ben el Teorema 1 a continuación. El conjunto Bahora termina en around  k=10000, que es around Scale=0.153. Esto significa que, siempre y cuando el usuario solicitado Scaleseaarriba 0.153, entonces unicode-mathconfiguraría las dimensiones de fuente correctamente.

Si lo solicitado Scalees inferior a 0,153, el problema de dimensión de fuente persiste. Pero se consideró que el uso normal nunca produciría Scale=0.153ni disminuiría, por lo que estamos seguros en su mayor parte. Ver análisis más detalladoaquíyaquí.

Viejas respuestas

Aunque estoy de acuerdo con Ulrike Fischer en que se trata de un unicode-matherror, me temo que no estoy de acuerdo con la afirmación de que “ \__um_fontdimen_to_percent:nNestá roto”. De hecho, usarlo \dim_to_decimal_in_sp:nes una gran mejora, pero esnodonde radica el verdadero problema. Primero presentaré mi solución y luego intentaré discutir la causa raíz.

Tenga en cuenta que la siguiente solución es temporal hasta que unicode-mathse solucione este problema en la próxima versión.

Solución

Para una solución relativamente simple, puedes usar la nueva función ScaleAgainpara distorsionar ligeramente el tamaño de la fuente (no será visible para el ojo humano):

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

Escalar de nuevo

En la práctica, tendrás que probar un rango ScaleAgaincercano a 1 para poder compilar. Nuevamente, esto se solucionará en la próxima versión de unicode-math.

Un teorema sobre el comportamiento de desbordamiento de unicode-math v0.8n

Para aquellos que estén interesados ​​en el extraño comportamiento del desbordamiento, aquí hay un teorema, basado en los dos ScaleAgainfactores fijos en la unicode-math versión 0.8n.

Primero vienen las visualizaciones sobre cuáles Scaleson seguros y cuáles pueden causar problemas:

Cerca Scale=1:
escala1
Cerca Scale=1.2:
escala1.2
Cerca Scale=1.5:
escala1.5

TodoverdeLos segmentos de línea representan los Scalefactores seguros, mientras querojoLos segmentos de línea representan los problemáticos.

Aquí está la rigurosa descripción matemática:
Teorema

En particular, Scale=1.031369386, Scale=1.031374755, Scale=1.031384644yScale=1.031390014 todo conduce a ! Dimension too large. Cerca Scale=1.03138:
escala1.03138

Discusiones

Las alturas x de Georgia y Cambria Math son, respectivamente, 986/2048y 956/2048. Y Scale=MatchLowercasese convierte correctamente Scale=1.03138en fontspec. Ahora bien, si aplicáramos laredefinición sugerida de\__um_fontdimen_to_percent:nNAl utilizar Latin Modern Math, nos sorprendería descubrir 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}

todavía produce el ! Dimension too large.error.

Aún más extraño, si en su lugar utilizamos un factor de escala de  1.03137o  1.03139, entonces su ejemplo de Georgia + Cambria Math se compila correctamente, al igual que mi ejemplo de Latin Modern Math (con o sin la redefinición de \__um_fontdimen_to_percent:nN).

La causa raíz del problema es la nueva característica ScaleAgainde fontspec, que está destinada a resolver un problema de larga data (consulteColocación de superíndice usando Unicode-Math con escalayLa opción de escala no funciona completamente con LuaLaTeX). Ah, y también el hecho de que TeX “no es bueno en matemáticas”.

Para configurar correctamente las dimensiones de fuente heredadas relacionadas con las matemáticas, unicode-mathdebe cargar la misma fuente matemáticatres veces. Pero TeX no permitiría cargar la misma fuente dos veces con el mismo tamaño, por lo que unicode-mathtiene que cargar la fuente en tamaños ligeramente diferentes la segunda y tercera vez. Estos tamaños ligeramente diferentes se obtienen mediantecompuestoel factor de escala anterior. Esta fue la razón principal por la que ScaleAgainse introdujo en  fontspec, así que unicode-mathpuedo hacerlo ScaleAgain=1.00001por segunda y ScaleAgain=0.99999tercera vez. Comomi comentarioComo señaló, a veces unicode-mathno logra distinguir los tres tamaños debido a la aritmética binaria de TeX.

Su ejemplo tuvo la “mala suerte” de tener Scale=1.03138, lo que se traduce como Round( 1.03138 * 2^16 ) = 67593. Después ScaleAgain=1.00001, TeX ve 1.03139, lo que se traduce como Round( 1.03139 * 2^16 ) = 67593. Entonces TeX piensa que la segunda familia y la primera familia son la misma fuente y procede a sobrescribir fontdimen bajo las instrucciones de unicode-math. Esto provoca el desbordamiento, porque las nuevas dimensiones de fuente ya no son porcentajes inferiores a uno, sino que ahora son longitudes físicas que pueden llegar a ser bastante grandes.

Con \setmathfont[Scale=MatchLowercase,ScaleAgain=0.99999]{Cambria Math}, básicamente estamos tratando de evitar que TeX cargue accidentalmente la fuente matemática con el mismo tamaño.

Respuesta2

En mi humilde opinión, la definición de \__um_fontdimen_to_percent:nNes defectuosa, debería usarse \dim_to_decimal_in_spen lugar 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}

información relacionada