| Ruibiao Qiu <ruibiao@arl.wustl.edu> |
| $Id: proposal.html,v 1.2 2005/06/28 15:57:58 ruibiao Exp $ |
Add wide character support for the native NetBSD curses libraries for better internationalization and better compatibility to the X/Open curses reference.
The lack of support for wide characters in the NetBSD implementation of curses libraries limits the support for internationalized character sets, and thus limits the uses of NetBSD in countries using wide character sets. In order to add support for wide characters in the NetBSD curses libraries, the curses internal storage of characters and attributes (as defined in $SRC/lib/libcurses/curses_private.h) needs to be modified. In particular, one possible data structure (__ldata) describing each character position could contain the following:
There are concerns of more than quadruply use of memory using this new storage structure. However, such increase is an inevitable price to pay if we want to enable wide character support in curses libraries. An alternative approach is to provide storage structures for both narrow and wide characters, and make it a compile time option such that the curses program developers can decide if they want to use the wide character support depending on the memory constraints.
With the modified internal character storage data structure, the character display, insert, and delete operations will be rewritten to use the new data structure. These following functions must be modified:
Another issue with wide character is the assembling of multi-byte/multi-column characters, especially when they are on the edges of a screen. waddch must be able to determine if there is space left at the end of line to place a wide character.
Multi-byte character encoding input should be changed to be compatible with get_wch() specified in the X/Open reference. I will study how multi-byte input applications (such as cxterm and XCin) feed the encoding of a wide character to the terminal, and what does wgetch() get from them. If wgetch() returns two integers of an encoded wide character, instead of one encoded integer, we will have to reassemble them back into one, as ncurses does. Thomas E. Dickey also suggested his work with dialog may also be interesting to check out.
In addition to the modifications, the additional wide character routines specified in the X/Open Curses Reference should also be added when necessary, such as echo_wch().
I would try to make the implementation as fast as possible, so that it will be usable on machines like vax and m68k. I will also try to make it use the smallest possible memory, for these types of machine. As an additional goal, I would try to make the wide character support as a compile time option, so that it could be omitted on boot media for small memory systems.
This project will take about six weeks if I work on it about 10 hours a week. I can start to work on it as soon as it is approved after 6/24. A more detail schedule is as below:
The NetBSD curses library currently does not support wide characters, which makes it unsuitable for internationalization. The X/Open Curses Reference gives more details about the wide characters for internationalization. Although the GNU Ncurses package can be used as an installed package to support wide characters, it is not part of the NetBSD source distribution, and thus is limited for certain applications, such as installation scripts. In addition, the Ncurses use more resources and may run slowly on some platforms with limited resource and processing capability (such as vax and m68k). Therefore, a fast NetBSD curses implementation with small memory footprint is highly desirable. We need to modify the NetBSD curses libraries to support wide characters for internationalization.
I am currently a Ph.D. candidate in Department of Computer Science and Engineering at Washington University in St. Louis. I will finish up this summer. I think I am the right person to take on this projects for the following reasons:
To-do list:
Put up a Sourceforge or Tigris or Savannah project page (as suggested by Google), and announce on the mailing list.
[Status: I looked at all three hosting sites, and made some comments below. That was before Hubert sent me the email about the umbrella project already set up at SourceForge. So, the comments below becomes irrelevant. But, I just keep it here for reference. :-) I will delete the two projects I requested at SourceForge and Tigris.
Sourceforge is the largest project hosting site. So, it makes sense to put the project there. I have submitted a request for a NetBSD-wcurses project, but it currently under review by Sourceforge. and I don't have the link to the project page yet. In comparison, Tigris seems to be another good hosting choice too. I sent a request for a new project, and it is under review now. However, the project page is already up and accessible. In addition, it has some cool features, such as four mailing lists, announcements, and discussion forums. On the other hand, Savannah requires an URL to the code for their review. Correct me if I am wrong, but this is not what I expected from a project hosting service. So, I decide not to use it as the hosting site. I will wait for the review results from both Sourceforge and Tigris, and check with Brett and Julian before I announce the project site on the mailing list.]
I would like to thank Julian Coleman and Brett Lymn (both major contributors of the current curses libraries) for providing detailed requirements information about this project, James K. Lowden, Thor Lancelot Simon, Jed Davis, Martin Husemann, and Thomas E. Dickey (the long-time developer and maintainer of GNU ncurses) for their valuable suggestions and feedbacks on the NetBSD tech-userlevel mailing list. The discussion on the mailing list:
Thanks to Google for sponsoring such an event to promote open source development. Thanks to the NetBSD team for maintaining a truly multi-platform operating system.
|
|
|