W3C home > Mailing lists > Public > www-math@w3.org > July 2003

Re: Accented variables

From: Robert Miner <RobertM@dessci.com>
Date: Thu, 31 Jul 2003 10:59:00 -0500
Message-Id: <200307311559.h6VFx0t23739@wisdom.geomtech.com>
To: jpederse@wiley.com, S.Pepping@elsevier.nl
CC: www-math@w3.org


Hi.

Simon Pepping wrote:

> Is there a specific or recommended set of characters which are suitable for
> accents on math variables? The symbols in the entities file isodia.ent
> http://www.w3.org/TR/MathML2/isodia.html may be a good candidate set. But
> they are all spacing accents, which by themselves are already higher and
> smaller than a normal character. This situation seems to be identical to the
> prime, discussed on this list:
> http://lists.w3.org/Archives/Public/www-math/2002Nov/0024.html.

and John Pedersen wrote:

> Is the set of combining diacritical marks (Unicode blocks U+0300-036F and
> U+20D0-20FF) more appropriate for use as accents (even though most don't
> have symbolic names)? There they do have, for example, an under dot
> (U+0323) in addition to the over dot. In MathML I suppose it would still
> need the <munder> treatment though (outside of <mtext>).

I can say a bit on the subject, but I'll start with some background
for the record.  I'm sorry this will sound pedantic to experts like
Simon and John.

The basic problem here (as usual) is that math and text are
different.  Combining and spacing diacritical marks make sense for
text, as do marks that are pre-raised and at "scriptlevel=1".  But as
you guys obviously realize, that model just doesn't work very well for
many situations in math, where you want the accent to be applied to an
expression. 

MathML took the point of view that math accents virtually always
represent operators, that is, no one use "x tilde" as a variable name
-- they mean the unversal covering space of x or whatever.  As a
result, MathML wants that relationship to be encoded in the markup,
as a base expression decorated with an accent, via msub, msup, etc.
As Simon notes, this is identical to the prime case.

Of course, the problem is that the typesetting for "a acute" is going
to be different that for "gamma sub t acute".  In particular, there is
likely going to be a special glyph in your font for a acute, or at
least for the combining accent, but with the compound constructions,
the rendering engine is going to have to handle it specially. 

MathML itself doesn't say which, if any, of the various possible
accent characters is preferrable, e.g. overdot vs. combining overdot
vs. center dot when what you mean is "derivative".  For one thing, its
probably a hopeless job to try to identify a single cannonical
character for every possible mathematical meaning, when in point of
fact, none of the text-oriented Unicode characters available is a very
good fit.  Now if a major publisher like Elsevier or Wiley wanted to
come up with a set of conventions, and disseminate them, that would be
a big step forward.  But as of today, there really isn't any such set
of conventions.  So, for better or worse, I guess the real answer to
your questions is "use the character that works best in most
applications."

Therefore, MathPlayer (and I assume Netscape/Mozilla) puts a lot of
effort into analyzing accent constructs and trying to do the right
thing.

If you think it would help you, I can look into distributing a
(probably partial) list of "accent characters" that MathPlayer gives
special treatment.  I'm a little hestitant to commit MathPlayer to a
specific list, since I don't have tons of faith we have made the right
decisions in every case.  However, if you guys are thinking about
establishing markup conventions within your companies, it would give
you some hard information to start with.

Let me know if you would find this useful.

--Robert

------------------------------------------------------------------
Dr. Robert Miner                                RobertM@dessci.com
MathML 2.0 Specification Co-editor                    651-223-2883
Design Science, Inc.   "How Science Communicates"   www.dessci.com
------------------------------------------------------------------
Received on Thursday, 31 July 2003 11:59:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:55 GMT