8

I also posts this here: http://texwelt.de/wissen/fragen/3000/interpunktion-in-lualatex-mit-unicode-math-von-hauptschriftart. The problem is that I want to have the \period symbol (also range="002E does not work) from the mainfont, but when I run this:

%!TEX TS-program = lualatex
\documentclass{standalone}
%
\usepackage[math-style=ISO]{unicode-math}
%
\setmainfont{MinionPro-Regular}
%
\setmathfont{LatinModernMath-Regular}
\setmathfont[range=\period]{MinionPro-Regular}
\setmathfont[range=\mathup/{num,latin,Latin,greek,Greek}]{MinionPro-Regular}
\setmathfont[range=\mathbfup/{num,latin,Latin,greek,Greek}]{MinionPro-Bold}
\setmathfont[range=\mathit/{num,latin,Latin,greek,Greek}]{MinionPro-It}
\setmathfont[range=\mathbfit/{num,latin,Latin,greek,Greek}]{MinionPro-BoldIt}

\begin{document}
    $\bigl(x^2+5\bigr).$
\end{document}

I get the following result:

enter image description here

Are there any ideas to solve this problem? Thanks for help.

I may think the problem lies in the \right.- and \left.-delimiters, because you won't get the incorrect result if you use \left and \right instead of \bigl( and \bigr). It seems as if range=\period makes them visible.

Is there a possibility to fix this?

Improve this question
3
  • Indeed, when range=\period is issued, when I trace the list built by $\left(x\right.)$ I get \right"42E000 instead of the expected \right"0 that would denote an empty delimiter. This happens also with XeLaTeX.
    – egreg
    Jan 15, 2014 at 16:11
  • @egreg Anything new on this subject? Should I report this to the unicode-math maintainers, as it still happens with an up-to-date miktex?
    – John
    Oct 16, 2014 at 22:25
  • I forgot this question; on my TeX Live 2014 the problem seems solved. Using unicode-math 2014/06/30 v0.7f.
    – egreg
    Oct 16, 2014 at 22:33

2 Answers 2

Reset to default
8

The problem has not yet been solved with version 0.7f of unicode-math, so this answer is just an attempt to see what's happening; an ugly workaround is proposed.

This is what I get when adding \showlists to the definition of \big with

\usepackage{etoolbox}
\makeatletter
\patchcmd{\big}{\n@space}{\n@space\showlists}{}{}
\makeatother

from $\big($.

unicode-math version 0.7e

\mathinner
.\left"28000
.\mathord
..\vbox(8.5+0.0)x0.0
.\right"42E000
### restricted horizontal mode entered at line 20
spacefactor 1000
### math mode entered at line 20
### math mode entered at line 20
\mathord
### restricted horizontal mode entered at line 18
spacefactor 1000
### vertical mode entered at line 0
### current page:
\write-{}

unicode-math version 0.7f

### math mode entered at line 20
\mathinner
.\left"28000
.\mathord
..\vbox(8.5+0.0)x0.0
.\right"0
### restricted horizontal mode entered at line 20
spacefactor 1000
### math mode entered at line 20
### math mode entered at line 20
\mathord
### restricted horizontal mode entered at line 18
spacefactor 1000
### vertical mode entered at line 0
### current page:
\write-{}

The output is obtained with XeLaTeX, but with LuaLaTeX it's similar. We can clearly see

.\right"42E000

with the 0.7e version, that shows exactly a centered dot after \right. With the 0.7f version we get

.\right"0

that is, the expected null delimiter.

Here's the PDF output from the OP's example.

Output with unicode-math version 0.7e (and TeX Live 2013)

enter image description here

Output with unicode-math version 0.7f (and TeX Live 2014)

enter image description here

Where's the magic?

In passing from 0.7e to 0.7f the entry for \period has been removed from unicode-math-table.tex, so range=\period does nothing. If we change range=\period to range=\mathperiod (the new name), the centered dot reappears.

Workaround

\documentclass{standalone}
%
\usepackage[math-style=ISO]{unicode-math}
%
\setmainfont{MinionPro-Regular}
%
\setmathfont{LatinModernMath-Regular}
\setmathfont[range=\mathperiod]{MinionPro-Regular}
\setmathfont[range=\mathup/{num,latin,Latin,greek,Greek}]{MinionPro-Regular}
\setmathfont[range=\mathbfup/{num,latin,Latin,greek,Greek}]{MinionPro-Bold}
\setmathfont[range=\mathit/{num,latin,Latin,greek,Greek}]{MinionPro-It}
\setmathfont[range=\mathbfit/{num,latin,Latin,greek,Greek}]{MinionPro-BoldIt}

\Udelcodenum`.=1073741824 % reset the right delcode

\begin{document}
$\bigl(x^2+5\bigr).$
\end{document}

enter image description here

According to my PDF previewer, the final period is in Minion Pro.

Improve this answer
7
  • I think the point behind the closing bracket is still set in Latin Modern (Compare to a dot directly after the $ and use Cambria Math for clearer visibility - the point in the math environment is still set in Cambria Math and thus a small square). It can be avoided if range=\mathperiod is issued, but this leads to exactly the behaviour observed for version 0.7e and range=\period.
    – John
    Oct 17, 2014 at 11:02
  • @John I don't think it's a font problem: since there's \right"0 no character is typeset, it's just a signal for inserting \nulldelimiterspace (that's later removed by \n@space in the definition of \big).
    – egreg
    Oct 17, 2014 at 11:44
  • It depends on which period we mean. If I only change Latin Modern to Cambria Math in your working example above, I don't get the centered dot after the bracket, but the final dot right before the dollar sign is still typeset in Cambria Math (a square, not a circle like it should be in MinionPro). I'm pretty sure in your working example the final dot is typeset in Latin Modern, but as the period is very similar to the one of Minion Pro this is not really visible. You get the correct final period if \mathperiod is used as range, but then the centered dots appear again.
    – John
    Oct 17, 2014 at 11:51
  • @John You're right, the bug is still there. The entry for \period has been removed from unicode-math-table.tex and that somewhat explains what happens.
    – egreg
    Oct 17, 2014 at 12:02
  • @John I added a workaround
    – egreg
    Oct 17, 2014 at 12:12
3

The question is somewhat general, but refers to the specific problem of periods, which have a special meaning for TeX delimiters. (Choosing other punctuation from other fonts works fine, right?) My understanding is that they should always have delcode of zero; unicode-math has a line of code to ensure this, and due to a broader bug in how range is interpreted it's not being run.

The next version of unicode-math will fix this. (You can check out the development version on Github but I can't guarantee it will work from night-to-night.) Sorry for the slow reply.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .