Recipient Institution:
Sun Wah Hi Tech (Nanjing) System Software Limited

Room D&E, 8/F Fusheng Building
1 Fuhougang, Nanjing 210008
People's Republic of China

Tel/Fax: 86-25-369 6091
Email: zqwang@sw-linux.com

Sun Wah Linux Limited

12/F, 9 Des Voeux Road West
Sheung Wan
Hong Kong

Tel/Fax: 85-22-2500230
Email: roger.so@sw-linux.com

Free Standards Group - Open Internationalization Workgroup

404 Wyman Street
Waltham, MA.02454
United States of America

Tel/Fax: 1-781-237-3442
Email: hshih@openi18n.org

Project Leader:
Roger So

Amount and Duration: US$ 30,000 / 12 months

Commencement Date:
1 January 2004

Project Proposal

Project Objectives:

General Objective:
The purpose of a terminal emulator is to provide support for applications that cannot use a window system directly. Internationalization support in terminal emulators is especially lacking in the open-source community. Development of a low cost, robust, and friendly user interface
is important to attain the following objectives:

Specific Objectives:
1. Bridge the digital divide between rich and poor computer users.
The majority of the world population speak non-Latin-based languages natively. However, all of the freely available terminal emulators support only Latin-based languages. Many non-Latin-based speakers cannot afford a commercially available user interface which adheres to their local cultural conventions.

2. Promote the use and ability to develop while maintaining cultural diversity.
Many computer users in developing countries have to cope with using English only when developing or receiving information on a computer. The iTerm project will enable computer users to utilize their own languages in any interface environment.

3. Meeting the special needs of countries with more than one official language.
A well internationalized terminal emulator will not only allows users to operate using their local languages, it will also enable the ability to dynamically manipulate information in multiple languages simultaneously. This is particularly useful in African countries where there is often more than one working language used at the same time in communication, e.g. Arabic and French.

3) Project Beneficiaries:

Free disbursement of the terminal emulator program will allow users to utilize more powerful computing devices using a "light-weight" device (i.e. PDA, cell phone). This is especially beneficial to those who do not understand a second language (e.g. English) and only have access to limited hardware resources.

iTerm is designed such that it can support any console environment. There are currently no console terminal programs that can support input/output of all the language support found in the OS. With iTerm, the terminal emulator can be enabled to support Kanji character input, for example. The users of popular toolkit environments such as GNOME and KDE, etc. will also benefit from this work.¡

4) Project Sustainability:

At the first release of this project, the deliverable will be hosted on the OpenI18N website at http://www.openi18n.org. The deliverable will be publicly available for download. The source code will also be freely available for access by CVS, concurrent version system. After the first release, OpenI18N will continue to maintain these resources and contribute patches if necessary.

5) Project Methodology:

The implementation of internationalized terminal emulators is divided into three parts, (libiterm, widget, and a terminal emulator program). They are discussed here.

libiterm:
The foundation of the internationalized terminal emulator "libiterm" implements the "View" independent core international terminal emulator capability, including BiDi support. libiterm is designed to be platform and architecture neutral. All platform dependent modules are provided only through the Service Provider Interfaces(SPI).

There are two categories of SPIs that abstracts out the platform interface complexity. The abstraction layer makes it easier for the user interface developers to build additional platform/environment bindings.
- The I/O SPI is generalized to communicate with the host machine to which the terminal emulators connect to.

There are several ways to connect to a host system. Typically, a connection is made through a pseudo tty (on a Unix like system) or a telnet/ssh connection. Usually these protocols are tied into terminal emulators and thus are difficult to support in other ways in connecting to a host. However iTerm I/O SPI provides an interface to support other connection methods, for example, a serial connection. In that case, the user can just create the serial connection module according to the interface without knowing the details of how the emulator works.

- The layout engine SPI provides the interface for complex text
rendering service.

This mechanism includes, but is not limited to, handling right to left ordering and context sensitive languages. The popular
toolkit may use different underlying text rendering services. The iTerm BiDi SPI provides an abstract interface to support the
different underlying services consistently.

