RE: [indic] Re: Proposal to add four characters for Kashmiri to the BMP of the UCS

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon Jul 07 2008 - 11:18:01 CDT

  • Next message: Michael Everson: "Re: wikipedia unicode font."

    Pravin S wrote:
    >
    > As per Devanagari syllable rule Matra's can,t combine with
    > vowel's, that's why Devanagari code chart consist of U+0904
    > to U+0914 vowels and corresponding Matras at U+093E to U+094C

    Yes, but the new vowels for Kashmiri (or other future vowels for other
    languages) may effectively combine with LETTER A, considered not like a
    Matra, but as a consonnant with an implicit vowel that is overridable. Of
    course you should not override the explicit LETTER A with the existing
    vowels used in Hindi and Sanskrit, but nothing forbids making this explicit
    vowel into an implicit one for other vowels.

    In that case, you won't necessarily need to encode two new matras, but just
    the two new vowel signs, to combine with the existing Devanagari letter A.
    After all, even with the other existing matras, they are "logically"
    decomposable into base letter A (with an implicit vowel) plus a vowel sign.
    This was certinaly not done for compatibility with ISCII, but here the new
    Kashmiri letters don't need such compatibility.

    In fact it may even occur that the current version of ISCII is not easily
    extensible itself to cope with 4 additional codes, but it could be extended
    to use two additional vowel signs for Kashmiri.

    The only rule that is true for Devanagari is not the fact that you can't
    combine a matra with a vowel sign, but the fact that you can't combine two
    explicit vowels in the same akshara (well it's not completely true, see the
    case for letters R and L...), in that case you need an other akshara for the
    second vowel (so this new akhsara will start by a matra, and this matra may
    be either one of the existing precomposed ones, or LETTER A, or LETTER A
    plus a kashmiri vowel sign or another non-Hindi/Sanskrit vowel sign that may
    be added in the future).

    Anyway, the layout engines will need to be updated in both cases to handle
    the new vowel signs correctly in Akhsaras like Ü-R, Ü-RR, ÜÜ-R, ÜÜ-RR, Ü-L,
    Ü-LL, ÜÜ-L, ÜÜ-LL (I don't know if they really occur in Kashmiri) or more
    complex ones with anusvara (if they can be nasalized) or visarga (for other
    variants).

    Christopher Fynn wrote:
    > Philippe Verdy wrote:
    > > (...)
    > > The kind of modification is also not a nasalisation (so
    > > an anusvara can't be used to note these phonetic vowel variants, and
    > > in fact the Kashmiri vowels can also be used with or without
    > > nasalisation, meaning that anusvara must remain usable separately with
    them).
    >
    > Philippe, you almost sound like you are making an argument to use
    > "variation selectors" here.

    Certainly not! The proposed Kashmiri vowels, in the way they are described,
    are definitely not glyph variations, they are distinct vowels that need
    distinct semantics, and they are not freely substitutable with other
    Devanagari vowels if the variations are not supported.

    The only issue is about the need to encode the precomposed independant
    vowels, or allow them to be composed using the existing LETTER A and one of
    the only two Kashmiri vowels signs. This could change some derived property
    for LETTER A because it could now be followed by a vowel sign, but anyway it
    could already be combined with other diacritics and notably the anusvara and
    visarga.

    So effectively, this could be solved easily by assigning a new combining
    class for the Kashmiri vowels. The problem will be: which combining class
    can be assigned. But is it really necessary to make for them a new combining
    class, different from those already used by other Devanagari vowel signs?
    Such class will not be needed for norlisation and needs not be specified,
    but can be assigned internally within the renderer, using its own classes
    for decomposing, reordering, and combining glyphs (not characters), or
    within OpenType fonts with AAT or Graphite recomposition and layout rules.



    This archive was generated by hypermail 2.1.5 : Mon Jul 07 2008 - 11:26:04 CDT