Re: Alignment and Embellished Operators

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

Received on Sunday, 11 April 2010 15:37:55 UTC