From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Sat Jun 28 2003 - 03:48:01 EDT
On Saturday, June 28, 2003 8:47 AM, John Hudson <tiro@tiro.com> wrote:
> I think Peter's point may be that scholar searching for patah
> followed by hiriq are most likely to search for <patah, hiriq>, and
> frankly who can blame them? This is what they see in the printed
> text, and it is what, hopefully, they would be able to input.
Do you think they will input codepoints blindly?
The only reason why the sequence <patah,hiriq> would be used is
a non-conforming normalization in the input.
If the user strikes the two keys <patah> and <hiriq>, the input method
for Traditional Hebrew will generate <patah,CGJ,hiriq>, the user will
effectively see these vowels in the correct order, and there will be
absolutely no problem for that user.
This logic of generating the vowels with a CGJ belongs to the input
method.
If the user is using a compliant Modern Hebrew input method, the
vowels will be reordered immediately in the input, and this will be
immediately visible in the display, as an invalid Modern Hebrew
input!
Many users of other languages are used to have several input
methods, switchable at will, for entering their language. This is
really common for Japanese and Chinese users.
On Windows XP (for example), the language bar (or its
user-selected accelerator keys) allows such immediate switch of
input methods. I don't see why there would not be for the
Hebrew language, two keyboard input methods, or an enhanced
input method that would combine both Modern Hebrew and
Traditional Hebrew... (Note that I use "Traditional Hebrew" and
not "Biblic Hebrew", as this use of multiple vowel signs may have
other applications than just transcripting the Hebrew Bible, a
work already performed for this most published book in the
world, and just waiting for another publication on the web...).
I'm am confident that this CGJ insertion for vowels that must not
be reordered can be done transparently within the input method,
which would be based on grapheme clusters for Traditional
Hebrew, instead of just individual letters for Modern Hebrew.
Of course it will be a little more complex than just mapping
deadkeys on keyboards (because this would require using
multiple deadkeys, in a non-logical input order). But it will
certainly be much less complicated than what was made for
Chinese, Korean or Japanese, and quite similar to what was
done to input modern Vietnamese (Latin-based)...
This archive was generated by hypermail 2.1.5 : Sat Jun 28 2003 - 04:29:35 EDT