mathjax
Double brackets with negative space appear misplaced
Issue Summary
In version 4 of MathJax we use double brackets with negative space, but one of the brackets appears misplaced on top and right from where it should be.
Steps to Reproduce:
- Use version 4 and enter:
\([\![r,s]\!]=\{r,r{+}1\}\) - See how the brackets appear
- If you use version 3.2.2 it appears correctly
- If you strip the second part of the equation like that:
\([\![r,s]\!]\)it appears correctly - Adding only one more character (like "=") causes the problem
Technical details:
- MathJax Version: 4: all the versions up to 4.0.0-beta.7
I am using the following MathJax configuration:
no configuration at all
and loading MathJax via
where 4.0.0 version has been installed via npm
Supporting information:
See the image below (version 4)
and version 3:
I am not able to reproduce the issue of the misplaced bracket, but I do see the reduced spacing in the second bracket (that you didn't mention). This turns out to be due to the fact that the negative space is being treated as a potential line break, and the tags used to do that seem to be interfering with the spacing. It may also be that the displaced brace is due to the same cause. (The current develop branch doesn't exhibit the spacing problem, so that may have been resolved somewhere along the way.)
One potential solution is to put braces around the whole expressions, which will prevent in-line linebreaking within the expression. That should clear it up.
Another option is to use the fact that the fonts in v4 have more extensive character coverage, and that includes U+27E6 (MATHEMATICAL LEFT WHITE SQUARE BRACKET) and U+27E7 (MATHEMATICAL RIGHT WHITE SQUARE BRACKET). So you could use
\(\U{27E6}r,s\U{27E7}=\{r,r{+}1\}\)
to get single-character versions of the brackets. You can, of course, create macros for this, such as
\newcommand{\llbrack}{\U{27E6}}
\newcommand{\rrbrack}{\U{27E7}}
\(\llbrack r,s\rrbrack=\{r,r{+}1\}\)
or something similar. You can use
MathJax = {
tex: {
macros: {
llbrack: '\u27E6', // an explicit U+27E6 character
rrbrack: '\u27E7'
}
}
};
as part of your configuration in order to pre-define those macros.
Hello and thank you for your reply!
I've created a reproducible example that clearly demonstrates the problem: https://codepen.io/alex-grigoriadis/pen/MYWrroB. I'm surprised you couldn't reproduce it, as it consistently occurs across all MathJax 4 versions even without any configuration at all.
The core issue involves double brackets with negative space ([![r,s]!]), where one bracket appears misplaced when followed by additional characters (like an equals sign). This displacement doesn't occur in MathJax 3.2.2 or when the equation stands alone without additional characters.
I understand your explanation that this is likely related to line-breaking behavior, where the negative space is being interpreted as a potential break point. However, there's no logical reason for a line break at this position, as there are no width constraints or other formatting requirements that would necessitate it. It appears only on the first occurrence of the double brackets and it also seems misplaced. All these create an unpredictable behavior that should be corrected.
For context, at Atypon, we don't author these equations ourselves - we process content from publishers. This creates constraints on potential solutions:
- We can't simply instruct publishers to wrap expressions in braces to prevent line breaks, as in many cases we do want the long equations to break.
- While your suggestion to use Unicode characters (U+27E6 and U+27E7) for single-character brackets is helpful, we can't mandate this change to publishers unless their current approach is definitively incorrect.
Could you confirm if this issue is already fixed in your development branch? If so, which future version will include this fix? This information would allow us to plan accordingly and temporarily work around the issue until we can adopt the fixed version.
Thank you for your collaboration on resolving this issue.
I've created a reproducible example ... I'm surprised you couldn't reproduce it
Thanks! It turns out to involve the interaction of two processes: in-line line breaking and the semantic enrichment that is part of the assistive technology support. I had the latter turned off when I was testing, and so the issue didn't occur for me.
However, there's no logical reason for a line break at this position
I wasn't meaning to defend that, only explain it. I agree that a negative space should not produce a breakpoint, and will make a PR to prevent that. I didn't mean to imply that no fix was needed. My suggestions concerning changing the input were meant as a means of working around the problem for now before a version is released that fixes it.
For context, at Atypon, we don't author these equations ourselves ...
Thanks for the additional information. I hadn't realized your situation (I didn't look at your profile to see that you are at Atypon).
If you are willing to make a change to your configuration, you could incorporate
MathJax = {
startup: {
ready() {
MathJax.startup.defaultReady();
const jax = MathJax.startup.document.outputJax;
Object.assign(jax, {
_markInlineBreak_: jax.markInlineBreak,
markInlineBreak(marked, forcebreak, linebreak, node, child, mo) {
if (child.isKind('mspace') && child.attributes.get('width').charAt(0) === '-') {
return marked;
}
return this._markInlineBreak_(marked, forcebreak, linebreak, node, child, mo);
}
});
}
}
}
into your configuration to patch the in-line breaking code to not break for negative-width spaces.
Could you confirm if this issue is already fixed in your development branch?
I believe it is, but through a different means. One of the contributing factors is the additional structure that the semantic-enrichment process introduces into the expression. In this case, there are additional mrow elements added into the internal MathML, and those produced mjx-mrow tags in the HTML output that had display: inline-block CSS styling. The [\![ appeared inside one of those, and the line break occurred inside of that giving you the first [ followed by a line break, followed by a negative skip and then the second [ inside an inline-block that was aligned on its bottom line of text. That caused the first [ to appear above the rest of the line (and seemingly to the right a bit, but it is actually the second line that is shifted left).
The mjx-mrow should be marked with the breakable attribute, where CSS will change it to having display: inline, which would have avoided the unexpected line break. That is done in the current develop branch, but not in the beta.7 branch. A patch for that would be harder to add to your configuration, so I give you the alternative above for that. I will make PR to prevent breaks at negative spaces.
which future version will include this fix?
The next release (beta.8) will have the addition of the breakable attribute, and should have the PR for the negative spaces that I will be making. This beta release has been held up for some months pending some major adjustments to the assistive technology support that is well under way, but not quite completed yet. I'm hoping it will be made in about a month, but it is a complicated set of changes that have been persistently troublesome. I think we are over the worst of it, so the reset should be more straight-forward.
Thank you so much for your thorough response, the investigation of the issue and the proposed workarounds. It's also great to hear that the issue will be addressed in the upcoming release. The provided patch is sufficient for us to resolve our current issue.