\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-math
und 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 Scale
Gebrauch 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.00001
und ScaleAgain = 0.99999
zu ScaleAgain = 1.0001
und ScaleAgain = 0.9999
effektivabgesenktdie 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 Scale
Benutzerüber 0,153, dann unicode-math
würden die Schriftabmessungen richtig eingestellt sein.
Wenn der angeforderte Wert Scale
unter 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.153
oder 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-math
Fehler ist, muss ich leider der Behauptung widersprechen, dass „ \__um_fontdimen_to_percent:nN
kaputt ist“. Tatsächlich \dim_to_decimal_in_sp:n
ist 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-math
das Problem in der nächsten Version behoben ist.
Lösung
Eine relativ einfache Lösung besteht darin, ScaleAgain
die 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}
In der Praxis müssen Sie einen Bereich ScaleAgain
nahe 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 ScaleAgain
Faktoren in unicode-math
v0.8n basiert.
Zuerst erfolgt die Visualisierung, welche Scale
sicher sind und welche Probleme verursachen können:
Nahe
Scale=1
:
NaheScale=1.2
:
NaheScale=1.5
:
AlleGrünLiniensegmente repräsentieren die sicheren
Scale
Faktoren, währendRotLiniensegmente stellen die problematischen dar.Hier ist die strenge mathematische Beschreibung:
Insbesondere
Scale=1.031369386
,Scale=1.031374755
undScale=1.031384644
Scale=1.031390014
führen alle zu! Dimension too large
. NaheScale=1.03138
:
Diskussionen
Die x-Höhen von Georgia und Cambria Math sind jeweils 986/2048
und 956/2048
. Und Scale=MatchLowercase
wird korrekt Scale=1.03138
durch in umgewandelt fontspec
. Wenn wir nun dievorgeschlagene Neudefinition von\__um_fontdimen_to_percent:nN
Bei 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.03137
oder 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 ScaleAgain
von 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-math
muss 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-math
muss 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 ScaleAgain
in eingeführt wurde fontspec
, also kann man es zum 2. Mal und zum 3. Mal unicode-math
tun . WieScaleAgain=1.00001
ScaleAgain=0.99999
mein KommentarWie bereits erwähnt, unicode-math
ist 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.00001
sieht 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:nN
sollte 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}