Re: [MathML3-last-call] mathvariant

[Sam Dooley]

Partially resolved with improved wording for section 3.2.2.

/w3ccvs/WWW/Math/Group/spec/xml/presentation-markup.xml
new revision: 1.281; previous revision: 1.280

Section 7.5 still needs updating to track changes in section 3.2.2.

Sam


<p>The <att>mathvariant</att> attribute defines logical classes of token
elements.  Each class provides a collection of typographically-related
symbolic tokens.  Each token has a specific meaning within a given
mathematical expression, and, therefore, needs to be visually
distinguished and protected from inadvertent document-wide style
changes which might change its meaning.  Each token is identified
by the combination of the <att>mathvariant</att> attribute value
and the character data in the token element.</p>

...

<p>In principle, any <att>mathvariant</att> value may be used with any
character data to define a specific symbolic token.  In practice,
only certain combinations of character data and <att>mathvariant</att>
values will be visually distinguished by a given renderer.  For example,
there is no clear-cut rendering for a "fraktur alpha" or a "bold italic
Kanji" character, and the <att>mathvariant</att> values "initial",
"tailed", "looped", and "stretched" are appropriate only for Arabic
characters.</p>

<p>Certain combinations of character data and <att>mathvariant</att>
values are equivalent to assigned Unicode code points that encode
mathematical alphanumeric symbols.  These Unicode code points are
the ones in the <loc href="http://www.unicode.org/charts/PDF/U1D400.pdf">SMP
Mathematical Alphanumeric Symbol</loc> range U+1D400 to U+1D7FF,
listed in the Unicode standard, and the ones in the
<loc href="http://www.unicode.org/charts/PDF/U2100.pdf">Letterlike
Symbols</loc> range U+2100 to U+214F that represent "holes" in the
alphabets in the SMP, listed in <specref ref="chars_BMP-SMP"/>.
These characters are described in detail in section 2.2 of
<loc href="http://www.unicode.org/reports/tr25/">UTR #25</loc>.
The description of each such character in the Unicode standard
provides an unstyled character to which it would be equivalent
except for a font change that corresponds to a <att>mathvariant</att>
value.  A token element that uses the unstyled character in combination
with the corresponding <att>mathvariant</att> value is equivalent to a
token element that uses the mathematical alphanumeric symbol character
without the <att>mathvariant</att> attribute.  Note that the appearance
of a mathematical alphanumeric symbol character should not be altered
by surrounding <att>mathvariant</att> or other style declarations.</p>

<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.
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 authors should recognize that support for
mathematical symbols that do not correspond to assigned Unicode code
points may vary widely from one renderer to another.</p>

[Karl Tomlinson-5]

Thank you for looking at this.

Sam Dooley writes:

> <p>In principle, any <att>mathvariant</att> value may be used with any
> character data to define a specific symbolic token.  In practice,
> only certain combinations of character data and <att>mathvariant</att>
> values will be visually distinguished by a given renderer.  For example,
> there is no clear-cut rendering for a "fraktur alpha" or a "bold italic
> Kanji" character, and the <att>mathvariant</att> values "initial",
> "tailed", "looped", and "stretched" are appropriate only for Arabic
> characters.</p>
>
> [...]
>
> Note that the appearance
> of a mathematical alphanumeric symbol character should not be altered
> by surrounding <att>mathvariant</att> or other style declarations.</p>
>
> <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.

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.

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"?

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?

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>.

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.

[William F Hammond]

Sorry, I've not really been following this, but several things
in this thread today have grabbed me.

Karl Tomlinson <w3@...> writes:

> . . .
>> Note that the appearance
>> of a mathematical alphanumeric symbol character should not be altered
>> by surrounding <att>mathvariant</att> or other style declarations.</p>

Is the meaning here of 'other style declarations' limited to MathML
markup or does it extend to CSS?  I think it should not extend to CSS.

> . . .
>> 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.

