Issue 42732 - Font drop down should be aware of current keyboard layout
Summary: Font drop down should be aware of current keyboard layout
Alias: None
Product: Internationalization
Classification: Code
Component: code (show other issues)
Version: 680m79
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@l10n
Keywords: oooqa, usability
Depends on:
Blocks: 41707
  Show dependency tree
Reported: 2005-02-14 13:15 UTC by samphan
Modified: 2013-08-07 15:01 UTC (History)
9 users (show)

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

Mixed Thai/English document that can be used for studying Word's behavior (19.50 KB, application/msword)
2005-12-02 05:05 UTC, jjc
no flags Details
Updated spec (27.49 KB, application/vnd.sun.xml.draw)
2006-01-19 13:42 UTC, jjc
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description samphan 2005-02-14 13:15:14 UTC
On Windows XP, WordPad has a drop down box for the current script, next to the
font name and font size drop down boxes; when the keyboard layout is changed,
the script in the drop down box changes automatically.

In MS Word XP, when you change the keyboard layout, the font drop down shows the
font of the script. For example, if you set 'Latin text' font to Times and
'Complex scripts' font to Angsana, pressing Alt-Shift to swtich the keyboard
layout between English and Thai will also switch the font in the font drop down
between Times and Angsana.

OOo implements this differently, after switching the keyboard layout, you have
to type something for the font drop down to change accordingly. The font drop
down should change as soon as the keyboard layout is changed (not after typing
something) to reflect the font for the text that will be typed next.
Comment 1 jjc 2005-02-15 07:17:47 UTC
The problem here is that it is that is hard for the user to control/understand
whether the font drop-down box will affect the Western font or the CTL font at
any point.  For example, suppose the user has been typing English and is about
to type Thai, and therefore wants to set the font they will use for Thai; at the
moment if they try to use the drop down font box to do this, it will change the
Western font and thus not have the desired effect.  If the current keyboard
layout is Thai, it seems very strange for the font drop down box to affect the
Western font.  The natural solution would seem to be for the current keyboard
layout to determine whether the font drop-down box affects the Western, Asian or
CTL font.
Comment 2 arthit 2005-02-20 19:30:50 UTC
Comment 3 jjc 2005-02-21 07:00:08 UTC
This seems related to issue 31803.
Comment 4 Martin Hollmichel 2005-05-11 16:11:16 UTC
set target to 2.0.1
Comment 5 falko.tesch 2005-05-12 12:46:28 UTC
FT: From what I understand the problem here derives from a bug that lies in
Writer 2.0.
Every time Writer is started it will re-set the keyboard layout to its default
Example: If Writer's locale is set to English US than the keyboard setting will,
regardless to its system default, set to English US once Writer starts up.
This is a bug that needs fixing.
Writer must behave like every other application under Windows:
Writer must start up with the default keyboard setting that is defined within
the system.

Coming to automatic change on drop down list boxes in WordPad and Word when
changing the keyboard layout:
Both apps change the list box entry once the *first* character is typed. Writer
behaves exactly the same here.

FT->OS: Hope you are the right owner for this.If not please forward to the
appropiate person. Thx a lot.
Comment 6 Oliver Specht 2005-05-12 14:04:15 UTC
->FT: What makes you think the Writer changes the keyboard layout? 
Even if it does I can not see this related to this issue. 

A solution that the font box shows and applies the font to the script type that
matches the current keyboard setting has a drawback: Once you select text in a
script type different from the keyboard setting what should be done? Show the
font of the selected text or show the font that would be used if you input the
next character?
Another problem: On non-Windows systems the current keyboard layout can not be

So Falko, what do you expect me to do?

Comment 7 jjc 2005-05-12 14:48:27 UTC
This hasn't got anything to do with the default keyboard setting. It's a matter
of making the choice of whether to display the Western, Asian or CTL font in the
font-box be sensitive to the current keyboard layout.

You can detect the current keyboard layout on X, using e.g. libxklavier.

os raises a good question of what to do when there is text selected.  I would
say in that case continue use the script of the selected text.  The current
behavior is not a problem when there's selected text: it's unambiguous what's
intended.  There's only a problem when there's no text selected: there are
multiple things that the user might intend, and I see nothing but the keyboard
layout that can be used to disambiguate them,

