On Windows, we automatically enable CJK language support after the user installs a CJK IME or keyboard layout. However, this doesn't work for RTL/CTL languages. Based on bug comments, I'm pretty sure we used to do this for RTL/CTL as well. However, I think this feature may have been disabled by the following commit: commit 23b92427e3c77fa8d04679ddcaf2dbd3e3580c5d Date: Thu Dec 22 23:12:14 2016 +0200 Enable “complex text layout” by default Hopefully fixing this problem is as easy as reverting this commit, but more investigation is needed.
Well, is it enabled by default on Linux? MacOS? That is to say, is this an issue with the Windows code or the platform-inspecific code?
(In reply to Eyal Rozenberg from comment #1) > Well, is it enabled by default on Linux? MacOS? That is to say, is this an > issue with the Windows code or the platform-inspecific code? This was never implemented outside of Windows, so it is a Windows-specific regression. This bug does not supersede the other bugs filed to expand language detection, but would at least fix the problem for a significant number of users by reverting to previously-working code.
Expanding scope because this bug affects all platforms. In addition to the Windows-specific issue, the referenced commit removed the trivial heuristic of enabling RTL/CTL support based on locale. Candidate revert is here: https://gerrit.libreoffice.org/c/core/+/191835 . For process reasons, I'll wait to commit it until this bug is confirmed.
Khaled claims, in the commit comment, that what this does is the opposite - i.e. that it _enabled_ CTL support by default. Would revert it really have the effect you expect? 8-| Anyway, let's see if Khaled can comment on this.
The commit message says what I thought it does and IIRC I verified at that time that it enabled CTL support by default for new profiles. But apparently, this is not what happens now since CTL is not enabled for new users, so either I was mistaken or something changed since then. I have no objection to reverting the commit if it actually made things worse.
(In reply to Khaled Hosny from comment #5) > so either I was mistaken or something changed since then. Itt may make sense to re-test the behavior with the code at the time of the commit; and assuming that checks out, i.e. behaves like you (Khaled) intended, a bibisect would reveral what broke this, which may be another relevant piece of code to take into account rather than doing a simple reversion.
(In reply to Eyal Rozenberg from comment #6) > Itt may make sense to re-test the behavior with the code at the time of the > commit I already did this as part of my investigation. The original patch never worked; it tried to set a default config value through code, but config defaults are defined in data. It's unfortunate, but these things happen. > rather than doing a simple reversion. The original code doesn't compile anymore, so I wouldn't call it simple. Hopefully it goes without saying that I'm not trying to throw this change over the fence.
(In reply to Jonathan Clark from comment #7) Ok, I trust your judgement on this, so marking as NEW. I noticed this: https://gerrit.libreoffice.org/c/core/+/191835 would you say it also regards bug 161255?
Thanks (In reply to Eyal Rozenberg from comment #8) > would you say it also regards bug 161255? In a sense, yes. I think what this does is put LO back in the state expected by the other devs commenting on that bug. The rest of the discussion there is still pertinent after this change. We should leave bug 161255 open, since we can still make improvements (especially on non-Windows computers). I also recently filed bug 168719 to track Mike Kaganski's suggestion to remove these options entirely.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/734499c11bcb0ed6a4a3eb2f8543dbcbcf29a11b tdf#168540 Restore automatically enabling RTL/CTL based on locale 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.