In view of the 2nd paragraph below I'm confused.  Is it thought
correct to use 'mathvariant' for switching on, for example, italic
style?

> This would be a change from MathML2, so I just want to check that
> this has been thought through.
>
> 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.

(Is it clear what portion of 'mathematical-alphanumeric' is negated
by the 'non'?)

As I have understood things, a string matching the pattern /^[A-Za-z]$/
(i.e., a single alphabetic character) inside an mi should by default be
rendered italic, but a string matching the pattern /^[A-Za-z][0-9A-Za-z]+$/
should by default be rendered upright.  This is a long-standing tradition
in mathematical typesetting.  I hope you're not suggesting this would change.

> One example to consider is U+221E INFINITY.  ...

With other strings inside an mi my own inclination would be to
be explicit about style -- and I mean style, not character casting --
if I care which way it is set.  Again I ask if the MathML attribute
'mathvariant' is the correct thing to use for that.  CSS is for style.
Isn't mathvariant provided for character casting, i.e., pointing to a
character other than that inside the mi?

> . . .
> 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.

While I do see (and understand) avoidance of the more esoteric reaches
of unicode, e.g., plane 1, I think the tools of avoidance should not
be style.  As I've said, I don't see mathvariant as stylistic.

                                    -- Bill

[Sam Dooley]

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

[Sam Dooley]

Bill,

Thanks also for your comments.

At 03:38 PM 10/13/2009, William F Hammond wrote:

>Sorry, I've not really been following this, but several things
>in this thread today have grabbed me.
>
>Karl Tomlinson <w3@...> writes:
>
>> . . .
>>> Note that the appearance
>>> of a mathematical alphanumeric symbol character should not be altered
>>> by surrounding <att>mathvariant</att> or other style declarations.</p>
>
>Is the meaning here of 'other style declarations' limited to MathML
>markup or does it extend to CSS?  I think it should not extend to CSS.

This language does extend to include CSS.  If an author encodes
<mi mathvariant="bold">v</mi> or <mi>𝐯</mi>, they should
get a bold lower-case v.  A style sheet could be used to specify
which font is used to display bold characters, but it should not
change the weight or shape of the character.

>> . . .
>>> 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.
>
>In view of the 2nd paragraph below I'm confused.  Is it thought
>correct to use 'mathvariant' for switching on, for example, italic
>style?

No, 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.

>> This would be a change from MathML2, so I just want to check that
>> this has been thought through.
>>
>> 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.
>
>(Is it clear what portion of 'mathematical-alphanumeric' is negated
>by the 'non'?)
>
>As I have understood things, a string matching the pattern /^[A-Za-z]$/
>(i.e., a single alphabetic character) inside an mi should by default be
>rendered italic, but a string matching the pattern /^[A-Za-z][0-9A-Za-z]+$/
>should by default be rendered upright.  This is a long-standing tradition
>in mathematical typesetting.  I hope you're not suggesting this would change.

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.  ...
>
>With other strings inside an mi my own inclination would be to
>be explicit about style -- and I mean style, not character casting --
>if I care which way it is set.  Again I ask if the MathML attribute
>'mathvariant' is the correct thing to use for that.  CSS is for style.
>Isn't mathvariant provided for character casting, i.e., pointing to a
>character other than that inside the mi?

I think we are saying the same things here:  CSS is for style,
mathvariant is for creating symbolic math identifiers, not for styling.
Whether or not you view mathvariant as a Unicode to Unicode map is an
implementation detail, since implementations are allowed to support
combinations that do not correspond to Unicode code points.

>> . . .
>> 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.
>
>While I do see (and understand) avoidance of the more esoteric reaches
>of unicode, e.g., plane 1, I think the tools of avoidance should not
>be style.  As I've said, I don't see mathvariant as stylistic.
>
>                                    -- Bill

Agreed, the tool of avoidance (mathvariant) is not intended to be
about style.

Sam