Bug 161205 - Font selection dialog doesn't persist choice of RTL-CTL + auto-chooses CJK
Summary: Font selection dialog doesn't persist choice of RTL-CTL + auto-chooses CJK
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.6.0.1 rc
Hardware: All All
: low normal
Assignee: Jonathan Clark
URL:
Whiteboard: target:26.2.0
Keywords:
: 156438 (view as bug list)
Depends on:
Blocks: CJK Language-Detection RTL-UI
  Show dependency treegraph
 
Reported: 2024-05-21 21:16 UTC by Eyal Rozenberg
Modified: 2025-10-14 20:46 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2024-05-21 21:16:23 UTC
I'm using LO with both RTL-CTL and CJK enabled. I'm working on an RTL document with RTL text and no CJK text. My keyboard layout is RTL. This should be enough, when I open the Format | Font... dialog for me to see the "Complex" sub-pane in front of the "Asian" sub-pane. Yet - I see "Asian" first.

Now, if it were the case that the Z-order of panes, or the selected pane, persists over subsequent openings of the dialog - I might get Asian once, then get Complex the next time, which would be not nearly as bad. But - that's not what happens; the choice is not persisted.

So, either way - the choice of sub-pane to pre-select/present in wrong.

Seen with:

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3
Locale: en-IL (en_IL); UI: en-US
Comment 1 Eyal Rozenberg 2024-05-21 21:18:12 UTC
This is relevant probably since we introduced the last significant rework of the font selection dialog. Also, I meant Format | Character... (not Format | Font...).
Comment 2 Heiko Tietze 2024-05-22 07:50:13 UTC
Would be nice, if the right tab is selected.
Comment 3 Eyal Rozenberg 2024-05-22 09:58:49 UTC
An app ignoring a user's repeated indication of preference is a bug, not just an enhancement. A design bug; another case of "the app wants to spite me"...
Comment 4 Jonathan Clark 2025-10-07 15:41:00 UTC
After fixing bug 168719, this will be much more important than low.
Comment 5 Commit Notification 2025-10-09 20:54:39 UTC
Jonathan Clark committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8a9527e17a625bf445974e0046db07a8c8fa186e

tdf#161205 Persist Complex/Asian tab choice in character dialog

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Eyal Rozenberg 2025-10-09 22:22:51 UTC
So, this is now an application configuration option... Is this how we do it with all persisted dialog tab selections, or is this a bespoke arrangement for the font dialog?
Comment 7 Heiko Tietze 2025-10-10 06:15:06 UTC
(In reply to Commit Notification from comment #5)
> Jonathan Clark committed a patch related to this issue.
This patch remembers whether CTL or CJK was active on the second tab. It could also go a step further and merge all three categories in one GtkNotebook - and remember what was selected. But as an intermediate solution not worth the effort.
Comment 8 Eyal Rozenberg 2025-10-10 16:46:59 UTC
(In reply to Heiko Tietze from comment #7)
> It
> could also go a step further and merge all three categories in one
> GtkNotebook - and remember what was selected. 

But that is not desirable... they're separated intentionally. The other alternative was a 3-way split of the window. We don't want only _one_ language group's font selection to be visible

> But as an intermediate solution not worth the effort.

It's not an intermediate solution...

I mean, ok, in the future, when we no longer have language group, then we'll need to rething this dialog as well, but that's far off.
Comment 9 Jonathan Clark 2025-10-14 20:46:37 UTC
*** Bug 156438 has been marked as a duplicate of this bug. ***