At 5:41 PM 7/2/96, rminer@geom.umn.edu wrote: >I'm having a bit of trouble divining from Bruce's proposal just how >stretchy operators are suppose to work. Here's what I said about them in the letter outlining the proposal, http://www.w3.org/pub/WWW/MarkUp/Math/WG/Smith-960531.html The properties of any operator token include: <nl> <br>... <li>Whether this operator is "stretchy". This is typically used for brackets. This affects only rendering, and typically means the operator's vertical size depends on that of its operands (for brackets, operands are what is contained between matching pairs).</li> </nl> <p> The attribute names and values corresponding to these properties are: <br>...<br> stretchy=true<br> What this means is: - Your display list is correct (though it doesn't show the attribute values of (mo "(") and (mo ")"), just as my letter did not, when they equal the default (dictionary) attributes of the operator). - (mo "(") and (mo ")") both carry the default attribute value stretchy=true, which means the renderer should grow them vertically based on their operands, which is (for brackets) what is between them. - The renderer doesn't have to know that they are brackets or that their operands are what is between them (as opposed to "next to them" like for (mo "+")) -- this is known only by the parser. The parser always puts single or matched operators and their operands into a single level of the display list. Thus, what the renderer thinks of as "the operands of an operator" is simply "whatever occurs in the same (mrow ...) construct as that operator". - So all the renderer does is, if any mrow contains any operators with stretchy=true, grows all of them based on the vertical sizes of the other elements of the same mrow. - Precisely how much it grows them (or even whether it actually does) is up to its own style judgement (or, in the future, to a style sheet). - If someone wants a specific pair of brackets to not be stretchy, they can get this behavior by saying, for each one, e.g. <mo stretchy=false>(</mo> (with no whitespace between the tags, since all characters between the tags form the characters of the operator, in this construct). (The original proposal letter referenced above may have been unclear about whether the other attributes not mentioned specifically in an <mo>...</mo> construct naming an already-existing operator would have their "global default values", or their values from the dictionary entry of the named operator. The next draft of that letter will address this; it's complex when some attributes are "derived from" others, but the short answer in this case is "the values from the dictionary entry". This means that <mo stretchy=false>(</mo> doesn't really create a whole new operator, but creates one just like (mo "(") but with just one attribute modified.) > Or what about an expression like > >||x-a| sin(b)| > >Typically, I would make the outer vertical rules larger, but I see no >way of creating a display list that would accomplish this. Am I >missing something? There is no specific way in my proposal letter for accomplish this second thing, unless the style rules of your renderer always do it. There are probably some kluges that would accomplish it in some renderers, but the "right way" is to let it (where "it" means some property that would lead to the behavior you want, e.g. "bigger-than- enclosed-brackets") be a named aspect of a rendering style, and to use the general mechanism for altering a rendering style parameter by name for a subexpression. This general mechanism was not covered in the letter but will certainly exist -- hopefully it will be identical or compatible with CSS. - BruceReceived on Tuesday, 16 July 1996 12:10:03 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:57 UTC