RE: fences (variable size math symbols)

Subject: RE: fences (variable size math symbols)
From: "Reynolds, Gregg" <greynolds@xxxxxxxxxxxxxx>
Date: Mon, 8 Jun 1998 11:33:30 -0500

> 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
	I think DSSSL does support what you're after.  If I understand
the spec (and your question) correctly, you need only extract the fence
characters and the content from the source tree (using sdql), and flow
them into the appropriate ports on the fence flow object.  "The
principal port, which is used for the main content of the flow
object...shall accept flow objects of the same class as the port of a
math-sequence flow object."  The math-sequence flow object, in turn
"produces a single area", and its port accepts a bunch of math flow
objects, including fence flow objects.  Meaning you can have as many
nested levels as you need.  The key point is that the flow object ports
represent areas (I think), so a DSSSL implementation with fence support
should use the flows attached to the principal port to drive the
construction of an area, and use the dimensions of that area to drive
the typesetting of the fences.  Where the contents include nested fence
flow objects, an implementation would need to apply this logic
recursively.  You the user shouldn't need to do any "typesetting"; you
need only direct the flow of content into ports/areas, as it were.  In
fact, if I understand DSSSL correctly, you shouldn't need to do any
*procedural* typesetting like you sketched in the first paragraph above.
It should be entirely a matter of declarative specification.  Also,
there need not be any explicit connection in the markup between the
content and how it is to be typeset, i.e., between the user's intention
to place stuff between fences and the markup of the stuff itself.  That
half of MathML explicitly encodes such formatting intentions may be
disregarded from the perspective of the DSSSL sheet.

	Your larger question was whether dsssl math flow objects are
sufficient to support MathML.  I think the answer is probably yes, but
the mapping is indirect.  Of course until somebody actually implements
such support this is purely speculative.

	- gregg

 DSSSList info and archive:

Current Thread
  • fences (variable size math symbols)
    • David Carlisle - from mail1.ability.netby (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 (8.8.5/8.6.12) with ESMTP id MAA21305Mon, 8 Jun 1998 12:37:02 -0400 (EDT) <=
        • David Carlisle - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id NAA22543Mon, 8 Jun 1998 13:20:40 -0400 (EDT)
      • Reynolds, Gregg - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id SAA27384Mon, 8 Jun 1998 18:49:56 -0400 (EDT)
        • David Carlisle - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id EAA14601Tue, 9 Jun 1998 04:54:46 -0400 (EDT)
          • Chris Maden - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id QAA24947Tue, 9 Jun 1998 16:07:55 -0400 (EDT)