117652 - Stretch siblings after finishing treating the embellished child

Status: RESOLVED FIXED

(Core :: MathML, defect)

Description

[rbs]

[This is something that I have been thinking of doing for quite some time. I 
mentioned it on n.p.m.mathml at one point, and even had the code for that in one 
of my trees. But I have been shuffling things around and may have buried it 
somewhere that I can't find at the moment -- if it is still around.]

The problem is this: with the current stretching protocol, if a stretchy 
embellished operator also has stretchy siblings, the siblings are stretched 
first, and the embellished operator is stretched _later_. This has some 
side-effects which are better illustrated with an example.

Using LaTeX notation for convenience, consider
   \left( \sum_{\rightarrow}^{X} Y \right)
where the width of 'X' is greater than the default width of \sum but 
less that the _forthcoming_ width of the stretched \sum.

With the current code, \rightarrow will be stretched to cover 'X' (because 
'X' has the current maximum width}, and then later on, when \sum is stretched
to cover 'Y' using a bigger \sum glyph, its width can become greater that the
width of 'X', thereby causing the previously stretched \rightarrow to appear
short underneath the now bigger \sum symbol.

So I am thinking of reworking the code a little bit so as to stretch
siblings after finishing treating the embellished child.

Comment 1

[rbs]

Attachment: testcase

Comment 2

[rbs]

Cc:ing [e-mail] who has manifested interest in this at the 
time I mentioned it on the newsgroup.

Comment 3

[rbs]

For the record, here is a thread that provides some background on how the
stretchy process works:
http://groups.google.com/groups?hl=en&th=3bd653c5adce279e&rnum=1

In particular, the following post briefly summarizes the current stretchy process:

From: "Roger B. Sidje" <[e-mail]>
Subject: Re: Embellished operators
Date: 1999/12/11
Message-ID: <[e-mail]>#1/1
To: Robert Miner <[e-mail]>
Newsgroups: netscape.public.mozilla.mathml


Hi Robert,

[...]

When looking at the code, you may wonder what is going on.
Given the following markup, here is an oversimplified description
of how the code will deal with it:

<mrow>
...
  <mtag>
     <mo>operator</mo>
     arguments
  </mtag>
...
</mrow>

1) [a] <mrow> will receive a command to Reflow/format itself.
       It will propapate that command to its children, using
       ReflowChildren.

       2) [a] <mtag> receives the Reflow command fired by its
              parent <mrow>. It, also, propagates that command
              to its children.

          [b] <mtag> realizes that it is an embellished
              operator. Therefore, it *doesn't* place/position
              its children. But instead it uses their rect to 
              store their reflow information (descent, ascent,
              width, height). [Note: reflow information are lost
              upon completion of Reflow(). Using the rect to
              store the ascent and descent is a work around. And
              because of this, there are some genuflexions in the
              code to ensure that rect.x and rect.y are cleared,
              even if the parent doesn't fire a stretch. Could
              allocate and free a temporary array. But that will
              slow things a little bit. It should be noted that rect.x
              and rect.y only become meaningful to the rendering system
              when FinishReflowChild() is called].

   [b] <mrow> fires a Stretch command on its stretchy children,
       asking them to stretch themselves *vertically*.
       <mtag> receives the stretch command. This means all its
       sibblings have been reflowed/formatted, and the parent
       knows the overall size. Therefore <mtag> uses the stretch
       metrics passed by the parent to fire its own stretch on
       its core embellished <mo>. Then, it can place/position its
       children and add lspace and rspace around itself.

   [c] <mrow> place its own children.


===========
Embellished operators are a very powerful concept and I think
they deserve more space in the REC. Some embellished operators
that are easily obtained in MathML prove difficult to markup
in TeX! Unfortunately, The semantics of embellished operators
is a bit too brief in the current REC, and as I was coding and
testing, some examples were ambiguous. As a result, I haven't
done any serious tuning of their placing/positioning. 

The only embellished tag for which I did more than just
getting the ingredients ready is <mover>. I have enclosed
a sample markup, and its rendering on bug 21479 at:
http://bugzilla.mozilla.org/show_bug.cgi?id=21479

It would be really helpful if you could attach a WebEq screenshot
for the corresponding sample, with variants when they are
further wrapped in other tags like msub/msup.

Thanks,
---
RBS

Comment 4

[rbs]

Attachment: extended testcase

Comment 5

[rbs]

Attachment: rendering of the tescase (before the fix to this bug)

Comment 6

[rbs]

Attachment: fix

Comment 7

[rbs]

Attachment: rendering of the testcase after the fix

Comment 8

[rbs]

Fix checked in.