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

After further consideration, I now think there may be merit in
allowing renderers some flexibility to modify individual notations
so that they look good with the other notations in the same
menclose.

I think different algorithms will likely be more optimal in
different situations, so I'm not suggesting that the spec specify
any particular algorithm to use, but can the wording "Each should
be rendered as if the others were not present" be reverted or
relaxed, please?

Maybe something like the following?:

"The order of the values given for notation should have no effect
on how the notations are rendered together."

The most compelling example for my change in viewpoint is the
notation="top left" situation.

  If a renderer were drawing only "top" it might like to add
  padding above a child content rectangle, but might not wish to
  extend the "top" notation horizontally beyond the content
  rectangle.  Similarly a renderer drawing only "left" might wish
  to add padding to the left of the content rectangle, but not
  extend the "left" notation vertically.

  If such a renderer were then drawing a "top left" with each
  notation "as if the others were not present" there would be a
  gap between the "top" and "left".

  However, I think many would consider it more aesthetically
  appealing to join the "top" and the "left" (and maybe that's
  what the author might expect).

Frédéric WANG writes:

> => Interpretation of "as if the others were not present"
>
> The algorithm proposed was:
>    1) Compute the least possible size for each notation
>    2) Compute the maximum of these lower bounds
>    3) Draw all the notations with this maximum size

This seems a sensible possible algorithm that renderers may choose
(but not feel compelled) to use.  It addresses the "top left"
situation well IMO, for example.

>     So you're right, 2) seems a bit contradictory because the
> maximum size depends on each lower bounds.
>
> But I think the statement in the draft should only be understood
> as:
>
> - the order of notations in the attribute doesn't matter (it
>   was the starting point of this thread)

Yes, that sounds sensible, and, if that seems the best approach,
then the wording would be best changed to clarify (as suggested
above or otherwise).

> - the lower bound in 1) of each notation is computed independently

Yes, indirectly, I think.  If the spec can indicate, without
specifying any particular algorithm, that the expectation is not
that the size of each notation be chosen to enclose former or
latter notations on the same menclose, then that might clarify
things.  Would simply stating that the order of the values should
not affect the rendering be sufficient?

>    As I said, steps 2 & 3 are in my opinion necessary to respect
> rule of non-nested notation (for a less esoteric example than
> circle+radical, see below).

I'm not convinced that they should be necessary.  Partly because
it is not easy to prove that one algorithm is the only solution to
a problem, and partly because there may be variations that are
more appealing in some situations.  If there is a notation that
extends a considerable distance in one direction and a "circle" is
also drawn with that notation, I think it should be up to the
renderer to choose whether to center the circle on the content or
center on the maximum extents of the minimum sizes.

> => Risk of a recursive algorithm
>
>     Because each lower bound is computed independently, a
> recursive algorithm is not possible in step 1) (and you agree with
> it). It is neither the case in 2) (you simply take the maximum of
> a finite set of values) nor in 3) (you draw each notation
> inscribed in a given rectangle whose size never changes).

Yes, this algorithm is not recursive, and sorry, I didn't mean to
imply that it was.

An algorithm that attempted to apply each notation to all other
notations might be recursive, but this algorithm does not do that.
Instead, it applies each notation similarly so that they render
consistently (for one sense of consistently).

> So I guess your remark is biased by the way Firefox works. Given
> a rectangle (or even simply one dimension), Firefox is able to
> stretch the characters so that its size will become close to
> this rectangle but can not guarantee that the character will
> exactly fit the rectangle. This means that for a combination
> such that "radical actuarial", 3) is not possible because we
> always need to readjust the size of the symbols: Firefox will
> stretch the radical symbol, then stretch the parenthesis symbol
> to cover the height of the radical symbol, then needs to
> readjust the size of the radical symbol and so forth. Of course,
> in the current version of the patch I cheat and use an order of
> priority on the notations to determine which size to
> take. However, it should ideally be possible to draw all the
> notations so that they are perfectly inscribed in a given
> bounding box.

Actually, I hadn't thought about that, but yes it should be
possible to draw all notations so that they are perfectly
inscribed in a given bounding box (if that is what the renderer
chooses to do).

> => Treatment of notations
>
>    The theoretical mechanism treats all the notations in the same
> way ...

I thought there was a distinction between enclosing and striking
notations, but I'm happy that there is not.

> => Considering shapes other than rectangles when choosing a size
> for notations
>
>    If you are able to handle other shapes than rectangle for
> bounding area, then it is not too difficult to modify step 1) so
> that the computation of the lower bound takes into account the
> shape of the enclosed content. I guess your remark refers to our
> discussion about two nested <menclose="circle"/>: in this case, if
> you know that the enclosed content is an ellipse then you will
> simply compute a better lower bound than the one given by the
> size_of_bounding_box*sqrt(2) but the rest of the algorithm need
> not be change.

I did have that situation in mind but I also had "circle
updiagonalstrike" in mind.  If only rectangular shapes are
considered, this algorithm results in the updiagonal extending
beyond the circle.  That wouldn't be "wrong" but a renderer may
choose to draw the strike only as far as the circle, which would
be more consistent with the drawing of "circle horizontalstrike"

> => About drawing the notation according to the size of children
>
>    So let's consider the example <menclose
> notation="updiagonalstrike circle box"/> (see screenshot).
>
> First the lower bounds are computed independently. For example,
> the formulae I use are:
>    - the strike simply takes the size of the content
>    - the rectangle takes the size of the content + a padding
>    - the ellipse takes the size of the content * sqrt(2)
>
>    But because if we don't take the maximum of the lower bounds
> before drawing the notations, the result will be similar to (1),
> that we would actually expect for the case of 3 nested <menclose/>
> elements. So there is an obvious asymmetry between notations which
> is a consequence of the choice way lower bounds are
> computed. Other implementers may use other formulae and for
> instance find that the box is greater than ellipse.
>    
>    Now if we apply the algorithm of the "maximum lower bounds",
> the strike, ellipse and box are all inscribed in a same bounding
> box (2). This is the result that I think everybody expect and
> which is close to the box+circle example that Neil added in the
> draft. All the notations are now considered equivalently and there
> is no nested notation in an arbitrary order...

With one algorithm the circle (almost) encloses the box; with the
other algorithm the box (almost) encloses the circle.  I don't
think there is a "right" rendering here, so I don't think the spec
should specify.

This is partly why I'm a little uncomfortable with the spec
stating "they should not nest one inside of the other".  Some
notations may naturally be smaller than others and the renderer
should not distort such notations just to ensure that they
overlap.

Received on Friday, 23 January 2009 05:21:26 UTC