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

In the example that Frédéric sent, there were *two *mencloses.  So while I
agree with your statement that a circle and a box should overlap if they are
on the same menclose because they are based only on the child element, when
one menclose is nested inside the other, that is not true.

    Neil

On Wed, Jan 21, 2009 at 9:08 PM, Karl Tomlinson <w3@karlt.net> wrote:

> >> 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."
>
> Frédéric WANG writes:
>
> > ... I was not actually suggesting a wording but just the two
> > main ideas to draw the notations. Karl expressed them better
> > than me:
>
> Frédéric, perhaps I didn't express my interpretation clearly
> enough because it sounds like we are still not interpreting the
> spec in the same way.
>
> >
> > 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 ...
>
> Up to this point, I thought we were interpreting things the same
> way.
>
> > ... and consequently the ellipse needs to take the whole width
> > for otherwise the "circle" notation is inside the "radical"
> > one).
>
> Here it became clear to me that we are not.
>
> Making the width of the "circle" notation depend on the width of
> the menclose element causes it to depend on the width of other
> notations, and so it would not be drawn "as if the others were not
> present".
>
> Regarding the '"circle" notation being inside the "radical"', I
> didn't read the current draft spec "they should not nest one
> inside of the other" as a strict requirement that notations must
> overlap.  I think it was added more to make it clear that
> implementations should not draw notations differently to make them
> nest.
>
> The issue here is really whether notations notate /child content/
> or whether they notate the /entire menclose element/, which was
> what I was trying to explain in this message
>
> http://lists.w3.org/Archives/Public/www-math/2009Jan/0015.html
>
> My interpretation is that most of the spec is worded to suggest
> that the notation is applied only to child content.  It is only
> the "updiagonalstrike" example that suggests that the entire
> menclose should be considered.
>
> IMO having each notation notate the child content is something
> that can be reasonably achieved, but having each notation attempt
> to notate the entire menclose is something that cannot always be
> achieved, as any algorithm risks becoming recursive.
>
> The algorithm described in this message
>
> http://lists.w3.org/Archives/Public/www-math/2009Jan/0016.html
>
> attempts to have each notation (or some notations) notate the
> entire menclose by sizing each notation so that it fits within the
> maximum bounds of the menclose.  I'm uncomfortable with this
> algorithm because
>
> * It treats some notations differently from others.
>
> * It seems to preclude an implementation from considering shapes
>  other than rectangles when choosing a size for notations.
>
> * Many of these notations attempt to enclose or strike out
>  something, which will usually mean wanting to extend a little
>  beyond that something.  So it makes more seems to me to position
>  and size these notations so that they are beyond some region
>  rather than so that they are within some region.
>