*** Bug 62061 has been marked as a duplicate of this bug. ***

reproduced on Libreoffice 4.0.1.2

it happen when your locale are not RTL langauge (Right to Left).

Operating Systems: ubuntu 12.10 (64 bit)

*** Bug 71913 has been marked as a duplicate of this bug. ***

I think what happens is that changing the font from the menu only the “western” font and when one starts typing in a CTL script (Arabic, Indic, etc.) Writer switches to the CTL font (both can be seen from Format → Character). It is very annoying indeed (together with the almost meaningless script classification), but I’m not sure what is the best way to mitigate this. May be changing the font in the font menu should change all the three font categories at once?

There is nothing meaningless in separation of fonts which contain letters and those which don't.

This is to confirm that I tested the bug in LibreOffice version 4.4.2.2.
The bug is still there. I would rephrase it to make it more accurate

Steps to reproduce:
1. Open a new text document in LibreOffice (e.g writer, impress, calc)
2. Change the language to Arabic, choose an Arabic font and type some text
3. The font chosen is not applied to the text and falls back to whichever font is set as default in Format -> Character... or the font set for the previous line.


Expected behavior
Changing the font should be applied to any characters written afterwards.


Workaround
You need to type first, highlight the text and then change the font for it to work which is very annoying

I confirm the bug is still available with the current version (5.2.1)

libreoffice-fresh 5.4.1
Arch Linux
4+ Years
and the annoying bug is still there
See you next year ;)

The bug is still present

Version: 6.1.1.2
Build ID: 6.1.1-3
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: en-US (en_US.UTF-8); Calc: group threaded

The bug is still present

Version: 6.0.7.3
Build ID: 1:6.0.7-0ubuntu0.18.04.10
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: en-US (en_US.UTF-8); Calc: group

Kubuntu 18.04

Bug still manifests with:

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: 162f5a20095c6937030d23ee03fb8f72c51eefa1
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_IL); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-06_16:55:45


But actually - it's not specific to Arabic. It's the same with Hebrew, and I assume all RTL languages and suspect perhaps CTL languages too.

Also renaming title to better reflect the actual bug.

I should also stress that this is a high-visibility bug - so much so that many of us experienced users ignore it, since we simply encounter it every time we open LO Writer. For newbies, it is one of the immediate annoyances they come up against.

So, I suggest an increase of priority.

Asking for UX eval on this issue.

Now, let's make the reproduction instructions even more specific:

0. Let FF1 be the default font family for RTL scripts in the Default Paragraph Style in Writer, and WFF the default font family for Western languages.
1. Have two keyboard languages enabled, one of them RTL (e.g. English and Arabic) in your desktop environment.
2. Create a new empty document.
3. Change your desktop environment's active keyboard layout to the RTL layout (e.g. Arabic).
4. In the font family textbox on the toolbar, select the listed font family, and replace it by typing a font family name _other_ than FF1 (e.g. if FF1 is "Amiri", type "Noto Naskh Arabic" and vice-versa). Let FF2 be this font family.
5. In the document body, type in some text in the RTL language (e.g. Arabic)

Expected results: 

* After step (3.), the listed font family is FF1.
* After step (5.), the typed text appears in font family FF2, and FF2 is listed in the font family text box.

Actual results: 

* After step (3.), the listed font family is WFF.
* After step (5.), the typed text appears in font family FF1, and FF1 is listed in the font family text box.


Bug still manifests with a recent build:

Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 360b5861fb46353e7a6b9f5abf13339cd719a8df
CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US

and also with an RTL UI language.

The default font for new documents is defined via tools > options > languages and switching the language is direct formatting. The supposed workflow is to change the paragraph style. => NAB

However, I don't know how the different scripts (ctl, cjk, western) are applied here. The expectation could be that having CTL enabled means to apply the respective font on switching the language. Mike, any developer insights?

