OpenVanilla – A Non-Intrusive Plug-In Framework of Text Services

Tian-Jian Jiang1,2, Deng-Liu, Kang-min Liu, Weizhong Yang3, Pek-tiong Tan4, Mengjuei Hsieh5, Tsung-hsiang Chang, Wen-Lien Hsu1,2 1. Department of Computer Science, National Tsing Hua University 2. Institute of Information Science, Academia Sinica 3. Department of Theatre, Taipei National University of Arts 4. Department of Physics, National Tsing Hua University 5. School of Information and Computer Sciences, University of California Irvine 128 Academia Road, Section 2, Nankang, Taipei 115, Taiwan {tmjiang,hsu}@iis.sinica.edu.tw

ABSTRACT not to know which applications they are serving. Because (IM) is a sine qua non for text entry of many of this quality, IMs can be seen as non-intrusive plug-ins Asian languages, but its potential applications on other lan- that adds functionalities to a running application. We will guages remain under-explored. This paper proposes a phi- explore the potential of this quality in the present research losophy of input method design by seeing it as a non- and show that IMs are not only useful for Asian languages, intrusive plug-in text service framework. Such design al- but also for European, African and even artificial lan- lows new functionalities of text processing to be attached guages. onto a running application without any tweaking of code. It should be noted that although alternatives to keyboard We also introduce OpenVanilla, a cross-platform frame- exist, none of them - speech recognition, handwriting rec- work that is designed with the above-mentioned model in ognition or optical characters recognition (OCR) - equals mind. Frameworks like OpenVanilla have shown that an keyboard in text entry efficiency and accuracy. As we input method can be more than just a text entry tool: it of- won't see the end of the keyboard's day anytime sooner, fers a convenient way for developing various text service input method will continue to play an important role in our and language tools. desktop environment. ACM Classification: H5.2 [Information interfaces and HUMAN FACTOR, USABILITY AND UI DESIGN ISSUES presentation]: User Interfaces. - Input devices and strate- The Problem gies, Interaction styles, Natural language. The QWERTY keyboard was designed for one single lan- General terms: Design, Human Factors guage. Modifications have been applied to the QWERTY Keywords: Input method, non-intrusive plug-in frame- keyboard to suit the needs of other European languages work, text service such as French QWERTY and German QWERTZ key- boards. This is the origin of the “keyboard layout” of mod- INTRODUCTION ern GUI environments. Most ideograph-based Asian languages consist of thou- sands of complex characters. It would be impractical to Although the idea of keyboard layout seems to have solved create a huge keyboard to map every possible character. the problem of language-specific text entry well, it has Modern GUI environments, be it Windows, Mac limitations. First, it is impossible to enter more than one OS X, or X11, all come with build-in tools for transforming language with one single layout. For example, a French multiple composition keystrokes into one single ideograph. keyboard may not be capable of entering Polish text. Sec- These tools are known as input methods or IM for short. ond, it is impractical to attach many different keyboards to a single device. To have French and Polish keyboard at- IMs are often categorized into “radical-based” or “phonet- tached to one laptop computer is unimaginable. ics-based” methods. With radical-based input methods, users get a character by typing the composing radicals, Finally, many devices simply cannot accommodate a large whereas with phonetics-based ones users get a character by keyboard. For example, mobile phones usually have less typing the syllables. If there are homophones, a choice will than 20 keys. This is where keyboard layouts become un- have to be made, and the proper character is selected and feasible: there is simply not enough space. Using input entered. methods is the solution that is scalable up to multiple lan- guage text entry, and down to limited hardware device. As most modern GUI environments are designed with standardized IM , applications usually do not have to Input methods like [1] have achieved more balance worry if a user is entering Latin characters or Asian- situation between the trade-off of keystroke numbers and language texts (and, in the latter case, applications need not keystroke-character conversion collision rates after some to know which kind of input method the user is using). research of human factor and language model. It's valuable That is to say, text entry is transparent to the applications. to mention Hsu's keyboard layout [2], which maps Chinese Likewise, IMs work through a standardized API and need bopomofo phonemes to 25 keys by phonetic rules and simi-

lar alphabets, as the following figure shows, it is more effi- ment for years. The last is no easier than its Microsoft or cient than any traditional layout, which occupies 40 keys. Apple equivalents, though. Such complexities and difficulties are the reason why many input method frameworks have been flourishing: both IIIMF and SCIM aim to relief the pain of IM development on X Window. The Japanese aims to provide a unified interface to more than two dozens of different IM modules, so that the whole set can be easily ported. OpenVanilla Input method also solves dead-key problems on many key- serves Mac OS X and X Window well. In general, a boards of European languages. When the size of keyboard framework should provide a set of abstract API, and takes is limited, using dead keys to input several symbol is also either a dynamic-loading or client-server approach to work impractical. as a mediator between input method modules, , and applications. A framework should also imple- Text Service ment a set of default widgets and event handlers. With such So far there are two flavors of definitions of text services. “facilities,” an IM developer can concentrate on algorithm Microsoft describes its Text Service Framework (TSF) by design with no further concerns on platform-specific de- “TSF provides a simple and scalable framework for the tails. delivery of advanced text input and natural language tech- Furthermore, when IMs convert source key codes to re- nologies. ... A TSF text service provides multilanguage quired target type, they are like output filters more in some support and delivers text services such as keyboard proces- sense. Actually, even using the same input method, output sors, handwriting recognition, and speech recognition.” On results still have chances to be tweaked by applying output the other hand, Apple defines its Text Service Manager filters for different purposes, e.g. conversion between Tra- (TSM) as “A text service is a specific text-handling task ditional Chinese and Simplified Chinese. such as spell-checking, hyphenation, and handling input of In short, given that problems of keyboard is still the main complex text.” Since this paper is focused on “keyboard” input device, human factors of input remain places for im- input method, we found it would be interesting to compare provement, many text processing requirements are still with spell-checking task. Although spelling checker is a unsatisfied, and input method development are not easy. handy function of MS Word, it is only available there. INTRODUCING OPENVANILLA However, it is possible to develop an input method for this OpenVanilla is the successor of two successful open source requirement, then a “check as you type” spelling checker projects on the Mac OS X platform: VanillaInput and will be born. SpaceChewing. Both projects were designed to provide Candidate List input methods that have been (and still are) inadquately During the text entry process, chances are that a sequence supported by Apple's built-in modules. OpenVanilla is de- of keystrokes maps to multiple characters or phrases. It is signed as an abstract text input/output service framework, especially so for phonetics-based input methods, such as and after two major releases (0.6 and 0.7) it currently en- for Chinese or Kana for Japanese. A user must then joys a wide user base. pick up the exact character/phrase he or she wants from a From IM development's point of view, OpenVanilla is de- list of possible choices. Such interaction requires display- signed with the following two principles: ing those candidate characters/phrases on screen first and The framework and a set of various IM modules waiting for a choice. We call this special UI widget “candi- • should be easy to deploy. date list”. The framework should offer a unified, platform- Candidate list is an indispensable widget for Asian lan- • independent interface to save IM developers' times on guage text entry. However, it can have applications other investigating complex platform-specific issues. It than picking up a proper character; it could also serve as an should allow anyone with some basic knowledge of on-the-fly spelling checker for European languages. More C/C++ to be able to write his or her own IM module. generally, it is a context-sensitive UI widget for any type of text services. OpenVanilla is divided into two parts: platform-dependent loaders and (mostly) platform-independent IM modules. HOW INPUT METHOD WORKS OpenVanilla is actually a very thin layer of interface be- Most modern GUI environments offer a set of low-level tween the two parts, because it consists of only two C++ API for writing an input method module, but nothing more. header files. This makes OpenVanilla, especially its IM A developer that wishes to build up a fully functional IM modules, extremely easy to port and deploy. will have to deal with UI representation and write complex event handlers from scratch. This task has been increas- What OpenVanilla Is ingly complicated on and Apple's Mac • It is a set of simple header files OS X as their GUI functionalities grow in the recent years. • It is a loose set of Loaders and Modules - but both are By contrast, the XIM framework has been the de facto tied with the simple and unified set of interface standard of IM development for the X-Window environ-

• It offers a unified interface to every key-event handler sidered as a network client, it requests text services from a (OVKeyCode, OVBuffer, OVCandidate, OVService) server via a TCP socket. Then, text services could be sepa- • It is UTF-8 based, using the C-style string definition rated from user interface to realize an ideal engi- internally and throughout the framework (plain-old and neering structure. It discloses possibilities to combine alter- dirty char* is a good thing, says OpenVanilla) native systems simultaneously, for instance, there could be more choices of programming languages, but not limited by What OpenVanilla Is Not system-level API and the compatibility of Inter-Process • It is not grandiose in design (hence avoiding the over- Communication. The network connection gives more pos- design syndrome) sibilities for Internet services, too. For example, the back- • It does not try to be a jack-of-all-trade framework end information could be obtained via on-line dictionaries or search engines. • It does not claim to solve all IM problems (e.g. hand- writing pad, voice input, etc.) - it aims to solve 95% of CUSTOMIZATION, SIMULATION AND the IM problems elegantly and is happy with what it PERSONALIZATION can do Writing an IM even needs no programming training. There is a most important module of OpenVanilla called “Generic • It does not claim to be “cross-platform” without real Module”, it could use a plain text file as an IM, and anyone implementation who knows how to use a text editor could generate his/her • It does not require complicated protocol or deep de- own IM easily. pendency tree Such a text file is called “.cin” which is given by it's file • It does not care the implementation detail of respective extension. This kind of data format was invented by the Loader/modules, although it encourages platform- XCIN project, which is another IM framework for X Win- independency under the UNIX tradition (lowest de- dow system. It uses a two-rows table to record how key- pendency, high fault tolerance, “just work” and “Do board events are converted. And, five variables shared by What I Say” philosophy, minimum configuration with almost all IMs could be configured within such a file for- well-defined default behavior) mat, too. These variables are listed in the following: What OpenVanilla Does Not Do: • Show candidates as you type. • No mouse event (would result in 90% code doing 1% • Maximum key sequence length. of rarely used features) • Commit at maximum key sequence length. • No fancy candidate window control (would result in platform-dependency) • Keys are used to choose candidates. • No complicated configure widget design (would re- • Use space key to choose the 1st candidate. quire dependency on certain GUI e.g. ). The Built-in IMs of MS Windows and Mac OS all use SOME CURRENT DEVELOPMENTS similar approach to customize IM modules, however, the OpenVanilla's simplicity and flexibility makes it easy to shared configurations are still required. Therefore the “.cin” bridge with other IM frameworks. A bridge module can be format has more generality than others. Based on the “.cin” written to use other frameworks' IM modules and then format, developers of OpenVanilla designed a generic IM loaded by OpenVanilla's Loader. Such is the case of module and successfully applied it on several popular Chi- OpenVanilla's UIM bridge that currently offers an nese IMs (Japanese Hiragana) input method module. In order to approve the generic IM module, and therefore to Another way of bridging is to write a loader in the form of make it evaluating to a generic IM engine, the parts of file a framework's module. This enables OpenVanilla's modules I/O, data structures and algorithms were replaced by data- work on other frameworks. Such is the case of OV's SCIM base systems. Based on the advantage of SQLite, develop- bridge which makes OpenVanilla successfully work on X ers could use SQL commands but not design an algorithm Window environment. It's SCIM loader, OVLoader-SCIM, by themselves to process wildcard searching or sorting, is actually an SCIM-compliant input method module, they no longer need to worry about the system performance which in turns loads other OpenVanilla modules dynami- or reliability while loading or saving data streams. cally. By editing the “.cin” file or the data in SQLite databases, it Because there was an issue that the candidate list of Open- is a piece of cake for users to customize the character bind- Vanilla 0.6 could not be displayed in Dashboard of Mac OS ing to some keys. Those ones who have specific needs can X 10.4 Tiger, a display server was added into the most re- generate a simplest IM plug-in easily without the help of a cent releases of OpenVanilla. It handles all graphical programmer. Researchers can generate different IMs very events, and it makes the design of user interface is sepa- fast by taking the same way when they need experiments or rated from back-end control logic, such a design is identical analysis, especially for constructing differed simulating to the spirit of MVC. environment while studying IMs for mobile devices. Also there is an experimental prototype of a socket-based For personalization, some modern IMs would like to input method mechanism. Each IM process could be con- “learn” about users' behaviors and adjust the order of can-

