Spec should specify what char to use for accents/lines

[NSoiffer]

TeX has a number of commands that correspond to mover/munder accents in MathML. The spec does not say what character to use for those accents. In some cases there are ASCII chars that could be used but also non-ASCII ones that are similar. Many of these characters should be stretchy when used with mover/munder.

At a minimum, the spec should say which (or all) of the following should be used for (stretchable) accents (some options listed) so that renderers and generators of MathML agree on what character(s) to use:

• \hat -- '^', U+0302, U+02C6
• \check -- 'v', U+0306, U+02D8
• \tilde -- '~', U+0303, U+223C, U+02DC
• \acute -- U+0027, U+00B4, U+02CA, U+0301, U+02B9, U+2032
• \grave -- U+0060, U+02BC, U+02CB, U+0300
• \dot -- '.', U+00B7, U+02D9, U+0307, and potentially others like U+2E33
• \ddot -- '..', U+00A8, U+0308
• \breve -- U+02D8, U+0306
• \bar -- '_', '-', U+00AF, U+02C9, U+0304, U+0305, U+0332, U+FF3F
• vec -- U+20D7, U+2192, U+27F6

Note: based on experience with MathPlayer, many of these alternatives were encountered "in the wild" so it is important that Core specifies these (MathML 3 should have) as people are having to guess what character to use.

• \overline -- should be same as \bar
• \underline -- same as \bar?

[fred-wang]

I think this is issue is showing a misunderstanding of the specification. There are three levels to determine when an operator stretches:

• The operator dictionary indicates which Unicode character is stretchy/largeop and this can be overidden by mo attributes.

• The complementary table to indicate the stretchy operator axis. In theory we could imagine characters stretchable in both axis, but that does not happen in practice.

• The OpenType MATH table provides stretchy construction for a given glyph/axis.

So people can just use any character as stretchy/largeop as long as they use a font with the proper construction in the MATH.MathVariants table. Actually, that's what the WPT tests do to test the properties of the whole operator dictionary as well as other tests related to stretching.

The complication is that Gecko and WebKit use various hacks to provide fallback constructions and math font selection which makes support inconsistent. I'm not sure we need to specify all of them in level 1, but there are already things tracked:

• Issue Mechanism to determine the default font-family / font-size on the <math> tag  #37: We decided to use font-family: math for the default font. However, this will still depend on user configuration and default system fonts.

• Issue w3c/mathml#69: We decided to postpone this and our consensus was to focus on OpenType MATH support instead. Non-normative unicode fallback are in https://mathml-refresh.github.io/mathml-core/#unicode-based-glyph-assemblies but don't cover much anyway ; another fallback method is to use scale transform which generally provides poor rendering.

• Issue w3c/mathml#11: We haven't decided anything about it but it's important in practice for the reason I explained in the 2018 thread. Non-normative tables are in https://mathml-refresh.github.io/mathml-core/#combining-character-equivalences

• Issue w3c/mathml#148 : We decided to postpone this. But this is important to stretch RTL operators.

To summarize: MathML Core does not need any change since it already fully describes when a operator will be stretchy or not. Because that depends on the fonts installed on the system and the content of their MATH table, and because users are free to create any web font for their own stretchy accents, statements like "U+XXXX should be used as a stretchy operator" are pointless and must definitely not be in the MathML Core specification. Enhancements are possibles to provide better practical experience but are tracked by other issues.

So I think the "MathML Core", "spec update" and "need tests" labels must be removed. Adding authoring suggestions for MathML Full like https://mathml-refresh.github.io/mathml/#chars_comb-chars are fine, but again these authoring suggestions shouldn't have any implication on how MathML core implementations will render things, which depends on the environment.

[davidcarlisle]

(moved the codepen link from the initial description above, pubrules on issue inlined in the spec)

@NSoiffer wrote:

Here's a codepen showing the results of using these various chars. Firefox seems to support several chars (based on them stretching); Safari doesn't seem to support any of them.

[davidcarlisle]

I don't think Full should do much more than reference the table

https://w3c.github.io/mathml-core/#combining-character-equivalences

in Core. Certainly we want to be compatible with that.

All the accents are essentially the same eg

\hat -- ^ U+005E, ̂ U+0302, ˆU+02C6

If we are giving authoring advice, best is U+005E (most natural markup as this is full size, raised in mover) next best U+02C6, and don't use U+0302 (combining characters in markup are tricky, witness that was hardest one to add above)

[NSoiffer]

Consensus to add to section 8.4 the correct chars to use.

Related to w3c/mathml-docs#39.

[davidcarlisle]

Call on 22-08-2024 consensus is to recommend non combing character (eg U+02C6) although current chrome implementation only makes U+0302 stretchy.