Re: unrecognised entities & mathvariant

Hi Thierry,

> ... Hence I'd be inclined to opt for the mid
> one, thinking that, at least an S would be shown in any context.
>
> But currently, though the 3 versions are equivalent in MP 2.1, only
> the first one displays the right glyph in mozilla 2.0. Are there plans
> to support other math-variants that the 4 basic weights in mozilla?

Yes, I think S with mathvariant="fraktur" is the best approach.

As to why it's not displaying in Mozilla: try adding a snippet to the
CSS sheet linked to your MathML, something like

     [mathvariant="script"] {
       font-family: "Euclid Math One", serif;
     }
     [mathvariant="fraktur"] {
       font-family: "Euclid Fraktur", serif;
     }
     [mathvariant="double-struck"] {
       font-family: "Euclid Math Two", serif;
     }

Also FOR NOW in document markup I'm using the following constructions
that supply colors so that when the mathvariant fails, as it will for
some readers, one at least sees a color distinction:

<mi mathvariant="double-struck" mathcolor="#b00">
<mi mathvariant="script" mathcolor="#00e">
<mi mathvariant="fraktur" mathcolor="#0b0">

> 2. the MathML DTD defines quite many entities and aliases. I would
> expect that a MathML aware tool would treat any alias as equivalent.
> this is not the case with current mozilla. For instance, hbar and
> emptyset are unknown to mozilla, while hslash and empty are: is this a
> bug or a feature and, in any case, where is the info why some of them
> are supported and who they are? (my feeling is that the official ISO
> name is implemented, and aliases, even part of the mathml DTD, are
> left apart: right ? --but is this mathml support?)

There's been controversy about the extent to which named CDATA
entities are to be supported.  I think the most conservative approach
for reaching the widest audience is not to use names but rather use
numeric U-value CDATA entities such as "&#x00E9;".  In particular,
there are browsing agents handling "&#x00E9;" properly that, at least
in some locales, will not properly recognize the character itself in
the UTF-8 or UTF-16 text encodings.

Cheers.

                                    -- Bill