Remove/Deprecate mglyph element

[fred-wang]

Currently this is not defined in MathML Core, only MathML 4.

• I think the need for custom glyph is already covered with modern HTML5 technologies by using web fonts and "Private Use Areas".
• If people want to use image, they can embed an HTML img tag into an mtext.

In any case, I think the idea of mglyph is a rather hacky temporary workaround. Ideally, people use characters defined in Unicode. These days, they should have enough characters available to write math.

[physikerwelt]

discussed in the telco on 2019-02-25:

• patrick ion points out that generating new glyphs is something which is used heavily in mathematics, .e.g, in knot theory.
• embedding HTML would be a more powerful option and superseded the mglyph functionality

[pdfion]

There was apparently a technology proposed for CJK gaiji that would do just fine for supplemental math characters: SING and replace . I have no idea if this is viewed as a current technology. Anyone know?
References:

• https://en.wikipedia.org/wiki/OpenType#SING_gaiji_solution
  ** The SING (Smart INdependent Glyphlets)[81][82] technology that made its debut with Adobe's Creative Suite 2 allows for the creation of glyphs, each packaged as a standalone font, after a fashion. Such a packaged glyph is called a glyphlet. The format, which Adobe has made public, is based on OpenType.
• SING: Adobe’s New Gaiji Architecture,Jim DeLaHunt (2004) | http://partners.adobe.com/public/developer/en/opentype/SING_Intro_IUC26.pdf

[pdfion]

That should read SING could replace mglyph.

[fred-wang]

@pdfion Thanks for the information. I think someone should investigate more, maybe contact people from CSS / Font WG to see if that's the kind of features already available in browsers ( https://drafts.csswg.org/css-fonts-3/ ). In any case, that aligns with the idea that this is something that has to be provided by CSS/font so we should just rely on it instead of defining our own feature in MathML.

(PS: I've fixed the formatting in your comment)

[dani31415]

While it is somehow acceptable that MathML4 is MathML3 + CSS - deprecation of attributes, if we remove the mglyph, we loss the capability of inserting images in MathML (for the case that the MathML is not part of an HTML 5).

I suggested Stand-alone MathML profile #58. Just in case we forgot that MathML should also exist outside web pages.

Maybe you are referring to MathML core. In which case the issue should be relaveled to core.

[NSoiffer]

@dani31415: is WIRIS using mglyph? If so, can you elaborate on the use case?

[davidcarlisle]

@dani31415 I agree that we should ensure that mathml is usable in non css environments and that this means we should keep elements such as mglyph in full (not core) unless there is an alternative available.

[fred-wang]

I'm interested in removing it from core (it is already not present, but just to confirm). Then I'll let others decide what to do in other specs, whether to write a polyfill etc

[fred-wang]

From https://lists.w3.org/Archives/Public/public-mathml4/2019Mar/0026.html
We decided to keep in full. We should experiment with polyfill to see if we can remove it from core.

For now, nobody reported any use of mglyph in #55

[davidcarlisle]

I think mglyh should definitely be in full (despite the unfortunate "mglyph" name denoting its original motivation) it's needed for image inclusion on non html contexts.

But I agree it can go from core (and so the references to it in html5 can go as well).

[NSoiffer]

This was discussed in the Core CG meeting today.

• @bkardell suggested a different solution would be to add img to full with all of imgs attrs. Then nothing would need to be done for implementations and full support of img would happen automatically as it is legal HTML in leaf elements.
• mglyph is not a complete subset of img because of valign and mathbackground, so that idea isn't a perfect replacement, but CSS could be used for them. CSS is not good in non-web contexts though.

After the call, @bkardell noted that neither Firefox nor Safari support mglyph.

In #55, no one reports using it.

Given non-support and minuscule(?) usage, I don't see a reason to move toward adding img to full nor to support in core. A polyfill is pretty easy to do.

The CG agreed to come back to this next week and see if anyone comes up with other info.

[dginev]

Adding an example, and a mention of <svg>:

In the TeX-authoring paradigm, authors sometimes interleave diagram code with equation code. For those inputs, tools such as latexml and tex4ht can at times attempt to map both math syntax and diagram syntax into transparent textual formats. Namely, by generating interleaved MathML+SVG (with possibly nested SVG+MathML, and vice versa).

latexml's current preference is to generate an <mtext><svg>...</svg></mtext> for such cases, with the SVG content deposited inline.

That is probably "good enough", but not particularly "clean" in the Presentation MathML sense, as indeed sometimes we have clear indications from the authors that the SVG content stands for an <mi> identifier or an <mo> operator. Here are 4 example screenshots from an arXiv article, for some illustration.

I am uncertain if <mglyph> offers an advantage to <mtext> in theory, but I thought to at least bring an example where we use <svg> directly inline. I am bringing this up today because latexml development refocused on this particular kind of content this week, and I recalled the mglyph discussion here.

We could likely reorganize to use <img src="name.svg"> instead, if need be. The main subtlety I see for that transition is managing href targets to point to an external URL rather than the local document. Why? Think of arrows annotated with a link to the theorem they use for the implied transition (see MathML in the details, but such links can also occur from within SVG diagrams).

<svg>
  <!-- ... diagram code ... -->
  <foreignObject>
    <math>
      <mover>
        <mo>⇒</mo>
        <mtext>
          <a href="#mytheorem">Thm 2.3</a>
        </mtext>
      </mover>
  <!-- ... further math and diagram code ... -->    
</svg>

Edit: To make my comment mildly more forward-facing, maybe the point I would bring up for consideration is that if a change is made to allow <img> inside token elements (notably <mi> and <mo>), that we may also consider allowing <svg> as well.

[davidcarlisle]

For your final "Edit" note, in mathml-in-html <img and <svg are already allowed in <mi> (by the spec and the parser, although some validators chose to flag token elements other than mtext) so no change should be necessary.

The main justification for <mglyph as for <maction, is systems supporting MathML but not HTML, as it gives a "native" MathML way to reference an image.

[NSoiffer]

Deprecating mglyph was discussed at the 5-9-2024 meeting. The main points were:

• mglyph is not implemented in any browser and is ignored by MathJax
• In a web context, mglyph and img are almost identical
• Outside of the web context, img might be something else [ed: I realized after the meeting, that's not true because img is part of the HTML namespace, so theoretically it can't mean something else; practically, it rarely has a namespace specified]
• Outside of the web context, a schema is needed to specify what is allowed inside of MathML leaf elements.

We had a straw poll: 4 people were in favor of deprecating it; 2 people were neutral.

[NSoiffer]

At the 12-9-2024 meeting, there was not consensus to deprecate or remove mglyph. @davidcarlisle felt that because MS Office uses it (on input, it only uses the alt text and its not clear that it generates it), he felt it would be bad to break office/word's implementation even though it is not used in the web context. @MurrayIII was also on the fence. @davidcarlisle also felt that, like maction, it provides a neutral target for images that can be mapped to other tags in whatever environment contains the math.

The conclusion was to add some text to discourage its use and suggest using img instead if targeting the web.

This issue can be closed once that text is added.