From: Neil Soiffer <Neils@dessci.com>

Date: Fri, 23 May 2008 12:27:30 -0700

Message-ID: <d98bce170805231227k74d67f2cqc6458971194c7010@mail.gmail.com>

To: "William F Hammond" <hammond@csc.albany.edu>

Cc: www-math@w3.org

Date: Fri, 23 May 2008 12:27:30 -0700

Message-ID: <d98bce170805231227k74d67f2cqc6458971194c7010@mail.gmail.com>

To: "William F Hammond" <hammond@csc.albany.edu>

Cc: www-math@w3.org

I don't think this discussion is of interest to the HTML mailing list, so I've removed that from the reply... On Fri, May 23, 2008 at 11:26 AM, William F Hammond <hammond@csc.albany.edu> wrote: > > David Carlisle <davidc@nag.co.uk> writes: > > > The mapping currently defined for lang to 27E9 (MATHEMATICAL LEFT ANGLE > > BRACKET) is definitely the correct one and if the definition of rang is > > changed at all from its html4 definition it should be to this and not to > > U+3008 (LEFT ANGLE BRACKET) > > > > The original definition was to U+2329 (LEFT-POINTING ANGLE BRACKET) > > which is in the 2xxxx block of technical symbols not CJK punctuation, > > and the name "rang" comes from ISOTECH entity set for technical > > publishing. So this entity has always been intended for mathematical use. > > (In my Firefox (2.0.0.14) it seems that only 2329 and 232A are > appropriately > stretchy.) > > It strikes me, however, that to the extent presentation markup can be > maximally semantic (which is related to what one might be able to coax > out of most mathematical authors some day), these brackets and other > stretchy balancers should, for presentation markup, be deployed via > <mfenced> (the list constructor). > > Routes for this include LaTeX's \left<...\right> or gellmu's \vect[<>]{...} > and \bal[<>]{...} [in releases so far, actually, \balab{...}]. mfenced is defined to be equivalent to <mrow> with <mo>s for the fences and separators.[1] Thus, there should be no advantage other than "convenience" (the term used in the spec) for using <mfenced>. > > > Then might one hope that user agents will durably pick up the right things > when rendering <mfenced open="<" close=">">...</mfenced>? > > Beyond that one might hope with <mfenced> that user agents will durably > pick up the right things with any of the aforementioned balancing pairs > as values for the <mfenced> attributes. > > Or is this asking too much of user agents? > <mrow> is the element that defines how much stretchy operators stretch -- see "Vertical Stretching Rules" in [2] for details. As it states in that section: If an operator has the attribute stretchy="true", then it (that is, each > character in its content) obeys the stretching rules listed below, given the > constraints imposed by the fonts and font rendering system. In practice, > typical renderers will only be able to stretch a small set of characters, > and quite possibly will only be able to generate a discrete set of character > sizes. In other words, you can't guarantee stretchy behavior even if you set it on the mo element. "<" and ">" aren't typically meant to stretch, and I would discourage the use of them as bracketing chars. That is not their intended use according to Unicode. Neil Soiffer Senior Scientist Design Science, Inc. www.dessci.com ~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~ [1] http://www.w3.org/TR/2003/REC-MathML2-20031021/chapter3.html#presm.mfenced [2] http://www.w3.org/TR/2003/REC-MathML2-20031021/chapter3.html#id.3.2.5.8Received on Friday, 23 May 2008 19:28:08 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:13:01 GMT
*