search

w3c / mathml

MathML4 editors draft
https://w3c.github.io/mathml/
Other
62 stars 18 forks source link

Spec should specify what char to use for accents/lines #247

Open NSoiffer opened 4 years ago

NSoiffer commented 4 years ago

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:

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.

fred-wang commented 4 years ago

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

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:

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 commented 2 years ago

(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 commented 2 years ago

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 commented 1 year ago

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

Related to w3c/mathml-docs#39.

davidcarlisle commented 2 months ago

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