## fences (variable size math symbols)

 Subject: fences (variable size math symbols) From: David Carlisle Date: Mon, 8 Jun 1998 16:02:44 +0100
Does anyone have any insight into whether the dsssl math flow objects
are sufficient to support MathML?

Specifically the fence flow object

The fence flow object describes a three-part area.
The parts described are:
the base area,   the open-fence area,   the close-fence area.
The fences should be extended according to the height of the base area.
NOTE 122 It is implementation- and font-dependent how this is achieved.

appears to be modeled on the TeX notion of \left and \right, ie an area
that is specifically marked as being surrounded by fences (with one or
both fences optionally omitted).

In TeX (by default, although changeable with sufficiently powerful macros
such as the AMS breqn package) line breaks are not allowed within the
area to be surrounded by fences. It is not clear what the intention is
in the dsssl standard. If line breaking is allowed there appear to be
two possible readings of height' in the above.

1) (no line break)

| lots of math stuff  |

2) line break. fences keep with text lines

| lots of
math stuff |

3  line break. fences surround complete expression.

| lots of    |
| math stuff |

However none of these readings of the fence flow object semantics seems
to be powerful enough to deal with the MathML fence operators. (Even if
I ignore the extra complication of embellished operators).

In MathML any number of  fence operators may appear in a given math list
(mrow element). they are supposed to grow according to the size of this
_surrounding_ expression.

The MathML recommendation says

Vertical Stretching Rules:

If a stretchy operator is a direct subexpression of an <mrow>
element, or is the sole direct subexpression of an <mtd> element in
some row of a table, then it should stretch to cover the height and
depth (above and below the axis) of the non-stretchy direct
subexpressions in the <mrow> element or table row, unless stretching
is constrained by minsize or maxsize attributes.

In the case of an embellished stretchy operator, the preceding rule
applies to the stretchy operator at its core.

If symmetric="true", then the maximum of the height and depth is
used to determine the size, before application of the minsize
or maxsize attributes.

The preceding rules also apply in situations where the <mrow> or
<mtd> element is inferred (see Section 3.5.1 for a discussion of
inferred <mtd> elements).

To specify this behaviour from dsssl I need to check whether any mrow
element contains any stretch operators, which is OK, but then I need
to a) typeset the expression without the operators, find the required
size, and then re-set the expression this time inserting the large
operators. For a backend like TeX there is not much problem in the
backend doing this calculation but my question is how do I tell the back
end to do that from within dsssl.

Or is this the wrong approach, and I should instead by looking for a non
standard flow object that behaves like a math-sequence, except that
certain specified subexpressions are stretched. ie a generalisation of
the fence flow object that allows any number of fences, at arbitrary
positions in the expression.

David

DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist

`
Current Thread
• fences (variable size math symbols)
• David Carlisle - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id LAA19115Mon, 8 Jun 1998 11:02:46 -0400 (EDT) <=
• <Possible follow-ups>
• Reynolds, Gregg - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id MAA21305Mon, 8 Jun 1998 12:37:02 -0400 (EDT)
• David Carlisle - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id NAA22543Mon, 8 Jun 1998 13:20:40 -0400 (EDT)
• Reynolds, Gregg - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id SAA27384Mon, 8 Jun 1998 18:49:56 -0400 (EDT)
• David Carlisle - from mail1.ability.netby web4-1.ability.net (8.8.5/8.6.12) with ESMTP id EAA14601Tue, 9 Jun 1998 04:54:46 -0400 (EDT)