- From: Frédéric WANG <fred.wang@free.fr>
- Date: Tue, 27 Mar 2012 21:47:44 +0200
- To: www-math@w3.org
- Message-ID: <4F721960.7060304@free.fr>
Any update on this issue? From the previous discussion, It seems to me that a clarification would be to say that the "base size" of an embellished op includes stretching that has already taken place in the subexpression. This would be consistent for both vertical and horizontal stretching rules. That's how I plan to solve the Firefox's bug. On 25/02/2012 02:51, Dave Barton wrote: > I agree with Frédéric, that option 2 seems most consistent. The spec > (mostly) says a stretchy operator should stretch to the maximum of the > non-stretchy sizes that should influence it, if there are any. So > in Frédéric's cases of a stretchy horizontal operator with nested > under/over embellishments, or a stretchy vertical operator with nested > embellishments to its left or right (i.e. purely space-like elements > in a same <mrow>), the operator should stretch to the maximum of the > sizes. > > Actually, I really only agree with this for horizontal stretching, > because I don't like the mrow rule that Neil mentions, and states is > probably not implemented in MathPlayer or Mathematica. Currently mtext > elements are defined to be space-like > (http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.7.4), so in > > <math display="block" alttext='f(A/B)+∫\text"some differential"'> > <mrow> > <mi>f</mi> > <mrow> > <mo>(</mo> > <mfrac> > <mi>A</mi> > <mi>B</mi> > </mfrac> > <mo>)</mo> > </mrow> > <mo>+</mo> > <mrow> > <mo>∫</mo> > <mtext>some differential</mtext> > </mrow> > </mrow> > </math> > > the final integral sign should stretch to cover the earlier tall > fraction, according to the spec. This is clearly not intended by the > author. I think the rules for embellished operators and space-like > elements are too aggressive. One can now add spacing using CSS, so > <mtext> elements are not usually just "space-like". Also without the > <mrow> rule for embellished operators, an author could control > stretching of e.g. this integral sign by choosing whether to put it in > a nested <mrow> or not. > > I am working on the MathML code in WebKit, as a volunteer. I haven't > gotten to horizontal stretching or even all the rules for embellished > operators yet, but this is my personal thinking so far. > > Cheers, Dave B. > > On Feb 24, 2012, at 12:21 AM, Frédéric WANG wrote: > >> On 24/02/2012 07:47, Neil Soiffer wrote: >>> I hope I'm stating this correctly: the embellished operator rules >>> are clear with the exception of the case of an mrow that contains an >>> embellished operator and space-like elements (the last rule in >>> http://www.w3.org/TR/MathML3/chapter3.html#id.3.2.5.7.3). >>> >>> ... >>> >>> For the vertical case, it is clear that if there was only one mrow, >>> then the maximum size would be used (200px). But that's not the >>> case. As your analysis in a subsequent email demonstrated, the >>> inner mrow should cause that mrow to be 200px. But since it should >>> act as an embellished operator, it is subject to further stretching. >>> >>> There are two possibilities: >>> 1. We ignore the stretching caused by the inner mrow and consider >>> the "normal" height to be be that of the unstretched "|". In this >>> case, the answer should be that the result is 100px because it >>> should stretch to the height f the space in the outer mrow. >>> >>> 2. We consider the stretched height of "|" caused by the inner >>> mrow's stretching to be the normal height of the operator. In this >>> case, the outer mrow doesn't stretch it further, so the answer is >>> 200px. If the outer mrow had a larger stretch than the inner one, >>> than the largest value should be used. >>> >>> The spec is silent on what to do here (AFAIK) -- the rule mentioned >>> for horizontal stretching is not listed as part of the vertical >>> stretching rules. I'm leaning towards '1' as being the correct >>> interpretation, so the result should be 100px. >>> >>> I haven't looked at the code, but I suspect that MathPlayer chooses >>> the inner one (even if the outer one is larger) because it doesn't >>> implement the "|mrow| whose arguments consist (in any order) of one >>> embellished operator and zero or more space-like elements" rule. >>> >>> I tried Mathematica and it behaves like MathPlayer (I didn't >>> implement this part of the code in MathPlayer, but did in >>> Mathematica). So both are doing it wrong (probably because they >>> didn't implement this rule). >>> >>> ... >>> >>> On Thu, Feb 23, 2012 at 1:02 AM, Frédéric WANG <fred.wang@free.fr >>> <mailto:fred.wang@free.fr>> wrote: >>> >>> ... what should be the size of the arrows (100px or 200px?) in >>> these examples: >>> >>> <math> >>> <mover> >>> <mspace width="100px"/> >>> <munder> >>> <mo>→</mo> >>> <mspace width="200px"/> >>> </munder> >>> </mover> >>> </math> >>> >>> and >>> >>> <math> >>> <mover> >>> <mspace width="200px"/> >>> <munder> >>> <mo>→</mo> >>> <mspace width="100px"/> >>> </munder> >>> </mover> >>> </math> >>> >>> An example with vertical stretching rules: >>> >>> <math> >>> <mrow> >>> <mspace height="50px" depth="50px"/> >>> <mrow> >>> <mo>|</mo> >>> <mspace height="100px" depth="100px"/> >>> </mrow> >>> </mrow> >>> </math> >>> >>> ... >>> >>> >> Thanks for your answer, Neil. >> >> It seems that we all agree on the results of munderover, however it >> is not consistent with Option '1' for the vertical case with mrow's >> (consider what you said for the first non-trivial case). Firefox is >> (more or less) using option '1' and now it supports all the >> embellished op rules, that's even causing a bug for the trivial test >> case when an <mrow> is added around the <mover> (reported by MathJax >> folks). >> >> Karl's interpretation and MathJax's implementation seems to be option >> '2'. I don't really mind between '1' and '2' in the vertical case >> (although I suspect '2' will be more work to implement it in Firefox) >> but to be consistent with the horizontal case, I would rather propose >> option '2'. >> >> -- >> Frédéric Wang >> maths-informatique-jeux.com/blog/frederic <http://maths-informatique-jeux.com/blog/frederic> > -- Frédéric Wang maths-informatique-jeux.com/blog/frederic
Received on Tuesday, 27 March 2012 19:46:53 UTC