27

I'm trying to track down the source of a problem with the new xetex binary in miktex. I think it is related to the following problem in TeXLive 2013:

\documentclass{article}
\usepackage{unicode-math}
\begin{document}
%$a_a$

\message{missing chars}
$a_{aa_{aa}}$
\end{document}

gives in the log-file the message:

Missing character: There is no ƽ in font [latinmodern-math.otf]/ICU:script=math
;language=DFLT;+ssty=1;!
Missing character: There is no Dž in font [latinmodern-math.otf]/ICU:script=math
;language=DFLT;!

The missing char mentioned in the log-file can change in subsequent math. And in most cases I get it only if there is at least two symbols in the subscript. Previous math can change the behaviour. Has anyone an idea what going on here? Where does the missing character message comes from?

Additional info: The missing char (and the error in miktex) appears at the closing math shift. So what is xelatex doing there which could give an font error?

Edit

More or less by chance I found out that the problem disappears (also in miktex) if one reload a math font with a range option and I could track down the effect to this line in the range code:

\documentclass{article}
\usepackage{unicode-math}

\ExplSyntaxOn
\keys_define:nn {unicode-math} {
  nobug .code:n = {
   \cs_set_eq:NN \um_map_char_single:nn \um_map_char_parse:nn
    }}

\keys_define:nn {unicode-math} {
  bug .code:n = {
   \cs_set_eq:NN \um_map_char_single:nn \um_map_char_noparse:nn
    }}

\ExplSyntaxOff

%\setmathfont[bug]{Latin Modern Math}
\setmathfont[nobug]{Latin Modern Math}
\begin{document}

$a^{aa^{aa}}$


\end{document}

The \um_map_char_noparse:nn sets mathcode, so the next step is to find out, why this disturbs the new xetex version.

Edit 2

I found out that the number in the error message in miktex (\textfont XXX is undefined) and the missing chars change if I use the ^^-notation before the math. With every additional use of ^^ the numbers/chars "count down". In TeXLive the missing char message disappears sometimes (obviously because the currently requested char is in the font). If there is no \par between the ^^21 the steps are smaller. Three or more ^^^ change the steps too.

That's all very curious, and I suspect some error in the handling of the ^^-notation -> this hypothese seems to be wrong see Edit 4.

\documentclass{article}
\usepackage{unicode-math}

\begin{document}
%        font name     TL missing char
%no ^^:  %197  .5      char 453

%uncomment one-by-one to see changes in error/missing char message

%^^21    %142  .5      char 398

%^^21    %91   .5      -

%^^21    %40   .5      -

%^^21    %245  ^^@     -

%^^21    %194  ^^@     -

%^^21    %143  ^^@     ^^8f

