Re: Alignment and Embellished Operators

I pretty much agree with your conclusion.  I think the typical case for an
embellished operator as an accent would be one that uses an mover/munder to
label an arrow.  In that case, both interpretations come out the same.
Other cases, especially in tables, seem really odd.  None the less, the spec
should say what should happen, even if it says either interpretation is ok
-- I'd rather it pick one though.

MathPlayer does deal with stretching in mtable, but I'm not sure whether it
does something sensible when given an embellished operator like in your
example.  I'll need to build some example cases and see...

We'll discuss this and try to come up with some language for the spec at our
regular meeting on Thursday.

Thanks for you input,

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


2010/4/11 Frédéric WANG <fred.wang@free.fr>

> Sam and Neil,
>
> Thanks for your answers.
>
> The bug I've mentioned [1] is very old and has had no activity since 2002.
> Moreover, it was reported and discussed only by the contributors to the
> Mozilla MathML project. So we can say that this more an issue for
> implementers than for users. Consequently, I don't think it's worth
> extending the syntax to give more control to the users (either by adding a
> new value as in my first suggestion or a new attribute as in Neil's
> proposal). Just clarifying the language in the spec in order to help
> implementers would be enough. That's why in my mail I say I prefer my second
> suggestion i.e. saying that embellished operator overrides the value of the
> align attribute.
>
> Sam's proposal is to say that alignment is done with respect to the core of
> the embellished operator rather than with respect to the whole embellished
> operator. This is also perfectly fine to me and actually it will be the same
> as my second suggestion when we have a perfect stretching i.e. when the core
> can stretch to the exact width of the munderover's base.
>
> I think the reason why an implementer may interpret that alignment should
> be done with respect to the core of the embellished operator is the
> statement of the Horizontal Stretching Rules [2]: "If (...) an embellished
> stretchy operator, is a direct sub-expression of (a) munderover element
> (...) then (...) the mo element at its core should stretch to cover the
> width of the other direct sub-expressions in the given element (...)". Here
> "cover" means two things for me: the core should stretch to be at least as
> wide as the other direct sub-expressions and the interval given by its left
> and right coordinates should include those of the other direct
> sub-expressions. But as pointed by Neil and demonstrated in my testcase,
> this interpretation is in contradiction with the alignment of munderover in
> MathML3.
>
> Finally, I've just thought that this issue may also happen with embellished
> operators and alignment in mtable. Mozilla does not currently support
> stretching in mtable's cells but I guess it would be more difficult to align
> with respect to the core of embellishment in that case, because we rely on
> HTML tables that know nothing about MathML embellished operators. So a
> reasonable change would be to say that, when embellished operators are
> involved in alignments, the implementers are free to use the core or the
> whole embellished operators. I think in practice, the width/height added by
> the embellishments are not too large. So except in very particular cases
> such that the example I give in my previous mail, the two alignments would
> essentially give the same result.
>
> Frédéric Wang
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=21479
> [2] http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.5.8.3
>