> A terminal is a character-cell device, with fixed-width character
> cells. This is not open to discussion, but fear not, it's not a
> problem!
Actually, this limitation makes some things more complicated, because
you have to use glyph variants instead of glyph composition in case
the width of the composed glyph changes.
> > Representing Vietnamese in a fixed-width simple terminal emulator
> > requires considerable rendering code, even though most of the
> > required accents and all of the alphabet is found in ascii.
>
> The rendering code is trivial. The terminal emulator just
> accumulates all nonspacing characters after the base character in
> one character cell, and blits the appropriate glyphs on top of one
> another.
At least for the u -> uhorn `accent' this doesn't work well...
> There's never a need for a mapping of a multi-element sequence of
> codepoints to one glyph. You juse use overstrike with appropriate
> variants. In the worst case you can emulate many-to-one with
> sufficient use of contextual glyph selection to make the base
> character map to a glyph containing all of the modifications while
> the combining characters all map to a blank glyph, but in practice
> you can almost always do something much more reasonable with fewer
> contextual rules.
Isn't the first sentence a contradiction to the remaining of the
paragraph? I think I'm misunderstanding. Please give an example.
Werner
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
