Let's stick to the plan, it's already implemented with curlies now.

Ok, I added the flag for adding curly for mkern and mskip for mhchem in the current implementation, seems to work.

Please specify required format upfront, this saves lots of time
Here the parameters extracted from the file. Statements without arrow don't have additional parameters.

Yes, I sent you file for this. This file can be also be (re)generated locally with a JsonToMathML maintenance script for now in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/923597/89

@Aklapper yes, I do

Hello @mhchem, I just wanted to inform you that I am currently working on a port of mhChemparser in typescript to PHP. I would be happy to get some help from you if you're interested. Let me know if you're available, and we can figure out the details on how we can collaborate on this.

I think when working in debugger with the codebase (speaking for TexVC-PHP which is similar atm) then it is fine to have the curly element when viewing the parsetrees. TexArray with a property could obfuscate things in this matter.

About the nested chem formulas:

Hello @mhchem, thanks for your help.

Statistical analysis from EnWikiFormulaeTest for the distribution of resolved mappings in BaseMethods::checkAndParse :

Notes in analyzing profile output for "MMLFullCoverageTestLocal.php":
~ encapsulate and encapsulateRaw work a bit differently locally.

Mapping QID to Math element needs resolution of items within tex see this paper

sideset can be realized with multiscript, not use mathoid reference

In T327391#8644227, @Physikerwelt wrote:

In T327391#8644214, @Stegmujo wrote:

However, solution draft can somewhere be saved here and then re-used or grammar adapted: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/889281

Did you test if tests (enwikiformulae) fail? I would expect that there is quite a significant amount of cases...

In T327391#8644129, @Physikerwelt wrote:

1. Re: Case 2

In T327391#8644080, @Physikerwelt wrote:

Re: Case by case check 1: " color-cases"

Case by case check 4: "limits-case"

Case by case check 3: "sideset"

Case by case check 2: "non-squashed literals case"

TC-Index is always related to index in "MMLGenerationTexUtilTestLocal.php"

Algorithm implemented for this one, is now for automated testing. Scientific algorithm will move to another task.

MathCAT:

• https://nsoiffer.github.io/MathCATDemo/, (which is up to date with github: 0.1.24) its implemented intent rules can be found here
• A quick check on the demo, shows that intent is read, but attributes seem not to be mapped:
• The point-example from below translated to text as: the point $1 comma $2
• Further examples of MathML with intent (Source):
  • Line segment example: "the line segment from $1 to $2"
  • X-coordinate example (~with correcting typo </mi>): "coordinate of <break time='150ms'/> $1 comma $2"

Collection of Information sources to realize a comparison algorithm:

Done for now, still the test (as some other tests) will need a comparison algorithm to make in-depth comparison of generated MathML and reference MathML.

For creating the mathml again, the MathSearch extension can be used. The Tex is in difference to FullCoverage-Wikitext the input tex is defined in JSON mostly, ParserTest135.json and TexUtilMMLLookup.json can be used to generation in a new maintenance script in MathSearch-extension .

In T327386#8549116, @Stegmujo wrote:

for mathoid generation:
$wgMathoidCli = -> see MediaWikiPage for that.

for mathoid generation:
$wgMathoidCli = .... /mathoid/cli.js

→ It shows how to annotate terms within a formula with other Wikidata-Concepts. Not directly clear how to add intents.

In addition to the current findings regarding semantics and annotation, LaTeXML and Mathoid seem to render some chars differently to current TexVC(PHP). The differently notated chars are not correctly displayed by browser-rendering (checked with Firefox):

MySQL database retrieval results for LaTeXML example entry of one formula:

Some notes: