2


Recently, I updated to MiKTeX 2.9, and after this the xelatex compiler fails when compiling documents with the fontspec package included. In other words, the following code won't compile:

\documentclass{article}
\usepackage{fontspec}
\setmainfont{Cambria}

\begin{document}
Hello world!
\end{document}

I don't know what has changed when I updated to MiKTeX 2.9, but I get the following build log message in TeXnicCenter:

("C:\Program Files\MiKTeX 2.9\tex\latex\euenc\eu11mr.fd")
xelatex.exe: Windows API error 1113: No mapping for the Unicode character
exists in the target multi-byte code page.

The same thing seems to be the problem when compiling in TeXWorks.

I've tried reinstalling MiKTeX 2.9 to make sure everything was up to date, but this did not help.

Does anyone have any idea how I can solve this problem? Answers are much appreciated.

EDIT:

Here's a list of specifics:

  • All outdated packages have been updated, and the file name database has been refreshed.
  • I do get a log file when compiling. The only file I don't get is the pdf output.
  • The operating system I'm using is Windows Vista.
  • The xelatex --no-pdf file cmd (terminal) command gives the same error message as quoted above.
  • My user name does contain a non-ASCII character. However none of the characters are outsude the Latin-1 charset.
  • No other file or folder has a non-ASCII character.
|improve this question
  • Your example works fine for me (with an updated miktex 2.9). Does it compile if you remove the \setmainfont command? – Ulrike Fischer Feb 9 '11 at 18:15
  • @Ulrike Fischer - The build log (in TeXnicCenter) is the same with or without the '\setmainfont' command. In both cases, TeXnicCenter produces no pdf output, while TeXWorks produces a faulty pdf output. When the '\setmainfont' is included, the TeXWorks output is "Cambria <newline> Hello world!" in the standard font. In both cases, TeXWorks gives the same Windows API error as quoted above. – eiterorm Feb 9 '11 at 19:13
  • Do the full path of the TeX file or the path of the Cambria font file contain any non-ASCII characters? – Philipp Feb 9 '11 at 23:14
  • @Philipp - No, none of the file paths contain any non-ASCII characters. – eiterorm Feb 10 '11 at 0:03
  • Does your user name contain a non-ASCII-char? Do you get the message if you compile on the command line? Do you get a log-file? Do you get the message if you use xelatex --no-pdf file? Which windows are you using? – Ulrike Fischer Feb 10 '11 at 9:08
4

I'm getting the same error message:

pdflatex: Windows API error 1113 : No mapping for the Unicode character exists in the target multi-byte code page.

with newest updates installed (Miktex 2.9 and all available updates installed on 2011-12-24). With about half a year ago the file worked perfectly.

The reason for the problem was that I was using a scandinavian character in my file name when using \includegraphics:

\includegraphics[width=8cm,height=7cm,keepaspectratio]{å}

When I renamed the file from å.jpg to ae.jpg, the error message disappeared:

\includegraphics[width=8cm,height=7cm,keepaspectratio]{ae}

The problems you are experiencing might have something to do with character encoding in file names.

Hope this helps anyone getting that error message with similar reason.

|improve this answer
  • 1
    I figured it was indeed the non-ASCII character in my username which caused the error, so I'm marking this post as the best answer. It seems that after the update, MiKTeX couldn't handle non-ASCII characters. MiKTeX had stored some required files in the 'C:\Users\username\AppData' folder (Windows Vista), and because my username contained a non-ASCII character, I got the error mentioned above when compiling. Sorry for the late reply. I haven't paid much attention to this website in a while. – eiterorm Jul 3 '12 at 16:38
  • Great, if this helped! – Vesa Linja-aho Jul 4 '12 at 17:42
3

This must be a build problem of xetex in Windows — I've never seen that error before. Try loading a font without fontspec:

\font\x="Cambria" at 12 pt \x hello

This should hopefully produce a similar problem that you can report to MiKTeX support.

|improve this answer
  • This does indeed give the same build error. Do you have any idea what might be wrong? – eiterorm Feb 10 '11 at 0:02
  • @eiterorm no idea at all, sorry. I suggest asking in a miktex forum. – Will Robertson Feb 10 '11 at 0:15
  • 2
    The miktex forum is quite dead. As far as I can see I'm more or less the only one who sometimes answers questions there. As the sourceforge interface is quite bad (it often throw me out and loose answers) I prefer to assemble the informations needed for a possible bug report here or in c.t.t. – Ulrike Fischer Feb 10 '11 at 13:47
  • @Ulrike thanks, I didn't realize. Perhaps the xetex list, then, might reach someone with more knowledge of this. – Will Robertson Feb 10 '11 at 22:10
1

There is no Cambria font on you computer. Try some standard fonts like Tahoma. If it works then it is not thing related with MiKTeX 2.9.

|improve this answer
  • @S. Boonto - The Cambria font is there. I have compiled documents with the very same preamble before updating to MiKTeX 2.9, and that compiled just nicely. The problem seems to be related to either fontspec, MiKTeX, Windows or a combination of the three. However, since it all worked before updating MiKTeX, I assume the problem is not directly related to Windows. – eiterorm Feb 9 '11 at 19:12
  • 1
    @eiterorm I try to reproduce your problem but could not found any mistake. I just see that you use the way to reinstall a fresh MiKTeX 2.9. I think this way you will not get the most update fontspec package. Could you check the version of fontspec? Is it 2010-11-24 version? – S. Boonto Feb 9 '11 at 21:03
  • @S. Boonto - After I reinstalled MiKTeX 2.9 I also updated all outdated packages and updated the file name database. Sorry for not being precise enough. So yes, the version is the 2001-11-24 version. – eiterorm Feb 9 '11 at 22:27
  • This is not the error for a missing font. – Will Robertson Feb 10 '11 at 0:16
  • @eiterorm Try a command line "initexmf -v --mkmaps -u". May be it is better than doing nothing. I know it is quite stupid suggestion. – S. Boonto Feb 10 '11 at 9:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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