% other char as superscript, only to avoid side effects:
% it doesn't change the behaviour
\catcode`\?=7
$k?{kk}$

\end{document}

Edit 3

An example emerged (MiKTeX Update: Error `\textfont is undefined` with Package `url`) which doesn't use unicode-math.

miktex users get error message directly, while in TeXLive 2013 on has to add some ^^21 to get the "missing char" message in the log-file:

\documentclass{article}
\usepackage{fontspec}
\setmainfont[]{LinLibertine_R.otf}
\usepackage{url}
\urlstyle{rm}

\begin{document}
^^21 

^^21    

^^21 

^^21 

^^21 

Test: \url{http://test-website.com}
\end{document}

The error happens only with the specific font. With e.g. LinLibertine_RB.otf there is no error.

Edit 4

Joseph Wright analysed the example in edit 3 and came up with an example which doesn't used the ^^-notation but simple chars to "count down" the error/missing char numbers. I also tried to find out what is so special about the libertine font and I think it has to do with math properties: Unlike LinLibertine-M.otf the font set math values like DelimitedSubFormulaMinHeight. Tests with other "math open type" fonts seem to confirm this:

\documentclass{article}
\usepackage[no-math]{fontspec}

\setsansfont{Cambria Math}% or some other font with "math properties"
                          % like LinLibertine_R.otf or latin modern math   
                          % it doesn't matter if it used outside math 
\ExplSyntaxOn
  \SetMathAlphabet\mathsf{normal}\g_fontspec_encoding_tl\sfdefault\mddefault\updefault
\ExplSyntaxOff  

\begin{document}
A 

A

$%
\mathsf{a_{aa}}\showoutput% 
$%
\end{document}

Work-around (not very good)

It seems that the error messages don't affect the end document. So one can remove unicode-math and load fontspec with the no-math option while writing the document and reenable the wanted math setup at the end and then compile with scrollmode to ignore all errors.

Edit 5 - a fix is in view

Khaled Hosny has committed a fix: https://github.com/khaledhosny/xetex/commit/b9f323a. Hopefully this will solve the issue in the more or less near future.

Edit 6 - Joy and Happiness

Today's update of the xelatex binary seems to have solved the problem for miktex.

Ulrike Fischer
  • 327,261
  • It happens also on TeX Live 2013 (Mac OS X, 10.8.4, MacTeX). – egreg Jul 07 '13 at 16:17
  • @egreg on the xetex list other confirmed the behavior too, but until now nobody had an idea about the source. – Ulrike Fischer Jul 07 '13 at 16:21
  • @UlrikeFischer: On my setup at least (up-to-date MiKTeX 2.9), your range-reload workaround seems to work only partially. E.g. $a^{2^{aa}}$ gives a \scriptfont 193 is undefined (character .5). error in the nobug mode. Can you confirm? – dpprdan Jul 22 '13 at 14:08
  • @dapperdan: I haven't the time now to make tests, but I can confirm that the work-around fails in various cases (I run into them too). But it could be useful to track down the source of the problem. – Ulrike Fischer Jul 22 '13 at 14:19
  • @UlrikeFischer: Are Jonathan or Khaled really aware of this bug? I have not seen a comment from them on the XeTeX mailing list nor anywhere else. It's been filed as a bug on MiKTeX and [unicode-math] (https://github.com/wspr/unicode-math/issues/253), but apparently not on XeTeX. (Granted, there is comment from Khaled on the unicode-math bug report, but IMHO it does not apply). Anyway, shouldn't we file it as a bug on XeTeX? – dpprdan Aug 16 '13 at 08:50
  • 2
    Just for completeness: This issue has been raised here and here on tex.sx. @UlrikeFischer's mails on the XeTeX mailing list are here and here – dpprdan Aug 16 '13 at 08:57
  • 2
    @dapperdan: I wrote Khaled an email and he answered me. I also informed him by mail about the content of edit 2 (without answer until now). It would be probably not a bad idea to add something to the xetex bug tracker so that the problem doesn't get lost, so do it. – Ulrike Fischer Aug 16 '13 at 09:00
  • @UlrikeFischer: I filed it. – dpprdan Aug 16 '13 at 13:03
  • @UlrikeFischer Do you see the message in TL2013 with the latest edit (I'm not quite clear on whether the demo is for TL or MiKTeX, or both) – Joseph Wright Aug 18 '13 at 16:56
  • 1
    @JosephWright: Yes the example is also meant for TL2013. I explictly added enough ^^21 to "count down" to a missing char in TL2013. I see there (only in the log) the message Missing character: There is no ^^90 in font [LinLibertine_R.otf]/ICU:script=lat n;language=DFLT;!. But as the error is obviously font dependant it is possible that it can't be seen on all systems. – Ulrike Fischer Aug 18 '13 at 17:01
  • @UlrikeFischer: I am probably stating the obvious here, but since I first misunderstood what you wrote in Edit 3 & 4: Edit 3 also does not compile on MiKTeX with math fonts like Cambria Math and XITS Math. I also happen to have LinLibertine_R_G.ttf installed on my system (once bundled with LibreOffice I guess), and with that it also does not compile. (Though it does compile if I remove the hyphen from the URL.) So if I understand correctly, the problem generally exists with opentype math fonts and fonts like LinLibertine_R.otf that "set math values like DelimitedSubFormulaMinHeight". – dpprdan Aug 20 '13 at 08:44
  • After instaling all updates, my document compiles, but I still get the ** WARNING ** Couldn't open font map file "kanjix.map". – matth Sep 02 '13 at 08:06
  • 1
    @matth: The warning is harmless. You can add an empty kanjix.map to get rid of it. Or wait: I made a bug report. – Ulrike Fischer Sep 02 '13 at 08:38
  • I don't want to object to anything with this question, I'm totally ok with it (cf. http://meta.tex.stackexchange.com/questions/3492/why-are-questions-on-package-bugs-issues-too-localized). But isn't this an extremely clear case of a "bug report", which the community usually is alarmingly swift at closing as being "too localized"? I'm not sure it's a good sign that "bug reports" from big names are treated differently from "bug reports" raised by more novice users. – Sverre Sep 02 '13 at 14:43
  • @Sverre: Well then vote to close it. I asked the question because I needed to pin the source of the problem and also because it was useful to have a record of the current state of the investigation. Now that the bug has been found and fixed (at least in miktex) I don't care a dam what happens with it. – Ulrike Fischer Sep 02 '13 at 15:02
  • @UlrikeFischer As said, I don't have anything against the question or it being asked, so I have no intention of voting to close it. I just wanted to point out a glaring inconsistency in how questions from veteran users seem to be treated very differently from questions from novice users. And I'm not sure if that's a good thing. That's all. – Sverre Sep 02 '13 at 15:09
  • @sverre: While it was clear from the beginning that there is a bug somewhere which affected all miktex users it was until last week quite unclear where exactly. It could have been a problem with unicode-math, the xetex binary, a font, only with miktex. The question was certainly not to localized two weeks ago, but now it is only the report of a bug which has been fixed. The status of a question can change during an investigation. – Ulrike Fischer Sep 02 '13 at 15:33

1 Answers1

9

It was a bug in XeTeX 0.9999 and have been fixed in master (with this commit). MiKTeX binaries seems to have been updated and the issued have been verified to be fixed (thanks to Ulrike Fischer). TeX Live binaries will not be updated until next year of course, but the missing char warning is, hopefully, harmless.