Re: [Mlterm-dev-en] mlterm, tibetan, and bitmap fonts?

[Rich F. <da...@ae...>]

On Mon, Dec 19, 2005 at 01:30:47AM +0900, mi...@mi... wrote:
> >my second question is off-topic, but maybe someone here can answer: is
> >screen's utf8 support usable? (including combining characters?) a
> >quick rtfs seemed to indicate so but i don't have an environment for
> >testing it at present. i'm quite addicted to screen, so if its utf8
> >support is broken i need to do something about that first...
> 
> In my understanding, screen can pass utf-8 but do not care about
> combined characters. So there should be some breakage.
> I'm not using screen these days and not sure its current state, though. 

In case anyone else cares, the answer is that screen is incredibly
broken in this regard and needs to be fixed. It implements combining
characters for 2-character combinations only, and does so by
dynamically allocating them in the utf-16 surrogates range for storage
in its buffers. In principle it can run out of slots and just forget
about some of the combining characters in one window if you use enough
of them in another window...

I suppose I can fix this horrible abomination correctly (store an
arbitrary-length list of combined characters for each cell) or by
extending screen's hack to store many-character combinations in its
fake character table, but either way this raises an interesting issue:
With traditional character cell storage, a fixed size window holds a
finite fixed number of characters (W*H). However with combining
characters in unicode, it seems that a utf8 terminal has no upper
bound on the storage requirement. Is it appropriate to just choose an
arbitrary limit?

Rich