W3C home > Mailing lists > Public > www-math@w3.org > September 2013

Re: New menclose notation coming in MathML 3, 2nd edition

From: Frédéric WANG <fred.wang@free.fr>
Date: Fri, 06 Sep 2013 10:12:00 +0200
Message-ID: <52298E50.5040608@free.fr>
To: Neil Soiffer <NeilS@dessci.com>
CC: mathjax-dev@googlegroups.com, "www-math@w3.org" <www-math@w3.org>
Thanks for the information Neil. I think that should be easy to 
implement, indeed. I'll open bug entries for that. BTW, could you also 
add the "updiagonalarrow" notation to that list ; I proposed it a few 
months ago to implement the LaTeX cancel package (used for example in 
LaTeXML and MathJax).

First a remark about deprecated unitless values that I mentioned in the 
past. While discussing mfrac@linethickness with a WebKit developer 
recently, I noticed that the examples of mfrac still use the deprecated 
unitless syntax 
(http://www.w3.org/Math/draft-spec/chapter3-d.html#id. and this 
caused some confusion. I think it would be worth checking all the 
definitions/examples again and remove the deprecated notations if any.

I don't how many new features you can add to the new edition, but 
MathJax currently attaches some CSS classes to MathML elements to 
implement non-standard features and I'm wondering if they can be 
standardized. The "updiagonalarrow" was one of them, now fixed in v2.2. 
Another one is to emulate TeX spacing, but that will be perharps a bit 
complicate to consider for a second edition and probably not wanted for now.

One issue that was raised several times in the past is the mathvariant 

"Renderers should support those combinations of character data and 
mathvariant values that correspond to Unicode characters, and that they 
can visually distinguish using available font characters. Renderers may 
ignore or support those combinations of character data and mathvariant 
values that do not correspond to an assigned Unicode code point".

One paragraph mentions that CSS, when available, may be used to 
implement mathvariant. This has caused some "style vs mathvariant" 
confusions in the past especially since MathJax and browsers currently 
only implement them via font-style/font-family/font-weight changes and 
they are probably not always "protected from inadvertent document-wide 
style changes".

While working on math fonts recently, it seems that many of them have 
characters from these "Mathematical Alphanumeric Symbols" block as well 
as other alphanumeric glyphs that are not accessible via Unicode. In the 
STIX fonts, that's a bit messy: many glyphs are duplicate between the 
reserved mathvariant code points and the various styles (-Regular, 
-Italic, -Bold, -BoldItalic), probably to work with the style-based 
implementations ; and the STIX fonts also have some non-Unicode glyphs 
(e.g. PUA characters for italic double-struck in STIX-Italic). In other 
cases, there is only one single "math" font and the style-based 
implementation can not work ; so we need a mechanism to access all the 
glyphs especially the non-Unicode ones. That's generally not a problem 
for MathJax: because of various technical issues we must split the 
(free) fonts and reorganize the glyphs in different code points if we 
want to add support for these fonts. However it's currently not possible 
to implement \mathcal and \oldstyle in MathJax (without adding 
non-standard CSS class) and it's a problem for other rendering engines 
that would like to support mathvariant for arbitrary math fonts. So here 
are two changes that I'd like people to consider:

1) Mention that renderers are allowed to pick non-Unicode glyphs from a 
font for combinations that do not correspond to an assigned Unicode code 
point. For example, if a font contains a non-Unicode glyph that 
represents a bold plus sign then this glyph can be used to render <mo 
mathvariant="bold">+</mo>. That's already implicitly allowed in the 
description, but that would provide a suggestion for implementers. Also, 
that seemed to be the only way to implement the Arabic ones when they 
were proposed 

2) Allow mathvariant values "calligraphic" and "oldnumerals". It's a bit 
controversial given that it's not clear if they have a specific 
mathematical semantics or are just stylistic changes (see for example 
http://lists.w3.org/Archives/Public/www-math/2006Jul/0013.html and 
comments at the end of 
https://en.wikipedia.org/wiki/Text_figures#History). However, for most 
of the mathvariant notations (except perhaps fraktur or double-struck) 
the implied mathematical semantics is not clear to me and most of them 
only looks like stylistic changes that can be used to provide a distinct 
mathematical meaning in some contexts (for example some physicists use 
bold to indicate a vector). At least, \mathcal and \oldstyle have been 
used in LaTeX and probably some people have used them to provide a 
distinguish mathematical meaning in the context of their papers. 
Certainly the logical class is not obvious but the same is true for 
values like monospace, sans-serif or (for me) the Arabic variants.

Any thoughts?

Le 06/09/2013 07:44, Neil Soiffer a écrit :
> The MathML WG is putting together a second edition that has a number 
> of errata, clarifications, and updates.  It is still a month or two 
> away from publication, but I wanted to give a heads up to key 
> implementers...  Probably the only thing new that affects rendering is 
> the addition of a new menclose notation added to the list of 
> recommended notations to implement.
> The new notation attribute value is "phasorangle".  It is a notation 
> that is widely used in circuit analysis but was missed by the WG.  It 
> is described here:
> http://www.w3.org/Math/draft-spec/chapter3-d.html#id.
> This is a diff-marked version of the spec so you can easily see the 
> changes.
> There is a TeX package that implements this:
> http://mirror.hmc.edu/ctan/macros/latex/contrib/steinmetz/steinmetz.pdf
> The key part (at least for me to implement it in MathPlayer) was to 
> see that it uses a slope of 2 (angle = tan^-1(2)) for the angled line 
> and that value seems to work reasonably well.  It was relatively 
> simple to implement in MathPlayer. I and the rest of the MathML WG 
> hope that it will be easy to add to MathJax, FireFox, and Webkit.
> Let me know if you have questions,
> Neil Soiffer
> Senior Scientist
> Design Science, Inc.
> www.dessci.com <http://www.dessci.com>
> ~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~
Received on Friday, 6 September 2013 08:12:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:46 UTC