On Fri, 24 Oct 2003, Chris Whiting wrote:
"Bob Hallissy" <Bob_Hallissy(_at_)sil(_dot_)org> wrote in message
I presume your algorithm depends on the Arabic presentation forms available
as separately encoded >characters in Unicode. If this is the case,
The algorithm, and all that I have seen, convert Arabic characters in the
\x{06--} range to Arabic Presentation Forms A ( starting at \x{FB50} or B
( starting at \x{FE70} ) characters depending on their medial, isolated,
initial, and final values per the Unicode standard.
When all you have is a 'dumb' font without opentype GSUB/GPOS tables
for Arabic, converting a sequence of U+06xx characters to a sequence
of characters in the Arabic presentation form is a reasonable (but
certainly limited) _fallback_. At the moment, Mozilla (on Linux) uses
the technique. However, Arabic presentation forms are not there
to be used forever but are there for the sake of backward compatibility.
(see the explanataion about the block in Unicode 4.0 which is available
in PDF at http://www.unicode.org) Nonetheless, what you plan to do would
be useful.
When intelligent fonts (such as opentype fonts, Apple's AAT fonts,
SIL's Graphite) with Arabic support are available, they had better be
taken advantage of. See the following references:
http://www.microsoft.com/typography/otfntdev/arabicot/default.htm
(Arabic OT spec.)
http://fonts.apple.com (AAT)
http://graphite.sil.org (Graphite)
http://www.pango.org (Pango : open source layout enginer for Gtk
that supports Arabic with opentype tables)
Jungshik