Re: menclose: several values in the "notation" attribute

> 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