Re: Biblical Hebrew (Was: Major Defect in Combining Classes of Tibetan Vowels)

From: Karljürgen Feuerherm (cuneiform@rogers.com)
Date: Wed Jun 25 2003 - 21:31:41 EDT

  • Next message: Christopher John Fynn: "Re: Major Defect in Combining Classes of Tibetan Vowels: Illustration"

    I'm rather new to the process, but this issue is of interest to me (so
    please bear with me wrt questions whose answers may be obvious to everyone
    else)

    > >For example, the alleged problem of the vocalization order of
    > >the Masoretes might be amenable to a much less drastic
    > >solution. People could consider, for example, representation
    > >of the required sequence:
    > >
    > > <lamed, qamets, hiriq, final mem>
    > >
    > >as:
    > >
    > > <lamed, qamets, ZWJ, hiriq, final mem>
    > >
    > >and then map <qamets, ZWJ, hiriq> to the required glyph
    > >to get the hiriq to display to the left (and
    > >partly under the following final mem).

    I was going to suggest something very similar, a ZW-pseudo-consonant of some
    kind, which would force each vowel to be associated with one consonant. (But
    create one when one exists already? Perhaps because:

    > There are a few problems with this scenario. One is that control
    characters
    > are unreliable agents in glyph-level processing.

    if somehow ZWJ is special and another consonant would avoid this.)

    >Most applications do not
    > paint control character glyphs, which means that they do not appear in

    I'm not sure what 'paint' means here. Whether something is visible or not is
    not necessarily the same as whether it exists in an encoded string or not.

    > glyph strings so cannot used in glyph substitution lookups.

    >This seems to
    > be a pretty much universal assumption about control characters.

    I am very surprised by this. Isn't it part of the function (or at least,
    pragmatic use) of ZWJ that applications and/or smart fonts can treat strings
    of C1-C2 or C1-ZWJ-C2 as equivalent or not (whether for rendering or other
    purposes), provided that they know the legitimate combinations which may
    occur?

    In which case,

    >Arguably, there are implementation options
    > that would overcome this problem, but they are complicated and the present
    > assumption seems pretty universal.

    isn't the problem not with the Standard (assuming the above or similar
    solution) but with the applications (Uniscribe or other)? (Of course I
    realize that this would do little for the end-user--a problem is still a
    problem. However, one wishes to address it in the correct arena.)

    General question: when does canonical reordering take place? At input time,
    at rendering time, at another time? (Perhaps there are more accurate ways to
    put this; but I assume the general gist of the question is clear.)

    Thanks

    K



    This archive was generated by hypermail 2.1.5 : Wed Jun 25 2003 - 22:06:45 EDT