Fehler „Dimension zu groß“, wenn \setmathfont die Option Scale=MatchLowercase hat

Fehler „Dimension zu groß“, wenn \setmathfont die Option Scale=MatchLowercase hat
\documentclass{article}
\usepackage{unicode-math}
\setmainfont{Georgia}
\setmathfont[Scale=MatchLowercase]{Cambria Math}
\begin{document}
n $n \sqrt[n]{n}$
\end{document}

Der obige Code erzeugt beim Setzen mit XeTeX den Fehler „Dimension zu groß“. Das Entfernen [Scale=MatchLowercase]behebt das Problem, aber ich brauche die Option für die Kombination anderer Text- und Mathematikschriften, die ich verwende.

Dieses Problem scheint neu zu sein. Das letzte Mal, dass ich ein XeTeX-Dokument gesetzt habe, das verwendet unicode-mathund enthält, \sqrt[n]{n}war vor etwa einem Jahr und das Problem war damals noch nicht vorhanden. Stimmt etwas nicht miteine der neuesten Versionenvon unicode-math, nämlich 0,8m oder 0,8n?

Trotzdem ist die PDF-Ausgabedatei in Ordnung. Ich bin mir nicht sicher, ob ich mir Sorgen machen sollte, aber es ist unpraktisch, den Fehler immer wieder ignorieren zu müssen. Als Workaround werde ich ^{1/n}vorerst die Notation verwenden.

Antwort1

Aktualisieren

Ab unicode-math v0.8o (04.03.2019) ist dieser Fehler für den normalen ScaleGebrauch behoben. Das Update enthälteine Variante von Ulrike Fischers Antwortund, was noch wichtiger ist,eine schlampigere Einstellung der Schriftgrößen in FAM 2 und 3.

Der Wechsel von ScaleAgain = 1.00001und ScaleAgain = 0.99999zu ScaleAgain = 1.0001und ScaleAgain = 0.9999effektivabgesenktdie obere Grenze der Menge Bin Theorem 1 unten. Die Menge Bendet jetzt bei etwa  k=10000, also bei etwa Scale=0.153. Das heißt, solange der angefragte ScaleBenutzerüber 0,153, dann unicode-mathwürden die Schriftabmessungen richtig eingestellt sein.

Wenn der angeforderte Wert Scaleunter 0,153 liegt, besteht das Problem mit der Schriftgröße weiterhin. Es wurde jedoch davon ausgegangen, dass bei normaler Verwendung niemals 0,153 Scale=0.153oder weniger entstehen würde, sodass wir in den meisten Fällen auf der sicheren Seite sind. Weitere detaillierte Analyse anzeigenHierUndHier.


Alte Antworten

Obwohl ich Ulrike Fischer zustimme, dass dies ein unicode-mathFehler ist, muss ich leider der Behauptung widersprechen, dass „ \__um_fontdimen_to_percent:nNkaputt ist“. Tatsächlich \dim_to_decimal_in_sp:nist die Verwendung von eine große Verbesserung, aber es istnichtwo das eigentliche Problem liegt. Ich werde zuerst meine Lösung vorstellen und dann versuchen, die Grundursache zu erörtern.

Beachten Sie, dass die folgende Lösung nur vorübergehend ist, bis unicode-mathdas Problem in der nächsten Version behoben ist.


Lösung

Eine relativ einfache Lösung besteht darin, ScaleAgaindie Schriftgröße mithilfe der neuen Funktion leicht zu verzerren (dies ist für das menschliche Auge nicht sichtbar):

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

Nochmal skalieren

In der Praxis müssen Sie einen Bereich ScaleAgainnahe 1 ausprobieren, um kompilieren zu können. Auch dies soll in der nächsten Version von behoben sein unicode-math.


Ein Theorem zum Überlaufverhalten von unicode-math v0.8n

Für diejenigen, die sich für das bizarre Überlaufverhalten interessieren, hier ein Theorem, das auf den beiden festen ScaleAgainFaktoren in unicode-math v0.8n basiert.