Word actually goes further: it has an option to automatically change the
keyboard layout to match the script of surrounding text whenever the user moves
to a new position in the text.
Comment 8 falko.tesch 2005-05-17 10:02:22 UTC
FT: Well, here is how Word 2003 on WinXP does ist:
User opens a new document -> font drop down list box shows default font of the
current active IME region (Western, CJK or CTL)
User presses a SPACE of text -> font drop down box show Western(!) default font
User continues to type after SPACE -> font drop down switches to default font of
the current active IME region (Western, CJK or CTL)

User selects text:
Text contains fonts of one IME region -> font drop down box show the adequate
default font only
Text contains fonts of 2 or more IME regions -> font drop down box is empty

FT-> Samphan: Is that how you want to have it?
I find is very strange that Word is always switching back to Times New Roman
when pressing SPACE. I would vote to only change the content of the font drop
down list box when the user actually *starts* typing in a different locale.
Comment 9 samphan 2005-05-19 02:58:53 UTC
> User opens a new document -> font drop down list box shows default font of 
> the current active IME region (Western, CJK or CTL)
> User presses a SPACE of text -> font drop down box show Western(!) default font

I follow the same procedure on Word 2003 on WinXP. 
Switch keyboard to Thai, open a new document, font drop down show 
'Angsana New', press a space, the font drop down still is 'Angsana New'.
Until I switch to English keyboard that the font drop down show 'Times New Roman'.

> I find is very strange that Word is always switching back to 
> Times New Roman when pressing SPACE. 

Consider it a MS Word bug and don't repeat it.

> I would vote to only change the content of the font drop
> down list box when the user actually *starts* typing in a different locale.

In my opinion, the font drop down should show which font the next 
character to be typed will be. That's less confusing.
Comment 10 jjc 2005-05-19 18:33:47 UTC
ft, I think the weirdness you're seeing is IME-related.  Try it on a system with
just English and Thai keyboard layouts and without any IME, switching between
keyboard layouts using the language bar.  You shouldn't see the SPACE behavior
you describe, which I agree is very strange.

If there's no text selected, the font box should show the Western, CJK or CTL
font according as the current keyboard layout is that of a Western, CJK or CTL
language.  This ensures that the font shown in the font box corresponds to that
which will be used for the next character the user types.  It also ensures that
the user can easily change the font that will be used for the next character
that they will type by first changing (if necessary) to the keyboard layout they
will use to type the character and then selecting a font in the font box.

You certainly don't want to wait till after the user has started typing CTL
characters, because when they want to change the CTL font, they need to do it
before they type any CTL characters; this is the main problem with the current

I'm afraid I can't really say exactly how things should work in the presence of
IMEs, because I have almost no experience using them.
Comment 11 falko.tesch 2005-09-28 17:02:48 UTC
FT: Specs published at
Please refer to spec to implement this issue.
Note: This is a Windows-only issue and must not alter the behaviour of
2.0.1 for all other platforms.
Comment 12 stephan_schaefer 2005-10-06 17:10:22 UTC
ssa->os: In CWS thaiissues VCL provides a new command event:
COMMAND_INPUTLANGUAGECHANGE that is send only on Windows whenever the user sets
the input language in the language bar to a language that is different from the
one that is currently used. The event is sent to the window that currently
receives key input.
The language can then be queried using Window::GetInputLanguage().
Comment 13 Oliver Specht 2005-10-13 16:02:33 UTC
Fixed in cws thaiissues in 

Created cloned tasks for Calc (issue 55928) and Draw/Impress (issu 55928)
Comment 14 Oliver Specht 2005-10-31 11:15:50 UTC
Reassigned for verification

