When compiling a file using XeLaTex in TeXShop on Mac OS X, the console persistently hangs after the detection of the XeTeX driver:
*geometry* driver: auto-detecting
*geometry* detected driver: xetex
./paper.tex:53: Extended mathchar used as mathchar (71311379).
<to be read again>
\relax
l.53 \begin{document}
It's possible to continue the compilation, but I'd like to understand what is going on. The problem seems to be related to the mathastext
package, which I use to allow math and text formatting both to use the TeX Gyre Termes font; commenting out the \usepackage
line for mathastext
relieves the problem.
I've seen discussions from 2006 (long predating the existence of mathastext
) saying that there is a bug in the XeTeX distro (v. 0.995 rev. D) and the only solution is to compile from source. (Google search results here.) The version of XeTeX currently installed on Mac OS 10.6.7 by TeX Live is 0.9997.4, but the problem persists, and I wonder if there is any newer intelligence on how to repair it or what causes it. I am having trouble building XeTeX manually.
Edit, 20110505
Because the discussion below became quite involved, I am summarizing the two main conclusions:
- There turns to be a bug in
amsmath
that requires the optionnoendash
to be passed tomathastext
. An alternate fix is offered by Philipp. - Discussion of how to get math formatting to apply to non-math text, without looking like math mode, was transfered to a different posting: applying math formatting to a non-math font.
your code loading mathspec which itself caused behind the scenes fontspec to be loaded with option no-math?
Edit: minimal example, as requested by Philipp
%!TEX TS-program = xelatex
%!TEX encoding = UTF-8 Unicode
\documentclass[12pt]{article}
\usepackage{geometry}
\usepackage{amsmath}
\usepackage{mathspec} % replaces amssymb; do not use unicode-math
\usepackage[italic]{mathastext} % propagates document text font to math mode
\usepackage{xeCJK}
\usepackage{fontspec}
\defaultfontfeatures{Mapping=tex-text}
\setromanfont{TeX Gyre Termes}
\begin{document}
The expected number of collisions in a given unit is \[E(collisions)=k\times\left(1-\left(1-\left(1/n\right)\right)^{{\left(k-1\right)}}\right)\]
\end{document}
Another edit, 2011.05.04, replying to JFBU's comment about [no-math]
.
With no-math
being passed to fontspec
:
\usepackage[no-math]{fontspec}
...
\setmainfont[Scale=1,Mapping=tex-text]{TeX Gyre Termes}
...
\usepackage[italic,noendash]{mathastext} % set *after* setmainfont
...
\begin{document}
au\(_{\rm3yā}\)
\end{document}
I get . But without
no-math
being passed to fontspec
:
\usepackage{fontspec}
...
\setmainfont[Scale=1,Mapping=tex-text]{TeX Gyre Termes}
...
\usepackage[italic,noendash]{mathastext} % set *after* setmainfont
...
\begin{document}
au\(_{\rm3yā}\)
\end{document}
I get . I believe these are the same; I chose ā because the height of the macron is very distinctive in Termes.
Edit, 2011.05.04b: In response to another comment of @JFBU, appearance of \centerline{0123456789}\centerline{$0123456789$}
with and without no-math
passed to fontspec
.
With no-math
:
W/o no-math
:
I see no obvious difference.
Best Answer
There is indeed a problem due it seems to an interaction between
amsmath
andmathastext
. As a temporary fix, loadmathastext
with optionnoendash
.EDIT [2012/10/18]. Versions 1.15x of
mathastext
uploaded to CTAN late September have incorporated a work-around to thisamsmath
+Unicode fonts problem. So it is not necessary to use thenoendash
option anymore. END OF EDIT.The following compiles on my system:
I switched to Times New Roman, as the TeX Gyre fonts are not available on the system I am currently on. I will edit my answer once I understand better what's going on.
Ok, it seems that the problem is related to the presence of the following two lines in
amsmath.sty
(lines 745-747)and to the fact that
mathastext
redefines the minus sign in math mode with the following instruction:Furthermore the file
amsopn.sty
(loaded by amsmath) makes a definition ofDeclareMathOperator
which seems to involve also a certain macro which will contain\mathcode'\-
(read the ' as a backtick). It seems that oncemathastext
has done its job with the line above to use the en-dash as minus sign, any call to\mathcode'\-
throws an error, as one sees by compiling just the following two linesin a TeX source with no package at all. So this situation creates a general incompatibility between
mathastext
andamsmath
(same for LuaTeX as engine !!), for which the only (due to the AtBeginDocument above) current work-around I see is the following:mathastext
with optionnoendash
\begin{document}
put the line written belowLine for XeTeX:
Line for LuaLaTeX:
Hope it helps. The author of
mathastext
should put this stuff in an AtBeginDocument instruction, but only if it is guaranteed this will be processed by TeX after the amsmath stuff. The following works on my system: