Edward Cherlin writes:
> It is almost trivial to implement Unicode text strings and files. It is
> considerably more difficult to create a useful library of text handling
> functions for Unicode text, but it can be and has been done. It is
> extremely difficult to implement keyboard input, printing, and display for
> full Unicode. So most recent operating systems have implemented Unicode
> data and files fully, but input, display, and printing only for the easy
> scripts, where ease of implementation is presently in the order
In my opinion, part of the reason that input methods do not exist for
so many of these languages is that creating an input method would seem
to be beyond the abilities of most users, including most of those who
would be interested in having an input method for a given language
(which may be a small population).
What we really need is an input method toolkit, or wizard, that would
enable a non-sophisticated user to develop input methods for their
favorite languages. Not to play OS-favorites, but Mule emacs does
have a framework for entering new input methods (called quail), and
while it does not look to be a trivial task, it certainly seems like
something I would investigate if I were sufficiently interested in a
certain unsupported language.
As far as I can tell, there is a certainly degree of functionality
which would permit input methods for most of the world's languages to
be specified. With all of the slick programming aids that are being
developed for the Windows environments, something for designing input
methods would be extraordinarily useful.
Of course, I speak not only of input methods, but also of display and
printing methods, among others.
--chris
-- christopher m. hogan language technologies institute chogan@cs.cmu.edu carnegie mellon university computational linguistics pittsburgh, pa
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:36 EDT