Description: Make Asian and complex text layout being enabled depend on locale be default Steps to Reproduce: 1. open Writer 2. Tools -> Options-> Language settings -> Default languages for document 3. Notice Asian and complex text layout checked Actual Results: Checked by default Expected Results: Well.. agreeing with microcode [https://www.phoronix.com/forums/forum/software/general-linux-open-source/1236159-libreoffice-7-1-community-edition-released] [Related to the link : Not a good read for LibO enthusiasts who are easily offended]. So not some kind of defense: Oppositional defiant mode The comment as some merits. Not seeing the point storing that (and not nice for the file structure). I would tend to flip it other side. People who need this, should enable it. Instead of enabled to be never used. Or restrict to country's where this being actual relevant. Western world unlikely to use Asian as general rule. The opposite does clear happen. Asking this without 'actual' background knowledge why this being done. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 3ed9bba283a6a67864c0928186e277240be0d9ba CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Sorry, since you are on a master build, you are likely doing a /A administrative install to Windows. Believe a full MSI installer does honor the locale. Setting CJK or CTL only as appropriate. What happens for you with a full (including write to Windows registry) with 7.0.4 or now 7.1.0 release? Suspect not the case. Also, don't see how the TL;DR rabbit hole of the phornix.com forum was applicable to this suggestion. Yes, enabling CTL and CJK (from Tools -> Options -> Language Settings -> Languages) will inject additional XML content of the default templates.
(In reply to V Stuart Foote from comment #1) > Sorry, since you are on a master build, you are likely doing a /A > administrative install to Windows. Nope. Mostly doing an actual install. If this advisable something else.. Also seen in safe-mode (master) Also with Version: 7.1.0.3 (x86) / LibreOffice Community (Portable) Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (nl_NL); UI: en-US Calc: CL Fine with Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Created attachment 169562 [details] Flat ODT text from a custom (en-US & English only) install of 7.1.0.3 attached is a Flat ODF of a document with a single DT paragraph. Done from a completely clean full install of LO 7.1.0, custom setting en-US only UI, and with just English dictionary. No CTL or CJK styling results, just style:font-name-asian and style:font-name-complex which I done think can be considered as non-western styling. The Tools -> Options -> Language Settings -> Languages do not select entries for CJK or CTL locales--their check boxes are un checked.
Isn't the question what happens on a CTL/CJK default OS?
(In reply to Heiko Tietze from comment #4) > Isn't the question what happens on a CTL/CJK default OS? in which contexts? Using an OS using CTL/CJK?. Or what happens if CTL/CJK disabled on a CTL/CJK
(In reply to V Stuart Foote from comment #3) > Believe a full MSI installer does honor the locale. Setting CJK or CTL only > as appropriate. This obviously hell to check if it's functioning properly (or not). Not to mention the fact it's impossible to bibisect.. Also not working for portable (like also appimage and such) FWIW: before I forget myself, it's not only about settings.xml. But also all the fall-back cruft (I think I saw different font stuff inserted (Style Inspector) for special symbols etc?)
Created attachment 169580 [details] Bibisect log Checkboxes introduced with ddc06f05a5b00473a312eb1723ed41c1c1ce41c is the first bad commit commit 0ddc06f05a5b00473a312eb1723ed41c1c1ce41c Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 18:00:11 2015 +0800 source-hash-fa3d5ca1f99fe253689004a45ec2888ebbe85fd3 commit fa3d5ca1f99fe253689004a45ec2888ebbe85fd3 Author: abdulmajeed ahmed <aalabdulrazzaq@kacst.edu.sa> AuthorDate: Thu May 30 12:33:32 2013 +0200 Commit: abdulmajeed ahmed <aalabdulrazzaq@kacst.edu.sa> CommitDate: Thu May 30 12:42:45 2013 +0200 Convert Languages tab page to .ui Deleted the readonly images too,it was not used any where else and was just confusing. Change-Id: Ibdcda961966ceab28b224335bfa2e154a395e788 :040000 040000 902cd6ebb474f97657611cfefafeb2cfd13f46f6 a5190b3d5ae5eb2a84c384793ea6598abcb21a84 M opt https://cgit.freedesktop.org/libreoffice/core/commit/?id=fa3d5ca1f99fe253689004a45ec2888ebbe85fd3
Created attachment 169581 [details] Bibisect log The bibisect repro got a user profile with.. and start storing checked (checkbox was always unchecked prior to this) bibisect-42max$ git bisect good 8a8b50772859fd6198e8e139ca853a4b7aca9133 is the first bad commit commit 8a8b50772859fd6198e8e139ca853a4b7aca9133 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 22:42:31 2015 +0800 source-hash-b8002169336b6b7597d32755e41fa3dc2688539e commit b8002169336b6b7597d32755e41fa3dc2688539e Author: Michael Stahl <mstahl@redhat.com> AuthorDate: Wed Nov 6 16:36:04 2013 +0100 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Thu Nov 7 14:27:50 2013 -0600 remove INPATH and PROEXT - WORKDIR path is just workdir - INSTDIR path is just instdir - WORKDIR_FOR_BUILD is workdir_for_build - INSTDIR_FOR_BUILD is instdir_for_build - replace other usage of INPATH by combination of OS and CPUNAME Change-Id: Ie398387ebd82a968ec2605f2103c55b43a231482 Reviewed-on: https://gerrit.libreoffice.org/6601 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Michael Stahl <mstahl@redhat.com> :040000 040000 a91ef1b12bc792fec917c940ca99c8d787acf392 6f5b46268bc835a1be168eece494e4abfdb543c5 M opt https://cgit.freedesktop.org/libreoffice/core/commit/?id=b8002169336b6b7597d32755e41fa3dc2688539e
@Caolan Is there anything obviously wrong with the commit mentioned in comment 7. It apparently always enabling Asian/CTL support nowdays. Previously it didn't (Linux bibisect repro 42max) However there is kind of bibisect issue. The 'checked' started to appear after user profile creation started functioning (again) (comment 8). So 3 months of unknowns (and/or lacking advanced bibisect skills to workaround to profile issue)
If anything I would say https://cgit.freedesktop.org/libreoffice/core/commit/?id=23b92427e3c77fa8d04679ddcaf2dbd3e3580c5d (please read commit message). But that's just for CTL, and unlikely to have any effect outside Windows.
(In reply to Maxim Monastirsky from comment #10) > and unlikely to have any effect outside Windows. Correction: I does affect other OSes (I somehow overlooked the m_bCTLFontEnabled change). It's the installed keyboards check which was Windows specific.
Hmm... but looking closely it appears that the schema has a fallback "false" value for Office.Common/I18N/CTL/CTLFont, which should reset m_bCTLFontEnabled anyway. So how did the mentioned commit achieved anything at all? I'm confused.
Don't see what UX can contribute here.
(In reply to Heiko Tietze from comment #13) > Don't see what UX can contribute here. Maybe me interpreting UX differently: user experience design.. Which for me includes what needs to be 'default'. But yes, this has a technical aspect in it.
@Mike I'm realizing, this bug maybe the reason for the effects at bug 139359 comment 5 [aside from the question what should happen if Asian and complex text layout being checked] So if there something more..
I can't repro the problem as reported: that with a clean profile, the two checkboxes in Options->Language Settings->Languages (namely, [] Asian and []Complex text layout under "Default Languages for Documents") are said to be checked. I cannot reproduce that with Version: 7.1.1.1 (x64) / LibreOffice Community Build ID: 575c5867c4cc13d7ae78f9ce39a54a52ed38c769 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL I just now have reset my profile, and the said checkboxes are unchecked. I personally disagree at all with this actual behavior (I think that this is exclusive software behavior, not inclusive; if some person wants to use Asian and/or CTL being in a Western locale, they have to explicitly enable the tools, as if they and their scripts are second-class users). However, as said, in the current version (as well as in all previous that I tested), I always had to *enable* the checkboxes to be able to test related functionality. If this is different for OP, then there likely is some "problem" related to specific set of options/environment. Maybe multiple MUIs or keyboard layouts are present on system, which trigger this behavior.