3
$\begingroup$

The following Minimal (Non-)Working Example is boiled down from @ElíasGuisadoVillalgordo's answer to Is there a complex which computes Čech cohomology?. Consider the following two displayed formulæ: $$\smash{\check H}$$ versus $$\smash{\check H}\tag{tagged}$$ The body of each is \smash{\check H}. The only difference in the source is that the second has a \tag, which shouldn't affect whether the accent renders on the $H$.

After discussion with @ZhenLin in the comments to their thoughtful answer about why this is an abuse of \smash (although I still think it represents a bug!), here's another version: $$\vphantom{\check H}\smash{\check H}\tag{also tagged}$$ Indeed, including a \vphantom fixes up the issue, so I think that may reasonably be regarded as a satisfactory workaround.

In case it doesn't render for you, here's what the first two look like for me. I am using Firefox 135.0.1 on macOS 15.1.1, with the HTML-CSS renderer. I am not using MathJax v3. It looks like there is some tiny remnant of an accent on the second $H$, but perhaps it gets cut off?

Image of the phenomenon described above

$\endgroup$

2 Answers 2

Reset to default
10
$\begingroup$

This is not a bug in MathJax, it is due to the following CSS that is part of the StackExchange primary.css file:

.MathJax_SVG_Display, .MathJax_Display, mjx-container {
    overflow:auto hidden
}

This is meant to allow long expression to scroll, (the auto setting in the x direction, but unfortunately, the hidden in the y direction means that expressions are clipped vertically, which is why you are losing the top of the expression, including most of the accent.

The only difference in the source is that the second has a \tag, which shouldn't affect whether the accent renders on the $H$.

The accent is rendered, it is just being cut off by the page's CSS. The reason the two differ in what is cut off is because the tagged expression uses a table layout, and that affects the height of the resulting HTML, as seen by the browser, and so the clipping is in a different place.

$\endgroup$
5
$\begingroup$

This is an abuse of \smash. It causes the box to be treated as having 0 height, which makes it impossible to calculate the correct height for the line. Notice that there is a little dot over the $H$ in the smashed example: that's the allegedly missing haček! It has been cropped too much, as you say.

In the original example, it would have been just as effective to write \check{H}{}^n to adjust the position of the superscript. The effect of the extra {} is to insert a 0 width box of normal height before the superscript. That leaves the height of \check{H} alone, so the height of the line remains what it needs to be to avoid excessive cropping.

$\endgroup$
8
  • $\begingroup$ Even if it is an abuse, it is surely also a bug, because this is not the behaviour exhibited by a LaTeX compiler. Nonetheless, thank you for your discussion of why \smash is semantically incorrect here; I had never really thought it through. My objection to the \check{H}{}^n construction is that it attaches the superscript to the 0-width box, not to \check{H}. Aside from my semantic dissatisfaction with this, it seems at least theoretically possible that there could be a line break between the \check{H} and the {}^n if such a construction were used systematically. $\endgroup$ Commented Apr 1, 2025 at 23:20
  • $\begingroup$ As ugly as it is, perhaps {\vphantom{\check H}\smash{\check H}^n} could satisfy my desire for a superscript attached to the \check H box. $\endgroup$ Commented Apr 1, 2025 at 23:21
  • $\begingroup$ LaTeX itself has similar misbehaviour. Try smashing a very tall box, e.g. \displaymode \sum_0^N, in inline mode! $\endgroup$ Commented Apr 1, 2025 at 23:33
  • $\begingroup$ Re, after correcting what I think was the typo of \displaymode (which doesn't work on my compiler) for \displaystyle, I regard that as different: as you indicate, we have told TeX that the box has height $0$, and it is behaving accordingly, running the vertical overflow into the previous line. Here, MathJax instead truncates and throws away the vertical overflow. But this might be in the category of not really a bug, but rather an essential limitation of HTML's layout capabilities. $\endgroup$ Commented Apr 1, 2025 at 23:53
  • $\begingroup$ (But I still don't understand why it should be the \tag that triggers this behaviour!) $\endgroup$ Commented Apr 1, 2025 at 23:56
  • 1
    $\begingroup$ Yes, I think it is some issue with the HTML/CSS. It probably can be worked around with enough effort. $\endgroup$ Commented Apr 1, 2025 at 23:58
  • 3
    $\begingroup$ “Doctor, when I put my copy in a \smash, the bounding box is too small to contain it and part of it is cut off.“ “Don’t do that, then.” $\endgroup$ Commented Apr 2, 2025 at 6:49
  • $\begingroup$ Isn't this kind of "abuse" the main reason for the \smash command to exist, in the end? $\endgroup$ Commented Apr 5, 2025 at 18:41

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.