Next Steps for RTL Math

Hello all.

Thanks to everyone who has written in with information about how math
is handled in Arabic and other RTL languages.  Let me attempt to
summarize the discussion so far, and outline some possible next steps.

1) There seems to be pretty good agreement as to how math
   should be rendered in Arabic (and probably other RTL languages 
   though most of the discussion has been about Arabic.)  The
   list technical MathML issues is fairly short:

   - Is a single attribute, such as xml:lang, sufficient to control
     layout direction?  The answer seems to probably be yes.
     Dr. Lazzrek's paper on modifying Mozilla takes a different
     approach of introducing new RTL versions of layout constructs
     like msup.  But it seems to me that this is conceptually
     equivalent to having an attribute on the standard constructs,
     even if that may be harder to implement in Mozilla.

     Some words are also probably required to explain the interaction
     with the Unicode bidi algorithm, which we should continue to
     respect for CDATA within MathML tokens.

   - There is an issue with the values of the mathvariant attribute
     not being appropriate for Arabic scripts.  E.g. Arabic math
     should permit values like 'looped' and 'stretched', in addition
     to the 'bold', 'sans-serif', etc values for Latin math.

   - There is an issue with Hindic vs Arabic numerals.

   - There is probably a need for a transliteration mechanism for
     cut-and-paste, etc.

   - There are many localization issues with content MathML.

   - A definitive list of symbols that should be reverse or partly
     reversed is required.

2) It seems to me that the goal of this activity should be to promote
   the development of software supporting RTL math.  I can see several
   ways to do that.

   - We can reduce the risk of supporting RTL math to software
     developers by producing a document that clearly defines what that
     means, e.g. by covering the list above.  This helps software
     developers, since they don't have to collect the requirements
     themselves, and can be reasonably certain if they implement it as
     we describe, it really will me user needs in a large part of the
     Arabic-speaking world.

   - We can increase the potential value of supporting RTL math, by
     improving the interoperability of MathML with other RTL and LTR
     math software.
   
   - By merely having an activity, we can increase awareness, serve as
     a clearing house for information about RTL math software, gather
     use cases, etc.  All of this helps create a viable market for RTL
     math software.  I think a little basic marketing data would be
     very helpful here.  For example, I personally don't have a clear
     idea of how widespread the use of computers in education is in
     the various parts of the Arabic-speaking world.


If there is general agreement on these points, as a next step I would
suggest trying to come up with an outline for a W3C Note on the
subject, and to identify people with the time to serve as
authors/editors for such a Note.

Comments?

--Robert

------------------------------------------------------------------
Dr. Robert Miner                                RobertM@dessci.com
W3C Math Interest Group Co-Chair                      651-223-2883
Design Science, Inc.   "How Science Communicates"   www.dessci.com
------------------------------------------------------------------

Received on Tuesday, 30 November 2004 19:15:12 UTC