Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix problem with \| being stretchy when it shouldn't be. (mathjax/MathJax#2632) #600

Merged
merged 2 commits into from
Mar 12, 2021

Conversation

dpvc
Copy link
Member

@dpvc dpvc commented Feb 25, 2021

Semantic enrichment together with certain TeX input can cause \| to be stretchy when it shouldn't. For example, \|X^X\|_x, can cause the problem. This is due to the fact that \| produces U+2225, which normally is not stretchy, but should be when used as delimiters with \left and \right. In order to accommodate that, the operator dictionary added U+2225 in prefix and postfix positions with stretchy="true", making the stretchy attribute different in infix from the other positions.

Because the TeX input jax removes attributes that are the defaults for the given nodes, the expression \|X^X\|_x, has \|_x in infix position (as an embellished operator), and so the U+2225 has stretchy="false" and fence="false" as defaults, and so these attributes that had been added explicitly by \| are removed in the cleanAttributes post-filter (that is not the case for the initial one, since it is in prefix position, where the defaults are true for those attributes). But when enriched, the result is that \|X^X\|_x is placed in an mrow (with the comma outside), and so the \|_x is now in prefix position, where it defaults to being a stretchy fence.

The basis of the problem is the different stretchability for infix versus pre- and postfix positions, which was due to an addition to the table to make the poor TeX mapping of the delimiter \| to U+2225 work. This PR resolves the problem by removing the changes to the operator dictionary for U+2225, and instead, having the delimiters \| and \Vert map to U+2016.

Resolves issue mathjax/MathJax#2632.

@dpvc
Copy link
Member Author

dpvc commented Feb 25, 2021

One potential backward incompatibility is that MathML that already has U+2225 where this PR now uses U+2016 will no longer be stretchy automatically. I don't know how prevalent that is, but if MathML output from TeX has been saved (e.g., through mathjax-node, for example), then that could contain this construction, and this PR would cause it to stop being stretchy.

One possible approach to that would be to modify

protected markMrows(mml: MmlNode) {
if (mml.isKind('mrow') && !mml.isInferred && mml.childNodes.length >= 2) {
let first = mml.childNodes[0] as MmlNode;
let last = mml.childNodes[mml.childNodes.length - 1] as MmlNode;
if (first.isKind('mo') && first.attributes.get('fence') &&
last.isKind('mo') && last.attributes.get('fence')) {
if (first.childNodes.length) {
mml.setProperty('open', (first as AbstractMmlTokenNode).getText());
}
if (last.childNodes.length) {
mml.setProperty('close', (last as AbstractMmlTokenNode).getText());
}
}
}
}

to explicitly pick up U+2225 (since it is no longer marked as fence="true") and to add stretchy="true" and fence="true" to the mo's, provided these attributes are not already set explicitly to false on one or the other of them.

@dpvc dpvc added this to the 3.1.3 milestone Mar 3, 2021
Copy link
Member

@zorkow zorkow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm.

@dpvc dpvc merged commit 01a5629 into develop Mar 12, 2021
@dpvc dpvc deleted the issue2632 branch March 12, 2021 19:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants