8
$\begingroup$

In revision 2 of Number of permutations in $S_{a + b}$ with $\operatorname{maj}(\pi) = b$ and $\operatorname{maj}(\pi^{-1}) = b$, I edited an equation that had been manually given the label (\ast) to use \tag. As usual when I have to make up a label for an equation that wasn't already given one, I used the existing tag; in this case, \label{*}, with the corresponding \eqref{*}. This worked fine in the generated preview, but, when the post actually rendered, the * inside \eqref was parsed as Markdown rather than as MathJax.

@GeraldEdgar's test suggests that this might not happen on MMO (or maybe we're not exercising the specific buggy conditions here?), but visiting the specific revision https://mathoverflow.net/revisions/384561/2 shows that it does happen on MO.

In case TeX in the main post affects @GeraldEdgar's test, $1 + 2 = 3$. In case you missed it, \begin{equation} \tag{*}\label{*} 1 + 2 = 3. \end{equation} In case you still missed it, refer back to \eqref{}. As @AntonGeraschenko points out, the problem is in referring to \eqref{} twice.

Since neither @AntonGeraschenko nor I am able to reproduce the problematic behaviour I report—that is, where the preview does not match the rendering—I probably made a mistake. I have accepted their answer, but if it would be better to close this question, then I have no objection to doing so.

$\endgroup$
2
  • $\begingroup$ An obvious answer is "don't use * as a label", which will certainly mitigate the problem, but my point is more about the preview not matching the rendered post than working around this specific parsing issue. $\endgroup$
    – LSpice
    Feb 21, 2021 at 18:28
  • $\begingroup$ Your equation in the question looks OK when I first come here, but goes bad when I edit. $\endgroup$ Feb 27, 2021 at 11:46

2 Answers 2

1
$\begingroup$

I'm not able to reproduce the mismatch between preview and render. When I go to edit the question and paste the source of that revision, I get the same (undesirable) rendering in the preview. Are you sure the preview worked before?

Diagnosis

The problem is that you used two *'s outside of math mode. The markdown processing (i.e. converting markdown to bold, italics, headings, etc.) happens first (server side if you're not using the preview), and then MathJax processing happens. Inside dollar signs, markdown explicitly avoids things it would normally process, on the assumption that stuff is meant for MathJax to consume. But outside of math mode (or raw code mode), the * in \eqref{*} looks like fair game. When you use two of them, the markdown processor happily converts them to <em> and </em> and then MathJax has no chance.

Proposed solution 1: Don't use markdown special characters in \label{}. The label you use isn't visible anyway (only the tag is).

Note also that when all the the MathJax on the page is processed together (which doesn't happen in preview), repeated labels will cause "Label multiply defined" errors in MathJax, because MathJax don't know anything about the semantics of questions and answers ... it's just one big web page to it. However, the same tag being repeated is totally fine (albeit potentially confusing to the reader).

Proposed solution 2: Put your \eqref{} in dollar signs so that the markdown processor ignores it.

Demonstrations

Problem: (Note I'm using _ instead of * to avoid global collision with the label in your question)

$$\begin{equation} A = B \tag{*}\label{_} \end{equation}$$
Look at equation \eqref{_}; isn't equation \eqref{_} awesome?

produces the following output:

$$\begin{equation} A = B \tag{*}\label{_} \end{equation}$$ Look at equation \eqref{}; isn't equation \eqref{} awesome?

Solution 1:

$$\begin{equation} A = B \tag{*}\label{ast} \end{equation}$$
Look at equation \eqref{ast}; isn't equation \eqref{ast} awesome?

$$\begin{equation} A = B \tag{*}\label{ast} \end{equation}$$ Look at equation \eqref{ast}; isn't equation \eqref{ast} awesome?

Solution 2: (Note I'm using __ instead of _ to avoid collision with the problem demonstration)

$$\begin{equation} A = B \tag{*}\label{__} \end{equation}$$
Look at equation $\eqref{__}$; isn't equation $\eqref{__}$ awesome?

$$\begin{equation} A = B \tag{*}\label{__} \end{equation}$$ Look at equation $\eqref{__}$; isn't equation $\eqref{__}$ awesome?

Global collision example:

$$\begin{equation} A = B \tag{*}\label{*} \end{equation}$$

$$\begin{equation} A = B \tag{*}\label{*} \end{equation}$$

$\endgroup$
7
  • $\begingroup$ Your workarounds definitely do work around the problem, but, as I mentioned, that wasn't really my worry—it's very easy to work around the problem once you know it's there. Anyway, I am almost certain that the problem did not show up in the original revision, but I also see what you report, that I cannot now reproduce it. So maybe I was wrong. $\endgroup$
    – LSpice
    Mar 4, 2021 at 19:17
  • $\begingroup$ Huh, the "global collision example" I added at the end doesn't produce the behavior I expected. I thought it'd give me a red box with the text Label '*' multiply defined, but instead I see a white box with the source in it. $\endgroup$ Mar 4, 2021 at 19:17
  • $\begingroup$ By the way, I think that labels are scoped to the individual answer, so that no global collision will happen. (At least, commands are so scoped.) $\endgroup$
    – LSpice
    Mar 4, 2021 at 19:18
  • $\begingroup$ @LSpice: does the last equation in my answer look correct to you, or do you see the underlying LaTeX source (as I do)? $\endgroup$ Mar 4, 2021 at 19:20
  • $\begingroup$ I see the underlying source. $\endgroup$
    – LSpice
    Mar 4, 2021 at 19:22
  • 1
    $\begingroup$ Curious. That means that both of our guesses about how MathJax is scoping labels must be wrong. If the scope were global (as I had guessed), we'd see the "multiply defined" error, and if the scope were restricted to individual answers (as you had guessed), then we'd see rendered math instead of source. $\endgroup$ Mar 4, 2021 at 19:25
  • 1
    $\begingroup$ Blazing new frontiers of wrongness! $\endgroup$
    – LSpice
    Mar 4, 2021 at 19:28
3
$\begingroup$

Trying to reproduce the problem. An equation $$ 4+2=9 \tag{*}\label{1} $$ and then reference to it \eqref{1}. How does it look?

Another equation $$ 4\times2 = 6 \tag{**}\label{2} $$ and a reference to it \eqref{2}. How does it look?

OK when the page is first rendered, or when the page is re-rendered later. But not OK following an edit with no re-render of the whole page. And I expect problems when there is other LaTeX above this on the same page.

$\endgroup$
8
  • $\begingroup$ Thanks for the test! I'm sure it's my fault, but I can't parse it—what does "following an edit with no re-render of the whole page" mean? $\endgroup$
    – LSpice
    Feb 23, 2021 at 13:28
  • $\begingroup$ If you think that exercising this with specific LaTeX in the main post would help, then I would be happy to do so. $\endgroup$
    – LSpice
    Feb 23, 2021 at 13:28
  • $\begingroup$ After an edit, if what you see is wrong, re-load the page. That fixes it. $\endgroup$ Feb 23, 2021 at 13:31
  • $\begingroup$ @‍GeraldEdgar, re-loading doesn't seem to fix mathoverflow.net/revisions/384561/2 . $\endgroup$
    – LSpice
    Feb 23, 2021 at 14:40
  • 1
    $\begingroup$ I think your oroginal solution is it: do not use * or ** as labels. (They are OK as tags.) I changed it to use labels not conflicting with markdown. $\endgroup$ Feb 23, 2021 at 15:26
  • $\begingroup$ That certainly fixes this specific problem, but it doesn't fix the problem of preview not matching rendered text, which was my complaint. In this case, since we're trying to reproduce the problem, I'm not sure what's gained by changing the labels so as not to reproduce it. $\endgroup$
    – LSpice
    Feb 27, 2021 at 14:05
  • $\begingroup$ As @AntonGeraschenko suggests, it seems that the problem is only exercised by a pair of asterisks in a paragraph, with some separation between them; e.g., by referencing the equation twice. Not \eqref{*} … $\endgroup$
    – LSpice
    Mar 4, 2021 at 19:23
  • $\begingroup$ … but \eqref{} and \eqref{}. $\endgroup$
    – LSpice
    Mar 4, 2021 at 19:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .