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 option`noendash`

to be passed to`mathastext`

. 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`

and`mathastext`

. As a temporary fix, load`mathastext`

with option`noendash`

.EDIT [2012/10/18]. Versions 1.15x of

`mathastext`

uploaded to CTAN late September have incorporated a work-around to this`amsmath`

+Unicode fonts problem. So it is not necessary to use the`noendash`

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 of`DeclareMathOperator`

which seems to involve also a certain macro which will contain`\mathcode'\-`

(read the ' as a backtick). It seems that once`mathastext`

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`

and`amsmath`

(same for LuaTeX as engine !!), for which the only (due to the AtBeginDocument above) current work-around I see is the following:`mathastext`

with option`noendash`

`\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: