In T409110#11345836, @Tgr wrote:

See manageForeignResources.php and its make-cdx option.

Thank you, that was easy.

@FrederikHennecke1 do you have a test case for the a tag rewrite?

tmml has the same problem

They also do in latexml @Dginev

I looked at \grave{a} and was unable to identify the underlying problem. The generated MathML code is identical to the MathML code generated by mathoid. If I render the resulting MathML code with the interactive Mathjax demo from https://mathjax.github.io/MathJax-demos-web/input/tex2mml.html the result looks fine

The energy efficiency of the new version has improved, so does the code coverage.

We had https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/904098 as an attempt to update to v2 before see https://github.com/MarcelBolten/phpeggy/issues/3 for a discussion

Maybe it would be better to run automated visual regression tests, like we did for the last switch in 2016 https://ceur-ws.org/Vol-1785/W48.pdf

Mh, there are quite some differences (even though ChatGPT does not see them)

No comparing both versions (MathJax and SVG).
https://bafybeigbcvunkrgnokzlasd6mowyekxzz2vflzswdxpf646l2v3vrlde3u.ipfs.dweb.link/?filename=MathJax.png
(MathJax)
https://bafybeiehb2hkktebinzmxmxcgu3f7zywaywst4ndl46sroako7v5oob2wu.ipfs.dweb.link?filename=SVG.png
(SVG)

@Reedy could you please have a look at the proposed fix?

In the output it says

17:45:02 DEPRECATED: The tests/phpunit/phpunit.php entry point has been deprecated. Use
17:45:02             `composer phpunit` instead.

I believe if we can identify where this comes from, the problem can be fixed easily.

Here the trick was to replace docker-compose exec mediawiki composer phpunit:entrypoint -- ./extensions/Math/tests/phpunit/ with docker compose exec mediawiki /bin/bash -c 'export COMPOSER_PROCESS_TIMEOUT=3600 && composer phpunit -- ./extensions/Math/tests/phpunit/unit'
The underlying reason was if I remember correctly, that the order of test execution matters as not all service dependencies are explicitly modelled.

Eventually, I could reproduce the problem locally with a unit test and come up with a fix.

It feels like this errors of this kind are related to the load of the CI infra https://grafana.wikimedia.org/d/ad656c66-d8b5-4b09-a54b-61e7df71fb17/zuul-3a-3a-gearman-prometheus?orgId=1&from=2025-10-21T17:10:08.313Z&to=2025-10-21T18:06:04.777Z&timezone=utc Especially if multiple changes for the extension math are submitted together it seems that those fail often.

In theory yes, but $options['useintent'] will almost certainly be false.

The current page fails to render <math>P</math> and <math>Q</math>. This is hard to understand.

The questionable code is

		try {
			$warnings = [];
			$result = ( new TexVC() )->check( $this->inputTeX, $options, $warnings, $texifyMhchem );
		} catch ( Exception ) { // @codeCoverageIgnoreStart
			// This is impossible since errors are thrown only if the option debug would be set.
			$this->error = Message::newFromKey( 'math_failure' );
			return [];
			// @codeCoverageIgnoreEnd
		}
		if ( $result['status'] === '+' ) {
			$result['mathml'] = (string)$result['input']->toMMLtree();
			$out = [
				'status' => '+',
				'output' => $result['output'],
				'mathml' => $result['mathml']
			];
		} else {
			$out = [
				'status' => $result['status'],
				'error' => $result['error'],
			];

So for one or the other reason ( new TexVC() )->check(... seems to return something without a status. It is not obvious to me why that would be the case. So one option would be to break down that function which is a bit complex and ensure that it always has status (and error if status is not +.

Is there a chance to see which input TeX expression is causing this? 1 example would be very helpful.

@JeanCASPAR I think we currently have still too many open problems to switch to plain MathML directly, however, we can use MathJax for rendering MathML which gives quite nice results.

This generates

<mstyle displaystyle="true" scriptlevel="0">
  <mn>1</mn>
  <mo stretchy="false">+</mo>
  <mn>2</mn>
</mstyle>

I don't see any problem with that. @FrederikHennecke1 please reopen if required.

State of 25-10-16

I think there are quite a few cases where two symbols form one operator. However, let's better start with one
Temml generates

<math display="block" class="tml-display"><mrow><mi>i</mi><mo lspace="0.2222em" rspace="0em">:</mo><mo lspace="0em">=</mo><msub><mi>e</mi><mn>1</mn></msub><msub><mi>e</mi><mn>2</mn></msub></mrow></math>

LaTeXML generates

<math id="p1.1.m1.1" class="ltx_Math" alttext="i:=e_{1}e_{2}" display="inline"><semantics id="p1.1.m1.1a"><mrow id="p1.1.m1.1.1" xref="p1.1.m1.1.1.cmml"><mi id="p1.1.m1.1.1.2" xref="p1.1.m1.1.1.2.cmml">i</mi><mo id="p1.1.m1.1.1.1" xref="p1.1.m1.1.1.1.cmml">:=</mo><mrow id="p1.1.m1.1.1.3" xref="p1.1.m1.1.1.3.cmml"><msub id="p1.1.m1.1.1.3.2" xref="p1.1.m1.1.1.3.2.cmml"><mi id="p1.1.m1.1.1.3.2.2" xref="p1.1.m1.1.1.3.2.2.cmml">e</mi><mn id="p1.1.m1.1.1.3.2.3" xref="p1.1.m1.1.1.3.2.3.cmml">1</mn></msub><mo id="p1.1.m1.1.1.3.1" xref="p1.1.m1.1.1.3.1.cmml">⁢</mo><msub id="p1.1.m1.1.1.3.3" xref="p1.1.m1.1.1.3.3.cmml"><mi id="p1.1.m1.1.1.3.3.2" xref="p1.1.m1.1.1.3.3.2.cmml">e</mi><mn id="p1.1.m1.1.1.3.3.3" xref="p1.1.m1.1.1.3.3.3.cmml">2</mn></msub></mrow></mrow><annotation-xml encoding="MathML-Content" id="p1.1.m1.1b"><apply id="p1.1.m1.1.1.cmml" xref="p1.1.m1.1.1"><csymbol cd="latexml" id="p1.1.m1.1.1.1.cmml" xref="p1.1.m1.1.1.1">assign</csymbol><ci id="p1.1.m1.1.1.2.cmml" xref="p1.1.m1.1.1.2">𝑖</ci><apply id="p1.1.m1.1.1.3.cmml" xref="p1.1.m1.1.1.3"><times id="p1.1.m1.1.1.3.1.cmml" xref="p1.1.m1.1.1.3.1"></times><apply id="p1.1.m1.1.1.3.2.cmml" xref="p1.1.m1.1.1.3.2"><csymbol cd="ambiguous" id="p1.1.m1.1.1.3.2.1.cmml" xref="p1.1.m1.1.1.3.2">subscript</csymbol><ci id="p1.1.m1.1.1.3.2.2.cmml" xref="p1.1.m1.1.1.3.2.2">𝑒</ci><cn type="integer" id="p1.1.m1.1.1.3.2.3.cmml" xref="p1.1.m1.1.1.3.2.3">1</cn></apply><apply id="p1.1.m1.1.1.3.3.cmml" xref="p1.1.m1.1.1.3.3"><csymbol cd="ambiguous" id="p1.1.m1.1.1.3.3.1.cmml" xref="p1.1.m1.1.1.3.3">subscript</csymbol><ci id="p1.1.m1.1.1.3.3.2.cmml" xref="p1.1.m1.1.1.3.3.2">𝑒</ci><cn type="integer" id="p1.1.m1.1.1.3.3.3.cmml" xref="p1.1.m1.1.1.3.3.3">2</cn></apply></apply></apply></annotation-xml><annotation encoding="application/x-tex" id="p1.1.m1.1c">i:=e_{1}e_{2}</annotation><annotation encoding="application/x-llamapun" id="p1.1.m1.1d">italic_i := italic_e start_POSTSUBSCRIPT 1 end_POSTSUBSCRIPT italic_e start_POSTSUBSCRIPT 2 end_POSTSUBSCRIPT</annotation></semantics></math>

and mathoid generates

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block" alttext="i:=e_{1}e_{2}">
  <semantics>
    <mrow>
      <mi>i</mi>
      <mo>:=</mo>
      <msub>
        <mi>e</mi>
        <mrow class="MJX-TeXAtom-ORD">
          <mn>1</mn>
        </mrow>
      </msub>
      <msub>
        <mi>e</mi>
        <mrow class="MJX-TeXAtom-ORD">
          <mn>2</mn>
        </mrow>
      </msub>
    </mrow>
    <annotation encoding="application/x-tex">i:=e_{1}e_{2}</annotation>
  </semantics>
</math>

so this is a regression (compared to the mathoid codebase which was the basis for the native implementation).

Hopefully resolved, please reopen, if it's still in the logs.

Hopefully resolved, please reopen, if it's still in the logs.

In T375861#10261734, @Physikerwelt wrote:

I created this codepen with a minimal examples that shows that ...

We discussed that today in the MathML meeting and decided to implement that with explicit spaces.

It was not needed up to now I think. Maybe there would be a performance gain if we used a read onlyclass https://en.wikipedia.org/wiki/Immutable_object?wprov=sfti1#PHP so you can introduce it if needed but it is a bit nicer to avoid having that

@Wgevaert, yes please test if everything works as expected on the latest master. If everything works, follow https://www.mediawiki.org/wiki/Backporting_fixes if you need to have the fix in an old branch. I would only backport it to branches you specifically need.

I would hope this is fixed together with T406568

It seems we can end up in a situation where status is failed and error is not set.

Looking into that.

Thank you. That seems to better match my expectations. I'll try to run your github on my machine to see if I can match those values. In https://ceur-ws.org/Vol-1785/W48.pdf we show the rendering time over the input length (Fig. 3). I find that a bit more intuitive (but more complicated) than the median.

Interesting, did you verify that something is actually cached?

I am closing that there are currently no plans to fork from mhchemParser (https://github.com/mhchem/mhchemParser) besides supporting PHP instead of JS. We might want to contact @mhchem directly, or file an upstream bug report. I am happy to backport a fix to PHP, but I would not want to have the ce command behave differently in MathJax/KaTeX and wikitexvc.

It's the same behaviour upstream. So I'm not trying to fix it.

it seems to be a problem in our translation of https://github.com/mhchem/mhchemParser (or in the upstream library). In the end, the generated standard LaTeX string for the second example is

<math chem>\ce{ [L_\mathit{n} M] }</math> works

<math chem>\ce{ {[L_\mathit{n} M]} }</math> does not
<math chem>\ce{ {[L_{\mathit{n}} M]} }</math> works

In T401623#11199076, @Dexxor wrote:

On dewiki, it's common to use {,} as decimal seperator, e.g. 3{,}14. Support for that would be nice as well.

Ok, it works in TeX. However, it does not seem to make a difference for either mathoid, Temml, or LaTeXML if curly braces are used or not.