Re: mover vs latin chars with diacriticals (also MathML support)

Neil Soiffer wrote:

>> 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.

I thought that o + combining-diaeresis and ö were two different things in
Unicode even when both are rendered equal. Of course, both are defined to
be "canonically equivalent" via "canonical decomposition" but are not
defined to be "equivalent".

> 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.

I have negative opinions on I consider are bad approaches and positive
opinions on I consider excellent ones (like anyone). Moreover, mainstream
does not mean more correct or better.

>> 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.

No, I did not find; that is reason I said in "my opinion". It is based in
the design of the DTD.

> 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.

I think that this point was roughly discussed in the past. The
difficulties on the implementation of MathML in browsers are due to
weakness of the MathML specification. I was trained by common hype that
"malign browsers developers" was stopping the spread of MathML but
developers claim me that real issue is that it is very difficult or even
impossible implement MathML 2.0.

That is reason that w3c CSS WG "abandoned" mathematics support. I have
been trained that MSIE was earlier interested in native support for MathML
but at the end they prefered an "external plugin" via third parties
because direct implementation of MathML in the MSIE rendering engine would
be unsafe for the browser. The same about additional module on Firefox; I
suspect limitations on Firefox support are due to own difficulties of the
implementation of MathML.

Opera browser developers like support for mathematics but explicitly
rejected native support for MathML because implementation was considered
unsafe. The problem is that MathML language cannot be integrated with rest
of technology.

The support of combining characters is minimal but it will increase. I am
not seeing exponential increasing in MathML support. I am beginning to
suspect many people will abandon MathML when discover its difficulties and
limitations. XSL-FO was popular in some niches (book printing) in the past
but now is apparently forgotten.

Take my own case as example, I adopted experimental MathML support in 2005
and now abandoned support in 2006, since it does not fit my requirements
and since there exists a big hole between MathML promises and that it
really achieves.

MathML promised good printing, searching, accessibility, content,
rendering, and standardization on scientists’ communication.

In practice, people translate MathML to TeX for printing (Prince’s
developers attempting to develop direct support for MathML printing have
need of many work, tricks, and modifications on the specification; I do
not know details). I suspect that others will translate to other languages
for printing.

Searching is not working, and leader search engines recommending to me
others ways for the journal. Even if tomorrow a specific MathML search
engine is implemented, I simply do not know how search, since each
document is encoded in different ways. Look example of q-dot encoded in
four different ways even by the same application.

Take the case of E = mc^2. I could try with E = mc2 (or E=mc^2) in Google
and works (is not excellent but works). Please could you explain me that
would I search if E = mc^2 is encoded in MathML (by commodity to write
only half a dozen of possibilities offer us the "standard").

Accessibility of MathML code in most of cases is poor than using the old
HTML + GIF + ALT. It is more, a guy writing a relativistic element of line
in pure HTML is doing better than MathML code is being served in journals
as Living reviews on relativity or ultra-technological blog such as that
of string theorist Distler. The first guy encode (ds)^2 in an old HTML
whereas MathML is being used as d(s)^2 (i.e. 2s ds).

Content MathML is mainly inexistent on the web (accessibility issue again)
and has problems also. I suspect many people would prefer to deal directly
with more solid designs as OpenMath.

Visual rendering is poor, due each author generates different
presentational code for same concept. Even the same code so trivial as
<mi>d<mi><mi>x<mi> is rendered as

"d x" in Firefox but "dx" in IE + MathPlayer

Moreover there are difficulties associated with extra mrows of usual ugly
code, there is not fine-tuning, most of formulas look better (at least
without zoom) using jsMath, which is based in a mixture of HTML and
images, et cetera.

About supposed advantages of using a standard for communications, I
provided an example of MathML code generated by different tools was
submitted to Mathematica 5.2 and two failed and the others rendered in
different ways. Using a simple TeX \dot{q} the equation would be more
"standard" and would work in any computer or tool with minimal TeX
support. I can interchange a TeX document containing $\dot{q}$ with
colleagues. If I received a MathML encoding of \dot{q}, which code would I
wait of four ones I listed? How many different ways are being distributed
in the Internet below a hype of "standardization"?

Before waiting miraculous spreading of MathML or forcing adoption via
publicity and advertising in conferences, papers, use it, use it, use
it... I would gently suggest you take a more positive approach and
redesign MathML from the bottom, eliminating all errors done in the past
in the next 3.0. Then all browsers will adopt native support;
accessibility will be a reality; author become happy...

Please do not claim that a body as w3c cannot do backward incompatible
changes because w3c has a good experience on those changes.

> 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.

Clearly we mean different by "support", somewhat as we perceive problems
in different ways. From the MathML FAQ

<blockquote>
MathML is XML-based. Will the browser manufacturers support XML fully?
Will they support MathML natively ?

Yes. Both Microsoft and Netscape have publicly declared support for the
XML recommendation. Some XML support is already available for IE 4. As the
browser manufacturers move toward fuller support of XML and the associated
style sheet standards such as XSL that are developing, support for MathML
will become more "native".
</blockquote>

Hum, now we observe XML support in many (all?) browsers, but I see only
"native" (via external module and not passing MathML official test suite)
support in Firefox/Netscape.

> 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?

I was referring that via small changes in the original ISO 12083,
XML-Maiden let us render lot of math using just CSS. If MathML WG had
modified the ISO 12083 for adapting it to the web instead of "reinventing
the wheel" situation now would be close one wait.

The changes needed in Firefox or in MSIE for supporting XML-Maiden are
minimal and just needed of a better support of available CSS 2. You will
not need an external plugin in MSIE.

