From: Stan Devitt <jsdevitt@stratumtek.com>

Date: Tue, 28 Oct 2003 09:22:41 -0500

Message-ID: <3F9E7BB1.4040205@stratumtek.com>

To: silverbanana@gmx.de

Cc: www-math@w3.org

Date: Tue, 28 Oct 2003 09:22:41 -0500

Message-ID: <3F9E7BB1.4040205@stratumtek.com>

To: silverbanana@gmx.de

Cc: www-math@w3.org

In a some sense, xhtml serves much the same purpose for browsers that postscript does for printers. One generally just writes the printer code necessary to cause the printer to show (say the appropriate thing. It is generally an information loosing transformation, although conventions and a clever use of div, span with class attributes can do better (as can a clever use of postscript functions). Thus, I'm really seeing two requests, at least one of which can be easily modelled right now. 1. The capability of embedding (some) xhtml in some part of mathml (so that we can drive the printer better) - This has significant implications for mathml display engines and is an extension to presentaiton mathml. 2. Introduction of one or more meta-math structure to describe multi-step solutions. (an extension to content mathml) There is nothing to prevent modelling this meta-structure in xml and mapping it to tables (or using CSS directly ) for presentation right now. Such a thing could move into the spec once it stabilized. Stan Devitt Bernd Fuhrmann wrote: > > > > > However I think a more portable solution would be to use an xhtml > table to get the layout and use individual math elements in teh xhtml > table cells to typeset the math fragments. > > Using tables for formatting would break the semantical structure of a > XHTML+MathML-document. Furthermore there are cases that would require > to use presentation instead of content markup which would be bad > aswell. Besides, using tables would force a renderer to put certain > data into certain places, while I think that one should be able to > "recommend" formatting. This is especcially important when there are > very long terms and/or narrow pages that require line breaks. A table > could never solve that! > > If there is indeed no way to do this in a reasonable way with MathML > 2.0 to do this, someone should add a mechanism to the next MathML specs. > > Regards, > Bernd Fuhrmann >Received on Tuesday, 28 October 2003 09:21:56 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:34 UTC
*