clarify pseudoscript handling

[NSoiffer]

Some fonts have characters like prime (U+2032) in a large font meant to be raised and others in a smaller "pre-raised" position.
The spec doesn't say anything about what should be done for these. Switching fonts should not result in a need to recode the MathML.

Also, although it mentions a lot of chars that should be considered pseudoscripts, most only are in a "superscript" position (eg., quotes, the superscripted numbers). Should renders have a special check inside msup/msubsup? Should there be a remapping for these cases? E.g, superscripted numbers -> regular numbers?

[davidcarlisle]

mathml3 says

Note this means that a renderer of MathML will have to treat pseudo-scripts differently from most other character codes it finds in a superscript position; in most fonts, the glyphs for pseudo-scripts are already shrunk and raised from the baseline.

I think that this makes it clear that the input should use msup as if the font had a large prime, and if the font actually has a small raised glyph it should adjust the rendering as far as possible.

[NSoiffer]

Apparently the MathJaX implementers either didn't see it or simply think it is wrong. MathJaX doesn't follow this rule. I filed a bug report that they don't agree with.

[brucemiller]

It sounds to me as if the MathJaX folks weren't so much disagreeing, as they ware saying they didn't currently have all the right glyphs in their fonts; that they'd fix it when they could.

[NSoiffer]

There will never be "right" glyphs (large version) of most of the pseduo-characters since they aren't really meant for math. E.g., the superscripted digits (e.g, U+00B2). The text @davidcarlisle pointed out says to display engines basically "deal with it".

[dpvc]

Apparently the MathJaX implementers either didn't see it or simply think it is wrong.

You are wrong on both counts, here. I saw it, and am fine with it, but @brucemiller is right, I can't implement it with the current fonts in use in MathJax. They are being updated, and the issue will be resolved for MathJax when that happens.

MathJax is still using the fonts I originally made for v1 more than a decade ago, before I knew all the ways MathJax was going to be used in the intervening years, and when I had only a passing understanding of the details of Unicode. I made some assumptions that turned out to be poor in hindsight.

MathJaX doesn't follow this rule. I filed a bug report that they don't agree with.

Again, you mischaracterize my response to you there. My comment did not indicate disagreement, but was simply an explanation of the current situation in MathJax. Indeed, it pointed out that we are already prepared to "deal with it", as you say, once I update the fonts. I do not see how this implies "disagreeing" with you.

There will never be "right" glyphs (large version) of most of the pseudo-characters

A number of modern fonts include alternate forms for use in superscripts and subscripts (not just for pseudo-scripts, but also for many other characters), for example, the STIX2 fonts and the AMS gyre fonts do this. So, for instance, the prime (U+2032) will be small and raised in the main variant, but larger and un-raised in the superscript variant (these are in the same font, and accessed via "font features"). MathJax can take advantage of that as it maps the characters it uses to the glyphs in the fonts. The current MathJax fonts don't have that (it wasn't widely supported 10 years ago), which is why I say support for this has to wait for the font update.

[fred-wang]

As a reminder, the idea of MathML Core (and its predecessor MathML in HTML5) has always been to follow what is done in Microsoft Word (and modern TeX engines or Firefox), that is rely on the ssty open type feature to perform the "deal with it" part (effectively delegating the choice to the font designers): w3c/mathml-core#135

However, we decided to move this to level 2 ( w3c/mathml-core#135 ) and there is no plan to implement it in Chromium before shipping the initial support.

Also, as discussed elsewhere, I don't think MathML Core should do something special for fonts that don't rely on OpenType math features.

[NSoiffer]

Same as #247