From: Michael Day <mikeday@yeslogic.com>

Date: Mon, 2 Feb 2004 07:20:50 +1100 (EST)

To: Luca Padovani <lpadovan@cs.unibo.it>

Cc: www-math@w3.org

Message-ID: <Pine.LNX.4.44.0402020713370.13293-100000@lorien.yeslogic.com>

Date: Mon, 2 Feb 2004 07:20:50 +1100 (EST)

To: Luca Padovani <lpadovan@cs.unibo.it>

Cc: www-math@w3.org

Message-ID: <Pine.LNX.4.44.0402020713370.13293-100000@lorien.yeslogic.com>

Hi Luca, > 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 6.2.3 Mathematical > Alphanumeric Symbols Characters. In all other cases, it is suggested > that renderers ignore the value of the mathvariant attribute if it is > present" Oh, that is interesting -- so the mathvariant attribute is really transforming characters rather than changing font (even if you might implement it by changing font). So this example: <mi mathvariant="bold-italic"> x </mi> should be treated as if the x was actually: <mi> 𝒙 </mi> (where U+1D499 is "MATHEMATICAL BOLD ITALIC SMALL X")? In that case there can be no italic digits, for as you say there are no such characters to map them to. However, what about this: <mi> h </mi> As far as I can see, there is no "MATHEMATICAL ITALIC SMALL H" in UNICODE, as the code point between G and I is left unassigned U+1D455. Does this mean that conforming implementations should keep a table of which characters must be mapped in this way, and should therefore leave the h in a non-italic font? Best regards, Michael -- YesLogic Prince prints XML! http://yeslogic.comReceived on Sunday, 1 February 2004 16:23:28 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 5 February 2014 07:13:40 UTC
*