Re: DIY OpenType Re-ordering (was: Representative glyphs for combining kannada signs)

From: Vinod Kumar (
Date: Wed Mar 22 2006 - 23:23:29 CST

  • Next message: Peter Constable: "RE: DIY OpenType Re-ordering (was: Representative glyphs for combining kannada signs)"

    On 3/23/06, Richard Wordingham <> wrote:
    > Philippe Verdy wrote:
    > > and reordering issues (at code point level) can also be achieved using
    > > glyph IDs within substitution tables
    > Not on Windows. For rendering only it can be imitated, but the imitation
    > does not work for editing the text. If you appear to have swapped two
    > glyphs (e.g. via contextual substitutions), apparently deleting one
    > character will actually delete the other!

    What Philippe Verdy said is correct. Normal editing works on the
    backing store of characters and should not know how those characters
    appear on the screen. The editor does not "swap characters". The
    backing store will contain the characters in Logical order. Devanagari
    Ki will be represented by Ka IMatra <915 93f>. The editor will present
    the sequence <915 93f> to the lower level. Depending on the pipeline
    below, the sequence may be reordered to <93f 915> (visual order of
    characters for Microsoft and IndiX typography). Or it may be directly
    passed to the font layer as in Apple Advanced Typography (AAT). If the
    font gets the characters in logical order, then it has to reorder the
    glyphs. With OpenType, reordering glyphs is a huge pain (which is why
    the characters are reordered before the OpenType font). AAT does the
    reordering within the font.

    > For example, to 'swap' characters K and E with glyphs gK and gE you could
    > try a sequence of rules such as:
    > gK > E_for_K / _ gE
    > gE > gK / E_for_K _
    > E_for_K > gE
    > which converts 'gK gE' to 'gE gK'. However, a process that would normally
    > delete gK would delete E from the backing store, with the result that
    > apparently deleting gK would convert the display 'gE gK' to 'gK'!
    > Richard.

    The mapping between what is highlighted on the screen and its
    originating character is much more complex than the one to one
    relationship between a Latin glyph and its character code. For Indic
    scripts, most normal editors would not allow you to select gK alone.
    The combination <gE gK> (Tamil, Malayalam?) would be selected
    together. The sprite cannot be placed beween the gE and the gK.If the
    sprite is placed after <gE gK> and an edit to delete the previous
    character is attempted, the gE will disappear from the screen and not
    gK. This is achieved most easily by the editor redrawing the screen by
    clearing the line and sending the backing store line of characters
    with E removed. Of course, you can complicate things for apparent
    optimization by clearing only the region after <gE gK> to the end of
    line and not the whole line. So the scenario described by Richard is
    incorrect even if the reordering is done on glyphs within the OpenType

    Reordering of glyphs within the font becomes necessary when the font
    does not have some glyphs. For example, consider Devanagari RDMa. If a
    glyph gDMa is available then this can be displayed as <gDMA gReph>. If
    gdMa is absent, but gHalfDa is present then it can be shown as
    <gHalfDa gMa gReph>. If gHalfDa is absent (the normal case) then the
    correct display is <gDa gHalant gReph gMA>. In this third case we will
    need a glyph reordering within the font.

    This reordering is best done at the font level as it is a result of a
    decision at the font level. Some apparently clever people try to do
    this at the higher level. They will send <Da Halant Ma> to the lower
    level font, check whether it produces <gDa gHalant gMa> and if so send
    <Ra Halant Da Halant> (or a reordered equivalent> followed by <Ma>.

    Vinod Kumar
    Project IndiX

    पृथिवी सस्यशालिनी
    Prithivi Sasyashalini

    This archive was generated by hypermail 2.1.5 : Wed Mar 22 2006 - 23:29:09 CST