Subject: fences (variable size math symbols) From: David Carlisle <davidc@xxxxxxxxx> 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 threepart area. The parts described are: the base area, the openfence area, the closefence area. The fences should be extended according to the height of the base area. NOTE 122 It is implementation and fontdependent 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 nonstretchy 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 reset 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 mathsequence, 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 


< Previous  Index  Next > 

Re: A Visual Introduction to DSSSL, Frank Boumphrey  Thread  RE: fences (variable size math symb, Reynolds, Gregg 
A Visual Introduction to DSSSL, Markus Reinsch  Date  Re: Deriving unique href target?, Chris Maden 
Month 