[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: console update
Re: console update
Tue, 10 Sep 2002 16:38:58 +0200
On Mon, Jun 17, 2002 at 12:58:12PM +0200, Niels Möller wrote:
> > Wide character support for curses is part of Single UNIX(R) v2.
> > It says:
> > "Implementations may limit the number of non-spacing characters that
> > can
> > be associated with a spacing character, provided any limit is at
> > least 5."
> But I think we should hope for actual Unicode compliance. Obviously I
> don't insist we have it now. But I object to an architectural
> decision that will make it harder...
I have thought about it, and I think that doing combining characters with
simple overstrike technic is simple enough to do even in text mode (we just
assign a new glyph slot for it, and |= the bitmaps for each combining
character). We also have a font by Markus Kuhn which supports this way of
combining characters (he recommends it for the 9x15 font - this is a bit too
large, but many characters in that font fit in 8-pixel wide cells if we use the
special ninth-column-should-be-empty trick of the VGA card to get the
spacing which is usually part of the font -- it will also work ok with the
8x13 font I guess).
So, I am almost convinced that supporting combination characters early on is
a good thing, as we can even make it a supported feature in the initial text
mode client, and definitely later in framebuffer clients.
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.
Now, the cost calculation:
Memory: Assume 6 virtual consoles with each 80x25 characters, and 1.5 pages
scrollback buffer (this is what Debian GNU/Linux has by default)
This is what we have now:
6 * 80 * 25 * 2.5 * 8 bytes (a wchar_t + attributes) / 1024 = 234 kB
Having 5 wchar_t's instead one triples the required memory (8 -> 24 bytes),
this would make 703 kB of memory (active memory per virtual console
accessed at the same time is 117 kB ~= 30 pages). Is that acceptable?
Performance cost: We have to recognize combining characters and attach them
to the previous character. We also touch more pages, as the data will
be spread over all of them.
What do you think?
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org address@hidden
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/