About ASCIIMath/MathML I prefer something as XML-MAIDEN 2.0 (clearly
motivated by previous ISO 12083)

<math>
  <fraction>
    <num>1</num>
    <den>n</den>
  </fraction>
</math>

over MathML

  <math title="1/n" xmlns="http://www.w3.org/1998/Math/MathML">
    <mstyle mathcolor="red" displaystyle="true" fontfamily="serif">
      <mfrac>
        <mn>1</mn>
        <mi>n</mi>
      </mfrac>
    </mstyle>
  </math>
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <mstyle mathcolor="red" displaystyle="true" fontfamily="serif">
      <mo></mo>
    </mstyle>
  </math>

First is XML and can be fine-tuning, decorated, etc. via CSS (or FO if you
prefer!) as I already do with HTML or XHTML text.

In MathML, I need learn new redundant tags and models as <mstyle>,
<maction>, etc. CSS does not work in my brosers for math but does for
text...

XML-Maiden is very easy to extend. It is trivial to add accessibility to
above XML-Maiden code. I cannot do it in ASCIIMath and I am obligated to
learn a new language (Content) and add <semantic> and <annotation> by hand
or use a different tool. Moreover, none browser can understand content
(and then for what?). Whereas today available browsers would understand
accessibility of a XML-Maiden mathematical code with minimal or maybe none
change.

Moreover, many MathML code generated with ASCIIMath is based in trick
usage; for example roman tokens are recommended to be entered as ‘H’ being
outputed as <mtext>H</mtext> or the recommended hint sum{::}_(k=1)^n which
offer us the MathML

  <math title="sum{::}_(k=1)^n" xmlns="http://www.w3.org/1998/Math/MathML">
    <mstyle mathcolor="red" displaystyle="true" fontfamily="serif">
      <mo>&#8721;</mo>
      <mrow>
        <msubsup>
          <mrow>
          </mrow>
          <mrow>
            <mi>k</mi>
            <mo>=</mo>
            <mn>1</mn>
          </mrow>
          <mi>n</mi>
        </msubsup>
      </mrow>
    </mstyle>
  </math>
  <math xmlns="http://www.w3.org/1998/Math/MathML">
    <mstyle mathcolor="red" displaystyle="true" fontfamily="serif">
      <mo></mo>
    </mstyle>
  </math>

If you consider that way to be a good approach to mathematics on the web
then...

For additional comments on ASCIIMath and why I rejected see

[http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html]

> 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.

Except that they decided math support was needed (but not following MathML
design ;-). They support natively SVG (whereas continue rejecting MathML
as MSIE also did and continues doing it).

They can render MathML via external processor (therefore the claim to "too
costly" is again hype "how good MathML is and how bad browsers vendors and
developers are" we are reading for years in many places). They rejected
was native support for the ugly MathML implemented in the rendering
engine.

Many people does not know weakness of MathML, only know that there is a
mathematical oriented markup from the w3c with lot of promises for
accessibility, structure, searching, "standardization", content...

Therefore, it is not difficult to understand the Safari poll results. This
behavior is also seen in Opera polls.


> 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?

Yes, MathML is w3c recommendation not standard. ISO 12083 is international
standard. HTML is also standard (ISO-HTML), etc.

The site is incorrect. I obtained wrong idea of that MathML or XHTML are
standard from many places.

For instance in "The Importance of MathML to Mathematics Communication"
sited at MathML official site I read

<blockquote>
Recent years, however, have witnessed a significant step forward in the
form of a standardized encoding for mathematical notation called
Mathematical Markup Language, or MathML.
</blockquote>

or

</blockquote>
Standard protocols and formats for exchanging structured data, such as
HTTP, HTML, and XML are fundamental to the software architecture of the
Web. In the case of math, MathML has become established as the standard
format for math in XML, and this stands to benefit mathematical software
development in a number of ways.
</blockquote>

Note also how I said that XML was a standard so recent as

[http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html]

Now I know that w3c is not a standard body, just a consortium.

Do not worry, homepage will be updated. Whereas above Canonical Science
Today page will be superseded by a new focusing on math and science I am
preparing since some time ago.

However, I detect a kind of double standard in many w3c folks. At the one
hand, the advantages of being using "standards" are popularized, but after
previous standards are ignored and substituted by models, specific
markups, specifications needing of further economic efforts by final
users, why?

> 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.

Yes, big mistake from my part, sorry. Not sure but I think that I was reading

00A8  168  die           isodia      =dieresis

in the MathML page

[http://www.w3.org/TR/REC-MathML/chap6/bycodes.html]


You are right at that point but I cannot agree in the rest.

i) You claimed in repeated occasions that presentation MathML is designed
for presentation, not for content. Then why you are now so worry that ü
and ü can be ambiguous? Is not the objective of Content MathML that of
disambiguating things rendering equal?

ii) Take a look to Bruce Miller <mi><mo> proposal

[http://lists.w3.org/Archives/Public/www-math/2006May/0004.html]

iii) I will support Unicode standard before w3c recommendation because I
do not see problem on ambiguity you claim and because I see more benefits:
search, rendering, on and off usage, et cetera.

>From Robert Miner article cited above

<blockquote>
Having a standard format also provides a clear direction for developing
conversion and import and export capabilities in specialized math
applications. A standard also encourages better, more uniform extension
architectures in generic applications, which benefit add-on math
components as well. Finally, and not least significantly, a standard
decreases the risk of investment and increases the potential for return,
which stimulates software
</blockquote>


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


Juan R.

Center for CANONICAL |SCIENCE)

Received on Tuesday, 2 May 2006 15:44:30 UTC