RE: E0000 Language Tags for Archaic Greek Alphabets

From: Peter Constable (petercon@microsoft.com)
Date: Mon Feb 28 2005 - 19:12:44 CST

  • Next message: Patrick Andries: "Re: E0000 Language Tags for Archaic Greek Alphabets"

    > From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]
    On Behalf
    > Of UList@dfa-mail.com

    > But I want to go even a little further, in order to implement *all*
    the
    > possible variations of archaic Greek scripts in one smart font. I want
    to define
    >
    > OLD_CRETAN_DORIC_LTR (left to right)
    > OLD_CRETAN_DORIC_RTL (right to left)
    > OLD_CRETAN_DORIC_ALT_LTR (alternate, left to right)
    > OLD_CRETAN_DORIC_ALT_RTL (alternate, right to left)
    >
    > and this, or more, for perhaps 10 different archaic Greek scripts...
    err, I
    > mean dialects.
    >
    > That probably isn't something that could/should end up on Microsoft's
    official
    > language list.

    Setting aside questions of what should end up in the OpenType registry
    of OT language-system tags, let me focus on what technology mechanisms
    should be applied to the choices you want:

    The choice between Old Cretan Doric and the alternate (or 10 other
    alternates -- assuming there's agreement that these should be considered
    variants of the same script rather than multiple scripts) can be handled
    using language-specific rendering; in the case of OpenType, this would
    happen with the application specifying a particular OT language-system
    tag and then using the 'locl' feature under that language system to
    select the necessary alternate glyphs. (This substitution should happen
    at the start of GSUB processing.) Other options are to use stylistic set
    features or 'aalt' (to select alternate glyphs one character at a time).

    The choice between LTR and RTL requires certain things to be done by the
    app and certain things to be done in the font. The app should take care
    of selecting the line direction (whether its control mechanism is a
    formatting setting or Unicode bidi control characters), and applying
    bidi mirroring to mirrored character pairs (per Unicode character
    properties). Then, for the RTL runs of text, a feature should be applied
    to select RTL variants of glyphs for non-mirror-paired characters. In
    OpenType, the 'rtla' feature should be used for this purpose.

    Peter Constable



    This archive was generated by hypermail 2.1.5 : Mon Feb 28 2005 - 19:15:27 CST