Re: Biblical Hebrew (U+034F Combining Grapheme Joiner works)

From: Philippe Verdy (
Date: Sat Jun 28 2003 - 03:48:01 EDT

  • Next message: Doug Ewell: "Re: Biblical Hebrew (U+034F Combining Grapheme Joiner works)"

    On Saturday, June 28, 2003 8:47 AM, John Hudson <> 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

    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

    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