Julian,

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
> systems.

I will look into this if time permits.

Any comment/suggestions/feedback is highly appreciated.

Thanks

Ruibiao