[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Next Steps for RTL Math
- To: General Arabization Discussion <general at arabeyes dot org>
- Subject: Fwd: Next Steps for RTL Math
- From: Youcef Rabah Rahal <y dot rahal at gmail dot com>
- Date: Thu, 2 Dec 2004 13:34:01 +0100
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Z6DWh6M8jaX/PPx3VscRsfuZf4fj25Mk/j3JO1kiMkqrvZd94vIfKTyPbwPgzx2Oby0pBi9a8lKMia94wbeQT1MaUbfcVpU326tTV7EwQoo1/xcgqQv+P2mL3t8Vn5+5RNAJmdmTub/ZxA238mwlCU2HYzbz1ZOYBYl/dQZttP0=
FYI
---------- Forwarded message ----------
From: Robert Miner <robertm at dessci dot com>
Date: Tue, 30 Nov 2004 13:14:39 -0600
Subject: Next Steps for RTL Math
To: www-math at w3 dot org
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 at dessci dot com
W3C Math Interest Group Co-Chair 651-223-2883
Design Science, Inc. "How Science Communicates" www.dessci.com
------------------------------------------------------------------
--
Youcef R. Rahal