Dear Chris,
Thanks for your response, so what you are suggesting is that the Unicode
does not change but only the display glyph should change right.
Currently, the implementation I am following is that once the user types in
a particular key say: 0x0622 , I look for the joining type of the
Nitin Kapoor nitinkapooro at hotmail dot com wrote:
Currently, the implementation I am following is that once the user
types in a particular key say: 0x0622 , I look for the joining type
of the character and then on the basis of the joining type of the
character and its neighbors I look up
On 18/08/2004 07:57:32 Doug Ewell wrote:
Your display looks at the joining
type of the character and its neighbors, and chooses a glyph on that
basis. Not a character, a glyph. Internally, you can actually use the
Unicode value of the presentation form as a way to index the glyph,
As has been
After a character changes the display form into one mentioned
in Arabic
Presentation Form B does it still belong to a joining type.
Nope. All the Arabic presentation forms implicitly have the joining
type U (non-joining) [and the joining metagroup no shaping].
For example: Lets say Unicode
Bob underscore Hallissy at sil dot org wrote:
As has been mentioned previously on this list (and I would like to see
it added to http://www.unicode.org/faq/middleeast.html):
This is not a reliable technique because not all Arabic characters
have a complete set of presentation forms encoded
If I don¡¦t use the Unicode values of Arabic presentation form B then how
will my display know which particular glyph to display? using the Unicode
values of presentation form B makes this easier but then the original
Unicode changes.
I am sorry but I am a bit confused with what to display
6 matches
Mail list logo
