Minutes: MathML full meeting, 27 Oct, 2022

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Deyan Ginev
   - Dennis Müller
   - Bruce Miller
   - Johannes Stegmüller
   - Steve Noble
   - Moritz Schubotz
   - Cary Supalo
   - David Farmer
   - Paul Libbrecht
   - Deyan Ginev
   - Sam Dooley
   - Bert Bos

<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc1#cp-md-0-regrets>
Regrets

Murray Sargent
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

MOS: introduced his guest Johannes Stegmuller (JS).

We introduced ourselves to JS.

JS: I'm quite new to the accessibility environment. I'm working actively on
the implementation of media wiki components for accessibility.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc1#cp-md-0-2-more-discussion-on-a-href-https-github-com-w3c-mathml-issues-260-converting-tex-expressions-to-mathml-core-expressions-a->2.
More discussion on converting TeX expressions to MathML core expressions?
<https://github.com/w3c/mathml/issues/260>

MOS: There are many translation tools from TeX to MathML. It is not
entirely clear how conceptually these translation tools work. It would be
good if we don't make the same mistakes that everybody else already did. We
should have some agreement on the best way to proceed before we start.

NS: wants to see standardization of what kind of MathML gets generated.
This would help his effort to produce accessible output. But, on the other
hand, with intent, he is not sure it matters that much.

DC: Adobe has funded a multi-year project to make tags so that people will
get better pdf documents from LaTeX documents.

DG: One of the reasons that MathML is not standard yet is that the
translation problem is not solved. DG discussed subscripts and superscripts
and the various orders in which these expressions are verbalized. The order
of verbalization might depend if the material came from presentation or
content sources. These two sources might emphasize different things.
Someone will have to decide how expressions are spoken, and it might be
necessary to have a large group make these decisions.

DC: It might not matter much about which choice you make.

NS: Discussed how many symbols a raised bar should cover in a math
expression and would this change the accessible output.

JS: It would be useful to collect some of these cases into a document that
could be used to start writing a standard. This document could show all the
variations that are currently used.

NS: Looks on the web for ways people write things before he makes his own
choice for what his software should do. It is useful for someone to say
that this is a good way to do it.

NS: does not think it is possible to get 100% agreement, especially if
someone else has tried something else and has not had problems with it.

DG: agrees that collecting examples is useful. It will help us know when we
can standardize.

NS: discussed nesting sub and superscript expressions which might change
the appearance of things.

MOS: Liked the implementation guide from Frederick, which specified what
developers should implement. Mos would like a guide to convert LaTeX into
MathML, but he does not know how big it would be.

BM: We are having two discussions. 1. Design a set of semantic macros that
would assist in generating accessibility to produce the best layout. This
would require a large community. Second question: just given basic TeX,
what is the best MathML to generate from it.

NS: has suggested that it really does not matter. What is the question that
we want to address?

NS: Are you looking at just plain TeX to MathML or are you thinking about
these more semantic markups?

MOS: As the first step, we want a standard type of TeX to convert into
MathML. Step two is to add new macros that could generate intent which
would be translated into MathML. Not everything would be annotated with
intent.

DC: Look at MathML core, there are not that many constructs. Like a dozen
things. Write down enough TeX to generate MathML core. No trig functions in
MathML core. This would be a start. write down the MathML core and its
corresponding TeX syntax.

DG: I am very fond of the idea of starting simple but I don't think we
should start simple alone, because we would just create another vendor.

DG: So we're talking about a media language that looks like TeX but does
not have certain Macros or any Macros, and you would see another project
that is just like KaTeX or MathJAX which defines this limited, fixed
syntax. So the only useful instantiation of this for me is, if all of those
vendors already did it, let us get together and find one standard way of
doing translation; otherwise, you just create another vendor.

DG: wants us to involve the MathJAX and KTeX teams.

JS: Somebody should start to formalize the standard or, at least, start
writing down cases. Is there any programming independent language to
translate from TeX to MathML?

NS: Are you saying to just right down the mapping from TeX to MathML?

NS: Are you thinking about a pseudo code to do the mapping?

NS: Do we know where MathJAX and KaTeX differ in their outputs?

DG: It is unclear what falls in and out of this project.

MOS: is looking at LaTeX and MathJAX to see where they differ. There was
nothing major in the differences.

PL: Thus far LaTeXML implementors are the only TeX-to-MathML implementers
who are involved. Perhaps we should bring MathJAX people into our
discussions? NS has tried to do this.

BM: We need to focus on what the question is. If we talk about the syntax
tree design, MathML gives you two choices already. We have a presentation
tree and a content tree. It is a design question of your system. What tree
is going to connect both the structure and the information that you need.

There is not a table saying this is the TeX and this is the corresponding
MathML. We have some recommendations about this. This information is
scattered through the spec.

DC: We want a small amount of TeX syntax to map to MathML in some
documented way. Later we can work with arbitrary input.

DG: How do we avoid making other people's mistakes? Standardizing may solve
this. If you want to learn from arbitrary tech you have a massive
documentation step. The quickest thing we can do is to collect examples and
get people together.

NS: Should we make sure that these already existing TeX macros are
supported?

DG: Yes, I would start there just to see what is in one example.

BM: We need to decide what the question is. Should we be dealing with the
entire document, or just isolated math expressions?

NS: MOS and JS, what should we be thinking about?

MOS: BM brought up that we should put a lot of effort into our tree, which
we use to represent the expression we want to convert into MathML. The
second part was to annotate the generated mathematics with intent. This
would be more difficult.

JS: Thanks for the discussion.

NS: wishes the MathJAX and KaTeX people would join us occasionally.
Appreciates Wikimedia participation.

NS: We will return to the question of what goes into the table of intents.
If people want to discuss other things, please let NS know.

DC sent this link: zauguin/luamml: Automatically generate MathML
equivalents for math expressions in LuaLaTeX
<https://github.com/zauguin/luamml>