On Sat, Aug 05, 2006 at 09:11:39AM +0200, Werner LEMBERG wrote: > > 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.
For nonspacing combining characters (Mn), the width of the combined character is the same as the width of the base character. Spacing combining characters (Mc) occupy their own character cell of course and behave exactly like a noncombining character except that they almost surely have ligatures. I'm sure you can give examples of where this behavior is not ideal, but at least it works. > > 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... For a few cases where it doesn't work well, you make a special glyph variant, optionally making the glyph for the combining character become blank in this case. That's how the Indic consonants where part of the glyph is deleted can be handled as 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. You're just misunderstanding the terminology I'm using. I'm speaking with regard to how it's implemented in the font's tables, not how you might think about it. Rich -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
