On Saturday, June 28, 2003 8:47 AM, John Hudson <[EMAIL PROTECTED]> 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)...
