Re: mover vs latin chars with diacriticals

Neil Soiffer wrote:

[snip]

> "=" means it is an informative comment.  Standards have
> informative comments and normative statements.  Informative
> comments are *not* part of the standard.  The informative
> comment says this can be used for the newtonian derivative
> notation, not that it should be used.

The Unicode folks explain the "legend":

i)  Upper case means Unicode name.

ii)  = means alternative name

iii)  · means informative note.

iv)  -> means cross reference

et cetera.


In the Unicode range I cited, I found 0307 with next description

<blockquote>
= derivative (Newtonian notation)

· IPA (withdrawn in 1976): palatalization

-> 02D9 "^·" dot above.
</blockquote>

If I understand correctly above Unicode legend (obtained from page 413 of
Unicode Standard 4.0 book) the "IPA palatalization" is an informative
comment whereas "derivative (Newtonian notation)" is an alternative name
(with semantics built-in).

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.

This is easy to understand. The important point is that Unicode is able to
differentiate dot above 02D9 (text) from combining dot above 0307
(formal), as it is able to differentiate between 0308 from 00A8 diaresis.

0308 may be useful for composition of mathematical "\ddot{u}" whereas 00A8
can be used in text for example in Spanish word "Cigüeña" (there is
already a special Unicode for this letter due to importance). Ü is a
letter; the "\ddot{u}" is a double derivative of u.

Then why is "= derivative (Newtonian notation)" not forced?

Because "\dot{u}" can be used in mechanics as (du/dt) (Newtonian
derivative) but in TIP and EIT thermodynamics it is common that "\dot{u}"
means (\partial u \partial t) because one work in a field-theoretical
approach.

That Unicode STANDARD really says is that exists semantic difference
between 0307 and 02D9 and the same about Unicodes 0308 and 00A8. That is
more presentational MathML 2.0 and the soap of <mover> and <munder> can
do.


> Citing STIX fonts as having pre-composed diacriticals is
> irrelevant.

The philosophy underlying STIX support for Unicode was explained by Tim
Ingoldsby in "Essential Technology for Scholarly Web Publishing" (American
Institute of Physics):

<blockquote>
One of the key enabling technologies that has made the STIX Fonts project
feasible is the development of the Unicode™ standard.
</blockquote>

<blockquote>
Unicode is an international standard (ISO10646) that describes a universal
character set designed to represent all major scripts of the world, as
well as technical symbols used in communications.
</blockquote>

<blockquote>
Unicode support is important for the STM community, because it provides a
unique way to identify every special character required for STM
publishing. All computer operating systems, all software applications
(e.g., word processors, symbolic algebra
tools, spreadsheets, etc.), and Web browsers have or soon will have full
Unicode support. If characters are identified by their Unicode reference,
and if all individuals have a set of Unicode fonts (like the STIX Fonts),
it will be possible for any author to publish a document encoded with the
Unicode character set and any reader to obtain the document with the
assurance that they will be able to properly interpret every character
contained in the author’s writing.
</blockquote>


> Precomposed characters  (as noted by some of the
> places you quote and the Unicode standard) can provide a better
> rendering.  However, they are a rendering technique and there is
> no reason a smart MathML renderer shouldn't substitute those
> glyph's for <mover> *if* they are available.

Are you sure that Unicode is just a "rendering technique"?

>> [http://www.geocities.com/chavchan/userjs/support.xml]
>>
>>Support for ANSI/NISO/ISO-12083 Mathematics DTD
>>
>> "Overscripts should not be used to produce accents, Unicode
>> based solutions (either combining diacritical marks, or
>> precomposed characters) are preferable in this case."
>
> 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?

I thought that was clear that

[http://www.geocities.com/chavchan/userjs/support.xml]

was a page to userjs-support by "chavchan" stored in geocities and titled

"UserJS processors for ISO-12083 Mathematics DTD and MathML 2.0"

I also thought that people at MathML would be able to see that ISO 12083
was developed ***before*** Unicode. Therefore, It is really surprising
that a MathML WG folk is claiming:

"As far as I could see, 12083 is silent on the matter."


By using MathML <munder> and <mover> instead of Unicode, one recover all
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. Unicode is designed for both on and off web
usage.

What is more, using standard Unicode one can add "semantics" (at least one
can differentiate dieresis from a double dot), whereas the <mover> of
MathML specification cannot.

Finally to say that if tool A based in Unicode try to communicate with
tool B using MathML, it will be needed some kind of conversion tool or
intermediate layer. I believe that this may be fine for programmers and
business specialized in scientific and technical packages (because need
for new commercial tools, new versions of current ones et cetera) but may
be not good for final users.


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

Therefore, I would encourage again support for *international standards*
before specific support for a w3c recommendation is not being very popular
and has many presentational problems.


Juan R.

Center for CANONICAL |SCIENCE)

Received on Saturday, 29 April 2006 18:21:37 UTC