- From: Sam Dooley <sam@integretechpub.com>
- Date: Tue, 13 Oct 2009 17:10:40 -0600
- To: www-math@w3.org
Karl, Thanks for your comments/questions. At 02:40 PM 10/13/2009, Karl Tomlinson wrote: >Sam Dooley writes: > >> <p>Renderers should support those combinations of character data and >> <att>mathvariant</att> values that correspond to Unicode characters, >> and that they can visually distinguish using available font >> characters. > >This sentence says "should" ... > >> Renderers may ignore or support those combinations of character data >> and <att>mathvariant</att> values that do not correspond to an assigned >> Unicode code point, > >... and this sentence says "may", implying that the better >behavior for renderers is to alter the appearance of all >non-mathematical-alphanumeric-symbol characters according to the >mathvariant attribute when possible. > >This would be a change from MathML2, so I just want to check that >this has been thought through. mathvariant is not about applying style, it is about applying semantics, that is, creating math symbols that carry meaning via style that should be protected from other style changes. Unfortunately, in too many ways, mathvariant still looks like it is about applying style, especially since there are few other means to control style in MathML itself. A renderer is allowed to alter the appearance of all characters according to the mathvariant attribute where possible, except for the mathematical alphanumeric symbol characters, which carry their own appearance as part of the Unicode code point. A renderer is also allowed to restrict the operation of mathvariant to alter the appearance of only those combinations described in the spec that have equivalent Unicode code points. The language does not intend to favor one behavior over another, since there are existing implementations that differ on this point. And yes, this does represent a change from MathML 2, but hopefully a backward-compatible one. >This would effectively mean that almost all >non-mathematical-alphanumeric-symbol characters in an mi element >without an explicit mathvariant attribute should be rendered in an >italic form. mi with a single character should still use mathvariant italic. mi with more than one character should still use mathvariant normal. This situation has not changed from MathML 2. >One example to consider is U+221E INFINITY. Some fonts have a >separate italic glyph that is very similar to the upright glyph, >and that is probably intentional because the font author thought >that the rendering of infinity should not depend on style. Other >fonts have an italic glyph that differs. So the rendering of ><mi>∞</mi> will depend on the font used. Should authors >expecting an upright form always explicitly use >mathvariant="normal"? What has changed is that a renderer is allowed to expand the set of single characters to which it applies mathvariant italic, but it need not do so. So yes, the rendering of <mi>∞</mi> will depend on the font used, and the specific renderer, but it always has. If authors depend on an upright form for a single character inside an <mi> that is likely to see significant font variation between italic and normal, then they should specify mathvariant normal. >Many font rendering systems will produce an italic (or at least >oblique) variant of a character even when there is no >hand-constructed glyph, so there is almost always a visually >distinguishable italic character. Or is there an expectation that >synthetic styles (either italic or bold) be suppressed and >only forms with glyphs from different font faces be used? There is no intention to specify how a renderer implements a particular effect, including the use of synthetic styles for bold or italic. >U+210F PLANCK CONSTANT OVER TWO PI is another interesting example. >U+210E PLANCK CONSTANT is a mathematical alphanumeric symbol but >U+210F is not. Thus <mi>ℏ</mi> may end up with more slant >than <mi>ℎ</mi>. Yes, interesting. The language in the spec says that <mi>ℎ</mi> should be equivalent to <mi mathvariant="italic">h</mi>. It seems to me that <mi>ℏ</mi> should also be equivalent to <mi mathvariant="italic">ħ</mi>, but others may disagree. Since both U+210E and U+210F are intended to be slanted characters, a renderer should render each as slanted. But that is a feature of Unicode, not of mathvariant. Since mathvariant was not originally intended to apply to U+0127, whether or not a renderer supports that particular combination is up to the renderer. >One thing that concerns me is that, although we now have better >Unicode support for mathematical characters than ever, there seems >to be an increased expectation of creating characters by other >means that resemble style. And yes, I could wish that mathvariant resembled style somewhat less, if only to avoid some of the confusion about how to use/implement it. It's main purpose has always been to give an alternative for those systems that are unable to support plane 1 character codes. Sam
Received on Tuesday, 13 October 2009 23:19:54 UTC