- From: Robert Miner <robertm@dessci.com>
- Date: Sun, 30 Apr 2006 18:39:13 -0700
- To: "White Lynx" <whitelynx@operamail.com>
- Cc: <www-math@w3.org>
- Message-ID: <D1EFB337111B674B8F1BE155B01C6DD619089C@franklin.corp.dessci>
Hi. In my experience, font designers don't do a good job with many mathematical accents. Partly this is because mathematics often takes them out of context. The font designer makes sure the tilde goes well with the n, not the capital X. Also, mathematics must frequently stretch accents to position them over multi-character symbols. Another issue in many fonts is that the accents don't behave properly with respect to italic correction. For really high quality mathematical typesetting, in many cases, you have to take apart these symbols and render and position the glyphs yourself. Another context where mover is preferrable is where semantics is required. Many deployed assessment and/or interactive tutorial systems I'm aware of that use MathML (and there are actually quite a lot) employ heuristic rules that look for <mover> to detect things like complex conjugation overbar and differentition dots. For example, in XSL it is much easier to write rules matching the tag name and the CDATA content than it is to parse the CDATA comment to look for these kinds of constructs. All that said, I believe the rule is fairly simple and should be: 1) For the short list of mathematical accents is wide use as operators (tilde, bar, dot, etc) the mover construct is usually preferable. 2) Whenever the combining character is there because the variable or text is in a language that requires it -- e.g. 3 apples + 2 apples in German and so on -- clearly use Unicode. 3) Use your judgment for the rest. It depends on what works, and who you are targeting. --Robert Dr. Robert Miner Director of New Product Development - our address has changed- Design Science, Inc. 140 Pine Avenue, 4th Floor Long Beach, California 90802 USA Main: (562) 432-2920 Direct: (651) 223-2883 Fax: (651) 292-0014 robertm@dessci.com www.dessci.com -----Original Message----- From: www-math-request@w3.org on behalf of White Lynx Sent: Sat 4/29/2006 4:28 AM To: www-math@w3.org Subject: Re: mover vs latin chars with diacriticals > If the spec is currently silent on this (maybe I missed where it talked about it), > do people think that the spec should recommend one form over the other? > If so which form? > [In case it is not obvious, I think <mover> should be recommended in the spec] For me it is far from being obvious. There is Unicode standard that defines combining diacritical marks some of which are by design intended for usage in mathematical formulae. Using redundant ad hoc markup instead of more universal Unicode solution that can be used in any XML application and even plain Unicode text is not the best option IMHO. Note also that current font formats provide mechanism (OpenType, Graphite) that lets font designers to specify exact position of combining diacritical mark with respect to base character (STIX and Gentium are examples of such fonts). In MathML approach it is unclear how MathML processor should retreive font metrics that ensure accurate positioning of accents. In addition note that Unicode standard specifies normalization mechanism that establishes correspondence between composed/decomposed characters (it is needed for string comparison/search purposes). > My reading of this is that if your dot means differentiation, you should > use mover. If x-dot is just some wierd atomic symbol chosen by an > eccentric author you should use the unicode. As Juan already wrote, there is combining diacritical mark specially reserved for time derivatives. > > [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). That page describes what is preferable in concrete implementation (UserJS processor for ISO-12083) it does not quote ISO 12083 (that was developed before Unicode standard). -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Received on Monday, 1 May 2006 01:39:29 UTC