The style inspector sidebar is an feature targeted (AFAICT) at advanced users and developers, for fine-grained control and even for debugging purposes. Therefore, it is more important for it to display exact, comprehensive information, than to follow the user preference regarding whether or not CTL or CJK UI is enabled in LO. This recently confused Telesto in reporting bug 150406. I'm sorry I had not noticed bug 137806 earlier and did not chime in. Regardless - a reasonable user would expect CJK and CTL properties / style aspects to _not_ be hidden in the Style Inspector, ever. Please unhide them.
If CJK/CTL are not enabled in Tools > Options > Language it makes no sense to show these attributes, done with https://gerrit.libreoffice.org/c/core/+/97530. What exactly do you have in mind with "never be hidden"?
(In reply to Heiko Tietze from comment #1) See also: bug 148257. See also: bug 104318 (and specifically, bug 104318 comment 19). The current idea behind hiding CJK/CTL UI is itself questionable; the current (industry-standard) way of dividing fonts to the three groups is also questionable and making some problems like impossibility to define which of the three fonts would be used for characters like commas; and the idea of hiding information about some formatting just because used decided to not show *controls* for that formatting is separately questionable.
Note that irrespective of hiding CTL/CJK UI, the UI *does* honor the hidden properties (e.g., uses respective fonts for respective text runs); and - most relevant to this issue - *shows* the propertied in its *most prominent* parts of UI - the main toolbar's font control would show you the CTL font used for the characters, that comes from that *hidden* CTL settings. So it is inconsistent to *show* the value in one part of the UI, but hide from another (Style Inspector), which, as noted, has an additional property of being targeted at *advanced* users.
(In reply to Heiko Tietze from comment #1) > If CJK/CTL are not enabled in Tools > Options > Language it makes no sense > to show these attributes ... What exactly do you have in > mind with "never be hidden"? The Style Inspector needs to inspect what's in the document - not what the user likes to write/use themselves. When I disable CTL for example - that means that I don't want to play with the direction of my paragraphs, I don't want to set fonts for Hebrew/Arabic and so on. But if I get a document with Hebrew and Arabic and RTL - it is what it is, it has what it has: And the Style Inspector should show these properties, just like Writer doesn't hide Farsi or Hebrew text in the document from me just because I disabled CTL in Tools > Options. So, it makes sense to _always_ show them in Style Inspector, regardless of the settings on Tools > Options > Language. It makes _no_ sense to hide these attributes in the Style Inspector, ever. If someone wants to temporarily focus on less properties in the Inspector, one could think of mechanisms like regexp filtering it, for example - but not this. Also - and this might shock some people - I agree with Mike's comment :-)
I struggle with the "always". If neither the option is set not the document contains CJK/CTL content it should be hidden. But admittedly the document content needs to be taken into consideration.
(In reply to Heiko Tietze from comment #5) > I struggle with the "always". If neither the option is set not the document > contains CJK/CTL content it should be hidden. Absolutely not. Should be visible. If personally you're not interested in it, then ignore it, but most users of the Style Inspector would want, and likely need, it to be visible.
(In reply to Mike Kaganski from comment #2) > The current idea behind hiding CJK/CTL UI is itself questionable; the > current (industry-standard) way of dividing fonts to the three groups is > also questionable and making some problems like impossibility to define > which of the three fonts would be used for characters like commas; I will say though that these points that you're making, Mike, while important in themselves, are not what this bug is about, i.e. I am not questioning CJK/CTL UI hiding nor the division into language-groups _here_. Just saying that the hiding should not apply to the Style Inspector.
(In reply to Heiko Tietze from comment #5) I would not take responsibility claiming that "most" users would or would not want to see that; but - this idea is wrong: you would then expand that to "if the document has no widowed/orphaned lines, we should not show widow/orphan settings in paragraph styles", and so on. (In reply to Eyal Rozenberg from comment #7) > I will say though that these points that you're making, Mike, while > important in themselves, are not what this bug is about These points are (1) to bring the whole picture for those who are not intimately familiar with the topic (like Western script users like myself), and (2) mentioned that this specific issue is *separately* questionable.
(In reply to Heiko Tietze from comment #5) Consider further the impact of the proposal made in this bug, on the documents mentioned in your comments: *if* the documents were authored by those who only use Western scripts, these documents will *only* contain CTL/CJK-specific entries in the Style Inspector under very limited set of places (specifically - most likely, only in the Default paragraph style). Everything else would not have overrides of the said properties, and hence would not list them - so the end result would be not giving any sizable downside.
As with all topics around the UI, hiding permanently irrelevant content but showing/disabling temporary unavailable is good usability. Western users do not know what CJK/CTL means and don't care. Unless they receive a document with this content. There is no benefit if we *always* show those attributes.
(In reply to Heiko Tietze from comment #10) > As with all topics around the UI Please think about Style Inspector again. It is *not* a "UI", it is an information tool. In it, the UI is its "plus" expansion buttons, its columns, etc. But the information in it is not a "UI" that you are talking about. It is the contents of the document, viewed from a different perspective. Besides that, the *user-side* benefits are: 1. Education about the true details of the document model, given to those who are interested in the details by definition (opening the tool indicates that). 2. Minimal surprise in cases like the mentioned bug 150406. 3. Performance of the tool (see below). From developer's perspective, the benefits are: 1. Ease of implementation (having a complex check of the document contents to figure if the document does or does not contain relevant features); 2. Less probability of implementation errors (do we consider unused styles as document contents that warrant showing the CTL/CJK items?); 3. No need to parse the *whole* document to decide that, when you only have a small context (the cursor position). So - the claim that there is "no benefit" is plain wrong - the benefits are obvious (from both sides), and they only need to be compared (and IMO, the benefits of always showing are much greater from both perspectives - users' and developers'). Additionally: the current implementation was created *defensively*, in the process of the tool creation itself - without really taking target audience users' needs into account: we created that hiding functionality without allowing users to see what they miss, and decide if that made life better or worse for them.
(In reply to Mike Kaganski from comment #8) > These points are (1) to bring the whole picture for those who are not > intimately familiar with the topic (like Western script users like myself), > and (2) mentioned that this specific issue is *separately* questionable. Fair enough. (In reply to Heiko Tietze from comment #5) > I struggle with the "always". Think about the Developer Tools in browsers. They never filter things out because you've opted for less UI items. (In reply to Mike Kaganski from comment #11) > Please think about Style Inspector again. It is *not* a "UI", it is an > information tool. Exactly this. When enabled/disables CJK or CTL in Tools > Options, they would assume the UI would not cater to use of such langauges; but - they would not assume that "reality will be hidden from them", so to speak. Thus * When voluntarily opening a document with CJK/CTL content, they would expect to see this content, not to have it hidden. * When using a inspection tool, they expect to inspect the actual state of the document, not to have it censored. That's why Telesto - a capable and knowledgeable user, who was specifically looking for the font settings in the Inspector, thought they were missing (in bug 150406), and it did not occur to him that LO might be hiding this information. > Additionally: the current implementation was created *defensively*, in the > process of the tool creation itself - without really taking target audience > users' needs into account Yup. Now, it's true in general than the project doesn't do a lot of user surveying (if any), so that's not specific to the Style Inspector, but nobody asked the RTL, Hebrew or Arabic Telegram group members for input about this. (In reply to Heiko Tietze from comment #10) > Western users do not know what CJK/CTL means and don't care. Western uses-of-style-inspector, who want to inspect the styles of documents with CJK/CTL content _do_ care and likely do know. And if the document don't have CJK/CTL-specific properties, then it doesn't matter anyway. Now, if you were to keep CJK/CTL-specific properties _collapsed by default_ in a subtree, then - ok, I guess that could make sense, maybe. But not hiding them.
(In reply to Mike Kaganski from comment #11) > 1. Education about the true details of the document model, given to those > who are interested in the details by definition (opening the tool indicates > that). > 2. Minimal surprise in cases like the mentioned bug 150406. > 3. Performance of the tool (see below). Wouldn't call this benefits. Big plus is that having CTL/CJK in the default style means to have it hidden in the derived items, if not changed. > From developer's perspective, the benefits are... Very good arguments.
Hiding was implemented in https://gerrit.libreoffice.org/c/core/+/97530. This is the code pointer for this easy hack.
Liu Hao committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f65ca3470ea2ede39314668348607dd061d003fe tdf#150409 CJK&CTL properties shouldn't be hidden in Style Inspector It will be available in 7.5.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.
Liu Hao, this bug is marked as New. If you solved this bug please assign this bug to you than mark it as Resolved - Fixed.