Re: angle brackets in math (Was Re: several messages ...)

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="&lt;" close="&gt;">...</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.8