1246657 - The Operator Dictionary lack entries for U+1EEF0 and U+1EEF1

Status: RESOLVED FIXED

(Core :: MathML, defect)

Description

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

These are mentioned on http://www.unicode.org/charts/PDF/U1EE00.pdf referred by the MathML 3 recommendation, but absent from their suggested operator dictionary. I don't think any math font supports them yet.

Stretching operators: The following operators stretch based on the width of the text that is displayed below or above them.
1EEF0 

Comment 1

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

Sorry, bug 405011 again, I'm re-sending. This makes me think that our operator dictionary may not support non-BMP or multiple chars entry at the moment.

Stretching operators
The following operators stretch based on the width of the text that is displayed below or above them.
1EEF0 ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL
  • used in Arabic mathematics to denote summation
  • stretched at the tatweel
  → 2211 ∑  n-ary summation
1EEF1 ARABIC MATHEMATICAL OPERATOR HAH WITH DAL
  • used in Persian mathematics to denote limits
  • stretched between the hah and the dal

Comment 2

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

I noticed that the updateOperatorDictionary.pl script does not handle well the non-BMP characters either.

MathML Core uses a compact form for the operator dictionary and handles these Arabic operators separately:
https://w3c.github.io/mathml-core/#dfn-algorithm-to-determine-the-category-of-an-operator

Comment 3

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

Attachment: Bug 1246657 - The Operator Dictionary lack entries for U+1EEF0 and U+1EEF1. r=emilio

This commit ensures that the following operators use category I from
MathML Core's operator dictionary [1] [2]:

U+1EEF0 ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL
U+1EEF1 ARABIC MATHEMATICAL OPERATOR HAH WITH DAL

which corresponds to zero lspace/rspace and stretchy. There should
already be exhaustive WPT tests operator-dictionary-* to check
these and other properties, but they may be shadowed by existing
failures or Firefox bugs, so add some more specific reftests for
spacing and stretching. However, nsMathMLmoFrame and nsMathMLChar
don't handle non-BMP characters very well, so only the first one
currently passes.

Also tweak updateOperatorDictionary.pl to ignore these special
operators.

[1] https://w3c.github.io/mathml-core/#dfn-algorithm-to-determine-the-category-of-an-operator
[2] https://w3c.github.io/mathml-core/#operator-dictionary-categories-values

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c9ca9a0093c9
The Operator Dictionary lack entries for U+1EEF0 and U+1EEF1. r=emilio

Comment 5

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/36043 for changes under testing/web-platform/tests

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/c9ca9a0093c9

Comment 7

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot