Re: Ideas for future improvements

> In any event, this is all water over the dam. Deprecating any
Presentation MathML tags would break too many implementations.

In the context of browser implementations, there are not many
implementations to "break", especially if such ideas end up helping browser
vendors to actually implement MathML. Converting to such a "restricted"
profile seems trivial.

Peter.


On Wed, Dec 3, 2014 at 11:29 PM, Murray Sargent <
murrays@exchange.microsoft.com> wrote:

> Re <mfenced> I think it should be kept and I'd prefer if <mnary> were used
> instead of the pot pourri <msup>, <msub>, <msubsup>, <mover>, <munder>,
> <munderover> for n-ary expressions. In OMML, there's <d> (essentially
> <mfenced>) for delimited objects (parenthetical/bracketed expressions) and
> there's <nary> for n-ary expressions. <nary> has three arguments: two
> limits and a n_aryand, whereas the pot pourri tags don't identify the
> n-aryand. OMML is an XML where you know from the opening tag what the
> object is, whereas Presentation MathML needs sophisticated parsing much
> along the lines needed for the Unicode plain text encoding of mathematics (
> http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf). In fact,
> the Microsoft Office MathML parser uses the rich-text string stack
> originally developed for building up plain-text math content.
>
> The main math layout ideas are documented in The TeXbook in Appendix G. In
> particular, you have objects with arguments and you measure the arguments
> (recursively) and place them along with lines, etc. as needed for the
> objects. A delimiter object is handy since you measure its contents and
> then display the result with brackets that fit (according to special
> rules). The inline approach seems more complicated to me. At least it
> requires a different approach from objects such as <menclose>. For the same
> reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use
> nontrivial code to convert the inline versions to the prefix versions.
>
> In any event, this is all water over the dam. Deprecating any Presentation
> MathML tags would break too many implementations.
>
> Murray
>