PRECONDITION: open any document, enter text: AVAVAVAV mark a part of the text: [AVAV]AVAV Format > Character > Highlighting: set Color to any color the kerning at the boundary is not correct (not beautiful but OK) PROBLEM DESCRIPTION: clear the color: Format > Character > Highlighting: set Color None the kerning at the boundary is still not correct (NOK) looking into content.xml you can find fo:background-color="transparent" in the automatic-styles the "transparent" can not be cleared except with Format > Clear Direct Formatting similar problem for Character Style settings EXPECTED BEHAVIOR: Format > Character > Highlighting: set Color None shall remove the fo:background-color, not set to "transparent" Version: 25.8.1.1 (X86_64) Build ID: 54047653041915e595ad4e45cccea684809c77b5 CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
I'm told this being by design.. not the kerning at the boundary part, but the fact that fo:background-color still being set when setting it to None
Created attachment 203167 [details] Screenshot (In reply to Michael Otto from comment #0) > the kerning at the boundary is still not correct (NOK) You mean the cut-off edges (here Liberation Serif)? This would be drawn correctly if kerning is off. Version: 25.8.1.1 (X86_64) / LibreOffice Community Build ID: 580(Build:1) CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 25.8.1-3 Calc: threaded Default PS, Default CS, Liberation Serif
(In reply to Heiko Tietze from comment #2) > Created attachment 203167 [details] > Screenshot > > (In reply to Michael Otto from comment #0) > > the kerning at the boundary is still not correct (NOK) > You mean the cut-off edges (here Liberation Serif)? This would be drawn > correctly if kerning is off. Right, it's about the cut-off edges as marked in your screenshot. And of course, if there is no kerning, there is no cut-off edge. But this is not what I intended with my bugreport. If we want to correct that, we should change the title to "VIEWING: bad kerning at background boundary". Or we add such a bugreport, and this bugreport well be obsolete if that bugreport is solved. My bugreport wanted to address: If a background is set and then removed again, the background is set to "transparent" instead of removing the fo:background-color item (and the VIEWING problem appears also with fo:background-color="transparent"). Setting the background to None shall restore the previous state: no fo:background-color item any more.
(In reply to Michael Otto from comment #3) > My bugreport wanted to address: > If a background is set and then removed again, the background is > set to "transparent" instead of removing the fo:background-color item > (and the VIEWING problem appears also with > fo:background-color="transparent"). > Setting the background to None shall restore the previous state: > no fo:background-color item any more. This specific point is NOTABUG. "Explicitly no background" is not the same as "background is not set here". E.g., when your (parent) style has background, and you want to make the specific paragraph with that style to have no background, it is not enough to make sure that there's "no fo:background-color item" - that would mean "we don't define any override; use the inherited setting". And it holds even when there was no inherited background. The program has no (and should not have) mind-reading abilities; my "explicitly set no background" could mean e.g. "I intend to set up styles later; so no matter what I will set to the style later, I explicitly want this paragraph to have no background". This is what Telesto meant by "I'm told this being by design". Yes it is. If your current bug is explicitly and exclusively about this, it must be closed.
(In reply to Michael Otto from comment #3) > Right, it's about the cut-off edges as marked in your screenshot. This is what kerning means. Learn more at https://en.wikipedia.org/wiki/Kerning for example.
(In reply to Mike Kaganski from comment #4) > > This specific point is NOTABUG. "Explicitly no background" is not the same > as "background is not set here". E.g., when your (parent) style has > background, and you want to make the specific paragraph with that style to > have no background, it is not enough to make sure that there's "no > fo:background-color item" - that would mean "we don't define any override; > use the inherited setting". ... > This is what Telesto meant by "I'm told this being by design". Yes it is. I agree, the design is to set "Explicitly no background" with None. > If your current bug is explicitly and exclusively about this, it must be > closed. The initial None is "use the inherited setting" and is different to the set-and-cleared-again None: "Explicitly no background", and you can't see the difference at the UI. I'm missing the possibility to set "background is not set here" in the UI. Actually only clear all formatting with Format > Clear Direct Formatting helps, but this is a secret feature, only found out by experienced users. Do we need an additional UI element for that? Wouldn't it be better to have a check option "Transparent" or "No Highlighting" on the Highlighting > Color tab and let the None always be the initial state?
(In reply to Michael Otto from comment #6) > Do we need an additional UI element for that? Wouldn't it be better > to have a check option "Transparent" or "No Highlighting" on the > Highlighting > Color tab and let the None always be the initial state? Note that the same applies to everything, not only background / highlighting. What UI would you suggest for the same issue in Bold / Italic / Underline etc.?
And most importantly: Direct formatting is intended for less experienced users; and this category needs most of all, that the final look and feel of the document matches the expectations. The fo:background-color item is the least of their concerns. The issue discussed here discusses a niche problem, that will not happen with the *primary* audience of the feature; and the advanced users, who can really find it, are definitely capable of finding the "secret feature", which is provided in context menu, main menu, Home tab of tabbed interface, explained in help and user guides, etc.
(In reply to Mike Kaganski from comment #7) > > Note that the same applies to everything, not only background / > highlighting. What UI would you suggest for the same issue in Bold / Italic > / Underline etc.? You are right, that's what Format > Clear Direct Formatting is good for. And less experienced users will find their way anyway. Thanks for your clarification. So the RESOLVED - NOTABUG that Heiko set is right, even due to a differrent reason.
(In reply to Mike Kaganski from comment #7) > (In reply to Michael Otto from comment #6) > > Do we need an additional UI element for that? Wouldn't it be better > > to have a check option "Transparent" or "No Highlighting" on the > > Highlighting > Color tab and let the None always be the initial state? > > Note that the same applies to everything, not only background / > highlighting. What UI would you suggest for the same issue in Bold / Italic > / Underline etc.? Only for the record: The Clear (All) Direct formatting is still quite heavy-handed solution, IMHO. If I highlight some text portion also formatted Bold/Underline/Specific font. I want to 'truely' reverse my action in a different session. I have to rely on 'Clear Direct Formatting'. Which also means removing Bold/Underline/Specific font. Or maybe some other DF I set I'm not directly noticing. A clear separation between - in case here - "No Highlighting" and "Transparent" would be a lot cleaner and more intuitive/straight forward. Using some DF means, it never can be 'removed' only converted to inverse. So enabling Bold, activates DF bold. Disabling Bold results in unbolding. The presence of DF will be permanent, except when using Clear Direct Formatting And having to rely on styles for each and every formatting seems impractical. Do I really need to create a style for each and every highlight color I'm using? The dogma of supposedly using styles for each and everything is still beyond me.
(In reply to Telesto from comment #10) > I want to 'truely' reverse my action in a different session. I don't see a *real* use case, that is important and common - again: note the *intended audience* of direct formatting. What is that "I want to truely reverse" scenario? Now consider this *real* scenario. A basic user, not deeply experienced in word processors, gets a document from someone (say: downloads from Internet); the document has part of the document highlighted properly using styles. The user wants to remove part of the highlighting. They select the wanted part, and use toolbar to choose "no highlighting". Suggest an alternative workflow for this case, that would fit the *basic* user.
(In reply to Mike Kaganski from comment #7) > Note that the same applies to everything, not only background / > highlighting. What UI would you suggest for the same issue in Bold / Italic > / Underline etc.? This question reminds me of several bugs: * Bug 89826: "Allow resetting individual style attributes to inheritance from parent rather than specific value" * Bug 88559: "Display of inherited attributes from parent styles in Styles dialog" where the question of an explicitly-set value vs unset/inherited also comes up.