The Format > Chatacter... dialog, Font Effects tab, has a "Relief" rubrique, and next to it, the checkbox for Outline'ing the text. If you select any relief effect, i.e. Engraved or Embossed - the Outline option becomes disabled; and indeed, it seems it is not applied to the text. However - the Outline checkbox is _not_ unchecked, so it's disabled at the state it had before you selected the relief effect. This seems like a UI-only bug, and probably has no effect on the document rendering itself.
Build: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Calc: threaded
Hello, Thank you for reporting the bug. I was able to reproduce the same result in 24.8.2.1 and 24.2.7.2. Steps to Reproduce: 1) Open LibreOffice doc 2) Click on Format 3) Select Character... * In "Effects" notice the "Outline" and "Shadow" is selectable when effect pulldown selection is set to "(Without)" Only. I'm not sure if this is the expected behavior, but I will reach out to gather more details and provide an update here. Stable Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 8; OS: macOS 13.6.3; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Previous Stable Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: ee3885777aa7032db5a9b65deec9457448a91162 CPU threads: 8; OS: macOS 13.6.3; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Sincerely, Chika
Created attachment 197512 [details] 24.8.2.1
Not sure this would be a good idea. Unchecking would be an action the user did not ask for. Maybe they are experimenting with options. The user might see it as invasive, if options they just checked are being reset.
(In reply to Buovjaga from comment #4) > Not sure this would be a good idea. Unchecking would be an action the user > did not ask for. But it's what Writer does. If you engrave or emboss, the out line is removed. The UI must reflect that, we can't claim there's an outline when there isn't one.
(In reply to Eyal Rozenberg from comment #5) > (In reply to Buovjaga from comment #4) > > Not sure this would be a good idea. Unchecking would be an action the user > > did not ask for. > > But it's what Writer does. If you engrave or emboss, the out line is > removed. The UI must reflect that, we can't claim there's an outline when > there isn't one. No it's not, it's disabled. There is a reason why the disabled state exists. It is a semantic difference. You are proposing to upend this concept in the whole UI. Do you have research to back this proposal?
(In reply to Buovjaga from comment #6) > No it's not, it's disabled. There is no such thing as a "disabled outline". When rendering text, it either has an outline, or it doesn't; it can't have a "disabled outline". Outline is a feature of non-embossed and non-engraved text. At least - that's how things stand now w.r.t. LO behavior. If you believe it's important for the state of outline to be persisted for when the user switches back - I might not object to that, but you could still not show it as a checked boxed in the UI. You could hide the entire UI for Outline; or alternatively, display something other than a check box (perhaps there's a third, null state?) I would not oppose that I suppose. But not the current state of affairs.
(In reply to Eyal Rozenberg from comment #7) > (In reply to Buovjaga from comment #6) > > No it's not, it's disabled. > > There is no such thing as a "disabled outline". When rendering text, it > either has an outline, or it doesn't; it can't have a "disabled outline". > Outline is a feature of non-embossed and non-engraved text. At least - > that's how things stand now w.r.t. LO behavior. > > If you believe it's important for the state of outline to be persisted for > when the user switches back - I might not object to that, but you could > still not show it as a checked boxed in the UI. You could hide the entire UI > for Outline; or alternatively, display something other than a check box > (perhaps there's a third, null state?) I would not oppose that I suppose. > But not the current state of affairs. Sure, but there are such things as an option vs. a disabled option. What you are proposing will have an effect on potentially hundreds of locations in the UI. That's why this needs research and discussion.
Relief, shadow and outline are different properties. Setting a relief does not automatically changes the values of the other properties. So the display "Checked and disabled" is correct. It says that the style applied to the portion of characters contains a relief setting and property "Shadow" is set. So when a sub-portion of characters is selected and for the sub-portion relief is set to "(Without)" the shadow setting of its environment is still active. It is correct, that LibreOffice shows, that there exist a "Shadow is set" even if setting a relief disables shadow rendering. Because relief, shadow and outline are different properties, it would be even correct to keep outline and shadow setting active, when a relief is set. But would that be more user friendly? If you think of nested styles or a style inheritance chain, it becomes more clear way the shadow mark does not change: Example A: The paragraph style has a shadow set and a portion of characters was directly formatted with a relief. Example B: A character style has a shadow set and a derived character style sets a relief.
More generally speaking, we discuss whether a disabled control is to not change the setting or to indicate that is has no effect in the application. Both are valid solutions. Admittedly there might be less ambiguous implementations- but do we need to change it? I don't think so, and my take is as well NAB/INV here.
My take is that this is a WF. There's a difference between the properties set to the text and the way the text is rendered. If you force "Outline" to be unchecked, you would be changing the text properties applied by the user, which is not nice. Notice that if "Outline" is checked and the user applies a relief, the outline won't be rendered. But as soon as the relief option is removed, the "Outline" option is checked and it is applied. The current implementation feels correct to me.
(In reply to Rafael Lima from comment #11) > If you force "Outline" to be unchecked, you would be changing the text > properties applied by the user, which is not nice. But we _are_ changing the text properties applied by the user: The user wanted outlined characters, and we're un-outlining them. So, either we interpret the switch to Engraved/Embossed as an indication of an intent to remove the outline - in which case the "Outline" checkbox should be cleared as per the user's request; or we don't, in which case we should keep the outline while embossing or engraving (and I don't think we want that). > Notice that if "Outline" is checked and the user applies a relief, the > outline won't be rendered. But as soon as the relief option is removed, the > "Outline" option is checked and it is applied. I'm against keeping this latent state. To give a related example: Some typefaces have Italic variants, and some don't. If I switch from the Normal to the Italic variant of a typeface, then switch to a typeface which doesn't support Italic (getting its Normal variant), then switch back - should I get the Italic variant? I would say "no". I'm doubly opposed seeing how it is not inconceivable to have text be both outlined and embossed or engraved.
(In reply to Eyal Rozenberg from comment #0) > This seems like a UI-only bug, and probably has no effect on the document > rendering itself. To me it looks, the effect is the same if one sets e.g. Embossed if the characters are normal, or when the characters are in Outline. Then removing the Embossed property, however, does show the characters without _or_ with Outline. So I'm with others that this is a WF.
I really disagree, but beyond some point, vox populi - vox dei. So closing.