- 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