Issue 42732

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.

Confirmed.

This seems related to issue 31803.

set target to 2.0.1

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

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

So Falko, what do you expect me to do?

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.

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.

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

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

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.

FT: Specs published at
http://specs.openoffice.org/g11n/keyboard_layout_awareness/42732_Font_drop_down_awareness_of_keyboard_layout.odt
Please refer to spec to implement this issue.
Note: This is a Windows-only issue and must not alter the behaviour of OO.org
2.0.1 for all other platforms.

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

Fixed in cws thaiissues in 
sw/source/ui/docvw/edtwin.cxx
sw/source/ui/shells/basesh.cxx

Created cloned tasks for Calc (issue 55928) and Draw/Impress (issu 55928)

Reassigned for verification

re-open issue and reassign to sba@openoffice.org

reassign to sba@openoffice.org

reset resolution to FIXED

SBA: Reopened to reassign.

SBA: Reassigned to HI.

SBA: Reset resolution to "Fixed".

HI: Verified with cws thaiissues = ok

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.

Reassigning to os.

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.

.

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

This feature is integrated since 680m141_8976.

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

Created attachment 31972 [details]
Mixed Thai/English document that can be used for studying Word's behavior

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)

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 +

2.0.1 is closed, adjusting target

Another problem is that the required behaviour is not yet implemented in Calc.

Created attachment 33381 [details]
Updated spec

We will not finish this task in the 2.0.2 time frame -> retargetted to 3.0

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?

Fixed for sw in 
sw/source/ui/docvw/edtwin.cxx
sw/source/ui/inc/edtwin.hxx
sw/source/ui/shells/basesh.cxx
sw/source/ui/uiview/view.cxx
sw/source/ui/uiview/view1.cxx

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.

It's still unclear how this is supposed to work in Calc.

FME: Reassigned to OS.

.

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) 

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

FME: Fixed the remaining Writer issue .

->james_clark:
What about the current state? There's not much time to get this issue into OOo
2.0.3.

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.

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

Target changed to 2.0.4

Reassigned for verification

SBA: Verified in CWS os79.

SBA: OK in 680m1 Build 9062.
Closed.