RE: tlug: was email software --> UNICODE input

["Olinsky, Craig" <olinskyc@example.com>]

>     CO> You could also put up a char-chart (by language/script/or code
>     CO> point) and have the user click, but that wouldn't be an
>     CO> efficient way to type either.
> 
> A GUI alternative to direct raw-hex input, yes. It would be nice if
> these two 'when-all-else-fails' methods were available _along with_
> any script/language-specific IM that was chosen.
> 
	The work to be done here would be new and/or efficient ways of
sorting or grouping the characters to make selection more convenient... as
opposed to a simple char-picker in the font or encoding order, or even a
sophisticated "sort" mechanism by various characteristics...  although as
was mentioned, you definately do not want to have to do this for an extended
text.

> Anyway, if
> there is an interest in the current state of (ugh! hurl!) this grand
> scheme, I can expound. (Not a Linux-related subject, I will respect
> hints, subtle or otherwise, to drop it from this list:)
> 
> In theory, my pet, the above-mentioned CHA, when fully developed,
> would provide a way to enter any kanji, including kanji outside of the
> Unicode Han repertoire. 
> 
	I'm definately interested in hearing more about this (I assume to
some extent, it's a variation on some of the stroke-based system?), but as
you said, it might be better to take this off-list...

> Unfortunately, even if this unlikely event
> occurred that still leaves out all the other scripts. So, at this
> point I'm inclined to say, yes, a common input method for Unicode is
> not in the cards.
> 
	Unless there's some "other" characteristic of a script/character
that would result in a limited subset of characters, from which one could be
chosen... So far we have:

		Pronunciation/Transcription (e.g. Japanese input, Chinese
pin-yin, etc.)

		...i suppose you could use a full IPA keyboard/entry scheme
for most scripts...

		Arbitrary code (position on keyboard, for small scripts)
		Appearance (stoke-based systems, handwriting, selection by
radical)

		? Meaning (dictionary search?) -- this would be better for
words, not specific characters.
		?
		?

> The ability to easily select from a list of script-specific or
> language-specific input methods which, in toto, provide access to all
> the characters in Unicode is probably the most productive approach
> now.
> 
	There's another dichotomy, though...  most IMEs now are
language-specific (although obviously limiting to one or more scripts),
while "keyboards" are script-specific (enabling entry of any language which
can be composed of the assigned keys).  A question is how we can (or if we
should) "merge" these approaches. I believe that even some small scripts
could benefit more from the "input method" concept... an example being word
processor auto-correct/auto-complete/auto-capitalize functions.  

>  If these input methods were chosen, modified or designed with the
> idea that they would all appear together in one list in one app, at
> least differences in input method UI could be minimized.  This alone
> would make them more attractive to new users. (But maybe not to old
> users who are already addicted to a particular approach.)
> 
	I.e., a standard input method framework / API
		         "             "       "        selection method
	               "             "       "        appearance? (language
specific)

	I agree with the concept that input methods should be able to
"layer" or "feed in" to each other...  e.g. Handwriting -> kana-kanji
conversion -> output;  speech -> kana/kanji;  text file (in romaji?) ->
kana/kanji; Automatic transcription (e.g. Kanji -> Romaji), perhaps to
display Japanese text on systems that don't support Japanese characters.

	This would necessitate all input functionality to be piped through a
common scheme, and perhaps for better treatment of characters/glyphs as
"objects" rather than just bytes (i.e. some sort of markup with language
information, etc.) and a lot of dictionaries.

	I wish I had some time to try to clean up these notions into
something more cohesive.

	Craig

	-- not speaking for intel


---------------------------------------------------------------
Next TLUG Meeting: 11 April Sat, Tokyo Station Yaesu gate 12:30
Featuring Tague Griffith of Netscape i18n talking on source code
---------------------------------------------------------------
a word from the sponsor:
TWICS - Japan's First Public-Access Internet System
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096