Zuerst erfolgt die Visualisierung, welche Scalesicher sind und welche Probleme verursachen können:

Nahe Scale=1:
Skala1
Nahe Scale=1.2:
Maßstab 1.2
Nahe Scale=1.5:
Maßstab 1,5

AlleGrünLiniensegmente repräsentieren die sicheren ScaleFaktoren, währendRotLiniensegmente stellen die problematischen dar.

Hier ist die strenge mathematische Beschreibung:
Satz

Insbesondere Scale=1.031369386, Scale=1.031374755undScale=1.031384644Scale=1.031390014 führen alle zu ! Dimension too large. Nahe Scale=1.03138:
Maßstab1.03138


Diskussionen

Die x-Höhen von Georgia und Cambria Math sind jeweils 986/2048und 956/2048. Und Scale=MatchLowercasewird korrekt Scale=1.03138durch in umgewandelt fontspec. Wenn wir nun dievorgeschlagene Neudefinition von\__um_fontdimen_to_percent:nNBei der Verwendung der modernen lateinischen Mathematik wären wir überrascht, Folgendes herauszufinden:

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

erzeugt immer noch den ! Dimension too large.Fehler.

Noch merkwürdiger ist, dass Ihr Georgia + Cambria-Mathematikbeispiel erfolgreich kompiliert wird, wenn wir stattdessen einen Skalierungsfaktor von entweder  1.03137oder  verwenden 1.03139, und das gleiche gilt für mein Beispiel für die lateinische moderne Mathematik (mit oder ohne Neudefinition von \__um_fontdimen_to_percent:nN).

Die eigentliche Ursache des Problems ist die neue Funktion ScaleAgainvon fontspec, die ein seit langem bestehendes Problem lösen soll (siehePlatzierung hochgestellter Zeichen mithilfe von Unicode-Mathematik mit SkalierungUndDie Skalierungsoption funktioniert mit LuaLaTeX nicht vollständig). Oh, und auch die Tatsache, dass TeX „nicht gut in Mathe“ ist.

Um die mathematisch bedingten Schriftgrößen korrekt einzustellen, unicode-mathmuss die gleiche mathematische Schriftart geladen werdendrei Mal. TeX würde es jedoch nicht erlauben, dieselbe Schriftart zweimal in derselben Größe zu laden, also unicode-mathmuss die Schriftart beim zweiten und dritten Mal in leicht unterschiedlichen Größen geladen werden. Diese leicht unterschiedlichen Größen erhält man durchAufzinsungder vorherige Skalierungsfaktor. Dies war der Hauptgrund, der ScaleAgainin eingeführt wurde  fontspec, also kann man es zum 2. Mal und zum 3. Mal unicode-mathtun . WieScaleAgain=1.00001ScaleAgain=0.99999mein KommentarWie bereits erwähnt, unicode-mathist es aufgrund der Binärarithmetik von TeX manchmal nicht möglich, zwischen den drei Größen zu unterscheiden.

Ihr Beispiel hatte das „Pech“ Scale=1.03138, dass es gab, was sich mit übersetzen lässt Round( 1.03138 * 2^16 ) = 67593. Nach ScaleAgain=1.00001sieht TeX 1.03139, was sich mit übersetzen lässt Round( 1.03139 * 2^16 ) = 67593. TeX denkt also, dass die zweite Familie und die erste Familie dieselbe Schriftart sind, und überschreibt die Schriftdimens unter der Anweisung von unicode-math. Dies verursacht den Überlauf, weil die neuen Schriftdimens nicht länger Prozentsätze kleiner als eins sind, sondern jetzt physische Längen, die ziemlich groß werden können.

Damit \setmathfont[Scale=MatchLowercase,ScaleAgain=0.99999]{Cambria Math}versuchen wir grundsätzlich zu verhindern, dass TeX die Mathematikschriftart versehentlich in der gleichen Größe lädt.

Antwort2

Meiner Meinung nach ist die Definition von fehlerhaft. Anstelle von \__um_fontdimen_to_percent:nNsollte verwendet werden :\dim_to_decimal_in_sp\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}

verwandte Informationen