Issue 21885 - RFE around an Input Method for OOo later
Summary: RFE around an Input Method for OOo later
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 RC5
Hardware: PC All
: P3 Trivial with 4 votes (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2003-10-29 17:50 UTC by tora3
Modified: 2013-02-07 22:37 UTC (History)
8 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description tora3 2003-10-29 17:50:15 UTC
RFE around an Input Method for later

Revision: 1.0 - October 29, 2003 by  Tora <>, Mikihiko Matsui

   With the enormous efforts focusing on Asian features the current 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
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()

 IM mode: ImmSetConversionStatus() / ImmGetConversionStatus()

(1) Default IM status for a new document
   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

   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 >

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

   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]

[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
   This feature provides users a chance to specify the initial IM status of

 See "Command line options" section in

   This option will override any other settings, except (4) attributes of
object,  if this command line option is taken.

[Possible Impacts on the UI]

[Possible Impacts on the Souse Codes]
   Need to be discussed.

(4) Adding an IM status to attributes of cells in Calc, etc
   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)

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

   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]

[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 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.
Comment 1 christof.pintaske 2003-11-04 17:55:24 UTC
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.
Comment 2 tora3 2003-11-05 08:03:09 UTC
   For UNIX variants, some primary members in Input Method Subgroup of 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    :
   ML(Input Method):

   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.

Comment 3 christof.pintaske 2003-11-05 17:49:43 UTC
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 ?
Comment 4 stephan_schaefer 2003-11-24 10:00:20 UTC
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):
and here (sentence mode):

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. 
Comment 5 falko.tesch 2003-12-08 15:27:46 UTC
Changed status
Comment 6 falko.tesch 2005-10-20 20:20:46 UTC
FT: Re-assigned to requirement default user