Add text to describe what should happen when not using an OpenType font

[NSoiffer]

The algorithms in the spec are written assuming that one has an OpenType font. This is related to #116, which is about fallback layout params in the tables. However, that doesn't cover (at least) two other cases:

1. What to do about stretchy chars.
2. Fallback order to find fonts when chars are missing (particularly for pieces of stretchy chars)

Some (many) fonts will lack stretchy chars or if they have them, something other than the (not defined for the font) OpenType tables need to be used or a font fallback is needed.

CSS defines how font fallback works, including at a character level. Because of the needs of math, perhaps we need to specify some that some additional OpenType with math table fonts should be added to the fallback list by the renderer.

[fred-wang]

1. What to do about stretchy chars.

Use of a generic Unicode table is mentioned: https://mathml-refresh.github.io/mathml-core/#unicode-based-glyph-assemblies

I don't think we should include anything for specific fonts that don't have a MATH table. Only Firefox has some hardcoded tables e.g. for old STIX versions but the plan is to remove them so it seems a wrong move to define them in the spec. We could also use a scale transform like Firefox, which allow to stretch things if people are happy with a poor rendering.

2. Fallback order to find fonts when chars are missing (particularly for pieces of stretchy chars)

This is w3c/mathml#37 ; unfortunately I don't think browsers have a standard way to handle fallback fonts in CSS. I was considering even introducing some "font-family: math;" (similar to 'monospace') to define that list.

[NSoiffer]

I suppose it could be useful to implementers to have glyph assemblies listed in the spec, but my guess is that Unicode lists them somewhere, so pointing to that reference would be better (assuming it exists). The bigger problem is that many? most? fonts don't contain these pieces and don't have math tables. So the spec needs to say what should happen.

I missed that w3c/mathml#37 existed. That raises some good issues. It looks like something was implemented with regards to this idea, but it doesn't seem to address the font family matching issue raised in w3c/mathml#37 (is that an issue with the implementation?).

I do feel the spec should say something about fallbacks for characters, potentially saying that the implementation should add fonts to the font-family list (although maybe not saying which fonts). For stretchy chars, adding a step that follows your suggestion to use a scale-transform when the character can not be located seems like something that should be specified. Having tests for that case also seems appropriate.

[fred-wang]

As I mentioned in https://github.com/mathml-refresh/mathml/issues/69#issuecomment-631937612 I don't think this is something we want for a first version of core