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 the Display form of the > current character in Presentation form B and then I ask my Display > Module to display the glyph matching to this Presentation form > (Unicode).
Yes, but note what you said. Your display module chooses the correct *glyph* for the character based on its joining type and that of its neighbors. However, neither the application nor the display module actually changes the underlying *character*. It is still U+0622, although it may be displayed with the glyph shown in the charts for U+FE81 or U+FE82. The glyph shown in the Unicode charts is not necessarily the only glyph that can be displayed for a given character. This is true for many characters in Unicode, and especially so for Arabic. The Arabic presentation form "characters" in the U+Fxxx ranges are actually not recommended for any use except compatibility with legacy standards. Display engines that can render Arabic are supposed to take a normal Arabic character in the U+06xx range and display the appropriate glyph automatically. > If I dont 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. You answered this question yourself: 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, but you must not actually change the underlying character to that value. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/