(In reply to Heiko Tietze from comment #18)
> The default font for new documents is defined via tools > options >
> languages and switching the language is direct formatting. The supposed
> workflow is to change the paragraph style. => NAB

Oh!

1. Even though we definitely need to make Writer comfortable to people who use styles, in no case we should make some basic tasks to *require* using styles, which is basically telling Benjamin to stop using the software.

2. This is basically in the same topic as that bug 104318, bug 146910, bug 146928, and others that make non-Western script users the second-class citizens.

There is some discussion (with Khaled expressing his opinion that the division to the three font categories is useless, also reflected here in comment 4, and which I support); there's bug 148257, and so on.

A UX solution to the problem of handling different fonts for different scripts in the same UI (style, but also direct formatting!) is needed.

(In reply to Heiko Tietze from comment #18)
> The default font for new documents is defined via tools > options >
> languages and switching the language is direct formatting.

This has nothing to do with the choice of the default font.

> The supposed workflow is to change the paragraph style. => NAB

1. Heiko, if you really believed that, then it should not have been possible to change the font family at all through the toolbar. But you don't believe that should be disabled. So actually, you're kind of gas-lighting here, and that is not nice of you. If we can change font family directly - then the appropriate language group font family should change, i.e. CTL once we've switched the keyboard language.

2. It's not even just about making the change it's also about the fact that the displayed family name is WFF rather than FF1.

(In reply to Heiko Tietze from comment #18)
Also, and outside the scope of this bug, Mike mentioned the discussions on other bugs where it is clarified that this:

> switching the language is direct formatting.

is an invalid claim. The choice of language for a stretch of text is not formatting (direct or otherwise).

(In reply to Eyal Rozenberg from comment #21)
> is an invalid claim. The choice of language for a stretch of text is not
> formatting (direct or otherwise).

It is a valid and correct claim. However, it should change.

(In reply to Mike Kaganski from comment #19)
> 2. This is basically in the same topic as that bug 104318, bug 146910, bug
> 146928, and others that make non-Western script users the second-class
> citizens.

While I agree that these are important issues, I'm not sure the bug we see here is even intentional. And that's because once you start typing RTL text, the font family selection combo-box _does_ switch to tracking the RTL/CTL font. So the developers who wrote this did want the combo-box to track the language family used where your cursor is right now.

> There is some discussion (with Khaled expressing his opinion that the
> division to the three font categories is useless, also reflected here in
> comment 4, and which I support); there's bug 148257, and so on.
>
> A UX solution to the problem of handling different fonts for different
> scripts in the same UI (style, but also direct formatting!) is needed.

Mike, Mike, wait... those are important discussions on fundamental issues, but this bug can be resolved perfectly well the way things stand now, without making changes to the document model or anything like that. All that's necessary is that when LO detects a keyboard layout change, for it to make the combo-box switch to the language group of the new keyboard layout.

(There is the question of what to do if you don't type a space between the Western text and intended CTL text, and then there's a clash between representing the character just before the cursor and the keyboard layout, but that's a finer point and is still not dependent on all of the deep discussions.)

> (In reply to Eyal Rozenberg from comment #21)
> > is an invalid claim. The choice of language for a stretch of text is not
> > formatting (direct or otherwise).
>
> It is a valid and correct claim. However, it should change.

Ok, let me rephrase - it is incorrect in principle, and in how a reasonable user thinks of language; but it is correct in the sense of being LO's current approach (sort of).

(In reply to Eyal Rozenberg from comment #23)
> Mike, Mike, wait...

:) Sorry.

> All
> that's necessary is that when LO detects a keyboard layout change, for it to
> make the combo-box switch to the language group of the new keyboard layout.

tdf#108151 makes *layout* change at least non-portable. However, I believe that it's possible to react on the entered character script uniformly; this, however, makes it only possible to switch on character entry, so space between words can't physically be part of the detection.

(In reply to Mike Kaganski from comment #24)
> tdf#108151 makes *layout* change at least non-portable.

Ok, but - that's a bug. We can make this bug depend on that bug - which I'll go ahead and do - and a fix for this bug will simply fail on Linux.

> However, I believe
> that it's possible to react on the entered character script uniformly; this,
> however, makes it only possible to switch on character entry, so space
> between words can't physically be part of the detection.

But we already do switch once a (non-neutral) character is entered. Perhaps I misunderstood your comment?

Had a long discussion with Hossein about this ticket (who thinks this is a plain bug) and related topics. As UX input was requested we have to consider the whole picture.

1. Of course we can change the three scripts concept and configure fonts per language, which would be an extendable list picked from all languages. For example English = Sans, Hebrew = AlefAlef, Arab = Madani.
Pro: It's possible to define one font for every language; the hidden controls could be visible but also hidden depending on a predefined subset
Con: Users might be familiar with the 3-script concept from Windows; configuring the hell out of the software is seldom desired

2. The most focal issue is that typing with a non-English character set should be recognized and have an effect on the text. It's expected that entering ABC makes this part English, АБГ becomes Russian, and ابت magically Arabic (ideally with the right country taken from locale). The appropriate font should be used, paragraph and character settings applied, and all tools including dictionaries just work properly. MSO works like this and changes the input language depending on the typed characters. 
Con: The language is part of the PS and the CS, as well as direct formatting. Switching magically makes it harder to understand the concept.
Pro: Convenience and usability; and we could keep the language if defined somehow
Remark: The task to detect the language is likely not trivial.

3. Back to 1: Providing defaults for so many styles is an overkill and makes it unclear what the supposed workflow is (templates overwrite tools > options). We could drop this concept and _allow_ to define _one_ font for the Default PS per locale setting.

(In reply to Heiko Tietze from comment #26)
> Had a long discussion with Hossein about this ticket (who thinks this is a
> plain bug) and related topics. As UX input was requested we have to consider
> the whole picture.

Unless it was a face-to-face/audio/video discussion, please try to have these on the LTR channel :-)

> 1. Of course we can change the three scripts concept etc. etc.

Mike, see what you did? You got Heiko to veer completely out of scope :-) 

Heiko, if we try to solve world peace and cold fusion first we'll certainly not resolve a bug which is independent of this effects. In fact, I won't even reply to the point you're making, here, to not derail the discussion.

> 2.

I will reply here _only_ in the context of fixing this bug, not beyond that.

> The most focal issue is that typing with a non-English character set
> should be recognized and have an effect on the text. It's expected that
> entering ABC makes this part English,

Not really, because many language have these three glyphs - most European languages in fact. (And when I say languages, I mean language-country combinations, if we're not treating those separately)

> АБГ becomes Russian,

Again, many languages (or language-country pairs):

https://en.wikipedia.org/wiki/Cyrillic_alphabets

> and ابت magically Arabic (ideally with the right country taken from locale).

Disagree with taking anything from the locale. Instead, we should take this information from the chosen keyboard layout. That's the mechanism which DEs offer us to handle input in multiple languages(/multiple language-countries). A keyboard layout corresponds to a language(+country), not just to an alphabet/script - and the user selects it knowingly and carefully. No magic.

> The appropriate
> font should be used, paragraph and character settings applied, and all tools
> including dictionaries just work properly. MSO works like this and changes
> the input language depending on the typed characters. 

Does it ignores the chose keyboard layout and only consider the character typed?

> Con: The language is part of the PS and the CS

It isn't. Or rather, in LO, it sort of is right now, but that's just a bug which needs to be fixed. That's not a con of tracking the keyboard layout. Let's fix that. Until it's fixed, let's ignore this fact for the purpose of having the font family combo-box track things. Actually, we're already ignoring it, since once you type a CTL character, the tracking changes.


>, as well as direct formatting. 

Once we make language not-formatting, this consideration automagically goes away.

> Switching magically makes it harder to understand the concept.

If you stick the keyboard layout, there is no magic - the user has consciously done this themselves. It is very easy to understand. (But things might get less intuitive when you set the language manually in LO, either after typing, as in 148257, or before typing, e.g. 

> Pro: Convenience and usability; and we could keep the language if defined
> somehow
> Remark: The task to detect the language is likely not trivial.

Again, it's been taken care of already. We just need to not throw away this information.


So, bottom line - this bug should, and can, just be fixed irrespective of deep philosophizing on language groups and whether language is in the style or not.

(In reply to Eyal Rozenberg from comment #27)
> So, bottom line - this bug should...

Fine for me if bugs get solved. Not UX business though ;-).

(In reply to Heiko Tietze from comment #28)
> (In reply to Eyal Rozenberg from comment #27)
> > So, bottom line - this bug should...
> 
> Fine for me if bugs get solved. Not UX business though ;-).

Well, it is a UI/UX bug... but let's not split hairs.

So, just to clarify - we're in agreement that the behavior should be rectified as requested by OP? And that the font family combo-box should track the keyboard layout? And that the priority here should be raised due to the (relatively) high visibility of this issue (i.e. you see it merely by creating a new document and switching keyboard layout)?

OK, let me explain what I think!

It is correct that the text language can be inferred from the keyboard layout. Then, LibreOffice should use this data, and also the information inside the font to set the font settings correctly.

It is true that user expects to see the correct font used for the RTL/CTL language, but what I am arguing is that even without any changes in UI, this bug can be, and should be fixed.

To do a comparison (and as an example behavior), please do the exact same set of actions inside MS Word. Open it, then set an Arabic font, type something in Arabic, and see that the text gets the correct fonts. If you look into the character properties, you will see that the font is set for RTL/CTL, and not Western language text. This is the behavior that I would expect in LibreOffice. The data is enough to make this happen, and a developer should be able to fix this problem even without any UI change.

Thus, this bug report is completely valid. It is also important, as it confuses the users why their font settings are not applied. I am raising the priority now.

(In reply to Eyal Rozenberg from comment #27)
> please try to have these on the LTR channel :-)

I meant to say the RTL channel of course. For those who don't know it: https://t.me/+GY3UwBnlDN9mY2M8

And thanks, Hossein, for the priority increase.

On Windows, WM_INPUTLANGCHANGE event is sent by system upon user changing keyboard layout / input language. This event is easy to use in updating the information displayed in the controls that show information related to the three sets of data (Western/CTL/CJK), including fonts (names, sizes, etc.). It could be initiated in ImplHandleInputLangChange [1], that handles the mentioned message.

Indeed, this is a Windows-only solution; fixing this should include a machinery ((a set of) virtual functions) allowing to define respective handling in all VCL plugins, if they support it.

Note that the narrow scope of this issue implies that it would still be only possible to define respective font for a given language group *after switching the input language*, e.g. setting the font and then switching the input language would still not set the font for the newly chosen group.

[1] https://opengrok.libreoffice.org/xref/core/vcl/win/window/salframe.cxx?r=34e017c4&mo=211062&fi=5867#ImplHandleInputLangChange

Hmm, I might still continue to propose things that already work (as in comment 24). This issue is about Linux, and I am a Windows developer and user, and also not a CTL/Asian script user. After enabling an Arab keyboard layout on my Windows system, I see that it at least *seems* to change things properly as I'd expect.

So unCC myself to not clutter it more.

(In reply to Mike Kaganski from comment #32)
> Note that the narrow scope of this issue implies that it would still be only
> possible to define respective font for a given language group *after
> switching the input language*, e.g. setting the font and then switching the
> input language would still not set the font for the newly chosen group.

This is fine. Let's fix things in the current UI approach to offer a consistent and reliable experience. Suggestions to revamp the UI in this direction or that will certainly be discussed on their own merits - elsewhere.