From: Philippe Verdy (email@example.com)
Date: Tue Jan 30 2007 - 19:38:09 CST
From: "Rick McGowan" <firstname.lastname@example.org>
> The draft for Proposed Update UTR #25, Unicode Support for Mathematics,
> has been updated. Please see the Public Review page for details:
I see that this draft shows many symbols in table 2.4 with a "missing" unicode codepoint in red (noted for example "2Bxx" instead of the actual codepoint hexadecimal value);
This concerns some rotated or smaller/larger or black/white variants of other existing symbols.
Does this suggest that these characters have been proposed for later encoding in ISO/IEC 10646? If not, why are those symbols present?
I know they may be present in some math language, but accessible only by their symbolic name in that language, but not by a named entity or numerical reference in XML, except through PUAs, but in that case, why giving "2Bxx" hints about their possible future encoding (it is still not proven that they will fit in block U+2B00..U+2BFF)?
Also, there's an editorial problem in the updated section 2.14 about the proposed invisible plus operator. The example shows an example for the invisible multiplication, but for me, it just renders as if the vertically stacked fraction that follows the number 3 was an exponent, not a multiplicator, so the invisible operator looks like an implicit exponent operator, not like an implicit multiply operator.
The reason of this caveat is that the fraction is rendered using a separate image, and the number 3 is encoded as text. The whole should be a transparent image showing the effective multiplication layout (transparency should also be used for examples, instead of the white background, if you want that the yellow background for emphasizing modifications appears; this concerns all images linked in the HTML version of the document)
This example also demonstrate that there's probably a need to encode an invisible exponent operator, to make the distinction with superscript notations used for example with integrals, summations, limits...
I've seen examples of maths formulas using top and bottom limits for integrals and summations, written above and below the sigma operator, and exponents (or functors like primes, asterisks, ...) after it, and if no operator is encoded, a renderer that cannot display the limits above and below the operator will need to place the limits after it, and move the exponent after the whole summation rendered between parentheses... Generally, such mixed usage occurs within expressions involving functors acting on fields (or on functions or on distributions or similar near-numeric objects) and returning other fields (or functions or distributions or similar near-numeric objects). Where possible, parentheses are avoided, but the place where upper and lower limits appear is significant.
This archive was generated by hypermail 2.1.5 : Tue Jan 30 2007 - 19:40:33 CST