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

On 09/06/2013 01:46 PM, Neil Soiffer wrote:
> We should definitely fix up the unit examples, although I'm less sure
> about the need for the fractionline=0 case since CSS allows the value of
> 0 to not have a unit [1].  This is noted in the MathML spec [2].
>
>
> As for "updiagonalarrow", I looked back at email and saw that the
> discussion died on both a lack of compelling use cases and that
> implementing an arrow in just one direction seems overly restrictive.

The discussion did die out, but I interpreted it to mean there
were no compelling use cases for more general, alternative or bidi forms.
Ie acceptance of updiagonalarrow, but no stomach for anything else.
... Or maybe not even that acceptance? (other than Frederic & I?)

All else equal, though, I certainly prefer general (or generalizable)
solutions.

> Any solution should generalize.  Any of the diagonal lines could have an
> arrow on either or both sides, so that introducing names for them would
> result in 6 additional named notations.  But why limit it to diagonals?
> Why not allow them on vertical and horizontal strikes?  That's 6 more
> named entities.  And what about along the top, bottom, left and right sides?
>
> Some of the naming can be eliminated by factoring out the arrow head
> from the line, so that you just add four named arrowheads for the
> diagonals and they combine with the line if it is listed (so that is
> four new named items instead of 6).  But each of the other lines
> (verticalstrike, top, ...) would require naming two more arrows, so
> there would still be a total of 16 new named items instead of 24, or at
> a minimum 8 if we just named arrows for the "strikes" (instead of 12 if
> we named all the arrow lines).  A slightly less powerful restriction
> would just mention the arrowhead location and appropriate arrow heads
> would be draw for any line that touch that location (e.g.,
> toprightarrowhead would combine with top, right, and/or
> upstrikediagonal). That results in just 6 new notations, but means less
> control.
>
> The original use for the notation pointed to the TeX package that
> implemented "cancelto".  But this command has another argument which the
> arrow points to.  That doesn't fit into the menclose notation.

The menclose gets you the arrow, wrapping the menclose with an msup
places the argument more-or-less correctly.
   <msup>
     <menclose notation="updiagonalarrow"><mi>a</mi></menclose>
     <mn>0</mn>
   </msup>
should work.

> As you can see, I'm rather skeptical that adding this is a good idea.
> Perhaps Bruce or Michael can look at arXiv files and tell us how many
> times cancelto is used in those files.  Maybe it is much more common
> than I think it is.

I may be misusing the arXMLiv interface, but it appears to be
used _over_ a dozen times!

bruce

>      Neil
>
>
>
> [1] http://www.w3.org/TR/CSS2/syndata.html#length-units
> [2] http://www.w3.org/TR/MathML2/chapter2.html#id.2.4.1
>
>
>
> On Fri, Sep 6, 2013 at 7:49 AM, David Carlisle <davidc@nag.co.uk
> <mailto:davidc@nag.co.uk>> wrote:
>
>     On 06/09/2013 09:12, Frédéric WANG wrote:
>
>     Frédéric,
>     thanks for your comments.
>
>
>
>         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.3.3.2.__3 <http://www.w3.org/Math/draft-spec/chapter3-d.html#id.3.3.2.3>)
>         and
>         this caused some confusion. I think it would be worth checking all
>         the definitions/examples again and remove the deprecated
>         notations if
>         any.
>
>
>     Thanks for the reminder: we should catch those:
>
>     in chapter3
>
>     mfrac example has
>     linethickness="2" and linethickness="4"
>
>     and the text states
>
>     a value of "0" renders without the bar such as for binomial
>     coefficients.
>
>     I suppose that should be
>
>     linethickness="200%" and linethickness="400%"
>
>     a value of "0pt" renders without the bar such as for binomial
>     coefficients.
>
>
>
>     There several examples using <mo maxsize="1"> to limit stretchiness
>     again I suppose they should be <mo maxsize="100%>
>
>     the text
>
>     <p>Note that each parenthesis is sized independently; if only one of
>     them had maxsize="1", they would render with different
>     sizes.</p>
>
>     would then need changing to match.
>
>
>
>         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
>
>
>
>     As a rough guide, we don't want to change the schema in a "second
>     edition" so any schema breaking changes go on a wish list for a 3.1 or
>     4, but unless that list gets unbearably long, the current intention is
>     to just do a "3.0 second edition".
>
>     the list of notations is open in the schema so adding updiagonalarrow
>     is a possibility (same as the phasor angle notation of Neil's message)
>
>
>         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.
>
>
>     How close a TeX emulation do you have in mind?
>
>
>
>
>         One issue that was raised several times in the past is the
>         mathvariant attribute:
>
>         "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
>         (http://www.w3.org/TR/2006/__NOTE-arabic-math-20060131/__arabic.xhtml
>         <http://www.w3.org/TR/2006/NOTE-arabic-math-20060131/arabic.xhtml>)
>
>
>
>     It might be (is) tricky to mention PUA characters in the spec.
>     In MathML 1, prior to the math characters being added to Unicode
>     (over a thousand at Unicode 3.1 and 3.2, and a few more at each release
>     since then) MathML was based on PUA assignments (aligned with the
>     original stix submission). To say this was controversial would be
>     putting it mildly. To say in a spec that PUA characters can be used for
>     anything puts the whole spec in danger of being rejected. The wording
>     introduced at MathML2 that strongly tied mathvariant to a mapping of
>     Unicode code points (rather than to font changes) was worked out over
>     long discussions with the W3C Accessibility experts who were as a group
>     totally opposed to any in-markup font style as opposed to external
>     CSS styling.
>
>
>
>
>         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
>         <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
>         <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.
>
>
>     This is similar to the above point in a way: calligraphic was
>     deliberately unified with script when the unicode math alphabets were
>     added. One can argue whether that was a good choice but it was the
>     decision Unicode took. MathML is more or less forced by design to follow
>     Unicode. Which means that script and calligraphic are considered font
>     variants of the math script block. To argue to Unicode that there should
>     be a Calligraphic alphabet one would probably need to find published
>     mathematical articles using Script and Calligraphic in the same
>     expression with different meanings. (That may not be impossibly hard to
>     find). This is similar to getting dotless j added, we needed to
>     reference published works that used a dotless j on its own, rather than
>     as a base for an accented j (most of which were already in Unicode).
>
>     Since you'd presumably want to implement these with css font changes
>     anyway, one possibility would be to standardise separately (in a
>     note, say) css class names for mathml, so
>
>     <mi class="calligraphic" mathvariant="script">C</mi>
>
>       (I don't know, just first thoughts)
>
>     David
>     [speaking for myself not for the working group]
>
>
>
>
>
>
>
>
>
>

Received on Friday, 6 September 2013 22:07:52 UTC