RE: fences (variable size math symbols)

["Reynolds, Gregg" <greynolds@xxxxxxxxxxxxxx>]

> -----Original Message-----
> From:	David Carlisle [SMTP:davidc@xxxxxxxxx]
> Sent:	Monday, June 08, 1998 12:20 PM
> To:	dssslist@xxxxxxxxxxxxxxxx
> Subject:	Re: fences (variable size math symbols)
> 
> 
	 ..snip.. 

> If I have an mrow element that contains three characters that all have
> the stretch attribute set to true, I need to stretch them all by the
> same amount. This is not the same as arbitrarily taking the
> subexpression containing the first two, making a fence object out of
> that, and then nesting that object in a fence object that wraps up the
> rest of the expression. In particular this latter algorithm would make
> the last fence larger if (as is often the case) the fences are being
> made slightly larger than the surrounding text. However it would
> probably do as a first attempt. Assuming that the effect on line
> breaking (if any) of nesting fence objects is not too detrimental.
> 
	I'm not sure I understand how this would be problematic in
DSSSL.  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?  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?

> > You the user shouldn't need to do any "typesetting"; you
> > need only direct the flow of content into ports/areas, as it were.
> 
> Yes I have to tell myself that every thirty seconds or so when using
> dsssl:-) Coming from an expressive typesetting language like latex,
> using a style language which has no access to the typeset object is
> rather a shock. Like working with both hands tied behind your back!
> 
	True, it's a change, but do you recall what fun it was to learn
TeX?  I sure do.  Like working with both hands chopped off.   Actually I
love TeX, but I think DSSSL will be cooler once we have a full
implementation.
	 
> > That half of MathML explicitly encodes such formatting intentions
> may be
> > disregarded from the perspective of the DSSSL sheet.
> 
> Now this I don't understand at all. If I want to write a dsssl spec so
> that any system that supports the dsssl math objects can typeset
> mathml
> then surely this is _exactly_ the half of mathml that I need to worry
> about. The content part of mathml I was planning to support by
> transforming to the presentation part of mathml. (This mapping is more
> or less fixed in the mathml recomendation.)
> 
	I should have written "That half of MathML *seems* to explicitly
encode..."  I'm kind of a radical when it comes to separation of content
and formatting specs; I just mean that the content tags don't directly
drive the formatting, even where content tags seem to reflect formatting
concerns, as in mathml presentation markup.   MathML is interesting just
because half of it is "presentational" markup; when I first read the
spec I howled in dismay, thinking they had blown the chance to create a
wonderful content-based abstract syntax for math, until a senior
colleague pointed out the error of my ways: at bottom mathematical
notation is itself content, kinda sorta.  I recall reading somewhere
that Euler (or Laplace or some such great mathematician) derived many of
his results purely by manipulating mathematical notations, and was
unable to rigorously prove them.  Anyway, all I meant was that we still
get to treat such markup as logical content as opposed to formatting
specs.  The mathml spec says: "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.
	 
> > 	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.
> 
> Which strange enough is what I am trying to do at present:-)
> 
	Excellent!  Something that will work with JadeTex?  Are you
doing all the math stuff in DSSSL?  Etc, etc.  More info!


	Best of luck

	Gregg


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