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."

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.

Received on Thursday, 22 January 2009 05:09:24 UTC