Apache OpenOffice (AOO) Bugzilla – Issue 21885
RFE around an Input Method for OOo later
Last modified: 2013-02-07 22:37:53 UTC
RFE around an Input Method for OpenOffice.org later Revision: 1.0 - October 29, 2003 by Tora <tora@openoffice.org>, Mikihiko Matsui <matui@pluto.dti.ne.jp> With the enormous efforts focusing on Asian features the current OpenOffifce.org/StarSuite Japanese has become superior to MS Office Japanese in a several ways. Nonetheless, OOo/SS can still be enhanced to greatly attract not only Japanese but also other Asian users. Making an Input Method (IM), also known as Input Method Editor (IME), which converts a keystroke sequence of alphabetical letters into Asian characters, more useful can be one of the feature enhancements that elevates a usability. The members of ja.openoffice.org have been discussing the following new features: (1) Default IM status for a new document (2) Saving the current IM status in a document file (3) Command line option that specifies the IM status at startup (4) Adding the IM status to attributes of cells in Calc, etc. (5) New service in the API that controls an the status MS Office Japanese already realizes (1) and (4) above, which are considered mandatory features among Office users. Word and PowerPoint Japanese start with an activated IM; Excel starts with an inactivated IM. Cells in Excel can have an individual IM status and mode as a part of its attributes, such as enabled/disabled, activated/inactivated/follow previous status, and class of Japanese characters. (2) and (3) will be new features that users probably have never experienced. (5) seems to be partially implemented as some functions of VBA in MS Office. Input Method, provided by OS venders or third parties and implemented outside OOo, helps users enter Asian characters through their alphabetical keyboard. It is usually activated or inactivated by pressing a special key or a specific key sequence, i.e. by hand. If an application software automatically alter the IM status properly in advance of user's keystroke, the user would find the software impressively useful. How to control the IM from OOo might depend on the OS on which OOo is running. For Windows there seems an API interface, provided by the OS, through which OOo may be able to handle the IM; for UNIX further studies about the interactions among OOo, IM, window manager, and X Window server might be needed. The following functions seem a set of ways that control the IM on Windows: IM status: ImmSetOpenStatus() / ImmGetOpenStatus() http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/ime_1n3n.asp IM mode: ImmSetConversionStatus() / ImmGetConversionStatus() http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/ime_5j8z.asp ------------------------------------------ (1) Default IM status for a new document ------------------------------------------ [Descriptions] This feature determines the IM status when an empty document is newly created. The initial values of the IM status, if possible, can be defined by users through, for example, Tools > Options. The default values that will be originally integrated in the install set are listed below: Writer: On, the same as MS Word Japanese Impress: On, the same as MS PowerPoint Japanese Calc: Off, the same as MS Excel Japanese Draw: TBD, maybe the same as Impress HTML: TBD, maybe the same as Writer Master: TBD, maybe the same as Writer On: IM is activated; Off: IM is inactivated; TBD: To Be Decided [Notes] This IM status will be overridden with (2) the settings retrieved from a document file if the IM status is not specified by (3) the command line option. [Possible Impacts on the UI] There might be some changes in the individual dialogue windows on Tools > Options. [Possible Impacts on the Souse Codes] OOo 1.0 does not programmatically control the IM or care about the status of the IM. On Windows OOo will have a capability to communicate with the IM through the API; on UNIX there might be no change due to insufficient API between OOo and the IM, or there might some changes. ----------------------------------------------------- (2) Saving the current IM status in a document file ----------------------------------------------------- [Descriptions] This feature allows users to continue to edit their document under the same circumstances as they did, by storing the current IM status along with the cursor position in a document file when the document is saved and retrieving them from the file when the file is opened. What kind of items should be stored in a document file are to be discussed later: e.g. the status (on/off) and mode (Hiragana/Katakana/etc). MS Office does not have this type of feature, even retaining the cursor position. Lacking this feature makes users irritated when they try to resume yesterday's work, but having this feature has users forget such interruption. [Notes] This IM status will override (1) default IM status, but must be overridden by (3) the command line option if the option is specified. If a document file does not include such information, maybe prepared with the former version or another application, (1) the default IM status will be applied, instead. [Possible Impacts on the UI] None. [Possible Impacts on the Souse Codes] Need to be discussed. Additionally, the XML file format should be revised. ------------------------------------------------------------------- (3) Command line option that specifies an IM status at startup ------------------------------------------------------------------- [Descriptions] This feature provides users a chance to specify the initial IM status of application. See "Command line options" section in http://www.openoffice.org/dev_docs/source/644/features.html [Notes] This option will override any other settings, except (4) attributes of object, if this command line option is taken. [Possible Impacts on the UI] None. [Possible Impacts on the Souse Codes] Need to be discussed. ---------------------------------------------------------------- (4) Adding an IM status to attributes of cells in Calc, etc ---------------------------------------------------------------- [Descriptions] This feature has already been invented and implemented in MS Office Japanese. This feature adds IM related attributes to a variety of objects such as cells in Calc, flames in Writer, textboxes in Impress or HTML, etc. When the object is focused, its IM status will automatically be altered as specified. The additional attributes and their value choices might be: - IM function is either enabled or disabled. - IM status is one of activated, inactivated, and uncontrolled. - IM conversion mode is one of Hiragana, Fullwidth Katakana, Halfwidth Katakana, Fullwidth Alphanumeric, and Halfwidth Alphanumeric. 'uncontrolled' means that OOo will not control the IM purposely. In other words, it is the same as OOo 1.0 implementation. 'disabled' means that the IM must not be activated whatever the user tries to activate it with a special key that usually toggles the IM status. Even though the IM status of the object is determined and set by these attributes when it gets a focus, the user can alter its status and/or mode with keystrokes or use of menus of the IM system if 'disabled' is not specified. Once the IM is activated or inactivated by this attribute settings, its status remains when the focus moves to another object that does not have any IM related attribute. In this case, its mode will be back to the default value, normally Hiragana, that is defined by the IM system. Here is one example that helps users fill some textboxes and/or fields in Writer and/or HTML, cells in Calc, fields in Data Source. With this feature the users do not need to think about the status or mode of the IM, and can concentrate on filling the fields given. Address Book - Name: (Enabled, Activated, Hiragana) - Name(Phonetic): (Enabled, Activated, Fullwidth Katakana) - ZIP Code: (Disabled, N/A, N/A) - Address: (Enabled, Activated, Hiragana) [Notes] The value of command line option will be ignored if these attributes are set and the object is focused at the time the application starts. [Possible Impacts on the UI] Here and there. [Possible Impacts on the Souse Codes] Need to be discussed. Import and export filter for MS Office should handle these attributes because Office already has them. -------------------------------------------------------- (5) New service in the API that controls an IM status -------------------------------------------------------- [Descriptions] This feature supports an API interface through which outer applications or users can remotely control the IM. In addition to the API, OOo BASIC should also support the API. [Notes] For a macro recorder, OOo 1.0 implementation is good enough. Please don't make any changes so that the recorder will not record any individual keystrokes but committed results, in the same way as OOo 1.0. [Possible Impacts on the UI] None. [Possible Impacts on the Souse Codes] Need to be discussed. Some of these new features are replicas of MS Office Japanese, but the others are newly invented by the members of ja.openoffice.org through lots of experiences in daily use of OOo. So, the ideas presented in this article are a mixture of the ideas provided by Windows users who know MS Office products very well and UNIX users who tend to invent new features. Obviously, these features will improve a usability of OOo/SS around Input Method.
cp->ssa: please comment on the technical possibilities for querying and setting ime states on windows (what type of state can I set ? is this a defined state or just a blob (i can set what i once got) ? please pass it on to FT then.
For UNIX variants, some primary members in Input Method Subgroup of OpenI18n.org have come to have an interest in this topic that will need additional capabilities of IM system to allow X Window clients to control an Input Method server through Internet-Intranet Input Method Protocol (IIIMP). They would like to work with us to enhance the IM system on UNIX for raising users' satisfaction, compared to MS-IME API's capabilities, by revising the IIIMP itself and persuading some IM vendors to implement it. Project Page : http://www.openi18n.org/subgroups/im/ ML(Input Method): http://www.openi18n.org/ml/ The Japanese 2nd prized Word Processor vendor, JustSystem, has already provided its IM engine for Windows, Linux, Solaris, and others that can use both IIIMP and XIM, named ATOK. http://www.justsystem.com/
cp->ssa: see above. somehow i failed to reassign ... cp->tora: that's definitively interesting. Do you have a kind of a roadmap for these features ?
SSA->FT: On Windows we can store the IME state in two 32Bit values and a boolean that indicates if the IME should be opened or closed. The two 32bit values store the conversion and sentence mode as defined here (conversion mode): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/ime_1xo3.asp and here (sentence mode): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/ime_3n3n.asp I see no problem in making these properties available by an API that can be used from the applications to set or retrieve those values. However, this is Windows only. On UNIX this information is not available yet. But the API can be defined in a way that would allow for later integration of UNIX specific properties. We only have to make sure that the originating platform and the size of the IME data is stored in the documents as well.
Changed status
FT: Re-assigned to requirement default user