- it only works for programs that render a whole string with x, not
actual character-cell based programs that will draw and redraw
characters in their respective cells, i.e. terminal emulators.
- it does not allow vertical stacking of combining marks, i.e. if
there's more than one they'll just overstrike one another and become
illegible.
- it does not account for the fact that the base character may have to
change form to accomodate the combining characters (either due to
conventions of the script itself or limitations of the font size,
e.g. uppercase latin characters having to become shorter to make
space for accents in small fonts).
what i would like is a standardized system for (ab)using or extending
the x11 font metrics to store the data on how characters should
combine. unfortunately i don't yet understand the x font system well
enough; however i believe that the width/ascent/descent/etc
information, which are otherwise not very useful on combining
characters, could be used to store the offsets for rendering the
combined character in the correct position relative to the base
character or the previous combining character. this rendering could be
performed one-character-at-a-time by the application, and possibly
also by an extension to the x server.
as for alternate glyphs for the base character when it's used in
combinations, i don't know what to do since x seems to have a shortage
of glyph numbers already.
the only alternative i know is for unicode terminals to ignore the
whole x font system and load their own pixmaps and data tables of
combining information. i don't think anyone particularly likes this
solution, but perhaps i'm mistaken.
other ideas...?
rich
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/