[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-14 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #34 from Eyal Rozenberg  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-14 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

Mike Kaganski  changed:

   What|Removed |Added

 CC|mikekagan...@hotmail.com|

--- Comment #33 from Mike Kaganski  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-14 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #32 from Mike Kaganski  ---
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=211062=5867#ImplHandleInputLangChange

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-14 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #31 from Eyal Rozenberg  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-13 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

Hossein  changed:

   What|Removed |Added

   Priority|medium  |high
 Whiteboard|BSA |

--- Comment #30 from Hossein  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-13 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #29 from Eyal Rozenberg  ---
(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)?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-13 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

Heiko Tietze  changed:

   What|Removed |Added

   Keywords|needsUXEval |
 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda
   |.freedesktop.org|tion.org

--- Comment #28 from Heiko Tietze  ---
(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 ;-).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-13 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #27 from Eyal Rozenberg  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-13 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #26 from Heiko Tietze  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

Eyal Rozenberg  changed:

   What|Removed |Added

 Depends on||108151

--- Comment #25 from Eyal Rozenberg  ---
(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?


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=108151
[Bug 108151] System input language is always ignored on Linux
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #24 from Mike Kaganski  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #23 from Eyal Rozenberg  ---
(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).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #22 from Mike Kaganski  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #21 from Eyal Rozenberg  ---
(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).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #20 from Eyal Rozenberg  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

--- Comment #19 from Mike Kaganski  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-12 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

Heiko Tietze  changed:

   What|Removed |Added

 CC|heiko.tietze@documentfounda |mikekagan...@hotmail.com
   |tion.org|

--- Comment #18 from Heiko Tietze  ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-10 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

Eyal Rozenberg  changed:

   What|Removed |Added

 Blocks||113438


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=113438
[Bug 113438] [META] Font name combobox bugs and enhancements
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Libreoffice-bugs] [Bug 62063] FORMATTING: Font textbox ignores keyboard layout change to RTL language

2022-12-10 Thread bugzilla-daemon
https://bugs.documentfoundation.org/show_bug.cgi?id=62063

Eyal Rozenberg  changed:

   What|Removed |Added

 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org
Summary|FORMATTING: After changing  |FORMATTING: Font textbox
   |to non-Western keyboard |ignores keyboard layout
   |layout, font textbox still  |change to RTL language
   |tracks Western font |
   Keywords||needsUXEval
 Blocks|43808   |129661

--- Comment #17 from Eyal Rozenberg  ---
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.


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=43808
[Bug 43808] [META] Right-To-Left and Complex Text Layout language issues
(RTL/CTL)
https://bugs.documentfoundation.org/show_bug.cgi?id=129661
[Bug 129661] [META] Right-To-Left (RTL) user interface issues
-- 
You are receiving this mail because:
You are the assignee for the bug.