From: Frédéric WANG <fred.wang@free.fr>

Date: Wed, 21 Jan 2009 19:06:18 +0100

Message-ID: <4977641A.7090506@free.fr>

To: Neil Soiffer <Neils@dessci.com>

CC: Karl Tomlinson <w3@karlt.net>, www-math@w3.org

Received on Wednesday, 21 January 2009 18:09:04 UTC

Date: Wed, 21 Jan 2009 19:06:18 +0100

Message-ID: <4977641A.7090506@free.fr>

To: Neil Soiffer <Neils@dessci.com>

CC: Karl Tomlinson <w3@karlt.net>, www-math@w3.org

> The current draft spec says: > > "Any number of values can be given for notation separated by > whitespace; all of those given and understood by a MathML renderer > should be rendered. Each should be rendered as if the others were not > present; they should not nest one inside of the other. For example, > notation="circle box" should result in circle and a box around the > contents of menclose; the circle and box may overlap. This is shown in > the first example below." > > This seems much simpler and clearer than what you propose. Sorry, I didn't know that the last version of the draft is always available so I wasn't informed of your changes. I was not actually suggesting a wording but just the two main ideas to draw the notations. Karl expressed them better than me: i) "position and size of each notation relative to child elements depend only on the child elements" ii) the size of the <menclose/> element (what I previously called rect2) is "the maximum extents of the particular set of notations" i) is clearly implied by "Each should be rendered as if the others were not present". ii) can be deduced from "they should not nest one inside of the other" (for instance in the example radical+circle you wrote for the MathML testsuite, the square root symbol on the left increases the width of the menclose element and consequently the ellipse needs to take the whole width for otherwise the "circle" notation is inside the "radical" one). So I think your proposal is fine :-) > The paragraph you referenced says that the size is left to the > renderer to decide. I think it makes sense to add some suggestions to > help out implementers (no sense in re-inventing the wheel), but > specifying lots of details or complicated algorithms tends to give > them the sense of a "rule" rather than a suggestion and makes the > already way too long spec even longer. If your size works for most > cases, I'll change the text to use your suggestion, but if it only > looks good for circles, I'm less enthusiastic about adding "do this > circles, do this for boxes, ..." It was simply a casual remark and I don't expect you to add the exact formula in the spec. I just wanted to point out that the empirical rule you gave is not generally true in the case of the "circle" notation (at least if I understand it well) and is likely to confuse implementers. For instance, I'm curious to see how MathPlayer displays the attached file circle_notation.xml. The ellipse needs to be large enough not to overlap with its content (see screenshot). If you do the exact math, the least possible size is given by the ratio sqrt(2). F. Wang

- text/xml attachment: circle_notation.xml

(image/png attachment: circle_notation.png)

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:41 UTC
*