fallbacks for nonexisting combining characters

[Robert Brady <robert@xxxxxxxxxx>]

I'm working xterm so it deals with rendering combining/combined characters
better.  In particular, I have it doing, in the drawing code (and not in
the decoding stage), doing

  * converting base+comb -> char, iff char is present in the font
  * converting char -> base+comb, iff char is not present in the font
 
    (This will let Arabic vowel-ligaturing happen. Doing
     consonant-ligaturing is a bit more scary

        [ to digress on this, it was a few months ago suggested that
          ALEF-LAM could be in the doublewidth font.  But this doesn't
          help in the case that the ALEF and the LAM have different
          attributes - what should happen here? ]
    )

  * if we have a top-accent on an i, draw it as a dotless i, instead.
    (unless its a combining dot above.) I should be doing something
    similar for js, but that would require use of the PUA.

  * not drawing combining characters if they aren't present in the font,
    this way we end up with "i" for "i-with-thingy-above" if there is no
    thingy-above in the font.
  
    But I'm not sure that this is a good way to do it, because it will
    be misleading.  But OTOH, I don't like the existing approach of
    overstriking the default glyph on the base character, as this often
    leaves it unreadable.

    What should be done?

-- 
Robert Brady
robert@xxxxxxxxxx

-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/