bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: console update


From: Niels Möller
Subject: Re: console update
Date: 10 Sep 2002 21:40:14 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> The way to organize it that each cell can hold up to five wchar_t's, as
> ncursesw does it, is ok I think, for two reasons: First, that is probably
> an upper limit to what applications and users expect to be supported by
> whatever free software display they are using, and second, it is very easy
> to implement, and is also an upper limit to what you can sensefully support
> by overstriking.  This should be good enough for a couple of years or
> whatever in real world compatibility, I would think.

The only sensible alternative I can think of is storing some kind of
"glyph id:s" in the matrix. I think Thomas argued before that that is
ugly. I think it might be ok, if one thinks about glyph id:s as
interned unicode strings.

I.e. given a sequence of base-character + combining characters (or
whatever units are desired, to me it makes sense to be able to
configure things so that certain combining characters are given
individual cells) one can intern that to get back a single integer
(analogoues to LISP interned symbols, java's string.intern, and
XInternAtom). The intern operation could also normalize the input, and
make sure that most or all strings that reduce to a single unicode
character under normalization form be get the same number as their
glyph id:s.

Regards,
/Niels




reply via email to

[Prev in Thread] Current Thread [Next in Thread]