Subject: Re: [Summer of Code]Wide Character Support in curses
To: Julian Coleman <firstname.lastname@example.org>
From: Ruibiao Qiu <email@example.com>
Date: 06/12/2005 13:05:03
Thanks for your information.
On Tue, 7 Jun 2005, Julian Coleman wrote:
> In order to support these functions, the curses internal storage of
> characters and attributes needs to be modified. For example, each
> character position might be described by a structure containg:
> character value (32 bits)
> character attributes (32 bits)
> character width
> non-spacing character list/pointer
This is a great start point. Thanks! I think the choice of the
associated non-spacing character(s) depends on how many non-spacing characters
are normally used. If there are many non-spacing characters associated with
each character on a screen, it makes sense to use the list of fixed size
(say, 5, the minimum requirement in the X/Open reference). However, if there
is not much non-spacing character, the fixed list wastes a lot of memory, and
the use of non-spacing pointers may be more memory efficient.
> Once the internals are done, the display of characters that are not one
> cell wide needs to be handled.
I think the affected routines include the routines to add (e.g. addch(),
addbytes()), to delete (e.g. delch()), and to insert (e.g. inch()). Any other
routines that assume character size of one must also be identified and
modified. The other routines should not be affected. In addition, should I
include new wide character routines in the X/Open reference, such as
echo_wchar(), or just keep the current set of routines? Should I add
X/Open routines that deal with non-spacing characters for this project?
> The exact implementation needs to be researched.
Indeed. I think the changes to the storage structure inevitably increase the
memory usage, but the non-spacing character support may not be necessary for
ports with limited resources. Perhaps, the attribute is sufficient. Are
these assumption and approach valid? As for the changes in the affected
routines, there should be just simple changes, and the additional time and
space should grow linearly.
Do you have some other specific idea in mind?
> It would be nice (but not essential
> for this project) if the wide character support could be made a compile
> time option, so that it could be omitted on boot media for small memory
I will look into this if time permits.
Any comment/suggestions/feedback is highly appreciated.