Note that this explanation is actually a guess. I do not know enough about how these things work to be sure. Caveat emptor.
It would be great to have a real solution to this problem.
A real solution requires extending the opentype versions of MnSymbol quite significantly, I think. (I explain why below - I don't mean that the coverage is insufficient.)
In theory the mentioned OpenType version of MnSymbol should allow a
proper solution, right?
No. This is not correct.
Furthermore, an explanation why setting up MinionPro+MnSymbol is not
straightforward in the first place would be great. After all,
MinionPro+MnSymbol is possible in plain pdflatex, and it would be
somewhat disappointing if it does not work in lualatex, which is
supposed to improve working with fonts.
It is unfortunately more complicated even in the case of text. It is several times of magnitude more complex again in the case of maths. I begin with the text case because it is simpler.
Text
What XeTeX and LuaTeX do is enable you to access all of the bells and whistles featured in sophisticated opentype fonts. This is fantastic in terms of providing access to 'regular' fonts. Suddenly, you do not need any special support package to write your text - or maths - using the same fonts used by any other application on your system.
The downside of this is that the opentype fonts need the bells and whistles. For example:
$ otfinfo -f fonts/opentype/public/lm/lmroman10-regular.otf
aalt Access All Alternates
cpsp Capital Spacing
dlig Discretionary Ligatures
frac Fractions
kern Kerning
liga Standard Ligatures
lnum Lining Figures
onum Oldstyle Figures
pnum Proportional Figures
size Optical Size
tnum Tabular Figures
zero Slashed Zero
So opentype will allow you to access the oldstyle figures, say, via the onum feature of the font. What does this mean? It means that the font has the relevant characters, of course. That is, it has to actually include 0, 1, 2 etc. oldstyle figures. But it also needs to do something else as this screenshot from fontforge shows:
If the font contained the characters but not the mappings needed for the font feature onum, we'd be stuck.
In contrast, (pdf)TeX cannot use fonts without specialised support files. This of course limits the fonts you may use. Even if you know how to prepare such files yourself, it is time-consuming and fiddly to do so.
On the other hand, the information the fonts themselves need to provide is relatively minimal. Essentially, they need to provide the glyphs (the pictures of each character), some basic information about each character (width, height etc.) and, ideally, kerning information (which says how the spacing should be adjusted when particular pairs of characters occur), and some general information about the font itself (name, encoding, x-height etc.). If some of this information is wrong, you can actually compensate for it in preparing the support files. For example, you can tell TeX that the character in slot 83 is a comma even if the font itself claims it is the capital A. That's more work, but it is doable.
Furthermore, any bells and whistles get specified in the support files. For example, suppose that you want to enable e.swash as an end-of-word swash character. In an opentype font, you must hope that the font specifies this as part of a font feature which can be accessed straightforwardly via Xe/LuaTeX. In (pdf)TeX, you don't have to hope - there's no point. This can't be specified in type1 fonts and (pdf)TeX couldn't use that information anyway. Instead, the support files must provide TeX with this information. So whoever writes those files specifies the relevant relationships.
So the onus in the case of Xe/LuaTeX and opentype fonts (absent special work arounds etc.) is very much on the font features being configured correctly. Xe/LuaTeX provide a general interface to any font, provided that font has the relevant features.
The onus in the case of (pdf)TeX with type1 (or truetype for pdfTeX) fonts is to a much larger extent on the font features being configured in the TeX support files. This is why it can make sense, for example, to write a package such as cfr-lm which provides access to exactly the same type1 fonts as lmodern. cfr-lm provides access to features of the fonts not supported by lmodern (which is why I wrote it).
So whether or not LuaTeX or XeTeX provide improved access depends very much on the font in question. In the case of a font with no TeX support files or no type1/truetype format, any access is obviously an improvement. In the case of fonts with sophisticated TeX support packages, Lua/XeTeX may or may not provide improved access, depending on
- the features of the opentype fonts involved
- any general limitations in the support TeX can provide relevant to the specific type1/truetype fonts involved
- e.g. features requiring more than 256 characters in a single font
- any specific limitations in the support files actually available for the specific type1/truetype fonts involved
- e.g.
lmodern does not provide access to oldstyle, proportional figures for use as default in text even though this access can be provided as cfr-lm demonstrates.
Maths
Mathematics is more complex. (pdf)TeX requires specially designed fonts plus specialised support files in order to typeset maths correctly. Unlike the text case, you cannot get very far trying to create support files for arbitrary fonts. As far as the fonts themselves are concerned, the issue here is primarily to do with coverage - you need various symbols and they need to fit together for the whole thing to work. Generally, only fonts designed for TeX have these.
Xe/LuaTeX similarly requires coverage i.e. the needed characters must be there. However, just as something more was required in the text case in the form of the relevant font features (e.g. onum), something more is required in the case of maths as well.
As I understand it, unicode-math provides access to the mathematical extension of the opentype specification developed by Microsoft for Office 2007. This essentially defines something a little like opentype features for text but for maths. Merely having a font with the requisite characters in opentype format is not sufficient. The font also needs to implement the relevant parts of the maths extension.
To see the problem, consider the following screenshots from fontforge. These were taken using Element > Other Info > Math Info > Exten Shapes. The first shows part of this table for Latin Modern Math:
The second is the table for MnSymbol at 10pt:
Similar comparisons can be done for other aspects of the maths configuration of these fonts.
Conclusion
In conclusion, MinionPro + MnSymbol is better supported by (pdf)TeX than it can be by unicode-math. To work straightforwardly with Xe/LuaTeX and unicode-math, the opentype versions of MnSymbol would need to be extended to support the relevant parts of the opentype maths extension.
Postscript
It turns out that there is a further problem with the opentype version of MnSymbol in combination with LuaTeX which has nothing to do with its lack of support for maths. This is actually why LuaLaTeX fails with a fatal error rather than just producing a crappy-looking PDF.
The following MWE can be used to reproduce the error:
\documentclass{article}
\usepackage{fontspec}
\newfontfamily \mymnsymbolfont {MnSymbol10.otf}
\begin{document}
\mymnsymbolfont +
\end{document}
LuaLaTeX fails with a fatal error. XeLaTeX compiles the document fine. I am not sure whether this is a bug in LuaLaTeX or MnSymbol or both. The analogous document using MdSymbol works OK with both engines.
Seeing the effect of using an opentype font without support for maths
To see why an opentype font which does not support the maths extension cannot be used straightforwardly, I therefore use MdSymbol with MinionPro. The following example compares this combination with Latin Modern with Latin Modern Math, which is default.
\documentclass{article}
\usepackage{amsmath}
\usepackage{unicode-math}
\begin{document}
\section*{Latin Modern with Latin Modern Math}
\begin{align*}
p(A_j/B) &= \frac{p(B/A_j) p(A_j)}{p(B)}\\
&= \frac{p(B/A) p(A)}{\sum_{i=1}^{n} p(B/A_i) p(A_i)}\\
\end{align*}
\[
v( A_i ) = \sum_{j=1}^\mathrm{n} v(A_i | B_j) \times p(B_j)
\]
\begin{gather*}
\max_{i=1,2} v(A_i|B_j) \neq \min_{i=1,2} v(A_i|B_j)\quad j=1,2\\
\text{but}\;
\bigl(\max_{i=1,2} v(A_i|B_2) - \min_{i=1,2} v(A_i|B_2)\bigr) > \bigl(\max_{i=1,2} v(A_i|B_1) - \min_{i=1,2} v(A_i|B_1)\bigr)
\end{gather*}
\setmainfont[
Ligatures = TeX,
]{Minion Pro}
\setmathfont{MdSymbol}
\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}
\section*{Minion Pro with MdSymbol}
\begin{align*}
p(A_j/B) &= \frac{p(B/A_j) p(A_j)}{p(B)}\\
&= \frac{p(B/A) p(A)}{\sum_{i=1}^{n} p(B/A_i) p(A_i)}\\
\end{align*}
\[
v( A_i ) = \sum_{j=1}^\mathrm{n} v(A_i | B_j) \times p(B_j)
\]
\begin{gather*}
\max_{i=1,2} v(A_i|B_j) \neq \min_{i=1,2} v(A_i|B_j)\quad j=1,2\\
\text{but}\;
\bigl(\max_{i=1,2} v(A_i|B_2) - \min_{i=1,2} v(A_i|B_2)\bigr) > \bigl(\max_{i=1,2} v(A_i|B_1) - \min_{i=1,2} v(A_i|B_1)\bigr)
\end{gather*}
\end{document}
Best Answer
the release date for Minion Math 1.020 with MATH table support is October 2011 (as I still need to perform some tests before release).
In my tests so far Minion Math works (with
fontspecandunicode-math) with LuaLaTeX and XeLaTeX, with slightly better results / less problems in LuaLaTeX. Optical sizes in math do work (with appropriate options for\setmathfont).Minion Math does fully support 4 different weights. In the current setup, Bold Math (Regular and Italic) is taken from a bolder weight, so your example will need a few extra commands (
\setmathrange) and will not work exactly, but almost "out of the box". The\fontsizecommands should work (I will check that).