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

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 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:34 UTC
*