W3C home > Mailing lists > Public > www-math@w3.org > January 2004

Re: When to stretch parentheses

From: Robert Miner <RobertM@dessci.com>
Date: Fri, 30 Jan 2004 12:17:09 -0600
Message-Id: <200401301817.i0UIH9C28797@wisdom.geomtech.com>
To: mf@w3.org
Cc: Stephan.Semirat@ac-grenoble.fr, davidc@nag.co.uk, Vincent.Quint@inria.fr, www-math@w3.org


Hi.

> Semirat Stephan <Stephan.Semirat@ac-grenoble.fr> wrote:
> 
> > However, when you write the formula by hand on a paper (i think that is 
> > what to be expected by a "good" renderer, isn't it ? that is to be the 
> > most readable possible) you only stretch parenthesis with what they 
> > contain, do you ?
> 
> I agree, and I don't think anyone would stretch in this particular
> case.


No! I must strongly disagree.  It is true that one does not want the
parentheses to stretch to cover the height of the fraction.  But if
what you put in the source is the MathML markup for parens that do
stretch to that height, then that should be the way it renders.  If
your markup is bad, then your rendering must be bad as well.

The proper markup for this expression encloses the parens and their
contents in an mrow:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
  <mi>e</mi>
  <mrow>
    <mo>(</mo>
    <mi>CM</mi>
    <mo>)</mo>
  </mrow>
  <mo>=</mo>
  <mfrac>
     <mi>a</mi>
     <mi>b</mi>
  </mfrac>
</math>

With this proper MathML encoding of the expression, all renderers
agree.  The parens do not stretch.

BUT, if you leave the mrow out, thereby removing a critical piece of
the mathematical structure from the equation, THEN you get a bad
rendering. 

> > So my view is that Mozilla has made the good choice...
> 
> Or rather that the spec does not specify the best rendering in this
> case. But consider another example:


No! The spec DOES specify the rendering.  The parens MUST stretch.
They alway stretch to cover the height of the children in the same
(possibly inferred) mrow.

> 
>           / 1 \           /   \ / 1 \
>           | - |           | 1 | | - |
>     / 1 \ | i |           |   | | i |
>     | 2 | | 2 |           | 2 | | 2 |
> a = | 3 | | 3 |   vs  a = | 3 | | 3 |
>     | 4 | | 4 |           | 4 | | 4 |
>     \   / \   /           \   / \   /
> 
> 
> where right is better than left.
> 
>                    / 1 \ 
>            /  \    | - |
>            | 1 |   | i |
>            | 2 |   | 2 |
> however, a | 3 | = | 3 |
>            | 4 |   | 4 |
>            \   /   \   /
> 
> is (in my opinion) acceptable. So maybe the rule should be flexible 
> and could depend on the operators between the subelements.

Again, just beat my dead horse a little bit more, you can achieve any
of these renderings if you desire them, by adjusting the markup
accordingly.  If you encode the expression to properly reflect the
mathematical structure and grouping of terms, then you get a good
rendering.  If you don't, then you get a different rendering.

Surely the notion that to get a good rendering, you have to properly
encode the expression is not such a radical idea for an XML
application.  The point of MathML is not merely to be a convenient way
of doing typesetting, but to actually try to capture the proper
expression structure as well.  The fact that bad markup leads to bad
renderings is just a (rather mild) way of trying to enforce that.

--Robert


------------------------------------------------------------------
Dr. Robert Miner                                RobertM@dessci.com
MathML 2.0 Specification Co-editor                    651-223-2883
Design Science, Inc.   "How Science Communicates"   www.dessci.com
------------------------------------------------------------------
Received on Friday, 30 January 2004 13:09:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:55 GMT