Re: mover vs latin chars with diacriticals

----- Original Message -----
> From: <juanrgonzaleza@canonicalscience.com>
> To: <www-math@w3.org>
> Sent: Monday, May 01, 2006 7:06 AM
> Subject: Re: mover vs latin chars with diacriticals

<snip>
>> >> Are you sure that Unicode is just a "rendering technique"?
> >
> > Please read what was written.  I said that *precomposed characters* are
> a rendering technique.
>
> Are you sure that Unicode *precomposed characters* are just a rendering
> technique?

Yes.  They are defined to be equivalent to their decomposed equivalent.  Since you are very good at looking at standards when prompted, I'll let you track down the reference as to why they are part of Unicode.

<snip>
> > People in the working group were very aware of its strengths
> > and weaknesses and MathML was developed with feedback from
> > users of 12083 (ie, publishers) as to what to avoid.
>
> Let me doubt this please, in my opinion presentational MathML 2.0 is a
> poor copy of ISO 12083.

Everyone is entitled to their opinion.  Based on your statements here and on your website, you have many opinions, mostly negative, and mostly (in my opinion), far from the main stream.

> > 12083 has "embellishments", which can be used for diacritical
> > marks in the same way that <mover> can be used for
> > diacritical.
> > My comment was that 12083 is silent on the matter which I
> > raised -- ie, whether a character should be used or whether an
> > embellishment should be used.
>
> In my opinion ISO 12083 relies on ISO 8879 (1986) for Diacritical Marks

On what is your opinion based?  Did you find any text in the mathematical section of 12083 to support that?  I didn't.

> > There are a lot of generalities here which about problems with
> > <mover> and <munder>.  Rather than misinterpret what you mean
> > to say, could you please clarify "the well-known difficulties,
> > weakness and error designs of MathML, including
> > incompatibilities with CSS and DOM and all that without
> > review real support of MathML in browsers".  Please list the
> > specifics with respect to <mover> and <munder> (to which your > comment
> applies).
>
> Sorry but Sun would burn all its combustible before ;-)
>
> Some ideas. Firefox does not pass many official tests of the  MathML test
> suite. Something so simple as
>
> <math style="color:blue">
>       <mn>2</mn>
>     </math>
>
> is not passed, one would recover the same error in a more general
> construct with mover or munder. Using a more general Unicode approach I
> could easily implement that effect via a CSS rule.
>
> Similar thoughts apply to official test <mn style="font-size:24pt;
> font-weight:bold">2</mn> and several other tests like mstyleAminscript1 et
> cetera.
>
> My firefox browser does not pass the munder1 and munder2 test, but I think
> that Unicode is not designed for munder2.
>
> I do not find satisfactory rendering of accents in the accent test suite.

Is your logic is that because one implementation does not implement all of MathML or implements some part incorrectly, MathML is bad?  How about looking at support for combining characters in MathML implementations besides FireFox -- I think you'll find that support minimal.  By your logic, combining characters are bad.  Or what about CSS support in browsers -- definite compatibility/completeness issues.  Or maybe XHTML is failure because the leading browser does not support.  Rather than complain about Firefox's limitations, I suggest you take a more positive approach and contribute to the volunteer project by fixing some of the problems.

>
> We also talked at this mailing list about the introduction of base inside,
> the ineffective double markup, and of the needed changes in <mover> and
> <munder> for can be fully incorporated in browsers rendering engine. All
> that was explcitely listed in previous postings.
>
> Moreover, Unicode is designed for on and off web usage. Printing of MathML
> is far from good and some people is transformating it to TeX before
> printing.

What is there in the design of MathML that makes printing bad?  You again criticize the implementations, not the design.
 
>
> The support of MathML in browsers is minimal and this is because
> difficulties for implementation. However, something so old as ISO 12083
> was implemented in Opera browser with minimal changes in original 12083
> (which was not designed for web!!!!).

I disagree that support for MathML in browsers is minimal.  It can certainly be improved, but between FireFox/Mozilla and IE+MathPlayer, 97% or more of the users are covered and the common usage cases are implemented.

As for Opera's 12083 support, are you referring to XML MAIDEN's "Experimental version of ISO 12083 processor written in EcmaScript + DOM + CSS.".  It claims it only runs in "Opera 9TP2" and indeed, I couldn't get it to work in the current Opera 9.00 beta.  If you have seen this work, why do you consider this superior to ASCIIMath's MathML work that makes use of JavaScript and MathML?

>
> Maybe you would think carefully why MathML, *specifically designed for
> web*, is being rejected for implementation in Opera browser (as was
> rejected in MSIE and others).

MS invented a mechanism that allows third parties to extend the behavior of IE so that MS didn't need to build in the kitchen sink.  IMHO, this is good design.  They specifically added functionality to support baseline alignment needed by MathPlayer -- that is an acceptance of the importance of MathML, not a rejection of it.

I can't speak to the reasons why Opera has not implemented MathML.  Perhaps they felt their target audience wasn't interested in math or that support for math was too costly for their target market (they apparently decided full support of SVG was too costly).  They are somewhat alone in not supporting MathML.  Although Safari currently doesn't support MathML, they would like to -- it was one of the most requested features when they had a poll several years ago.

<snip>
> I repeat again that Unicode is a standard whereas MathML is not and we
> would prefer more general "markup" over specific one.

If I remember correctly, your reasoning is based on the fact that the W3C doesn't issue standards, just recommendations.  So HTML, XML, CSS, XSLT, ... are not standards either (despite your site referring to XHTML as a standard -- a double standard on what is a standard :-).  Who is the "we" you refer to? 

<snip>
> > Wrong:  Unicode's "COMBINING DIAERESIS" (308) has several
> > aliases, one of which is "double derivative".  So if you
> > feel the informative alias as "double derivate" is a good use
> > of the code point, you have lost the distinction between
> > the two.  If however, you use it as a diaeresis and use
> > <mover> to represent the mathematical meaning, then you
> > have distinguished between the two usages.
>
> I doubt that you can find ambiguities on the aliases of 0308; in
> mathematical usage it can be interpreted as double derivative. No, you
> cannot use 0308 for diaresis as you are claiming because the code for
> diaresis is 00A8!!! I repeat again that Unicode is able to distinguish
> usages but MathML <mover> cannot.

I'm surprised your are making a claim that 00A8 is suppose to be used for diaresis.  The entry for it clearly says it is a *spacing* character, not a combining character and the entry even says that it is roughly equivalent of 0020 (space) + 0308.  Using Unicode's combining characters for math almost always will result in ambiguities between its linguistic meaning and its mathematical meaning.


Neil Soiffer
Senior Scientist
Design Science, Inc.
neils@dessci.com
www.dessci.com
~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~