The mathaccent property is used to help produce accents that work more like TeX's accents, but it doesn't get serialized by SerializeMmlVisitor since the mo object itself sets this properly based on the accent being used (so that MathML will work like TeX without the need for extra data attributes). So U+2192 (right arrow) get mathaccent set by default. But macros like \overrightarrow set mathaccent to false to prevent them being treated like accents (since the TeX accents take up no horizontal space, whereas the right arrow can extend beyond its base and needs to take up space). This setting of false is lost when we serialize the internal MathML for SRE and then parse it again.
This PR fixes that by having the MmlVisitor (the base class for SerializedMmlVisitor) check whether the value of mathaccent should be added as a data attribute so that it will be properly preserved, and change the data attribute name from data-mjx-accent to data-mjx-mathaccent. We also add a list of characters that should have mathaccent set to false by default (so MathML will work like TeX without extra data attributes), and move the right arrow to this list.
In the past \overrightarrow{x}\overleftarrow{x} would have the wrong spacing (the arrows touch) because the right arrow was getting mathaccent set to true when the SRE output is parsed. This PR should fix that.
This also affected things like \overrightarrow{x}^2 where the 2 was too close to the base, since the arrow width was being treated as 0. But if the right arrow is not considered a math accent, then the 2 (or other superscript) would be placed too high (in TeX the \overrightarrow acts like an accent for purposes of superscript placement). Now that mathaccent is set to false explicitly, we use the presence of the mathaccent property to indicate the superscripts should be placed like math accents, while its value determines whether the width of the accent is set to 0 (mathaccent=true) or not (mathaccent=false). One can check this by testing if the position of the 2 in \overline{x}^2 is different from that in {{}\overline{x}}^2.
The
mathaccentproperty is used to help produce accents that work more like TeX's accents, but it doesn't get serialized bySerializeMmlVisitorsince themoobject itself sets this properly based on the accent being used (so that MathML will work like TeX without the need for extra data attributes). So U+2192 (right arrow) getmathaccentset by default. But macros like\overrightarrowsetmathaccenttofalseto prevent them being treated like accents (since the TeX accents take up no horizontal space, whereas the right arrow can extend beyond its base and needs to take up space). This setting offalseis lost when we serialize the internal MathML for SRE and then parse it again.This PR fixes that by having the
MmlVisitor(the base class forSerializedMmlVisitor) check whether the value ofmathaccentshould be added as a data attribute so that it will be properly preserved, and change the data attribute name fromdata-mjx-accenttodata-mjx-mathaccent. We also add a list of characters that should havemathaccentset tofalseby default (so MathML will work like TeX without extra data attributes), and move the right arrow to this list.In the past
\overrightarrow{x}\overleftarrow{x}would have the wrong spacing (the arrows touch) because the right arrow was gettingmathaccentset totruewhen the SRE output is parsed. This PR should fix that.This also affected things like
\overrightarrow{x}^2where the 2 was too close to the base, since the arrow width was being treated as 0. But if the right arrow is not considered a math accent, then the 2 (or other superscript) would be placed too high (in TeX the\overrightarrowacts like an accent for purposes of superscript placement). Now thatmathaccentis set tofalseexplicitly, we use the presence of themathaccentproperty to indicate the superscripts should be placed like math accents, while its value determines whether the width of the accent is set to 0 (mathaccent=true) or not (mathaccent=false). One can check this by testing if the position of the 2 in\overline{x}^2is different from that in{{}\overline{x}}^2.Resolves an issue from mathjax/MathJax#2226.