Re: DIY OpenType Re-ordering

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Thu Mar 23 2006 - 18:44:57 CST

  • Next message: Richard Wordingham: "Re: DIY OpenType Re-ordering"

    From: "Richard Wordingham" <richard.wordingham@ntlworld.com>
    > By 'base character' I meant the first consonant of the cluster in the
    > encoding sequence.

    Personnaly I exclude a dead RA (when it will be transformed to a repha form) as the significant base character for the graphical rendering, and the significant base character becomes the next consonnant,which comes leter in the consonnant cluster. As this implies reordering (of glyphs only), this is not the encoded sequence. It can be the base letter only if it is "detached" from the cluster by a ZWJ or ZWNJ (depending on the way its virama should be rendered, with a RA half-form or with a RA+halant)

    > Philippe Verdy wrote:
    >>From: "Richard Wordingham" <richard.wordingham@ntlworld.com>
    >> For Unicode, the base character is not that one, it's only the start of a
    >> combining sequence, and we all know that a combining sequence is less than
    >> an Indic cluster (notably when there are multiple consonnants separated by
    >> halant so that some of them are dead consonants, or when there are ZWNJ
    >> and ZWJ at end of a consonnant cluster).
    >
    > Is it appropriate to call a Unicode virama acting as a control character a
    > halant? I thought a halant was a visible mark.

    Possible. But Unicode does not really differentiate halant (the glyph) and virama. There's some extra controls needed to make such difference, when it is orthographically significant. (ZWNJ, which is a much more a control)

    >> But I still don't know any locale-sensitive conjunct that has special
    >> reordering or composition rules (The encoded Marathi letters in the
    >> Devanagari block for example don't have final dandas, so the half-form and
    >> repha problem does not apply to them and they apparently don't need
    >> complex reordering rules, but there may be cases where subjoined forms may
    >> occur and should be controled, complexifying the regexps that the font
    >> reordering algorithm uses to match the cluster patterns and then select
    >> their corresponding string of glyph ids.)
    >
    > Hindi and Sanskrit apparently have different rules for when a conjunct is
    > preferred to the use of a half-form. Reportedly almost every consonant or
    > conjunct in Marathi has a half-form, even though the half-form may look like
    > the full form plus halant. (It can't be a halant, because the short i-matra
    > precedes the half-form. :-)

    For a font, the full form + halant is not the half-form, it's just the way to transcript the dead letter, because these letters don't have half-form. So if we speakabout making a font that works for Marathi, it reallyissimpler to consider that it has no half form. I don't know what a sequence with such dead letter + virama + ZWNJ can encode distinctly compared to dead letter+virama, given that the virama will become a halant on the full letter in both cases.

    What is the few letters that need representation with nukta. If the corresponding letter without nukta can take a half-form, does it also apply always to the letter with nukta? Or are there specific glyph to create a true "half-form" (for use in conjuncts)?

    >> My opinion is that a font has to match a style that first works according
    >> to a single locale, and that locale variations are defining a new,
    >> separate style, which should be supported in another font, or in a
    >> composite OTC font with alternate names to match those styles. In that
    >> case, no specific "feature" must be selectedor enabled by the application,
    >> it just selects the font by name according to the expected style.
    >
    > Isn't this 'locale' feature what the OpenType 'language system' is for?

    Yes. But I don't like it much. It's just simpler to have multiple fonts, each with their name,easyto access in most applications, but possibly grouped into a single composite font file. "language system" feature selectors in OpenType just complicates things for the applications, meaning that it willbe difficult to get the same level of support for the language variant as the level for the default variant that does not need such feature selection (in Notepad for example: how can one work with the locale-specific features, if there's no default style for that language variant in the available fonts?)



    This archive was generated by hypermail 2.1.5 : Thu Mar 23 2006 - 19:00:47 CST