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

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
*