From: Karl Tomlinson <w3@karlt.net>

Date: Thu, 22 Jan 2009 18:08:44 +1300

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

Cc: Neil Soiffer <Neils@dessci.com>, www-math@w3.org

Message-ID: <87eiywgc6b.fsf@karlt.net>

Date: Thu, 22 Jan 2009 18:08:44 +1300

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

Cc: Neil Soiffer <Neils@dessci.com>, www-math@w3.org

Message-ID: <87eiywgc6b.fsf@karlt.net>

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

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