From: Doug Ewell (email@example.com)
Date: Wed Aug 18 2004 - 01:57:32 CDT
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
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
> 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.
This archive was generated by hypermail 2.1.5 : Wed Aug 18 2004 - 02:03:33 CDT