RE: Last Call Working Draft of MathML 2.0, 2nd edition published

Robert Miner [mailto:RobertM@dessci.com] wrote on 05 May 2003 16:53:
> Hi.
> 
> > In a recent discussion with publishing colleagues the 
> following question
> > came up: What is the meaning of 
> > 
> > <mi mathvariant="bold">&#x1D538;</mi>
> > 
> > Is it at all allowed? If the answer is clear, then maybe 
> the explanation in
> > the spec should be expanded to include it. Or is it not 
> possible to give a
> > definite answer in the current version of MathML?
> 
> My opinion is that it's allowed, but not meaningful, and probably
> shouldn't have any effect on rendering.  The relevant paragraphs from
> section 3.2.2 of the spec that I base this on is:
> 
>    "A issue arises in that the natural interpretations of the 
> mathvariant
>    attribute values only make sense for certain characters. 
> For example,
>    there is no clear cut rendering for a 'fraktur' alpha, or a 'bold
>    italic' Kanji character. In general, the only cases that 
> have a clear
>    interpretation are exactly the ones that correspond to SMP Math
>    Alphanumeric Symbol characters.
> 
>    "Consequently, style sheet authors and application developers are
>    encouraged in the strongest possible terms to respect the obvious
>    typographical interpretation of the mathvariant attribute 
> when applied
>    to characters that have SMP Math Alphanumeric Symbol 
> counterparts. In
>    all other cases, it is up to the renderer to determine 
> what effect, if
>    any, the mathvariant attribute will have. For example, a renderer
>    might sensibly choose to display a token with the contents &sum; (a
>    character with no SMP counterpart) in bold face font if it has the
>    mathvariant attribute set to 'bold' or to 'bold-fraktur', and to
>    display it in a default Roman font if the mathvariant 
> attribute is set
>    to 'fraktur'. As this example indicates, authors should 
> refrain from
>    using the mathvariant attribute with characters that do 
> not have SMP
>    counterparts, since renderings may not be useful or predictable. "

I guess I should have read that section better. Still I am not quite
satisfied.
- The notion of correspondence is not well defined. It suggests something
similar to lc-uc correspondence, but it is not defined.
- Since the SMP Math Alphanumeric Symbol characters only contain latin and
greek alphabetic characters and digits, I keep the feeling that mathvariant
only makes sense with those characters.
- Thinking about this, I feel that the sum example is wrong. <mi
mathvariant="bold">A</a> is a semantically different character from A, <mo
mathvariant="bold">&sum;</a> is only a style variant of this operator, and
that is not what mathvariant is supposed to convey.

With kind regards,
Simon Pepping
DTD Development and Maintenance
Elsevier
s.pepping@elsevier.com
www.elsevier.com/locate/sgml

Received on Friday, 9 May 2003 11:01:20 UTC