Discuss bugs in itex2MML.

(Repost from the other discussion as this looks bug-like to me.)

Okay, let’s try this here. Compare and contrast:

How it ought to look:

With a \displaystyle at the start. In LaTeX, this is to ensure that the subscript to \lim is underset.

Now with a bit of grouping to help.

Somehow, the <mstyle displaystyle="true"> is getting inside the \lim processing, turning the <munder> in to a <msub>.

It’s a matter of the precedence rules that you expect not being respected by itex2MML

 \lim_{n\to 0}

is set with an <munder>. But, when you type

\displaystyle \lim_{n\to 0}

the precedence of the ”_” is not treated as being higher. The above is treated as equivalent to

{ \displaystyle \lim }_{n\to 0}

which is set with an <msub>. Putting in the grouping explicitly:

\displaystyle { \lim_{n\to 0} }

gives you what you were expecting.

I think this is confusing. Probably, you were expecting \displaystyle to behave more like \color{red} does (compare the definitions of COLOR and of DISPLAY, respectively, in itex2MML.y).

Update:

Let’s see: ${\displaystyle \underset{n\to 0}{\lim }\frac{1}{n}=0}$

Yup. itex2MML 1.4.8 works as you’d expect.

Once again: thank you very much!

The optional argument syntax for extensible arrows doesn’t swallow spaces correctly. If I type \xrightarrow [a]{b} then in LaTeX, this is equivalent to \xrightarrow[a]{b} because spaces are automatically swallowed after commands. However, in iTeX then they are not equivalent:

Thanks.

This looks like a bug in how Firefox renders MathML, but I thought I’d check with you first. How do $\hat{\otimes }$ and ${\displaystyle \hat{\otimes }}$ look to you? To me, the first has the hat offset to the right. I presume that it shouldn’t be so.

Correct.

The accents work correctly when accenting an <mi> (see this old bug), but not when accenting an <mo>, unless the style is displaystyle.

Thus:

You should file a bug report.

Done

(My word, but that’s a complicated form. “What did you do?” I looked at a MathML web page. “What happened?” It didn’t look right. “What should have happened?” It should have looked right.)

‘Cept it’s not a Firefox bug; it’s a Gecko Core (MathML Component) bug. As filed, no one relevant will see it. If you, as the Reporter of the bug, can reclassify it, maybe it will have a fighting chance of getting some attention.

Seems that I can so I have.

According to Frédéric, it’s a feature, not a bug. I could change \widehat{} (and its cousins) to wrap their output in an <mstyle displaystyle='true'>, but that might have unintended side-effects.

I notice that Frederic has now closed this and says that the correct way to handle them is with movablelimits="false". So that makes this now an itex bug again!

Identifiers lumped together in MathML output

Example: $X_ab$ produces output $X_{\mathrm{ab}}$ <msub><mi>X</mi> <mi>ab</mi></msub>

Output should be more or less $X_{a}b$ <math><msub><mi>X</mi> <mi>a</mi></msub><mi>b</mi></math>

Two things wrong with this: first the “b” would never be subscripted in LaTex, and second, two variables should not be lumped in the same <mi></mi> element because this causes MathML to set them in upright rather than italic type. So each variable really needs to be in its own <mi></mi>

That’s a “feature”, not a bug.

As described here, $ab$ is a single token in itex (tranlated to <mi>ab</mi>); $a b$ are two tokens (translated to <mi>a</mi><mi>b</mi>). MathML is semantically-richer than (La)TeX, and this convention gives you the ability to enter multi-character tokens, which will be interpreted as such, when translated to MathML.

Good enough then and thank you. I thought $X_a b$ was producing an unacceptable space, but that was just a Firefox peculiarity.

From what I’ve seen, many of these issues come from the differences between how LaTeX interprets expressions and how MathML parsers implement them. Even when the generated MathML is technically valid, browser rendering can still produce inconsistent results depending on the engine.

Wrapping expressions explicitly or adding grouping often seems to be the safest workaround when parser precedence is ambiguous. It’s not always ideal, but it does make the output more predictable across different environments.

If anyone is looking for additional resources or related web tools, you can find more information here.