From: Karl Tomlinson <w3@karlt.net>

Date: Fri, 23 Jan 2009 18:20:45 +1300

To: www-math@w3.org, Frédéric WANG <fred.wang@free.fr>

Cc: Neil Soiffer <Neils@dessci.com>

Message-ID: <877i4mfviq.fsf@karlt.net>

Date: Fri, 23 Jan 2009 18:20:45 +1300

To: www-math@w3.org, Frédéric WANG <fred.wang@free.fr>

Cc: Neil Soiffer <Neils@dessci.com>

Message-ID: <877i4mfviq.fsf@karlt.net>

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

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