Huge $\sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}}$

Question

Background

While thinking about these two meta questions

1. scaling root problem
2. $\sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}}$

I've come up with another "root problem" which I call "Huge $\sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}}$"

Problem

How can I combine the solutions to these two meta questions to render an enlarged version of $$\sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}}$$ with even vertical separations above and below the middle square root sign?

My attempt

The solution of question 1 suggests putting \Huge{…} inside the square root sign.

$\sqrt{\Huge{e^\overline{X}}}$

$\sqrt{\Huge{e^\overline{X}}}$

However, in "$\sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}}$", there're three square roots.

$\sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}}$

I tried enclosing each word under the square root sign with \Huge{…} like

$\sqrt{\underbrace{\text{Nested}}_{\texttt{\Huge{…}}} \sqrt{\underbrace{\text{root}}_{\texttt{\Huge{…}}} \sqrt{\underbrace{\text{Nested}}_{\texttt{\Huge{…}}}}}}$

$\sqrt{\Huge{\text{Nested}} \sqrt{\Huge{\text{root}} \sqrt{\Huge{\text{problem}}}}}$

$\sqrt{\Huge{\text{Nested}} \sqrt{\Huge{\text{root}} \sqrt{\Huge{\text{problem}}}}}$

but I'm getting broken square root signs.

Answer 1

Its unclear to me what you want this for, but if you only want to adjust MathJax output as it appears on your computer, there is the Right click > Math Settings > Scale All Math... option available in the drop down menu that appears when you right click on some rendered MathJax. This will rescale all MathJax on a page. Here is a picture of the dropdown menu

Clicking gives me the following prompt

and here is the result when I input 500%

which may be good for occasional use; if you want to have the option on more-or-less permanently then 200% is quite usable . There is also the Zoom Trigger and Zoom Factor options in the drop down menu (visible in above screenshot) that are similarly or maybe more useful

The good thing is that this is a true rescaling of the original smaller output. In particular, if the output at the more 'usual' size (and hence more likely to have been tested by the MathJax dev team) is correct for you, then this will continue to be correct. When you put tall things inside a squareroot, such as \Huge modified math, the tail tends to be adjusted in other ways. Of course, no other computer will see the change.

Answer 2

1. We have to put \Huge inside the braces {} like {\Huge …}.
2. We can use \mathstrut to unify the vertical separations above and below the middle square root sign.

$\sqrt{ {\Huge \text{Nested}} \sqrt{ {\Huge \text{root}} \sqrt{ { \Huge \mathstrut \text{problem}} }}}$

gives

$\sqrt{ {\Huge \text{Nested}} \sqrt{ {\Huge \text{root}} \sqrt{ { \Huge \mathstrut \text{problem}} }}}$

Answer 3

tl;dr– Looks like the core problem is MathJax inappropriately applying a size-modifier to the implicit √-character that it uses to render the radical. The trick to avoiding this problem would be ensuring that the implicit √-character doesn't have a non-default size-modifier applied to it, either by avoiding applying one or else by shielding it with \normalsize.

---

Looks like a rendering bug.

The problem appears to be specific to \sqrt having a non-standard size-modifier, e.g. \Huge.

Examples:

• Problematic:
  $\large \sqrt{x}$ renders as ${ `` { \large \sqrt{x} }"} .$

• Not-problematic:
  $\sqrt{\large x}$ renders as ${`` \sqrt{\large x} "} .$

We can copy/paste the MathJax-rendered expression to see that it uses the √ character at the start of the radical. It seems like the rendering would be correct if √ were rendered at the default-size, \normalsize, but applying another size-modifier to it messes it up.

My guess is that this is a bug coming from the size-modifier inappropriately applying to the √-character at the start of the radical. Presumably the folks maintaining MathJax could fix this by having the √-character in the radical not react to a size-modifier as normal-text.

---

Work-around.

As a partial work-around, we can define

\def\Sqrt#1{{\normalsize{\sqrt{#1}}}}

, then use \Sqrt instead of \sqrt.

For example:

\def\Sqrt#1{{\normalsize{\sqrt{#1}}}}
\Sqrt{\Huge \text{Nested} \Sqrt {\Huge \text{root} \Sqrt{\Huge \text{problem}}}}

renders as $$ \def\Sqrt#1{{\normalsize{\sqrt{#1}}}} \Sqrt{\Huge \text{Nested} \Sqrt {\Huge \text{root} \Sqrt{\Huge \text{problem}}}} $$

The drawback to putting \normalsize before \sqrt is that it strips out the external-size-modifier for the internal-content as well as the radical, requiring \Huge to be written several times above. If not for the apparent bug, then

\Huge \sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}}

