Re: From [b-hebrew] Variant forms of vav with holem

From: Peter Kirk (peter.r.kirk@ntlworld.com)
Date: Thu Jul 31 2003 - 19:51:49 EDT

  • Next message: Karljürgen Feuerherm: "Re: Hebrew Vav Holam"

    On 31/07/2003 16:13, Kent Karlsson wrote:

    > Peter Kirkwrote:
    >
    >
    >>Kent Karlsson wrote:
    >>
    >>
    >>
    >>>No, I think ZWJ may be exactly the way to go here.
    >>>
    >>><consonant, holam, (accent), ZWJ, alef/vav> for making a 'ligature'
    >>>(of sorts, in a technical sence) where the holam is displayed on the
    >>>alef or vav. Without the ZWJ, the holam would be displayed on the
    >>><consonant> to which it logically belongs. (alef and vav are base
    >>>characters, so the ZWJ is not breaking any combining sequence here.)
    >>>
    >>>
    >
    >
    >
    >>This is an interesting idea, but I don't think it quite works. The
    >>decision whether to shift holams on to a following alef or vav is not
    >>something to be decided on a per occurrence basis
    >>
    >>
    >
    >Then why do you and others propose to add a new character?
    >
    >
    I considered it but now I think it is not the best way to go. Ask others
    for their views.

    >
    >
    >>but enforced on all
    >>renderers. Rather, it is a rendering decision which should be applied
    >>consistently, depending on context, through a whole document
    >>or style.
    >>So it is not something to be encoded, but something which
    >>should depend
    >>on the font etc.
    >>
    >>
    >
    >But you are saying that current mechanisms that try to be that
    >"smart" sometimes fail.
    >
    >
    There are two possible scenarios with different mechanisms. One
    mechanism has been shown to work, the other may fail:

    1) Encode holam male as holam - vav. The algorithm to shift holam to a
    following vav with no other vowel works and has already been implemented
    in Ezra SIL (though I di find a small but fixable bug). A special
    mechanism can be used to force the holam male rendering in a context
    where it would not be regular, cf. use of ZWJ and ZWNJ to force select
    particular Arabic forms. But this would never be necessary in normal
    Hebrew text. So no problem here.

    2) Encode holam male as vav - holam. The algorithm to disambiguate this
    one from vav consonant with holam haser is complex and ambiguous. I
    suppose ZWJ, ZWNJ, CGJ etc could be used to disambiguate if necessary,
    but this disambiguation is necessary in regular text and not just in
    special isolated forms, so the whole thing gets a bit messy. In fact the
    best way to disambiguate in this case would be to encode every holam
    male as vav - ZWJ - holam or whatever. But then I see below that you
    don't seem to allow any of these characters in such a case.

    >
    >
    >>The distinction which does need to be encoded is between
    >>holam male and
    >>vav followed by holam,
    >>
    >>
    >
    >Which my proposal trivially acheives:
    >vav-holam: <vav, holam>
    >some consonant followed by holam male: <[consonant], holam, ZWJ, vav>
    >
    >
    But then you don't need the ZWJ as vav, holam is already distinct from
    holam, vav. Or does it serve some purpose which I haven't grasped?
    Remember that I don't want an encoding distinction from the holam being
    above the consonant, as this is a rendering issue.

    >
    >
    >>as many (though not all) renderers
    >>want to make
    >>this distinction but they can only do so if there is an encoding
    >>difference. It would certainly be an option to encode holam
    >>male as vav
    >>- ZWJ - holam
    >>
    >>
    >
    >This breaks the combining sequence, and is therefore a non-option.
    >
    >
    Understood.

    >
    >
    >>or vav - CGJ - holam.
    >>
    >>
    >
    >This breaks the logical order of characters, ...
    >
    True. That's why I prefer the encoding numbered 1 above. But others
    insist on this order on the grounds that the mark must come after the
    base character with which it is graphically associated. As two
    principles conflict, one or other must be given precedence.

    >... and (mis)uses the CGJ
    >(which would be better deprecated, despite the desparate attempts
    >at making it useful).
    >
    >
    Well, if you don't like to use CGJ and want to deprecate it, perhaps we
    should define a new character which has the right properties and
    intentions to go here. I would be interested to see in precisely what
    ways such a character would differ from CGJ.

    >
    >
    >
    >>But if this holam is to be encoded
    >>before the vav, the ZWJ is redundant.
    >>
    >>
    >
    >It seems to be more of a spelling difference than a font difference.
    >
    >But one could have the convention that <[consonant], holam, (accent),
    >vav>
    >always got the holam on the vav, even if the vav is vowelised; and
    >use <[consonant], holam, (accent), ZWNJ, vav> to put the holam on
    >the [consonant], regardless of if the vav is vowelised or not.
    >
    >
    This sounds good. Perhaps we could have the same sequence with ZWJ for
    the holam to be on the vav even when the vav is vowelised, which is
    required for the version of the divine name which I posted.

    And then if we want a word initial holam male e.g. for a list of glyphs
    or just possibly for some other language, I suppose we would have to
    encode it something like ZWSP - holam - ZWJ - vav, or use WJ (2060 word
    joiner) instead of ZWSP. Or do you have a better suggestion for this?

    >I see absolutely no reason whatsoever to encode any new character for
    >these cases. (The cases with two vowels on a Hebrew consonant is quite
    >different.) But you have to choose if the ZWJ solution is the best or
    >the
    >ZWNJ solution is better.
    >
    > /kent k
    >
    >PS
    >Why does everyone jump on the option here to encode a new character?
    >It is quite clear that none is needed for this! But everyone is
    >appalled at
    >the prospect of encoding new characters for solving the double vowels
    >problem (where encoding new characters in a smart way appears to
    >be the very best solution). Strange...
    >
    >
    >
    >
    I now think I agree with you, Kent, at least on the principle if not on
    the detail. For a few hours I was on the new character bandwagon, but
    now I have dropped off it. But let's see what others have to say.

    -- 
    Peter Kirk
    peter.r.kirk@ntlworld.com
    http://web.onetel.net.uk/~peterkirk/
    


    This archive was generated by hypermail 2.1.5 : Thu Jul 31 2003 - 20:38:30 EDT