121748 - Stretch fences after stretching non-fences

Status: RESOLVED FIXED

(Core :: MathML, defect, P1)

Description

[rbs]

This is a continuation of what I once mentioned in the newsgroup:
http://groups.google.com/groups?hl=en&th=1a58dfbdd3a1ac18&rnum=1

Now that bug 117652 has been fixed, I am about to also implement the other idea 
of stretching fences after stretching non-fences. Shouldn't be too difficult.
I will attach the example that motivated me to do that.

Comment 1

[rbs]

Attachment: testcase

Comment 2

[rbs]

Attachment: screenshot - current rendering of the testcase

As I was preparing the testcase, I had some second thoughts. I initially had
some concerns about catering for the messy markups that automatic MathML 
generators currently produce but I am not sure if it is worth prusing this bug
now. I will leave aside for now.

Comment 3

[rbs]

The reason I had some second thoughts is that it would make it even harder for 
authors to notice that the big \Union (on the left) is actually stretching to
cover the "\lim_{\infty}f^{-1}" that is behind! And so are doing the 
parentheses, BTW.

Thus leaving things as is might encourage people to properly group their markup.
If the parenthesis where to be stretched, people could think that such large 
glyphs that apparently come from nowehere is the default behavior. Most people 
won't draw a connection with the tall box of "lim_{\infty}f^{-1}" that is 
behind.

Comment 4

[rbs]

Attachment: extended testcase

same as the earlier testcase, but includes an additional example in which the
\lim is kept outside. This provides a better illustration of the effect that I
alluded to in my previous comments.

Comment 5

[rbs]

Moving this to Mozilla 1.0. My eyes hurt seeing several real-life examples with
markups that exacerbates this. The reality on the ground is that markups are 
often not grouped properly, so let's be lenient here.

Comment 6

[rbs]

Attachment: patch ('diff -wu' format)

Comment 7

[rbs]

Cc:ing roc/attinasi for r/sr.

Comment 8

[rbs]

Attachment: screenshot - before & after, with explanations

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Are you sure we should do this? It seems like we're making our rendering more
complicated and making some arguably invalid markups look better and others look
worse. Can you argue that with this patch we'd be doing something simpler and
less surprising to authors? What about consistency with other renderers?

Automatic tools that are generating improperly nested mrows can be fixed.
Unnecessarily complicated rendering behavior will last a lifetime.

Comment 10

[rbs]

Attachment: screenshot - comparison between Amaya/IE/Mozilla

Some details:

* Examples 1 & 2 are to highlight the 'behind effect' that I mentioned earlier.
I made a taller box by using <mfrac line="10px"> (or so). The screenshot shows
that IE is buggy and is ignoring the attribute whereas Amaya does some weird
things with it.

* Example 1 is the case where the \lim{}{} box is _outside_ the <mrow>. From
the rendering, it appears that both Amaya and IE are leaving it outside (as
expected) and producing parentheses to cover what is inside. In
Mozilla-before-the-patch, the parentheses are short because, by design, the
embellishments are not included in the determination of the size to be used for
stretchy elements. In Mozilla-after-the-patch, the embellishments are still not
included, but when doing the newly added pass that stretches fences, the size
used (specifically for fences) include embellishments that are not on fences
themselves, and that's why the rendering now matches with Amaya and IE (both
Amaya and IE seem to always include embellishements -- this has a side-effect
w.r.t. \sum\sum in other situations).

* Example 2 is the case where the \lim{}{} is inside the box. Here, all
renderers are stretching to cover its box (the 'behind effect') as illustrated
by the engineering of a height to make the \lim{}{} box really tall.

* Example 3 consists of a careful markup where sub-expressions are grouped in a
structure that captures the meaning of the expression. All renderers behave
similarly here.

* Example 4-6 show differences between renderers (red color -- but I used the
same file and the emphasis was on IE vis-a-vis Mozilla). Some characters (such
as ||) are not stretched in Amaya & IE. Mozilla supports more stretchy
characters than these renderers and is stretching them, however Example 6 shows
that if these positions were occupied by characters that could be stretched by
the other renderers, they would have stretched them. There is in oddity in
Amaya: stretchy characters with embellishements (e.g., "]^p") seem to cause
troubles. The upper arrow is another interesting example. Again, because
Mozilla doesn't include embellishments: the arrow isn't stretched to cover the
indices in the \sum, rather it is stretched to cover what the sum applies to.
In IE, it is stretched to cover everything but it seems not to be treated as a
symmetric operator (which is a bug since all MathML operators are symmetric
unless marked up as symmetric="false"). A more consistent behavior for IE would
have been to stretch it as it is doing with the parentheses.

Comment 11

[rbs]

>Can you argue that with this patch we'd be doing something simpler and
>less surprising to authors? What about consistency with other renderers?

From the comparative testings, it now seems the patch improves things vis-a-vis 
other renderers and where we behave worse other renders won't behave any better.

Comment 12

[rbs]

Attachment: patch to limit the tweak to <mfenced>

Since I can't sell the earlier patch, I have made another simpler patch to
limit this to <mfenced>, e.g., <mfenced open="[" close="]"> ... </mfenced>. In
this context, it is more likely that authors might want the opening fence and
the closing fence to cover everything fully, i.e., if the children of <mfenced>
happen to have emebellishments, these will be covered as well.

Note: @@ -1168,32 +1168,36 @@ is not strictly part of this problem. It is meant
to address the wide height problem in <mi>symbol</mi> when the symbol happens
to be picked from a font with weird metrics (similar tweaks were already made
for <mo> to make the selection looks nicer).

Comment 13

[rbs]

Comment on attachment 81560 [details] [diff] [review]
patch to limit the tweak to <mfenced>

roc, do you buy this patch?

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 81560 [details] [diff] [review]
patch to limit the tweak to <mfenced>

r=roc+moz

Comment 15

[Marc Attinasi]

Comment on attachment 81560 [details] [diff] [review]
patch to limit the tweak to <mfenced>

I would not assume you can get a FontMetricsFor in + 
aPresContext->GetMetricsFor(font->mFont, getter_AddRefs(fm)); - check for null
(it seems to be a problem in the talkbacks anyway).

Other than that, it looks fine, though I don't pretend to understand this stuff
:)

Comment 16

[rbs]

Checked in the trunk. Have asked drivers for branch approval.

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 81560 [details] [diff] [review]
patch to limit the tweak to <mfenced>

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 18

[rbs]

Checked in the m1.0 branch. Resolving as FIXED.