unicode@Unicode.ORG
> Dan> There is also an additional problem by having the combining character
> Dan> coming after the non-combinging, instead of before, as when reading
> Dan> interactively and a program want to act on a singel character it must
> Dan> use a timeout waiting for more bytes to decied when no more combining
> Dan> characters will arrive. If it had been defined that combining
> Dan> character came before the non-combining, parsing would be simpler -
> Dan> the non-combining ends a combining sequence.
>
> I have always been of the opinion that timeouts were poor solutions
> for interactive input. But, I have seen them used to effectively
> improve input speed a little. However, I am more than willing to
> sacrifice that capability for more generality. Besides, I have not
> seen a situation where that kind of input is needed for quite a
> while (with the exception of ftp and telnet); GUI's have taken over
> the world.
With or without GUIs: No timeout needed. Ten extra lines of code,
two extra variables, and a little extra work for the computer.
You need one variable pointing to the last non-combining character,
and another describing the glyph's rectangle on the screen. Render
what you have, and if the next character you get turns out to be
another combining character, go back to the last non-combining
character, erase that rectangle, and render as far as you can again.
Putting combining characters before the non-combining character would
make such speculative rendering impossible.
Disclaimer: I'm still out of my depth discussing this. I'm no Unicode
expert, just a GUI programmer, and the GUI toolkit I work on doesn't
support Unicode yet. (That's why I'm here, actually.)
--Arnt
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:31 EDT