Re: fences (variable size math symbols)

Subject: Re: fences (variable size math symbols)
From: David Carlisle <davidc@xxxxxxxxx>
Date: Tue, 9 Jun 1998 09:46:46 +0100

Thanks for the comments. I will experiment some more before coming back.
While I know something about TeX I am still basically teaching myself
dsssl, so sometimes I am not clear in my own mind whether things I am
finding difficult are because they are difficult or because I have not
mastered the appropriate bit of dsssl yet. So I don't want to abuse this
list too often.

> but do you recall what fun it was to learn TeX? 

Just about, but I'm getting too old to remember my youth.

> Can you post an example of the source text upon which you expect
> to operate along with a description of what the expected output would
> be?

Will try below, although I came to this question by contemplating how to
implement the mathml report rather than by having a particular example.

> One specific point, though: I suspect issues like the exact sizing
> of the fences as you mention above are what the standard has in mind in
> note 122 wrt implementation dependencies.  Also, have you looked at how
> a math grid flow object might be used for this?

Yes fence stretching is explicitly implementation dependent. But that is
why I can not see how to do multiple fences with the current `two fence'
flow object. To use TeX syntax for a moment...

If I want to produce  ( a + b ) + ( c + d ) with all the brackets the
same size (and `a' `b' etc something large enough that this is an issue).
Then in MathML I am just supposed to put all 11 elements in a <mrow>
and give the brackets fence="true" and stretchy="true" attributes (which
actually they have by default.)

Then TeX does not support this at all easily (and dsssl likewise).

You could try to arbitrarily nest, something like

<null><null>( a + b ) + ( c + d )
  |     |   |_______|   |       |
  |     |_______________|       |

but that gets the horizontal spacing wrong (which could be corrected),
inhibits line breaking (could possibly be corrected, but I don't think I
can do anything about that from within dsssl) and most importantly I
need to know what the `system dependent' stretching is doing.

If the brackets around (a+b) mean that the resulting expression is
larger than a+b then the above nested form will make the second and
third brackets progressively larger.

That is, if my system dependent part is doing what the second TeX
expression below is doing, then I need to know not to try to use nested
fence objects in dsssl.

=================== plain tex example.

$\left.\left.\left( a + b \right) + \right( c + d \right)$


$\left.\left.\left( a + b \right) + \right( c + d \right)$


> The presentation elements are meant to
> express the syntactic structure of math notation in much the same way as
> titles, sections, and paragraphs capture the higher level syntactic
> structure of a textual document."  We may not have quite the same
> latitude for formatting the former as for the latter, but the
> structure/format distinction is still there.

Actually one of my gripes about the MathML report is that it over
specifies the formatting. In particular the spacing around operators are
fixed (to often inappropriate values) You can override with attributes
in the document markup but that is not really what I want to see.

Of course MathML also has hooks for giving semantic-only information
without explicit presentational style at all. In particular it mentions
OpenMath at several points as a suitable language. Which is the project
that I am currently working on.

> Excellent!  Something that will work with JadeTex?  Are you
> doing all the math stuff in DSSSL?  Etc, etc.  More info!

Well my dsssl is not yet for public consumption. (and anyway it doesn't
yet work) as I have mainly been trying to map in my own mind how to
understand the hard bits like fences and alignments. I still have to do
the useful but dull work of mapping all the mathml operators numbers etc
to suitable dsssl.

jade/jadetex is what I am using initially but I'd hope to keep to
standard dsssl constructions so that the thing would work with any dsssl
system. This format neutral style specification is presumably the main
advantage of dsssl (otherwise I could more easily just get TeX to read
the MathML files directly).


 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)
        • Sebastian Rahtz - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id FAA15099Tue, 9 Jun 1998 05:06:12 -0400 (EDT)
        • David Carlisle - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id HAA24814Wed, 10 Jun 1998 07:16:40 -0400 (EDT)
      • Reynolds, Gregg - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id LAA19791Tue, 9 Jun 1998 11:44:01 -0400 (EDT)