From: <juanrgonzaleza@canonicalscience.com>

Date: Fri, 7 Apr 2006 08:10:38 -0700 (PDT)

Message-ID: <3970.217.124.69.246.1144422638.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Date: Fri, 7 Apr 2006 08:10:38 -0700 (PDT)

Message-ID: <3970.217.124.69.246.1144422638.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Mikko Rantalainen wrote: [snip] > Okay, could you point us to correct basis for over and under scripts? Well, in the ASCII rendering the base for over is "base" and in your MathML example the base for over is ("base" + "sub" + "sup"). > If you render the above MathML example by e.g. Gecko rendering > engine you end up something fairly similar to above ASCII presentation. And in some cases <msub><msup> can render similar to <msubsup> but we need the latter, ok? > If you want to transfer more semantics you have to give us more > information but just the ASCII rendering of the end result. > As already explained I used an ASCII art contained in a *standard* for math. Any case the point is not possible misunderstanding about above ASCII art did mean. The important question is that MathML 2.0 cannot encode that (like cannot encode other things). > Are you asking for a way to markup a multiscript where you have > scripts at N, NE, SE and S locations (compass directions)? Would you > be happy with a multiscript construct that allowed 8 positions (N, > NE, E, SE, S, SW, W, NW)? Or would there be need for more script > positions? No! I was not asking for. That IS already solved by available *standards* previous to MathML. Today, I do not know of needing for more script positions, but if tomorrow more were needed would be relatively easy extend SGML model because solid markup design. In MathML you would need of dozens of new tags and novel content/processing models. > > Multiscript rendering vs. actual logic > > I believe that there's always some logic for multiscript rendering > that would result from some kind of nested elements. If you have > rendering such as > sup > BASE > sub > then it's always logically either "(BASE_sub)^sup" or > "(BASE^sup)_sub. Usually the former. No! (BASE_sub)^sup and (BASE^sup)_sub and BASE_sub^sup are three different things! Only BASE_sub^sup corresponds to ASCII sup BASE sub This is reason of MathML difference between <msup><msub>BASE sub</msub> sup</msup> and <msub><msup>BASE sup</msup> sub</msub> and <msubsup>BASE sub sup</msubsup> Others markups also differentiate (including TeX and, of course, ISO 12083). The PROBLEM with MathML is the poor design model for scripts, which is not easily extensible except by complicating a lot of the DTD and the parsing. Previous standards did a better work. > Likewise, if you have markup like > ____ > BASE > sub > it's either "(BASE with overline)_sub" or "(BASE_sub) with > overline". I've yet to see a construct where you *logically* have > "BASE with both overline and subscript". Your example would be interpreted like "(BASE with overline)_sub". The render of "(BASE_sub) with overline" would be more close to _______ BASE sub Now, I cannot remember of any construction special kind you are requiring, which, of course, does not mean can it be useful in some discipline. Simply I do not know. > There's, of course, the > rendering. I understand the need to render > sup > BASE > sub > instead of > sup > BASE > sub > where the superscript would be leftwards from "BASE_sub" > combination. However, it's only rendering detail, the logic still > applies that it's (usually) "BASE_sub" to power of "sup". > > -- > Mikko > You are saying is not compatible with both computational and notational issues. One does not render your first example _instead of_ second. That is not true. Two ASCIIs are usually different things! Already in pure mathematics k T i , k T i, and k T i are (usually) three different mathematical objects, *none* of them meaning "BASE_sub" to power of "sup" you wrote. Therefore, you are forced to render them in three different ways. Juan R. Center for CANONICAL |SCIENCE)Received on Friday, 7 April 2006 15:10:54 UTC

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