Re: [LaTeXML] Fwd: Special TeX/LaTeX fonts in MathML (calligraphy vs. script)
David Carlisle <[email protected]> Mon, 21 Jul 2014 11:51:12 +0100
| Newsgroups | gmane.comp.mozilla.devel.mathml |
|---|---|
| Message-ID | <[email protected]> |
On 21/07/2014 11:22, Peter Krautzberger wrote: > And it would definitely help if the MathWG would take an official > position on issues like this. Speaking personally, not speaking for the group, but... we could try to take a position but it's not clear what the position should be. For mathvariant there is always a tension between switching fonts (which is often needed for legacy or typographic reasons) and switching to the upper plane math alphabets which fits better with a direct interpretation of the Unicode character model underlying MathML. The MathML spec doesn't enforce any rendering technology so it only says that mathvariant should work like the upper plane characters. It will not take a position on whether you should implement that by mapping <mi mathvariant=bold to the upper plane and using the same font, or to map the upper plane alphabets back to the BMP and switch fonts. See for example https://github.com/wspr/unicode-math/issues/254 for a discussion about what unicode-math (support for math in unicode tex extensions) should do with \mathbf (tex markup equivalent of mathvariant="bold") The calligraphic alphabet has the additional problems that by some readings of Unicode it "should" be unified with script. I suspect that the best we could do _now_ is to make a note suggesting a markup such as <mi class="calligraphic" mathvariant="script">A</mi> that different implementations could then pick up or not as they see fit. We could also, if people want that, try to coordinate a request to Unicode to add a new math alphabet, I have some sympathy with that as a good final outcome but getting code points assigned, and in particular enough fonts using those code points that it would make sense to use them in documents, would take some years so having a class attribute based markup (which has much better fallback than using new code points on existing systems) may still be worthwhile. David