# Background

While thinking about these two meta questions

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.

• I apologize if this seems brusk, but: I don't see this as much of a problem, and I think that the proposed solution causes more problems than it solves. The poor typesetting annoying, but ultimately a problem with MathJax, not SE (that is, contact the maintainers of MathJax). Moreover, the MathJax syntax contains syntactic information which can be used by screenreaders when accessing the site. Using "hacks" to get the visual display just right is likely to obfuscate some of that syntactic information, making the site less accesible.
– Xander Henderson Mod
Feb 9 at 18:52
• @XanderHenderson Imagine that you have a nested square root inside a subscript under another subscript—one might want to enlarge the nested square root to properly read this. Feb 10 at 7:44
• Or one could find a way to typeset the document so that it avoids nested radicals in nested subscripts. And, realistically, how often does this come up? Of course, you have also neglected the rest of comment---the MathJax code also contains syntactic content about the mathematics being displayed. Using hackery to make it display in the way you want is likely to obfuscate that information.
– Xander Henderson Mod
Feb 10 at 13:43
• A really good way to make things bigger, which is not a hack and does not obfuscate the semantics, is to zoom the browser. On Chrome for instance you hold Ctrl and roll the mouse wheel. On a phone you can touch with two fingers and then spread them apart. Feb 11 at 15:06
• @JohnHenckel agger & Δ'd ✓'d ans Feb 11 at 15:20
• I believe \large, \Large, \Huge and similar things are switches: the text is affected from that point onwards. Compare some writing \textbf{in bold} now normal with some writing \bfseries{in bold} now normal for another example of a switch. Same for fonts like \upshape, \rmfamily, etc. Aside: one should use \itshape/\rmfamily/etc rather than \it/\rm/etc Feb 12 at 9:15
• The issue is only with the HTML-CSS output. If you switch renderers, you will get the correct output. Mar 4 at 22:49

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.

• ty 4 ans and your time but the output doesn't look good. \Huge is one of the commands for resizing math. One might want to resize the math for some reasons, say for accessibility reasons. When easily confusing characters like $i$ and $j$ or $i'$ are in a subscript of a subscript (denoting the index of a subsequence of a subsequence) inside a square root which is inside another square root, one might want to enlarge them in a post for explanation. My question body is clear enough. It only asks for enlarging a particular math expressions (the nested square root). Feb 6 at 17:18
• I didn't ask to resize other math expressions. Feb 6 at 17:20
• You're welcome. @GNUSupporter8964民主女神地下教會 I think it is easier to teach the visually impaired to use Scale all math... than it is to make anyone who wants to use similar characters like $i,\iota,\hat\imath,\ddot{\imath},\overset{\circ}\imath$ put these things inside a \Huge modifier. It is also neither feasible nor advisable to edit all such MSE content to use \Huge. In addition, \sqrt{\sqrt{\sqrt{\dots}}} is easier for screen-readers than \sqrt{\Huge\sqrt{\Huge\sqrt{\Huge\dots}}}. If I was partially sighted, I think I would appreciate the option of using 200% globally. Feb 7 at 1:26
• @GNUSupporter8964民主女神地下教會 My point about being unsure is I do not know who would consume your content: I wrote the answer in case you are writing something for personal use. A secondary reason it is unclear to me is because I am unable to reproduce broken square root signs on any of my devices, with or without $\Huge$ (the ones with \Huge look weird, but all lines are continuous), and you did not include pictures. Feb 7 at 1:27
• thx 2 JohnHenckel's ans i realized the importance of semantics and i shifted the '✓' mark to ur ans Feb 11 at 15:22
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}} }}}$$

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 √?

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

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.

• 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. Mar 4 at 22:50
• @DavideCervone: I edited in a response to your comment in the above answer.
– Nat
Mar 6 at 21:09
• As I mentioned above, it is not that the surds are mis-sized; it is that the overline is misplaced. The positioning is not taking some of the scaling factors into account. I know what it issue is, but thanks for trying to diagnose it. The HTML-CSS output is more than 10 years old, and has lots of browser-specific hacks and is most fragile of the renderers. It has not been (and will not be) ported to v3, and bug fixes will be made only periodically (v2 is only undergoing maintenance). This will be fixed in a future version, where there are sufficient bug fixes to warrant a release. Mar 7 at 16:09
• On the other hand, SE has not updated MathJax in several years. They are at v2.7.5, but the current version is 2.7.9, so even when a fix is available, it is not clear when it will be included in SE sites. Mar 7 at 16:09
• FYI, there is a bug fix for this queued up (since January) for the next release Mar 16 at 15:21