W3C home > Mailing lists > Public > w3c-math-erb@w3.org > July 1996

Re: Stretchy Operators

From: Bruce Smith <bruce@wolfram.com>
Date: Tue, 16 Jul 1996 20:11:24 +0400
Message-Id: <v0213050dae1156959681@[194.220.185.74]>
To: rminer@geom.umn.edu
Cc: w3c-math-erb@w3.org
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.

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