Bug 123543 – [MathML] The double bar vertical delimiter does not stretch properly

• Status: RESOLVED
• Resolution: FIXED
• Component: MathML

[Martin Robinson]

It seems that the Unicode code point of this character is defined incorrectly in RenderMathMLOperator.cpp.

[Martin Robinson]

The issue here seems to be that there are two vertical bars in Unicode ‖ (U+2016) and ∥ (U+2225). We don't handle the latter, which is the one that happens to be in the mathematical section, so we can trivially add support.

[Martin Robinson]

Created attachment 215691 [details]
Patch

[Radar WebKit Bug Importer]

<rdar://problem/15394014>

[Martin Robinson]

Created attachment 216050 [details]
Patch for EWS

[Brent Fulgham]

Comment on attachment 216050 [details]
Patch for EWS

r=me

[Brent Fulgham]

If the EWS bots looks good, I think this should be landed.

[Martin Robinson]

I need to update Mac results since the test itself changed, unless you want to do it in another commit after the patch lands. Either way is fine with me. :)

[Build Bot]

Comment on attachment 216050 [details]
Patch for EWS

Attachment 216050 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/21158042

New failing tests:
mathml/presentation/mo-stretch.html

[Build Bot]

Created attachment 216052 [details]
Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-12  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 216050 [details]
Patch for EWS

Attachment 216050 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/20608058

New failing tests:
mathml/presentation/mo-stretch.html

[Build Bot]

Created attachment 216054 [details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[Brent Fulgham]

Created attachment 216056 [details]
Re-Upload of Patch with Mac Baseline

[Martin Robinson]

Created attachment 216525 [details]
Rebased patch for Mac results

[Brent Fulgham]

Comment on attachment 216525 [details]
Rebased patch for Mac results

r=me

[Martin Robinson]

Committed r159219: <http://trac.webkit.org/changeset/159219>

[Frédéric Wang (:fredw)]

I've been working on bug 99620 and stretch-mo is the only remaining failing test after my local changes. ∥ (U+2225) has a very confusing entity name, its Unicode name is actually "PARALLEL TO", that's an infix operator ("X is parallel to Y") not a delimiter. The MathML operator dictionary says it is not stretchy and not a fence.

Unfortunately, some people have used that character as a delimiter, instead of U+2016. So I'm wondering if we really want to make it stretchy... (IIRC, that's what Gecko does)...

[Martin Robinson]

(In reply to comment #16)
> I've been working on bug 99620 and stretch-mo is the only remaining failing test after my local changes. ∥ (U+2225) has a very confusing entity name, its Unicode name is actually "PARALLEL TO", that's an infix operator ("X is parallel to Y") not a delimiter. The MathML operator dictionary says it is not stretchy and not a fence.
> 
> Unfortunately, some people have used that character as a delimiter, instead of U+2016. So I'm wondering if we really want to make it stretchy... (IIRC, that's what Gecko does)...

Correct me if I'm wrong, but the operator dictionary just specifies the default value of the stretchy operator. The user can still override that by setting the stretchy attribute equal to true. I believe it's up to the user agent what operators stretch in that case. Perhaps the test should just have stretchy=true added to the parallel to operator.

[Frédéric Wang (:fredw)]

(In reply to comment #17)
> Correct me if I'm wrong, but the operator dictionary just specifies the default value of the stretchy operator. The user can still override that by setting the stretchy attribute equal to true. I believe it's up to the user agent what operators stretch in that case. Perhaps the test should just have stretchy=true added to the parallel to operator.

Yes, that's correct. I think we can add stretchy=true in the test if we really want to keep it stretchable. And I can add two stretchy prefix/postfix forms for that operator, for people who use that as open/close fences.