didates dynamically. One of our ongoing tasks is taking the For CJKV users, it's not surprising that intelligent input concept of Cache Management Pattern [3] as the principle methods include built-in dictionaries. Actually this ap- to design such a function. Usages must be tracked and proach could be applied on English writing, too. While cached first, and then information could be mined from experimenting socket based input method mechanism, an them. IM which can notify synonyms in candidate list by using WordNet has been implemented. The user interface mi- SHOWCASES grates from dictionary query application style to input The “.cin” format originated from the famous Xcin project, method style. the first open-source project that offers various Chinese input methods on X11. OpenVanilla's generic IM module uses this open, text-based format to support IMs like Cang- jei, Array or Dayi, all of which have their respective user SUMMARY base in the Chinese-speaking world. IMs should not be limited to only work with Asian lan- Because of OpenVanilla's lean API, a Tibetan IM module guages, but also an alternative of traditional for that supports four keyboard layouts and character stacking inputting Latin scripts. Moreover, they are essentials of has been written within about 300 lines of codes. mobile devices for any language. Extending to a higher level of text service framework, IM escapes the literal meaning of the word “input”. It could be used as spell checking, dictionary, character conversion, and even inline scripting language interpreter. The potential The OpenVanilla Team has also created an IM for Roman- of such text-based application is under-explored. ized Taiwanese (Peh-oe-ji; POJ). POJ makes extensive use To make these goals easier to achieve, this paper has pro- of Latin characters with . OpenVanilla's POJ posed a perspective of “non-intrusive plug-in framework of module is so far the best and the most flexible among its text services”, and it has been implemented and proved by equals. Because of this module's flexibility, we are confi- OpenVanilla framework. With this scalable framework dent that it can be adapted to others languages that use design and flexible user interface “candidate list”, develop- , as many European languages, Vietnamese, or ers and users could release their creativity in a more feasi- African languages. ble way to bring potentials to realities. FUTURE WORKS Implementing a bridge between OpenVanilla and Windows IME API is one of the most important tasks in next step, because input method framework is absent on this most As OpenVanilla is -compliant, it supports symbol- popular platform. based input methods with ease. An example is its “EHQ” The framework design of OpenVanilla is still growing. We module, which enables users to type some 1,200+ Unicode wish it to be an experiment platform with positive feedback symbols, many of them “dingbats,” with meaningful mne- route between researches and applications. Importing natu- monics, e.g. type “*” and you get a long list of available ral language processing techniques [4] to make user- star-shaped dingbats. friendly interface is one of the key points in near future. ACKNOWLEDGMENTS

The authors would like to acknowledge the contributions of We can even create input methods for European, African, Deng Liu, Kang-min Liu, Weizhong Yang, Pek-tiong Tan, or even artificial or programming languages: such is the Mengjuei Hsieh and Tsung-hsiang Chang in the developing case of OpenVanilla's Klingon IM module. OpenVanilla. REFERENCES 1. C. James, M. Longé Bringing text input beyond the While concerning IMs as output filters, you can use simple desktop. In Proceedings of CHI'00 Human Factors in codes to convert the form of the results of IMs. OpenVa- Computing Systems, 2000, pp. 49–50. nilla supports Traditional-Simplified Chinese conversion, it 2. W.L. Hsu Chinese parsing in a phoneme-to-character is different with other converters that take the strategy to conversion system based on semantic pattern match- transform user selected sentences, but it converts as you ing. International Journal on Computer Processing of type. It is an outstanding application of output filters. Chinese and Oriental Languages 40, (1995), 227–236. OpenVanilla also supports a module to convert ASCII characters to Morse code, it makes anyone can encode their 3. M. Grand, Patterns In Java, Volume 1, 2002 messages without professional training. OpenVanilla could 4. J.L. Tsai, W.L. Hsu Applying an NVEF Word-Pair support a Braille output filter by the same way. Identifier to the Chinese Syllable-to-Word Conversion Problem. In Proceedings of COLING’02, Taipei, 2002.