Repository navigation
Spec should specify what char to use for accents/lines #247
Description
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+FF3Fvec-- 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?
Activity
fred-wang commentedon Aug 25, 2020
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 commentedon May 8, 2022
(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 commentedon Aug 17, 2022
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+02C6If 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 commentedon Jan 5, 2023
Consensus to add to section 8.4 the correct chars to use.
Related to w3c/mathml-docs#39.
davidcarlisle commentedon Aug 22, 2024
Call on 22-08-2024 consensus is to recommend non combing character (eg U+02C6) although current chrome implementation only makes U+0302 stretchy.
tmke8 commentedon May 17, 2025
Am I understanding it correctly that if I don't want the accent to stretch (which is actually the case for all the LaTeX commands mentioned in the issue,
\hat{},\tilde{},\vec{}, etc.; the corresponding stretchy commands would be\widehat{},\widetilde,\overrightarrow, etc.), then using the combining characters is fine?Because the thing is that the math fonts actually use the combining characters to store the glyphs for
\vec{},\hat{}, etc. See for example this page from the New Computer Modern symbol table (the 5 fonts compared are New Computer Modern, XITS Math, STIX Math, TeX Gyre Pagella Math, DejaVu Math TeX Gyre, and Fira Math):And indeed, the combining characters look much better with these fonts in Firefox (and also Chrome(!), if you center the glyphs in the font, which can be done with FontForge):
results in
The second version just looks completely wrong (not just the size, but also the type of arrow).
NSoiffer commentedon Nov 7, 2025
@eerii: Please note that in the above MathML, the first x with an arrows renders differently in Chrome and Firefox, with the Firefox rendering being correct (which is the one shown). The Chrome rendering (using "STIX Two Math") is
Here's firefox's rendering with the same font:
davidcarlisle commentedon Nov 13, 2025
see also the table of characters set by latex unicode-math package
https://tex.org.uk/macros/unicodetex/latex/unicode-math/unimath-symbols.pdf
NSoiffer commentedon Nov 16, 2025
I (with some additions by David) have created a large table that shows many of the accent characters in multiple fonts. If you look at the table in different browsers, you'll see Firefox does a pretty good job, Safari has some issues (mainly accent height as noted in w3c/mathml-core#301, and Chrome has a lot of issues. Some of the fonts have problems with some characters.
I tried to draw some conclusions from this in this PR. Specifically this commit: 2caf807. Hopefully Chrome gets fixed.
tmke8 commentedon Nov 16, 2025
For Chrome's horizontal misalignment, I previously modified the glyphs in the font file to make the relevant glyphs horizontally centered (I had a script for doing this). With such a patched font file, Chrome looks better than Safari.
Just noting this for general interest; obviously Chrome should actually center glyphs by itself.