re-open issue and reassign to
Comment 15 Oliver Specht 2005-10-31 11:16:04 UTC
reassign to
Comment 16 Oliver Specht 2005-10-31 11:16:11 UTC
reset resolution to FIXED
Comment 17 stefan.baltzer 2005-11-07 15:32:31 UTC
SBA: Reopened to reassign.
Comment 18 stefan.baltzer 2005-11-07 15:33:01 UTC
SBA: Reassigned to HI.
Comment 19 stefan.baltzer 2005-11-07 15:33:32 UTC
SBA: Reset resolution to "Fixed".
Comment 20 h.ilter 2005-11-07 15:57:30 UTC
HI: Verified with cws thaiissues = ok
Comment 21 jjc 2005-11-10 16:19:03 UTC
There's a little problem with the implementation.  The vertical height of the
cursor doesn't change immediately to match the font size.  The spec says
explicitly it should change immediately.  For example, if your CTL font has a
size of 18 and your Western font has a font size of 10, then changing from
English to Thai keyboard layout should cause the size of the cursor to change
(increase) immediately.  Currently it only changes after you enter some characters.

This happens in both Writer and Impress.
Comment 22 jjc 2005-11-10 16:28:35 UTC
Reassigning to os.
Comment 23 Oliver Specht 2005-11-10 17:35:14 UTC
That can only be an error in the spec.

The cursor reflects the font size attributes of the script type at the current
location. The attributes and script type are not influenced by the input locale.

->MH: Who is now responsible for the spec?

Set to fixed to finish the CWS in time.
Comment 24 Oliver Specht 2005-11-10 17:35:31 UTC
Comment 25 h.ilter 2005-11-11 09:55:22 UTC
I've verified it again with a new cws build. The font-type and the font-size
will change immediately as soon as I change my input from "en" to "th".
Font: en:Thorndale; th:Angsana New
Size: en: 12; th:18
Comment 26 h.ilter 2005-11-17 16:44:43 UTC
This feature is integrated since 680m141_8976.
Comment 27 jjc 2005-12-02 04:59:32 UTC
I'm sorry to be a bore and keep reopening this, but the current implementation
(as seen in 2.0.1rc1) is badly broken from a user experience point of view: the
current behaviour is both highly unintuitive and inconsistent with Word.  There
are two problems:

1. The font dropdown is now sensitive to the keyboard layout; the problem is
that it is now sensitive *only* to the keyboard layout, which was not intended.
 When you change the keyboard layout from eg Thai to English, the font dropdown
changes from showing the CTL font to showing the Western font. So far so good. 
But now when you move the cursor from English text to Thai text (leaving the
keyboard layout as English), the font dropdown continues to show the Western
font rather than changing to show the CTL font.  This is a change in behavior
that was not in the spec.

2. The font dropdown is no longer in sync with the cursor size. (This is the
problem I mentioned in a previous comment.) This is very unintuitive, and in
explicit contradiction to the spec.

Word's behavior is quite subtle:

a) The font dropdown is *always* in sync with the cursor size. Conceptually,
there's a single current script group, which controls both the font dropdown and
the cursor.

b) When the keyboard layout changes, the current script group changes to that of
the keyboard layout.

c) When the cursor moves, the current script group changes to be that of the
character before the cursor.  If the cursor is at the beginning of a non-empty
paragraph, then it changes to the character following the cursor.

d) When backspace is used to delete a character, the current script group
changes to be that of the character deleted.

Part of the problem here is the implementation not following the spec (eg
problem 2), but part of the problem is that the spec failed to make certain
things explicit (which is partly my fault, for which I apologize).
Comment 28 jjc 2005-12-02 05:05:55 UTC
Created attachment 31972 [details]
Mixed Thai/English document that can be used for studying Word's behavior
Comment 29 jjc 2005-12-02 05:12:11 UTC
I should also mention that Word has an option (enabled by default) whereby it
can automatically change the keyboard layout when the cursor moves.  Since OOo
doesn't have this feature yet, the Word option should be turned off (on
Options|Edit) when looking at Word's behaviour.

The behaviour is approximately:

e) if the "Automatically change keyboard layout" option is set, then change the
keyboard layout to match the current script group (actually I guess this means
that the state is a current input language rather than a current script group)
Comment 30 jjc 2005-12-02 06:04:26 UTC
On a separate note, I was told that it was impossible to implement this on
Unix/Linux.  I don't understand why it's impossible:

- we can surely make use of the Xkb extension; it's ubiquitous nowadays and vcl
already uses it

- Xkb gives you events so you can track the current keyboard group (1-4)

- the only difficult bit is to figure out the script or language from the
keyboard group; I can see three possible approaches for this:

a) for each keycode, find the keysym bound to the keycode in the group; from
this set of keysyms deduce the script

b) use the symbolic name of the groups (the groups field in XkbNamesRec); this
corresponds to what is specified in the symbols file by eg

   name[Group1]= "Thailand";

c) parse the symbolic name of the set of symbols being used (the symbols field
in XkbNamesRec); this typically has a structured form with a segment for each
group separated by +
Comment 31 Mathias_Bauer 2005-12-09 10:14:10 UTC
2.0.1 is closed, adjusting target
Comment 32 jjc 2005-12-15 17:49:16 UTC
Another problem is that the required behaviour is not yet implemented in Calc.
Comment 33 jjc 2006-01-19 13:42:03 UTC
Created attachment 33381 [details]
Updated spec
Comment 34 Mathias_Bauer 2006-01-23 13:18:20 UTC
We will not finish this task in the 2.0.2 time frame -> retargetted to 3.0
Comment 35 niklas.nebel 2006-02-22 14:42:10 UTC
How is the updated feature supposed to work in Calc? Still only in edit mode,
like the current implementation? If so, what's the initial state after starting
a (filled or empty) cell's edit mode?
Comment 36 Oliver Specht 2006-03-17 11:33:14 UTC
Fixed for sw in 

The spec point regarding characters deleted with backspace has not been
implemented. To implement the regarded change requires a considerable amount of
development time. It should be moved to the Future Tasks section.
Comment 37 niklas.nebel 2006-03-20 17:16:03 UTC
It's still unclear how this is supposed to work in Calc.
Comment 38 frank.meies 2006-03-21 10:54:44 UTC
FME: Reassigned to OS.
Comment 39 frank.meies 2006-03-21 10:55:58 UTC
Comment 40 jjc 2006-03-22 13:14:31 UTC
There's a little problem (in the os79 CWS which mh just made available), which
you can reproduce as follows:

- change the keyboard to English
- the font drop down will shown Times Roman
- type some English
- change the keyboard to Thai
- the font drop down now shows Angsana New
- using the font drop down change the font to Cordia New
- the font drop down now shows Times Roman instead of Cordia New (although it
did correctly change the CTL font to Cordia New) 
Comment 41 jjc 2006-03-22 13:28:20 UTC
As regards Calc, I think it's fine just to work in edit mode.  After starting
edit mode, I think the behaviour that is most consistent with Writer is:

- when the cell is empty, the font drop down display is determined by the
current keyboard layout

- when the cell is not empty, the font drop down display is determined by the
position of the cursor and the contents of the cell
Comment 42 frank.meies 2006-03-29 12:21:22 UTC
FME: Fixed the remaining Writer issue .
Comment 43 Oliver Specht 2006-04-24 07:28:32 UTC
What about the current state? There's not much time to get this issue into OOo
Comment 44 stefan.baltzer 2006-04-28 13:27:53 UTC
SBA: Another week hass passed...
From the QA point of view, this one does not fit in the regular time frame for
OOo 2.03 anymore. Monday, May 1st is bank holiday in Germany and last regular
CWS integration is Thursday, May 4th.
I propose to shift the target to OOo 2.04.
Comment 45 andreschnabel 2006-05-25 18:46:50 UTC
can someone please update the status of this issue? 
- Is it correct, that it is set to be fixed or are there still problems?
- are all Fixes integrated in 2.0.3?

if there are any problems left target should be moved to 2.0.4
Comment 46 Oliver Specht 2006-05-29 10:36:43 UTC
Target changed to 2.0.4
Comment 47 Oliver Specht 2006-07-20 07:07:23 UTC
Reassigned for verification
Comment 48 stefan.baltzer 2006-07-26 11:36:41 UTC
SBA: Verified in CWS os79.
Comment 49 stefan.baltzer 2006-08-15 14:05:37 UTC
SBA: OK in 680m1 Build 9062.