Subject: RE: fences (variable size math symbols) From: "Reynolds, Gregg" <greynolds@xxxxxxxxxxxxxx> Date: Mon, 8 Jun 1998 17:41:10 0500 
> 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 contentbased 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
Current Thread 


< Previous  Index  Next > 

Re: fences (variable size math symb, David Carlisle  Thread  Re: fences (variable size math symb, David Carlisle 
Ventura 4.XX and MIF backends, DELAHAY F. ESO/DAI  Date  Re: fences (variable size math symb, David Carlisle 
Month 