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