Re: mover vs latin chars with diacriticals

Neil Soiffer wrote:

> Please see
> http://www.unicode.org/versions/Unicode4.0.0/ch16.pdf
> for a full description.  Here is an excerpt about "Aliases"
>
> <blockquote>
> Aliases
> An alias (preceded by =) is an alternate name for a character.
> Characters may have several aliases, and aliases for different
> characters are not guaranteed to be unique. Aliases are
> informative and may be updated....
> </blockquote>

Just I said

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

<blockquote>
But if you ask if 0307 may be interpreted *always* as Newtonian
derivative, the reply is not. This is reason that Unicode standard says
that alias may be useful alternative choices but at the same time warning
us that alias is informative and may be updated in future Unicode
standards.
</blockquote>

I already said that alias was informative. Note also offered an
explanation of why.

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

>>> This is one person's opinion, not what ISO-12083 says.  As
>>> far as I could see, 12083 is silent on the matter.
>>> While it is informative to get another opinion on this,
>>> implying that this is what 12083 says is false (at least as
>>> far as I could see in 12083's math section).
>>
>> Implying that this is what 12083 says? Where?
>
> Again, you misread what I wrote.  I was merely clarifying what you
quoted as being one person's opinion, not what was contained in the
12083.

Would be interesting see exactly in what part of the previous link the
author was saying that comment on Unicode "was contained in the 12083."

> Of course the MathML committee members knew that 12083 was
> developed years before MathML.

Which may do more difficult to understand some design options taken by the
committee.

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

> I realize that English is not your first language; before you
> resort to insulting remarks about the intelligence of others,

It was no my intention. But if you feel better, please let me add I
consider to myself to be not clever. One can see couple of mistakes and
errors I did in

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

for instance.

> 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

Seeing the general character of entities in ISO 8879

Most are accents, more breve, caron, cedilla, dieresis, etc. and seeing
that there is not double dot I suspect that are left to textual purposes.
However, I suspect that in future revision of ISOs we will be increasing
usage of specific mathematical international standard Unicode ranges.
Which would be preferred over specific non-standard markup as <mover> and
<munder>.

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

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.

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

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

It is also know that MathML specification is easily abused. We saw
examples of this. White Lynx listed examples of abused <mover>

I will list examples of MathML output for q-dot and renderings via
Mathematica 5.2. It is a disaster. That is avoided using Unicode.

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

> This is both a red-herring and wrong.
> Red herring:  Presentation MathML is meant to be used for mathematical
> notation.  It is not meant to be used to construct linguistic
> modifications of characters...as several people have already replied.
> Nor is it meant for writing chemical formulas (another area where you
> misapplied MathML and used it as evidence MathML is flawed).

Hum!

i) Unicode is able to differentiate diaresis from double dots and all
that. MathML <mover> and <munder> say nothing.

ii) Argument claiming for what was designed presentation MathML forgets
that content Markup is not popular. Most of tools and all browsers focus
on presentation MathML. By forcing usage of <mover> and <munder> we are
forcing ambiguous coding because content MathML will be not used for
disambiguating.

iii) It is interesting see that MathML is not designed for chemical
formulas. Several points about this.

a) From descci.com I obtained

<blockquote>
WebEQ
Interactive math on the web

Design Science WebEQ™ Developers Suite is a comprehensive toolkit for
building web pages that include interactive math. The world's leading
e-learning companies, content developers and education portals are using
WebEQ to create web-based learning environments that help educators engage
students in math and science on the web. Because WebEQ is based on Java
and MathML technology, solutions you develop will be platform- and
browser-independent.
</blockquote>

The Features page says "Expanded editor preferences, including new support
for chemistry notation". Please explain there to your readers/users that
MathML is not designed for chemical notation.

b) I thought that x + y = xy was math (Boole algebra). I thought that Na +
Cl = NaCl was math also and that is just chemistry if I said that Na and
Cl are. Somewhat as E=mc^2 is math but E=mc^2 is physics if you explain
that E is energy m is mass...

m can be negative in pure math, E=mc^2 is "equal" to y=ax^2 but m in
physics is not negative...

c) Please note that next fragment

<blockquote>
In different presentational contexts, the multiplication operator might be
invisible " H  e", or rendered as the spoken word "times". Generally, many
different presentations are possible depending on the context and style
preferences of the author or reader. Thus, given " H  e" out of context it
may be impossible to decide if this is the name of a chemical or a
mathematical product of two variables H and e.
</blockquote>

in "4.1.1 The Intent of Content Markup"

[http://www.w3.org/TR/2003/REC-MathML2-20031021/chapter4.html]

may be confusing for readers.

d) Here

[http://chem2.chem.ncsu.edu/~hennesse/Experiment_29.xml]

MathML is being used for "for writing chemical formulas"

And also in ASCIIMath page here

[http://math.chapman.edu/cgi-bin/mathxml.pl?ASCIIMath_Comments_and_Suggestions]

The situation in last page is still poor because a trick is used for
rendering roman tokens.

Please take the time for personally aware to that entire people that
MathML was not designed "for writing chemical formulas" and they are
"misusing" it.

e) When I mean the use of MathML for rendering simple chemical formulae I
mean similar thought to expressed by Digital Archive of Journal Articles
National Center for Biotechnology Information (NCBI) National Library of
Medicine (NLM)

here

[http://dtd.nlm.nih.gov/tag-library/2.0/n-2r30.html]

f) I also find interesting to see as The American Physical Society writing
the formula for water using TeX, whereas apparently MathML is not thought
for that.


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

By using <mover> the tool has absolutely no idea that I am encoding and
one recover all errors and difficulties cited previously.

>
> 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 Monday, 1 May 2006 14:06:34 UTC