is responsible for mapping the keystrokes to their individual Unicode values.
This should be handled properly by the input module which may allow data
entry using an appropriate keyboard. This internal string will have Unicode
values only in the assigned code space for each script.
The internally stored
string may be processed by the application for any purpose. Typically the
application should display the string if an interactive user interface
is supported. To render the text properly, the application may make use
of the Uniscribe engine provided by Microsoft or use other approaches.
Going through Uniscribe might permit a degree of standardization but may
still be inadequate for specific applications. In such a case, the application
might use the Open type services library (OTLS) to query the nature of
support provided by an Open type font and identify the glyphs to be displayed.
Uniscribe does this too.
In either case, the
application receives enough information about the Unicode glyph indices
in the Open type font which would actually constitute the display. The
Font rendering may be easily accomplished by using suitable OS services
such as provided by Rich Edit. Note that the Glyph indices are meant only
for identifying the glyphs in the font and the text string indicated as
"B" in the above diagram does not represent the code values for the consonants
and vowels. Should the application support cut/copy/paste
features, the onus is on the application to maintain a backing string containing
only the input codes so that a match could be effected between the glyph
codes and the assigned codes by regenerating the display virtually and
comparing the codes with the already displayed ones. This process
would identify the portion in the input string corresponding to the blocked
text in the display.
The application can
make use of the OLTS to query for specific features supported by the Open
type font such as the availability of glyph substitution, alternate glyphs
for a code value, positioning information for ligatures etc. In this case,
the application should know how to relate the linguistic requirement to
the script. This method gives the developer much flexibility but requires
him/her to know the display rendering issues as well. This is a very stringent
requirement and one which is quite difficult to meet in practice since
Software Developers are not linguistic experts and do not in general know
the nuances of actual rendering or linguistic processing of the text
application could use the Uniscribe functions to accomplish the same. However,
it is not guaranteed that the implementation of Uniscribe is correct or
even adequate from the linguistic angle. Uniscribe itself relies on OLTS
services to figure out how text should be rendered consistent with the
conventions followed for a language. It is a bit odd that this approach
emphasizes the script and builds in support to cater to specific languages
supported by the script. It is usually the other way. The text pertains
to a language but is rendered using any appropriate script.