widget:
A widget is a component of the software, for example, button widget, menu widget, text widget and so on. Widgets are constructed based on the "libiterm" library are are considered the "View" objects of a terminal emulator. In special environments, such as a frame-buffer console, a widget will not be available because it requires a window system. In such an environment, a terminal emulator could be constructed directly based on the support provided by "libiterm". There are various widget sets used by different user interface environments, for example, gtk used by GNOME and QT used by KDE. The iTerm project will provide Widgets which are reusable modules and provide terminal emulator component for various widget sets such as gtk or QT.

terminal emulator program:
The Terminal Emulator facility would implement application specific code, such as initialization, parameter handling, etc.. With this support, a developer could concentrate on adding or creating fancy user interfaces without the need to re-invent the more complex terminal emulator handling which would now be generally provided.

Usually, input methods(IM) are provided by a window system, therefore the widget uses that IM to obtain its data. "framebuffer iTerm"(fbiterm) is one of those special cases of which the user cannot rely on any widgets since there is no associated windowing system. Therefore, framebuffer doesn't have the usual IM and reads only keyboard data directly. This makes it difficult to input non-English languages, e.g. East Asian languages. An example is the Linux frame-buffer console. In that environment, the console needs to be able to handle the input from any code set without window system support.

To solve the problem, fbiterm implements an internet-intranet input method protocol(IIIMP). IIIMP is a protocol of IIIM framework(IIIMF) which is designed architecture and platform independent. IIIMF has a client library called "libiiimcf" for client side implementation.

Figure 1. iTerm framework

6) Project Timelines:

The iTerm project is currently being implemented according to the methodology previously discussed. We have already developed libiterm, libXiterm (Athena Widget of iTerm), xiterm and fbiterm which are highlighted in green in figure 1.

Progress has stopped due to lack of funding with the items highlighted in Red in figure 1. remaining to be done. The times to implement these items are described as follow:

The use of "PM" here denotes person months to be worked
The use of "I18N" means Internationalization.

7) Project Output:

These projects will produce the following results.
1. libiterm: The platform independent terminal emulator module and document
2. fbiterm: A Linux frame-buffer terminal emulator which has multi lingual input methods
3. widget for MS Windows: A reusable terminal emulator component for Microsoft Windows
4. iTerm for Windows: An internationalized terminal emulator for Microsoft Windows
5. libgtkiterm: A reusable gtk widget of iTerm
6. giterm: An I18N terminal emulator built on GNOME technology
7. libqtiterm: A reusable QT(KDE) widget of iTerm
8. kiterm: An I18N terminal emulator built on KDE technology

8) Project Monitoring:

The following mechanisms are, or will be put, in place to monitor the project.

- Development is being, and will be, done in an open CVS repository:
iTerm has been developed in a CVS repository which can be accessed
by any internet user.
- Bi-weekly snapshot: bi-weekly snapshot archives will be provided for
users who don't want, or may not have, CVS access.
- Discussion on a mailing list: every iTerm related discussion is
held on an publicly open mailing list.
- Progress and status information are published: changes of each
snapshot are published on the mailing list and website when snapshot
is released.

9) Copyright and Dissemination:

In keeping with the policies of the Free Standards Group and its Open Internationalization workgroup, wherein we develop and publish our work freely and under open source licenses, we will allow for copying and free disseminating of the works produced from this project.
Specifically, we intend to publish this work under the "Common Public License" version 1.0 which can be found at http://www.opensource.org/licenses/cpl.html.

References:

i. Model-View-Controller (MVC)

The Model-View-Controller is a commonly used architecture for graphical
user interface. The MVC paradigm is a way of breaking an application
interface into three parts. It was developed to map the traditional
input, processing and output in the computing environment into the
user interface world:

Input --> Processing --> Output
Controller --> Model --> View

The model is used to manage information and notify observers when that
information changes. It manages one or more data elements, responds to
queries about its state, and responds to instructions to change state.

The view is responsible for mapping graphics onto a device. A view
typically has a one to one correspondence with a display surface and
knows how to render to it.

A controller is the means by which the user interacts with the
application. A controller accepts input from the user and instructs
the model and view to perform actions based on that input.

The model, view, and controller are intimately related and in
constant contact. Therefore, they must reference each other. The
picture below illustrates the basic Model-View-Controller relationship