`DeclareMathOperator` spacing

[Lordfirespeed]

Issue Summary

Operators declared using DeclareMathOperator* don't have the correct spacing around them when subscripts or superscripts are applied to them.

Steps to Reproduce:

Code:

\DeclareMathOperator*{\argmax}{arg\,max}
\DeclareMathOperator*{\argmin}{arg\,min}

\begin{gather}
)\min_{x}()\\
)\argmin_{x}() \\ \\
z\min_{x}y \\
z\argmin_{x}y
\end{gather}

Actual result:

the mjx-munder element corresponding to arg min is missing the space="2" attribute which is present on the element corresponding to min.

The mjx-mi element corresponding to y is missing the space="2" attribute when it follows arg min which is present when it follows min.

Expected result:

Technical details:

• MathJax Version: 3.2.2
• Client OS: KDE Neon User Edition (Ubuntu noble 24.04)
• Browser: Obsidian 1.9.14 (Electron 37.3.1, Chrome 138.0.7204.235)

Supporting information

Interestingly, when the sub/superscripts are removed, the example behaves as expected.

[dpvc]

Thanks for the report. I'm looking into it. For now, you can work around it by using

\DeclareMathOperator*{\argmax}{{arg\,max}}
\DeclareMathOperator*{\argmin}{{arg\,min}}

using an extra set of braces.

[dpvc]

No. I'm wrong the braces don't help. I was sure it was working a few minutes ago, but now it isn't working. I must have not been testing it correctly. Sorry!

[dpvc]

I have figured out the issue and will make a PR to fix the problem. It is actually two related issues, one where the TeX class of the operator isn't being properly set when there is a subscript (that is causing the spacing problem), and one where the classes of the parts within the operator are being incorrectly set to be operators themselves (leading to excessive space at the \,). The PR will fix both, but in the meantime, you can use the following configuration to work around these problems.

MathJax = {
  startup: {
    ready() {
      const {AbstractMmlBaseNode} = MathJax._.core.MmlTree.MmlNode;
      Object.assign( AbstractMmlBaseNode.prototype, {
        _setTeXclass_: AbstractMmlBaseNode.prototype.setTeXclass,
        setTeXclass(prev) {
          const result = this._setTeXclass_(prev);
          const base = this.childNodes[0];
          if (base.isKind('TeXAtom')) {
            this.texClass = base.texClass;
          }
          return result;
        },
      });
      const TexParser = MathJax._.input.tex.TexParser.default;
      Object.assign(TexParser.prototype, {
        _Parse_: TexParser.prototype.Parse,
        Parse() {
          if (this.stack.env.operatorLetters) {
             this.stack.env.noAutoOP = true;
          }
          this._Parse_();
        },
        _mml_: TexParser.prototype.mml,
        mml() {
          const mml = this._mml_();
          if (this.stack.env.noAutoOP && mml.isKind('mi')) {
            mml.removeProperty('autoOP');
          }
          return mml;
        }
      });
      MathJax.startup.defaultReady();
    }
  }
};

[Lordfirespeed]

@dpvc since pull/1367 was merged, shall we close this (and/or add the Merged tag)? - i'm not sure what the convention is for this repository!

[Lordfirespeed]

On a related note - will MathJax continue to release versions on the v3 release line, or has v4 become the sole supported release? if v3 is still supported, might some features/bugfixes (like this one) be backported? is there a standard process for that?

[dpvc]

shall we close this

No, I keep them open until the version is released.

or add the Merged tag

OOPS, I should have done that when it was merged. Sorry!

will MathJax continue to release versions on the v3 release line

Probably, but infrequently. There are some things that can be back-ported, but I'm not sure how much of the will be done, or when. Since v4 is largely compatible with v3, I don't know w strong reason to remain with v3, especially once the next release is made the cleans up the issues that have arisen with v4.