Subject: Re: [Summer of Code]Wide Character Support in curses
To: Brett Lymn <email@example.com>
From: Ruibiao Qiu <firstname.lastname@example.org>
Date: 06/13/2005 10:15:55
On Mon, 13 Jun 2005, Brett Lymn wrote:
> On Sun, Jun 12, 2005 at 04:23:42PM -0500, Ruibiao Qiu wrote:
>> To improve the memory usage, I propose a different structure than my
>> original structure. Essentially, it is about the same as the existing
>> storage structure. That is, the character value is still an 8-bit
> No. A wide character is 32bits.
Thanks for your feedback.
I guess I did not make it quite clear there. Sorry about the confusion. What
I really meant is to keep a storage structure for each display position on a
screen. The 32-bit value of a wide character is split into the value fields
of the four character display cells, using bit mask and shift operations.
Similarly, a 16-bit wide character is split into two cells.
For example, a wide character of width 2 with a value of 0x9ABC would occupy
two storage cells, one with a character value of 0x9A and the other with
0xBC. In addition, the attribute of the first half-character indicates that
it is the beginning of a wide character, and the second be the end.
IMHO, this storage structure does not make cursor positioning more difficult.
Because there will be characters of different widths on a screen (see the
reasons below), moving up or down the cursor simply make it go to the display
cell directly using the current position without summing up all the width in
all the proceeding cells of the current and next lines. It may fall into the
middle of a wide character, but with the help of the alignment field, the
start of the wide character can be easily located, if necessary.
Besides, there were suggestions that all wide characters in the same screen
have the same width from the discussion. From a wide character application
users' perspective, I think that is too restricted. A user may want to mix
single-width character and wide characters in the same screen because it saves
screen space and looks nicer. For example, phone numbers and an English
address are normally displayed in single-character formats. There is
a single/wide character switch function in all Chinese input method module
just for this purpose. So, I think the storage structure should have a way to
indicate the width of the character, although it does not necessarily need a
Anyway, it is always good to have more people discuss the proposed solutions.
I really appreciate it. I plan to implement with the several viable
alternative storage cell structures discussed here, and compare their memory
usage and performance to find out the good solution.
Please keep sending your comments and feedback. Thanks.