Katex: Sizing Commands spacing not right with roots

[ry-randall]

Example: \Huge \sqrt[22]{a}

[ronkok]

We might be applying the \kern-10mu incorrectly. We are now applying it to the right of the outside of the root, where the governing style is \textstyle. If we applied the same kern inside the root, it would be applied at \scriptscriptstyle and the radical doesn't shift as far to the left. I'll look into it a little more.

[ronkok]

Well, it’s complicated. It turns out that KaTeX, LaTeX, and MathJax each have their own unique approach to large radicals. Below are three treatments of \[ \sqrt a \Huge \sqrt a \sqrt[2] a \]. Those are KaTeX, LaTeX, and MathJax, in that order.

There are three reasons why math can get taller or shorter. (1) Stacked elements such as fractions. (2) Style changes such as \scriptstyle. (3) Size changes such as \Huge. KaTeX deals consistently with tall arguments by choosing tall radical glyphs. LaTeX and MathJax do that for stacked elements but act differently when the source of the tallness is due to a size change such as \Huge.

LaTeX \sqrt ignores size changes altogether. LaTeX \sqrt[<root>] deals with \Huge not by picking a taller glyph but by applying a scale factor to the \normalsize radical. MathJax does the same thing whether or not the \sqrt has an optional root. That’s why MathJax roots fit next to the \Huge radical. There is more space there than there is next to a KaTeX unscaled but taller glyph.

I don’t see any reason to match LaTeX behavior in this case. It looks broken to me. Even when the glyph is taller, the root is in the wrong horizontal position.

I can match the MathJax behavior and that will create enough space so that the root does not interfere with the radical. However, that will be a significant effort so I want some buy-in up front before I start work. Is the MathJax behavior what we want?

[ronkok]

An alternate approach would be to let the KaTeX radicals remain as is, and instead vary the root's kern distance. There is currently a \kern-10mu on the right side of the root. That distance needs to vary with size if we keep the current radicals.

[ry-randall]

Hmm, switching the kern distance based on the size seems like the easiest solution by far, but could likely cause issues in the future.

For example, if we expect that users might be adjusting those size factors (i.e. map large to 1.1) then they'd have to do it in two places (for the sqrt spacing as well).

That being said, that sounds like an edge case. Unless other folks have more outstanding concerns, then I think that's a simple solution to a tough problem.

[ronkok]

I've thought a bit more about this, and I don't think either approach is much more difficult than the other. We should just pick the behavior that we prefer and not worry about how hard it is to implement.

[ry-randall]

I think the MathJax solution looks nice. Just want to clarify that MathJax is scaling the sqrt symbol, and the root itself, but not the content inside the sqrt?

Would be worried about how this would affect the root/sqrt symbol visually? I'm assuming it's a 1-1 scale factor?

Also, this would just be a special case for sqrts/roots. Are there other symbols that would fit this case?

[ronkok]

but not the content inside the sqrt?

Yes, any characters under the radical already get scaled up and I don't propose to change that. Characters in the root also scale up. But the root is \scriptscriptstyle so it isn't as large as the math under the radical. I don't propose to change that either. I'd say just as an eyeball estimate that MathJax is using a different ratio of \textstyle to \scriptscriptstyle when they size their root. I'll keep the \scriptscriptstyle scale already defined by KaTeX.

this would affect the root/sqrt symbol visually?

Yes, the line weight will get thicker.

Are there other symbols that would fit this case?

I'm going to take one thing at a time. I'll work on radicals for now.

[edemaine]

In general, I'm uncomfortable following MathJax because "it looks good". We should be following LaTeX as closely as reasonably possible.

A source of the problem here is that you're really not supposed to use sizing commands like \Huge in math mode. I'm not sure if @ronkok tried this directly with LaTeX, but it gives major warnings that you shouldn't do what you're doing. Of course, it does do something.

Doesn't the mu unit already scale with font size? I'm a little confused about why this isn't working.

[ronkok]

KaTeX has allowed sizing commands like \Huge in math mode since release 0.3.0 and delimiter.js has always gone to a great deal of effort to support that behavior with resizeable delimiters.. Perhaps it would be appropriate to disallow sizing in strict mode but it's too late to break that behavior otherwise.

Doesn't the mu unit already scale with font size?

Yes it does, and if we scaled up the \normalsize radical then it would scale both vertically and horizontally and there would be enough horizontal room for the kern to work properly. In fact, that is exactly what KaTeX did from release 0.3.0 to release 0.7.1. It changed in release 0.8.0 and I suspect that the change was inadvertent, not intentional. There are no PRs in that release that proclaim an intent to change delimiter sizing behavior. I suspect the change is an inadvertent consequence of PR #719 or perhaps #755.

So I propose to change the delimiter sizing in general and radical sizing in particular to act more like KaTeX did before release 0.8.0. That would not change behavior when math is stacked. It would not change behavior due to style changes such as \scriptstyle but it would change behavior during a size change such as \large. That change would be accomplished by scaling a delimiter/radical.

Now as @edemaine has noted, all of this sizing behavior is contrary to LaTeX. I would have no objection if someone were to disallow all of it in strict mode, but I think that is a matter for a separate PR.

[ronkok]

I can confirm that PR #719 did change delimiter sizing behavior.

Now keep in mind that PR #719 did not change delimiter sizing for \large in way that conforms to LaTeX. LaTeX doesn't perform that sort of delimiter sizing at all. If we keep a permissive delimiter sizing, then we are free to do it in the pre-#719 manner or in the post-#719 manner. The pre-#719 method matches MathJax and enables a root on a \large radical.

I think we ought to change radicals at least to the old behavior. I don't have strong feelings either way on delimiters in general.

[edemaine]

Thanks for investigating! That definitely sounds like the simplest fix. Would this then match the MathJax behavior? Would it correspond to if, in LaTeX, you exited math mode, changed the font size, and then re-entered math mode? (I'm a little surprised that's not what LaTeX does with size commands... unclear why LaTeX behaves in this buggy way.)

[ronkok]

if, in LaTeX, you exited math mode, changed the font size, and then re-entered math mode?

No, LaTeX does not scale up the radical; the line weight does not change. And it does something weird relative to the baseline. Here's an example rendering of
\( \sqrt[3]{\frac M M } \sqrt[3]{\text{\Huge M}} \) :

If the baseline were not so odd, I'd say that looks similar to current KaTeX behavior, but with a better positioned root.

[edemaine]

Understood. I meant something slightly different -- your \sqrt isn't in the \Huge context. Consider the following LaTeX, which exits math mode, changes font size, then re-enters math mode:

$$ \sqrt[3]{\frac M M } \mbox{\Huge $\sqrt[3]{\frac M M }$ } $$

(quicklatex render)

Now the line width is scaled! (\text also works, though renders slightly differently.)

I believe this (\text{\Huge $...) is essentially what we're proposing to simulate in KaTeX (when just writing \Huge). Does this seem reasonable? (I'm not entirely sure.)

As an aside, this probably is a good thing to warn about via strict, especially if our behavior differs from LaTeX (but even then, given that LaTeX warns too).

[ronkok]

Yep. I'll have a PR ready in a couple of days.

[kevinbarabash]

Perhaps it would be appropriate to disallow sizing in strict mode but it's too late to break that behavior otherwise.

Agreed. There's a fair number of content items on khanacademy.org that use this behaviour. We did this to make the radicals easier to read.

I think we ought to change radicals at least to the old behavior.

Sounds good.

@ronkok thanks for investigating this. This is tricky stuff.

[ry-randall]

Fixed via #1485