- From: Jacques Distler <distler@golem.ph.utexas.edu>
- Date: Thu, 24 Sep 2009 17:27:21 -0500
- To: www-math@w3.org
- Message-Id: <1C35B614-2DDC-4D49-B3D4-5D8393B8556F@golem.ph.utexas.edu>
I really don't like the philosophy behind the paragraph on @mathvariant, specifically, the statement [1]: By design, the only cases that have an unambiguous interpretation are exactly the ones that correspond to SMP Math Alphanumeric Symbol characters, which are enumerated in Section 7.5 Mathematical Alphanumeric Symbols. The mathvariant values "initial", "tailed", "looped" and "stretched" are expected to apply only to Arabic characters. In all other cases, it is suggested that renderers ignore the value of the mathvariant attribute if it is present. There are three ways a renderer can satisfy a request for a particular mathvariant. 1) The desired glyph may be found as a variant-glyph --- in some font that the renderer has available --- at the same code-point. 2) The desired glyph may be found --- in some font that the renderer has available --- associated to another code-point (say, in Plane-1, as discussed by the current text). 3) If the desired glyph cannot be found, perhaps some transform (overstriking, say, in the case of bold) may achieve an approximation of the desired effect. I don't think the Spec should be micromanaging how a renderer is supposed to deal with @mathvariant. If the renderer has the desired glyph available to it, it should make use of it (whether through mechanism (1) or (2)). If it doesn't have the desired glyph available, "MathMLforCSS" is not magically going to solve the problem. As a specific example, the current Spec says that <mi mathvariant="bold-italic">ı</mi> should be ignored, despite the fact that a) Many fonts (STIXGeneral, Verdana, Trebuchet, Times, Palatino, ...), have a bold-italic variant-glyph for U+0131. b) This is a perfectly reasonable variant to request. Jacques Distler [1] http://www.w3.org/TR/MathML3/chapter3.html#presm.commatt
Received on Thursday, 24 September 2009 22:28:03 UTC