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.

You said

"We noticed that in some cases (for instance a <menclose notation="circle"/>
arround a <mtable/>) it's better to use sizeof(rect2) =
sqrt(2)*sizeof(rect1)."

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

Of course, the decision is not up to just me, but that's my opinion on it.

    Neil



On Mon, Jan 19, 2009 at 11:43 PM, Frédéric WANG <fred.wang@free.fr> wrote:

>   I agree with Karl about the ambiguity of "content". I believe it's
> because there are two kinds of notations:
> - for "strike notations", it is clear that "content" means children of
> <menclose/> but
> - for "enclosing notations" it can also means the other notations (if we
> don't specify that notations overlap).
>
>   I think before the second part that describes more precisely each
> notation, you should add a general mechanism to render the notations of
> menclose. For instance:
>   1) the children of <menclose/> have a bounding box rect1.
>   2) the <menclose/> element has a bounding box rect2 whose size is
> computed according to the size of rect1 and the notations used.
>   3) all the notation are inscribed in rect2 (and hence possibly overlap).
>     Then 2) and 3) can be explained more:
> - a "strike notation" has not effect over the size of rect2
> - an "enclosing notation" encloses rect1. rect2 is given by the size of
> rect1 + the size of the components used to draw the notation (radical
> symbols, padding...)
> - "updiagonalstrike" extends from the lower left corner to the upper right
> corner of rect2
> - etc
>
>   By the way, I'm not sure the following suggestion is relevant for
> "circle" notation:
> "In practice, paddings on each side of 0.4em in the horizontal direction
> and .5ex in the vertical direction seem to work well"
>
>   We noticed that in some cases (for instance a <menclose
> notation="circle"/> arround a <mtable/>) it's better to use sizeof(rect2) =
> sqrt(2)*sizeof(rect1).
>
> F. Wang
>
>  On Fri, 14 Nov 2008 21:01:15 -0800, Neil Soiffer wrote:
>>
>>
>>
>>> The spec currently 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.
>>> For
>>> example, notation="circle horizontalstrike" should result in circle
>>> around
>>> the contents of menclose with a horizontal line through the contents. "
>>>
>>> That seems pretty clear to me that all of the values should be rendered.
>>>  It
>>> is maybe less clear that they should overlap, but the paragraphs that
>>> give
>>> default spacing from the content, so that is pretty strongly implied just
>>> as
>>> it is in the text above.  Is it really necessary to add something that
>>> say
>>> they should overlap?
>>>
>>>
>>
>> What is perhaps not clear is whether or not "contents" or
>> "content" includes the notations.  Most of
>> http://www.w3.org/TR/2008/WD-MathML3-20081117/chapter3.html#presm.menclose
>> seems to imply that "contents" are its arguments (child elements),
>> but not the notations.  This is most strongly suggested here:
>>
>>  menclose accepts any number of arguments; if this number is not 1,
>>  its contents are treated as a single "inferred mrow" containing
>>  its arguments, ...
>>
>> The one thing that seems contradictory to this interpretation of
>> "content" is the example in this statement:
>>
>>  The values "updiagonalstrike", "downdiagonalstrike",
>>  "verticalstrike" and "horizontalstrike" should result in the
>>  indicated strikeout lines being superimposed over the content of
>>  the menclose, e.g. a strikeout that extends from the lower left
>>  corner to the upper right corner of the menclose element for
>>  "updiagonalstrike", etc.
>>
>> Assuming the "menclose element" includes the notations, a
>> strikeout from "the lower left corner to the upper right corner of
>> the menclose element" would strikeout other notations as well as
>> child elements.
>>
>> However, an interpretation that includes the notations in the
>> contents also could not be consistent, because it would not be
>> possible to have both "roundedbox" and "circle" enclose other each
>> other, nor could they enclose a updiagonalstrike, while that
>> updiagonalstrike strikes out the roundedbox or circle.
>>
>> As most of the section seems to use "content" and "contents" to
>> refer only to child elements, not notations, I expect that it's
>> best not to infer too much from the "updiagonalstrike" example?
>>
>> If so, I would suggest changing the wording to avoid using the
>> expression "menclose element".  Perhaps
>>
>>  e.g. a strikeout that extends from the lower left corner to the
>>  upper right corner of a rectangle enclosing the child elements
>>  for "updiagonalstrike", etc.
>>
>>
>>
>>
>
>