Re: Operator Dictionary MathML 2 vs. MathML 3

Thanks for catching that.  As David noted, the draft is frozen.  We
will have a formal procedure for noting problems as soon as the draft
is published and you should submit your comments then so they are
logged and addressed.

Back in August, we looked at a number of books as to how they dealt
with stretching of large operators.  MathML 2's operator dictionary
said that almost all large ops should stretch, but that is not what is
typically done in a book. Most books don't even stretch integrals
beyond a few fixed sizes (possibly because of limitations of
typesetting, but that's the convention now).  A few did the same for
sums and products.  Because of that, we changed the *suggested
default* to be non-stretchy *by default* for all large ops as this
corresponds to common typographic usage.  There are two key things to
remember:
1.  this is the suggested default -- a renderer is free use whatever
defaults they feel is best for their audience
2.  this is a default -- if someone specifies that they want a large
operator or other character to stretch, the renderer should do so if
it can.

The later point is really important -- please try to implement
'stretchy' for as many characters as you can.  That includes large
ops, fences, arrows, ...  IMHO,  it is far more important that if
someone specifies stretchiness (on or off), that the renderer does
that because the author is specifically stating their desire.
Obviously though, you will be limited by the fonts available, and
chapter 3 makes that limitation clear.

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, WebEQ, Equation Editor ~



2009/9/23 Frédéric WANG <fred.wang@free.fr>:
>   Also, it looks like large operators such that "n-ary summation" or
> "integral" that were stretchy in MathML 2 and in the last MathML 3 working
> draft are no longer stretchy in the internal editor's draft. Is it
> intentional (some people pointed out this difference with TeX [1]) or
> another error? Anyway, it seems inconsistent with what is written in chapter
> three [2] :
>   "Most common opening and closing fences are defined in the operator
> dictionary to stretch by default; and they stretch vertically. Also,
> operators such as &sum;, &int;, /, and vertical arrows stretch vertically by
> default."
>
> Frédéric Wang
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=363240#c21
> [2] http://monet.nag.co.uk/~dpc/draft-spec/chapter3.html#id.3.2.5.8.2
>
>

Received on Wednesday, 23 September 2009 16:51:20 UTC