TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to use the tipa package with fontspec, but they don't play nice together. I've read previous questions trying to solve the issues that come up (like this one), and that's the solution I've been using so far.

However, I've bumped into a problem that I can't really understand. Below I include a (unrealistically brief) MWE taken from the question linked to above. The real document is much more complex, but this illustrates the problem nicely. The following document compiles with no warnings or errors for me:


  \renewcommand\textipa[2][r]{{\fontfamily{cm#1}\tipaencoding #2}}


But adding a line like


breaks it. What is really puzzling is that compilation halts without any sort of warning, even with -interaction=nonstopmode enabled. In the above example I could simply use \~an\~a, without the tipa environment, but in other cases this is not an option.

I've read the recommendations for linguistics papers, but since all my transcriptions are already typed out using tipa, I'm reluctant to give it up and start doing the charmap spelunking that would be necessary.

Is there a way to use \~ in a tipa environment while still using fontspec?

share|improve this question
Just remove the fontspec line and it will work. – Yiannis Lazarides Feb 26 '13 at 20:58
It also works if I don't use \~, but that's the whole point: I need fontspec just as much as I need \~. I find it hard to believe that it is not possible to use both. – jja Feb 26 '13 at 21:12
Tex doesn't stop, adding \tracingall shows that \~ gets itself into an infinite loop expanding to a definition that includes itself. Not entirely sure why yet – David Carlisle Feb 26 '13 at 21:26
{\fontencoding{OT1}\selectfont\~ a} works although it's a bit less than ideal. – David Carlisle Feb 26 '13 at 21:27
@DavidCarlisle, that does work, but it doesn't seem to keep the tipa environment, does it? Because something like \textipa{{\fontencoding{OT1}\selectfont\~ O}na} does not print a nasalised ɔ but an O with a tilde on top. – jja Feb 27 '13 at 12:32
up vote 5 down vote accepted

The problem here is xunicode, which as observed in the linked question makes some changes to the tipa system on the assumption that Latin Modern has appropriate glyph coverage. Perhaps the easiest way around this is to prevent xunicode loading at all:

\expandafter\def\csname ver@xunicode.sty\endcsname{}


as the tipa mechanism is then left alone. Note that this may break other things: the outcome will very much depend on the real documents involved. (You may need to manually 'restore' parts of xunicode.)

share|improve this answer
It's been some time since I asked this question, so I can't even remember what the eventual solution I used was. But this definitely solves the issue at hand, so I'm going to accept this. And damn the consequences of those things that might get broken! :) – jja Aug 12 '13 at 0:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.