First, thanks for the style inspector feature! It looks like a very useful tool for advanced users. Description: Most LibreOffice styles offer three separate font choices, for western text, Asian text (Chinese, Japanese, and Korean), and complex layout text. It seems that the new style inspector, introduced in 7.1, only supports western text and complext layout text, but ignores Asian text. Steps to produce: 1. Make sure "Asian" checkbox is selected in Tools > Options > Language Settings > Languages > Default Languages for Documents; 2. Open style inspector sidebar for a new blank document in Writer, expand the "Default Paragraph Style" tree; 3. Observe that properties like "Char Font Char Set" and "Char Font Name" are displayed for the western text, "Char Font Char Set Complex" and "Char Font Name Complex" etc. are displayed for complex layout text, but nothing for Asian text. My LO version is 7.1.0 alpha1: Version: 7.1.0.0.alpha1 (x64) Build ID: 987671387712c4f9061d6216ff2f001a7bb9e57b CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded P.S.: It may be also worth discussion to not show / gray out Asian text and complex layout text related properties when they are disabled. I can file a new bug for this if necessary.
CJK and CTL are hidden, see https://gerrit.libreoffice.org/c/core/+/97530 meanwhile move to InspectorTextPanel.cxx GetPropertyValues(). To my understanding CJK/CTL should be hidden unless enabled in Tools > Options. No need for UX input.
Created attachment 166901 [details] Screenshot with 7.1.0 alpha1 on Windows 10 (In reply to Heiko Tietze from comment #1) > CJK and CTL are hidden, see https://gerrit.libreoffice.org/c/core/+/97530 > meanwhile move to InspectorTextPanel.cxx GetPropertyValues(). > > To my understanding CJK/CTL should be hidden unless enabled in Tools > > Options. Well at least it doesn't match what I experienced, see attached screenshot. CJK is enabled in Tools > Options > Language Settings > Languages, CTL is disabled. Style Inspector shows "... Complex" properties, not "... Asian" ones.
Fun... When I enable both CJK and CTL text in Tools > Options, I see *neither* "... Asian" *or* "... Complex" properties. And when I disable both CJK and CTL, I can see those properties in style inspectors. The code that control whether to hide them seems to have the logic reversed, at least on Windows.
(In reply to Ming Hua from comment #3) > Fun... > > When I enable both CJK and CTL text in Tools > Options, I see *neither* "... > Asian" *or* "... Complex" properties. And when I disable both CJK and CTL, > I can see those properties in style inspectors. > > The code that control whether to hide them seems to have the logic reversed, > at least on Windows. I confirm this bug The issue is in // Hide Asian and Complex properties if (SvtLanguageOptions().IsCJKFontEnabled() && rPropName.indexOf("Asian") != -1) return false; if (SvtLanguageOptions().IsCTLFontEnabled() && rPropName.indexOf("Complex") != -1) return false; defined in /sidebar/inspector/InspectorTextPanel.cxx?r=4fbd6386#65. The code means "if CJKFont is enabled and rPropName is related to Asian return false", this should rather be // Hide Asian and Complex properties if (rPropName.indexOf("Asian") != -1 && !SvtLanguageOptions().IsCJKFontEnabled()) return false; if (rPropName.indexOf("Complex") != -1 && SvtLanguageOptions().IsCTLFontEnabled()) return false; "if CJKFont is *not* enabled and rPropName is related to Asian return false" I cannot see how we missed this issue. @Heiko Should I work on this? Version: 7.1.0.0.alpha0+ Build ID: d15aa807be1c595dad9abc1dea04bb922570015a CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded
(In reply to Shivam Kumar Singh from comment #4) > The code means "if CJKFont is enabled and rPropName is related to Asian > return false", this should rather be // Hide Asian and Complex properties if (rPropName.indexOf("Asian") != -1 && !SvtLanguageOptions().IsCJKFontEnabled()) return false; if (rPropName.indexOf("Complex") != -1 && !SvtLanguageOptions().IsCTLFontEnabled()) return false; I missed the *not* operator ;-)
(In reply to Shivam Kumar Singh from comment #4) > Should I work on this? just for information from Tomoyuki Kubota I've written the exactl patch (even before assigning to myself), https://gerrit.libreoffice.org/c/core/+/105054 but a unit test failed considering that the time I can spare is limited, I don't mind your assigning to yourself and start writing code:) In that case, I will just abandon my code.
(In reply to Shivam Kumar Singh from comment #4) > I cannot see how we missed this issue. @Heiko Should I work on this? FWIW, himajin100000 came to the same conclusion and has already submitted a patch: https://gerrit.libreoffice.org/c/core/+/105054 It's stuck at a failed UI test right now. I'm not a programmer and can't help much, so just passing this information along, so that you guys can work together and avoid duplicate work.
Tomoyuki Kubota committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/73e0b664881d95510be9605b98a2671926f4697a tdf#137886 condition for asian and ctl property seems wrong It will be available in 7.1.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.
It works for me now in: Version: 7.1.0.0.alpha1+ (x64) Build ID: 693553210828538680408832157faad9654758c8 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded Thank you himajin100000 for the fix! BTW do you plan to work more on this bug or did you just forget to close it?
> BTW do you plan to work more on this bug or did you just forget to close it? um, after my initial patch, Xisco Fauli fixed the unit test issue. It was helpful. but acutually, I'm not yet sure about what is included in the 118 properties, and 136 properties, and that unsureness in just being a small hurdle for me to close this bug myself.
typo: and that unsureness is just being
(In reply to Ming Hua from comment #9) > It works for me now in: Works for me too with: Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: fddad2ed797f1773ed5be979a0b05d3f976b744e CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded
Dear Ming Hua, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
(In reply to himajin100000 from comment #10) > but acutually, I'm not yet sure about what is included in the 118 > properties, and 136 properties, and that unsureness in just being a small > hurdle for me to close this bug myself. Nine months has passed and no complaints so far. Let's mark this as FIXED.
(In reply to Heiko Tietze from comment #1) > To my understanding CJK/CTL should be hidden unless enabled in Tools > > Options. > > No need for UX input. We (= RTL QA group) should have been consulted about this IMHO. At the very least this should have been made to block, or be related to, RTL-CTL.
> Eyal Rozenberg <mailto:eyalroz1@gmx.com> changed bug 137886 > <https://bugs.documentfoundation.org/show_bug.cgi?id=137886> > What Removed Added > Summary The logic of hiding CJK/CTL properties in style inspector seems > reversed CJK properties in style inspector are hidden while CTL > properties aren't Why did you change this? The specific problem was the reversed condition, that was implemented earlier [1] ; this bug was about that. Your comment 15 targets Heiko's words that were exclusively in frame of this bug, and as such, were completely correct. Above all, I even gave you the complete picture in the bug 150406 comment 6, and it was clear there *where* had the proposal appeared (not in any bug, but in a discussion of a gerrit change during implementation of the feature). You should create a new bug for this issue that you raise. [1] https://gerrit.libreoffice.org/c/core/+/97530