[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tanween variants and Unicode
- To: General Arabization Discussion <general at arabeyes dot org>
- Subject: Re: Tanween variants and Unicode
- From: Meor Ridzuan Meor Yahaya <meor dot ridzuan at gmail dot com>
- Date: Mon, 29 Aug 2005 09:14:14 +0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=chEkkhNpes8ST6Ma+a+9WFsooTyEP+D/+zIKQyT57BVxbIjsXTJw8eiRCG5+Y+IclQ1/f4vM7o9zdJM9xrL5IIfORPofGdpQvL6sB8SFiJGNZTz1U1GKrHfOizOLC5SoCO7Yqs+RqL85tdPFcl6oa5TolrHJuSS056VljfzlXlY=
> I agree with you that some of the characters need to be clarified.
> >So, if you ask me, the best is for unicode to either change the
> >glyph/character property as propsed by Yousif, or add few more
> >codepoints for the "missing" glyph. Second approach probably can be
> >adopted faster.
> Faster? Not really. It takes over a year sometimes to get a new codepoint added to Unicode since with each new codepoint a whole bunch of discussion may take place. Some take even longer than a year. And then you have to wait for companies to support the new version of Unicode in their software which usually takes at least another year on top of that. For instance we have been working on the new hamza codepoint for two years now since it is considered kind of controversial and we still couldn't get it added. I hope it will make it to Unicode 5.0 but we're not even sure. There is a chance it might be delayed till Unicode 5.1.
When I say faster, I mean to implement it in technical perspective,
not Unicode adoption. The first option that I referred to basically
have the same problem with the new Hamza: it introduces the shaping
behaviour to the Arabic block. So far, in the Arabic block, we have
right joiner, dual joiner, mark, and stanalone ( I think that'a all).
So to propose a new character which have a stanalone and a medial
joiner only, the rendering engine will need to create a "new" feature,
and a new character group. So, repeat this process for all rendering
engine out there, we will have to wait for a very long time. Not to
mentioned the adoption by font developers.
> >Another important thing about technology: Pocket PC 2003 does not have
> >full opentype support. I'm not sure about palm, but I doubt it has.
> >So, we can't display the text on those platform. I think these
> >platform is very important for displaying the Quran, since it is the
> >most convenient for all. ( I really would like to get one specifically
> >for reading the Quran).
> Don't worry, by the time these new features get added to Unicode and companies start implementing the new Unicode version it will be at least several years anyways. By that time I hope OpenType support would be added to those platforms but of course font portability is another problem. For instance Bitstream recently added OpenType support to Symbian OS which runs on cellphones. And as far as I know there is some support for OpenType in Pocket PCs (OpenOffice.org says that there is some OpenType support in Pocket Word http://xml.openoffice.org/xmerge/plugins/pocketword.html). Windows Mobile 5 probably has a little better support. By the time Unicode 6.0 is out probably Windows Mobile 6 or something gets released and hopefully they will have yet better support there.
Well, pocket word does not really support opentype table, it just
support to display opentype font. Initially, I did'nt realize this,
but later I come to know that some people referring to Opentype font
to the font that wraps postscript font in opentype/truetype style
table, not the GSUB/GPOS table. I'm not sure about symbian, but Pocket
PC definitly does not have any support for GSUB/GPOS table. Windows CE
5 will have the support, but I did not look it up the spec for arabic.
So, if your concern is about unicode does not want to accept a new
codepoint, why not do this: proceed with your proposal, but make sure
the features that we require are hightlighted and spelled out as
clearly as possible. We do not want to introduce more ambiguity. While
you are at it, you might want to suggest to them to at least change
the description for superscript alef. So, if that get standardize, the
only thing missing is the small superscript waw. I'm not sure how to
At the same time, it might be a good idea for arabeyes to work on
something on how to make it backword compatible with other
technologies. One thing that come into my mind is to assign those
missing glyph to PUA, so that we can use it consistently across our
application. Others might want to follow.
Lastly, we need to start to develop search algorithm. I'm not sure how
we can develop one, based on your proposal. Maybe you have a better
idea. (This is not my area really, since I'm not an expert in Arabic).