New entries in the operator dictionary for U+1EEF0 and U+1EEF1

[fred-wang]

I don't know if that was fixed but just to move issue here:
https://lists.w3.org/Archives/Public/www-math/2016Aug/0014.html

[physikerwelt]

@fred-wang how can we figure out if it was fixed? To be completely honest, I do not understand how a change in the MathML standard would affect this matter.

[davidcarlisle]

@physikerwelt it looks like at the time <operator-dictionary entries were added

      <character id="U1EEF0" dec="126704">
         <unicodedata category="Sm" combclass="0" bidi="ON" mirror="N" mathclass="A"/>
         <mathlatex set="unicode-math">\arabicmaj</mathlatex>
         <operator-dictionary form="prefix" stretchy="true"/>

although there is some discussion in the email thread about whether it should also have spacing added,
This is visible in unicode.xml in the xml-entities repository (the original one and the clone in this mathml-refresh area)

That entry in unicode.xml should mean the entry appears in appendix C but it appears not, I'll check the build this evening.

If we want the core to be a self standing spec I guess the operator dictionary should be in the core spec as well.

[davidcarlisle]

The build of the mathml4 spec was using an older copy of unicode.xml that was fixed with commit
cafb501

These character now appear in the table as the first entries in

https://mathml-refresh.github.io/mathml/appendixc.html#oper-dict.entries-table

[fred-wang]

If we want the core to be a self standing spec I guess the operator dictionary should be in the core spec as well.

Yes, we need to move this and several other things (like embellished op, mathml length...) into the core and remove quotations of MathML 3. This is another TODO.

[fred-wang]

I think this is essentially fixed now. Thanks David!

[NSoiffer]

Agreement that this is dealt with

[fred-wang]

Fixed in WebKit: https://bugs.webkit.org/show_bug.cgi?id=153984
Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1246657

[fred-wang]

Resolution:
I can't find the minutes, but it was agreed in
#8 (comment)

Specification:
Updated by David.

Implementation:
Fixed in WebKit: https://bugs.webkit.org/show_bug.cgi?id=153984
WebKit's code imported in Chromium.
Bug reported to Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1246657

Polyfill:
Not needed.

Tests:
We should import WebKit's one:
https://trac.webkit.org/changeset/205111/webkit
mathml/presentation/non-bmp-operators-spacing.html
mathml/presentation/non-bmp-operators-stretching.html

[fred-wang]

Reopening since we need tests

[fred-wang]

I started to add tests for Operator Dictionary entries in web-platform-tests/wpt#19123

I realize that it lacks explicit values for priority (which does not matter for layout), lspace and rspace. For the first character, I guess we want something similar to other n-ary sum?

As said on the mailing list, the spacing is the default i.e. 0.2777777777777778em (aka "thickmathspace" in full) which is probably too big.

I don't really have strong preference about the values, but I'd like at least to have explicit lspace and rspace values unless 0.2777777777777778em is intentional.

@davidcarlisle Can you please take care of that and make a proposal for the next MathML CG meeting?

[davidcarlisle]

yes I will look, Also  @khaledhosny may be able to have a more informed opinion on the spacing requirements for these two characters, Khaled any suggestions welcome:-)

[fred-wang]

@davidcarlisle After writing tests for the operator dictionary, I notice all browsers fail the accent test for the following operators:

 ª ª feminine ordinal
 " " quotation mark
 ‛ ‛ single high-reversed-9 quotation mark

I can't find these entries in Gecko/WebKit. Do you know if that's something that was added recently?

[davidcarlisle]

@fred-wang " (U+00222) U+00AA U+201b all have entries in the MathML3 spec operator dictionary with an accent field set to true https://www.w3.org/TR/MathML3/appendixc.html so I don't think anything has changed here for some years.

[fred-wang]

@davidcarlisle Thanks I can see them in https://www.w3.org/TR/2014/PER-MathML3-20140211/appendixc.html but not in https://www.w3.org/TR/2010/REC-MathML3-20101021/appendixc.html

So I guess browsers need to be updated

[davidcarlisle]

@fred-wang but on the other hand are the ordinal signs and quote marks really used as accents, seems a bit odd. I guess it was me that edited this info into unicode.xml but there must have been a bug report or something I'll see if I can find any record.

The old CVS log entry says that the opertaor dictionary entries were added for all the primes etc listed in

https://www.w3.org/TR/MathML3/chapter7.html#chars.pseudo-scripts

but I'm not sure that this really means that the characters should have the accent property set to true?

[fred-wang]

@davidcarlisle IIRC, one idea is that all operators used as scripts would have "postscript" form. I'm not sure the accent property is needed, it's only supposed to be for overscript.

(BTW regarding pseudo-script, this is a property that is supposed to be controlled at the font-level, not dictionary one. See w3c/mathml-core#135 )

[NSoiffer]

Hmm, Unicode says for 201B: "has same semantic as [2018 -- char didn't render] but differs in appearance". Given that, it is strange that the operator dictionary entries aren't the same. Seems like a bug.

[rwlbuis]

Neil, are you talking about these two?
https://www.fileformat.info/info/unicode/char/2018/index.htm
https://www.fileformat.info/info/unicode/char/201b/index.htm

These are different in appearance, also we have no entry for 2018 here (but have one for 201B):
https://mathml-refresh.github.io/mathml-core/

[rwlbuis]

Neil, are you talking about these two?
https://www.fileformat.info/info/unicode/char/2018/index.htm
https://www.fileformat.info/info/unicode/char/201b/index.htm

These are different in appearance, also we have no entry for 2018 here (but have one for 201B):
https://mathml-refresh.github.io/mathml-core/

Nm, you probably were talking about the MathML 3 appendix C.

[NSoiffer]

Yes, that's correct about appendix C. In https://mathml-refresh.github.io/mathml-core/, both are mentioned:

‘	‘	left single quotation mark	prefix	10	0	0	fence

‛	‛	single high-reversed-9 quotation mark

[khaledhosny]

yes I will look, Also @khaledhosny may be able to have a more informed opinion on the spacing requirements for these two characters, Khaled any suggestions welcome:-)

I have no idea either. I guess they should be spaced like similar operators.

[fred-wang]

I wrote:

Unicode 6.1 mentions that U+1EEF0 and U+1EEF1 are used for Arabic sum and Persian limit. Additionally, Azzeddine Lazrek indicated to me that U+1EEF1 is also used for Arabic product.
Regarding the default value, I think the "prefix" and "stretchy" properties added by David are correct. I don't know about the spacing, but the default thickmathspace value is probably too big. So in the doubt, I'd recommend setting the default lspace/rspace to 0 or 1.

Some integrals use 0 and 1, however, n-ary sum/product and other large operators use: lspace=1, rspace=2 ; so I'm proposing to do that instead. The operators are also in https://mathml-refresh.github.io/mathml-core/#stretchy-operator-axis. Then I would keep the remaining property as it, until someone complains.

[fred-wang]

@fred-wang but on the other hand are the ordinal signs and quote marks really used as accents, seems a bit odd. I guess it was me that edited this info into unicode.xml but there must have been a bug report or something I'll see if I can find any record.

The old CVS log entry says that the opertaor dictionary entries were added for all the primes etc listed in

https://www.w3.org/TR/MathML3/chapter7.html#chars.pseudo-scripts

but I'm not sure that this really means that the characters should have the accent property set to true?

I opened #151 for this separate issue.

[fred-wang]

I'm closing this. These operators are handled. It seems nobody has an idea of a correct spacing, so using existing category is fine.