A strange bug that have magically resolved itself

[shniubobo]

This is NOT a bug report, but a question about a bug that has never been reported before, and has already been auto-magically resolved, which I am very curious about.

On rehype-mathjax@<7, there was a bug that Chinese characters in math formulas were rendered in a wrong way:

And after updating to 7.0.0, the problem was gone:

What makes me even more curious is that, the problem only happened when using webpack, and did not happen for tsc (To reproduce that, clone this repo).

I have found out that remarkjs/remark-math@b353e49 solved the issue, but I cannot figure out why, why removing jsdom could solve this bug, and why the bug was only reproducible using webpack.

[wooorm]

Hi!

a) Your HTML repro is missing <meta charset=utf8>. Stuff like that often messes up things
b) Your repro repo prints things to console, it doesn’t render them: to not spend too much of my time on this, I give up
c) it could definitely be that there is a problem in JSDom with rendering things. Or, that there is a problem with webpack bundling a big library like JSDom!

[shniubobo]

Hi!

a) Your HTML repro is missing <meta charset=utf8>. Stuff like that often messes up things
b) Your repro repo prints things to console, it doesn’t render them: to not spend too much of my time on this, I give up
c) it could definitely be that there is a problem in JSDom with rendering things. Or, that there is a problem with webpack bundling a big library like JSDom!

a) The meta tag doesn't help, and actually this bug was first found in a large project, which has all these things.
b) The differences are that, some characters are missing transform="translate(*,0)", some other transform="translate(*,0)" attributes have wrong values, and the overall width of the <svg> is wrong. It seems that MathJax cannot calculate the correct width of each character. I have attached two html files containing the output, plus some boilerplate code, so that you could open them in a browser to see what's happening (the suffix is txt because github doesn't allow html).

with-bug.txt
without-bug.txt

[shniubobo]

I’m not familiar with math syntax in markdown / HTML or related libraries. But I am familiar with Mermaid and JSDom. I can tell you from experience that JSDom doesn’t support DOM sizes. So if the library depends on the DOM to calculate sizes, it makes sense the output is incorrect when you’re using JSDom. This is why rehype-mermaid uses Playwright to render diagrams in a real browser.

Thank you very much for the information! That's a very good start point for me to investigate further.

[wooorm]

As you mention transform(0), it might then also be related to the mathjax jsdom integration: when I swapped that, I noticed that the value “0” behaves differently. See the test files: remarkjs/remark-math@b353e49.

[shniubobo]

As you mention transform(0), it might then also be related to the mathjax jsdom integration: when I swapped that, I noticed that the value “0” behaves differently. See the test files: remarkjs/remark-math@b353e49.

Sorry if I have missed something, but I searched for "transform" in the linked test files' diff, but didn't find any occurrence (there were 4 in the other files, which seemed to me not related).

And to be clear, what i meant was that some instances of translate are missing. Please see the diff for detail.

[wooorm]

Correct, no transform, but there are 0s, in the test case, and in your translate.
It is one idea. That the bug could also be in the mathjax + jsdom integration. Mathjax has many open issues. Such as mathjax/MathJax#3224. Or mathjax/MathJax#2893.

[shniubobo]

Correct, no transform, but there are 0s, in the test case, and in your translate. It is one idea. That the bug could also be in the mathjax + jsdom integration. Mathjax has many open issues. Such as mathjax/MathJax#3224. Or mathjax/MathJax#2893.

Thank you for the links! Actually I have tried searching in their repository, but did not find anything relevant. Some issues are indeed related to Chinese, or other non-ascii characters, but not the same as what I was trying to resolve. For example, the issue described in mathjax/MathJax#3224 is only applicable to MathJax v4, and even for v4 the problem is different from mine (the Chinese characters don't overlap with each other; they're just overlapping with the English letters that follow them). I have tried adding mtextInheritFont: true as suggested by that issue, but had no luck.

Anyway, I'm now trying to find clues in their code how these translate values are determined.