GeezerVison

I'm questioning this new parameter for positionMathGroup: it adds another special-handling for LaTeX that I don't think is necessary.

Plain text labels don't need it, and I'd like to find a way to treat the labels the same way.
Further, only repositionMathGroup uses this approach, so the same label is measured one way when first placed and another way when repositioned.
I think we should follow a similar approach to finalizePosition where we measure the unrotated size once, record it, and reuse it later.

Once MathJax finishes, the Mathjax promise callbacks call repositionMathGroup while the label is already rotated, and repositionMathGroup measures the tex again at that point.

A rotated element measures larger than it really is, which is why this PR needs its extra rotation handling. And measuring again gives a second chance for the result to differ from the first measurement.

As in finalizePosition, which measures with the rotation cleared, we should measure the tex once in that state and keep the result, instead of measuring again here.

repositionMathGroup measures the tex itself every time it runs, so the size it gets depends on how the label is rotated or scaled at that moment.

A rotated or scaled label measures differently from how it was laid out. That is the problem this PR works around for rotation, and the same cause leaves tex off-centre when the graph is scaled with CSS (for example transform: scale(0.7)).

I think it should accept an already-measured, unrotated size instead, so we measure once and reuse the result. We can render the tex in place and unrotated with visibility: hidden, record its size in local (untransformed) units, and pass that in (or read it inside the function). Measuring in place, inside the graph, keeps the result consistent with whatever CSS applies to it.

getMathOrTextNode now returns the glyph group inside MathJax's output (svg g), which couples this implementation to MathJax's own internals that we don't control.

If the unrotated size is measured once and reused, as suggested in the other comments, hover would not need to look inside the tex output at all. The one place that already knows that structure is texToSVG, which selects the svg and its defs from MathJax's output.

getUnrotatedSize has to work out whether a label is rotated, by reading the transform matrix (getScreenCTM).

Rotation is already inferred a different way elsewhere in this file (positionMathGroup rotates any math group whose class starts with y), and colorbar/draw.js needs a workaround for that guess. Each extra way of guessing is one more thing that can disagree with the others.

If we measure once with the rotation cleared, as suggested in the other comments, we never need to detect rotation here at all.

This makes hoverlabel.namelength have no effect on a name that is a single tex expression, causing it to disagree with the attribute description.

With namelength: 0, a plain name is hidden, but a tex name is now shown in full.

We should update attr description. Note the description is part of the schema, so npm run schema needs to be re-run after this.

This test only covers the tex in the name label, but the fix also moves the tex in the main label.

Could you add a case where the main label is a single tex expression (for example hovertemplate: '$\\sum_{i=1}^{n} x_i$<extra>one</extra>'), with two traces in hovermode: 'y', and check that the tex stays inside its label?