could be sufficient, though it currently renders as: $$ \Huge \sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}} $$ .

---

Clarification: Why does it appear to be a bug with respect to √?

This answer's tl;dr begins with:

Looks like the core problem is MathJax inappropriately applying a size-modifier to the implicit √-character that it uses to render the radical.

@DavideCervone commented:

The problem is not with the scaling of the surds, but with the placement of the overlies. This is a bug in the HTML-CSS output, but changing to CommonHTML or SVG will produce the desired results.

@DavideCervone's comment points out the apparent situation while I'm suspicious it may be something else, so figured it'd be good to clarify the apparent discrepancy.

First, to acknowledge the point: if we look at something like $$ {\boxed{ \Huge \sqrt{\text{Nested} \sqrt{\text{root} \sqrt{\text{problem}}}} }}_{,} $$ then the most obviously wrong part appears to be the line through the top of $`` \text{problem} " ,$ rather than anything directly with a √-character. I agree with this observation.

That said, my guess is that that apparent problem is downstream of the actual bug. I'd speculate that it's one of those situations where someone over-corrected for a bug downstream of where it occurred, causing a secondary problem. So, it'd probably be best to address the primary problem first, then revert the buggy downstream over-reaction to the primary problem.

To clarify, I'd suggest looking at this rendered in both HTML-CSS and Common HTML: $$ {\boxed{ \Huge{\sqrt{\sqrt{\sqrt{\sqrt{\sqrt{\sqrt{\sqrt{\sqrt{\sqrt{ \color{red}{ \sqrt{\rule{1em}{1em}} } }}}}}}}}}} }}_{.} $$

Observations:

1. In Common HTML, this mostly looks about right. Most of the problems are confined to HTML-CSS.

   • So, I'd suggest Common HTML as a known-good(-ish) viewer as we look into HTML-CSS.

2. Regarding $\boxed{\color{red}{\sqrt{\rule{1em}{1em}}}} :$

   • In Common HTML, the radical hugs pretty tightly.

   • In HTML-CSS, the radical is looser. The overall structure is larger, with a weaker wrapping around the content within the radical.

3. Regarding the largest √'s at the start of the expression:

   • In Common HTML, they appear mostly consistent.

   • In HTML-CSS, they become fractured, with both vertical and horizontal display errors.

So, here's my speculation about what happened:

1. The HTML-CSS-rendering code applies a size-modifier to text, as generally desired.

   • For example, \Huge{xyz} applies the \Huge{}-modifier to the graphical elements for x, y, and z.

2. The HTML-CSS-rendering code applies a size-modifier to other graphical elements, too, as generally desired.

3. The HTML-CSS-rendering code constructed the \sqrt-graphical-element under the principle of being non-textual...

4. ...except (and this is my guess!), the code accidentally considered the √-character as a textual element, sizing it up as such even though it should've already been sized up as a non-textual-element, causing inappropriate, excessive sizing-up.

5. Someone realized that there was a bug, but instead of fixing the root-issue, they tried to counteract it with a counter-balancing size-reduction transform. I speculate that this is why, for example, the radical's line strikes-through $`` \text{problem} "$ in an above example.

If my guess is correct, then these things should be observable:

1. The HTML-CSS-renderer should have the radical more over-sized than in the Common HTML-rendered.

   • Which is the case, most notably in the loose-wrapping in the inner-most radical above. Can also be seen if the same large-radicals are rendered in both renderers, then overlaid via copy/paste with transparency.

2. There should be other graphical counteractions apparent in the HTML-CSS-rendering.

   • Which is the case, most notably in the outer-most radicals shown above.

As a practical fix for the MathJax maintainers:

1. Check if the √-character is indeed getting double-sized-up: once due to being a structural-element and once due to being a text-element.

2. If so, remove one of those sizing-ups, even if it makes the rendering look even worse.

3. Then, track down all of the counteractions, and perhaps remove those, too, if they can't be remediated. Go for simplistic right now.

4. Once the root problem and its related counteractions are removed, the rendering should look decent-ish (even if odd) and the code-design should be relatively simple (since less should be happening).

5. Then add in the touch-ups and transforms to get it looking more stylish.

Hard to be sure that this is necessary the problem/solution without looking at the code and such, but this'd be my guess. I hope the observations help to communicate ways in which the renderings would seem to reflect this hypothesized issue.