Re: Opinions wanted: deprecate mglyph from MathML 4 (full) spec?

Deyan,

Thanks for the pointers to JATS and for the example. It does look like
JATS's <private-char> is similar to <mglyph>, but differs in that the *child
*either directly or indirectly provides the data for drawing whereas
<mglyph> uses an attr for indirect reference.

I looked at MathJaX and they verify that mglpyh input is correct
(appropriate attrs). However, they skip over it when getting leaf content
(core/MmlTree/MmlNode.ts:getText()). In the HTML generation code (vs SVG),
it looks like they use <img>.

I believe that anywhere <mglyph> can be used now, <img> can replace it. So
I think essentially renaming "mglyph" to "img" will work everywhere and
that for those processors looking for "mglpyh", they can more or less
change to searching for "img" if we get rid of "mglyph" and say to use
"img" instead. The "less" part of "more or less" is that one can put
arbitrary html inside of leaves, so <img> may turn up in other places that
<mglyph> is illegal. If we deprecate <mglyph> we can suggest this
replacement and also suggest looking for <img> along with textual content
when looking to display the content in contexts where support for HTML is
not available.

    Neil


On Wed, Sep 4, 2024 at 2:47 PM Deyan Ginev <deyan.ginev@gmail.com> wrote:

> Hi Neil, all,
>
> To my reading, this is an obvious situation for MathML Core, which has the
> Web Platform available at all times.
>
> For MathML Full, it would be nice to have more transparency about which
> non-web use cases MathML 4 is trying to enable. Are they in circumstances
> such as JATS+MathML and PDF+MathML, where CSS and <img> tags are not
> available?
>
> JATS may be a good example. If I recall this is the classic challenge: if
> an external XML vocabulary decides to fully *delegate* math syntax to
> MathML, then MathML itself needs to provide the *entire* tag suite to
> capture the necessary scope of representation. In consequence, this leads
> to a necessary conflict with "mixed" context uses, such as HTML+MathML,
> where tags are allowed to intermingle.
>
> JATS also has a similar vehicle to <mglyph> which they could reach
> for, called <private-char>:
>
> https://jats.nlm.nih.gov/archiving/tag-library/1.3/element/private-char.html
>
> LaTeXML is not currently emitting <mglyph>, but I am quite certain custom
> glyphs are used in arXiv and emitted as images in today's HTML. For a
> dramatic example, one can examine Sections 4 and 5 of hep-th/0508154:
>
> https://ar5iv.labs.arxiv.org/html/hep-th/0508154#S4.Ex15
>
> So I would claim the need for representing these custom glyph constructs
> is real, if rare. I wonder if asking the JATS group for an opinion on
> <mglyph> would be a constructive attempt at outreach.
>
> Greetings,
> Deyan
>
> On Wed, Sep 4, 2024 at 3:40 PM Neil Soiffer <soiffer@alum.mit.edu> wrote:
>
>> At the last Math WG meeting, there was some discussion of potentially
>> deprecating <mglyph/> from MathML full. It is not part of core. For
>> browser-based implementations, embedding <img/> inside of a leaf element is
>> an alternative to <mglpyh>.
>>
>> According to this MDN page
>> <https://devdoc.net/web/developer.mozilla.org/en-US/docs/Web/MathML/Element/mglyph.html>,
>> <mglpyh> is not implemented in any browser. I wrote a codepen
>> <https://codepen.io/nms/pen/GRbwxzR> and verified this is true for
>> Chrome and Firefox.
>>
>> If you oppose deprecating <mglpyh>, please reply and state your reasons
>> for continuing to keep it in the MathML 4 spec.
>>
>>