IMO, it's not good to implement such non-trivial processing. Imagine a case when user selects a text run where multiple formatting is applied: paragraph style with bold; paragraph style with regular; char style with bold and another with regular; direct formatting with both... and their different superpositions. Now what would come if user clicks Bold? The text run should be analyzed part-by-part, and each part given its own new formatting just to make it Bold? or non-bold (like in "toggle")? Even if we decide to make it all Bold, then, while visually it will be what user expects, internally this "bold" will be a number of independent runs with different combination of style and direct formatting... and then behavior of such text run will be inconsistent with what user intended.

Pressing buttons of direct formatting is just that: applying direct formatting. No need to try to figure some more clever processing, to find then that another user finds it confusing. Better emphasize that it's direct formatting, and deprecate it visually in favor of styled approach.

(In reply to Octavio Alvarez from comment #0)
> User expectation is broken: unapplying Bold means "remove the bold
> attribute" not "set weight to regular".

Agreed with the reasoning that user expectation comes from html where removing (b)(/b) (not sure that <> is kept) unset the boldness. But the processing is error-prone, as Mike says, and we have plenty of functions to unapply a direct formatting: undo and clear formatting.

What's your take, Cor, Stuart, Jay?

Have to agree with Mike as when you mix paragraph style, character style and direct formatting it doesnt always end up how one would imagine, which is why we have things like clear direct formatting to reset things to scratch.

Lets take this scenario

1. type 'LibreOffice is so great'
2. Ctrl+1 to set heading 1 style
3. select 'LibreOffice'
4. press Ctrl+B (makes it unbold)
5. Ctrl+0 to set text body style (now all text is unbold)
6. Ctrl+1 to set heading 1 style

What do you expect to happen now?
a) that all the text is bold like heading 1
b) that 'LibreOffice' retained its unbold attribute and the rest of the text is bold

Yousuf's question is not easy to answer. I gave it a deep thought before submitting the suggestion and could not come to a clear and obvious answer but I have a suggestion.

I suggest that attribute removal should only occur when using Direct Formatting applying/removal tools (like the Bold toolbar button or the Character dialog from the Context menu).

So if it were on my hands I would do option (b): The "LibreOffice" word had been set to Weight:Regular and changing the underlying style does not remove the Weight:Regular DF.

Rationale: I can only affirm that user expectation is broken when unapplying DF attributes. This may happen on styles too but I cannot affirm this. So let's tackle the DF experience for now. Most probably users that know styles understand DF a better than those who don't.


Additionally, I would like to share a small experiment I just did on Word to compare behaviors:

1. Set "Heading 1" style to be Bold.
2. Write "Red Bold Regular".
3. Set "Red" to red color.
3. Hit Ctrl+B twice on "Regular".
4. Set the paragraph to the "Heading 1" style.

"Regular" will also be bold, but "Red" will keep its red color. This is the expected behavior.


Another idea: explicitly add "inherit" options to each attribute, for example, the Bold button would be a dropdown with "Inherit from Styles, Bold and Regular". But maybe this would be too cumbersome.

(In reply to Octavio Alvarez from comment #4)
> So if it were on my hands I would do option (b): The "LibreOffice" word had
> been set to Weight:Regular and changing the underlying style does not remove
> the Weight:Regular DF.

As you chose (b), then this bug should be closed as WONTFIX as you are accepting that the current behaviour is the correct behaviour, that the change of paragraph or character styles doesnt alter the set value at the direct formatting level.

We need 3 possibilities at the direct formatting level - inherited, bold and unbold - in order for things to work correctly.

I would close this bug now, but lets hear what Cor, Stuart, and Regina have to say.

Then I chose option (a) ;-) Out of kidding, option (a) is not a bad option either and I am open to it if it makes it easier to understand. It's a sign that it may be easier for other users too.

However, at risk of sounding too verbose, I think a clarification is in order:

My suggestion is [so far] strictly about *the application / un-application of default formatting* because it clearly breaks the user expectation as currently implemented. It has [so far] nothing to do with changing styles. Changing a style is just the easiest way to expose the broken behavior. Another way is through the paintbrush as DF plays a role on how it works:

1. New document.
2. Type "Plain" and hit Enter.
3. Type "ForcedRegular" and hit Enter.
4. Type "Heading 1", and hit Ctrl+1.
5. Hit Ctrl+B twice on "ForcedRegular"
6. Place cursor between "a" and "i" in "Plain". Hit Paintbrush. Hit the "a" in "Heading". Nothing happens at all.
7. Place the cursor between "r" and "c" in "ForcedRegular". Hit Paintbrush. Hit the "a" in "Heading". The word "Heading" turns regular.

This manifests in issues #112872. Some users think this inconsistent, some think the Paintbrush does not properly work. I think it works but it has an inconvenient algorithm. Please note: my suggestion won't fix the paintbrush, in fact, my suggestion may even make the the paintbrush feel even more broken but it will clear one of the most invisible variables that occur when editing documents to give a more consistent UX. The paintbrush tool itself is broken (hint: it should replace all formatting on the target, not just add DF,  with the formatting of the source, including styles, but that's another story).

Also, think what happens when a user saves a document and sends it to somebody else for modification. Invisible Direct Formatting can be all over the document, with Writer being prone to be perceived as plain broken.

With this clarification, I understand your question as a proposal to *extend my suggestion* in order to make it as congruent / compatible as possible with other work flows in the program. I choose option (b) just because I can [so far] only affirm brokenness about DF. This does not invalidate my suggestion, only the proposed extensions, so we are back to my suggestion as originally suggested:

When applying Direct Formatting, attributes that end up matching the underlying styles [1] should be unset.

[1] By styles I mean the resulting style after calculating the style hierarchy.

However, I am also open to accept your proposed extension to apply this logic when changing styles too. Your scenario sounds much more likely to occur by mistake (as in "Oops, I applied the wrong style let's reapply the correct one") but if this makes a user lose its DF, the user will always have Ctrl+Z, which is much more well known and understood.

Let's include possible solutions. If the property is not part of the style it is removed when unapplied. "Hello <b>bold</b> world" -> "Hello bold world" instead of "Hello <n>bold</n> World" with n=normal weight. Doesn't work (well) when the style contains bold and you toggle it on/off. Undo in terms of checking whether bold has been set before is also not an option as we would need to save all interactions. Could work somehow during the current session but would be very error-prone IMHO.

The only solution is to implement the first option and "forget" all previous direct formattings after a style is applied. Meaning unsetting a property removes it but also applying a style let it disappear when equal. That leads to confusions too and we should weight which of the two options is less weird or more convenient.

(In reply to Octavio Alvarez from comment #6)
> Then I chose option (a) ;-) Out of kidding, option (a) is not a bad option
> either and I am open to it if it makes it easier to understand. It's a sign
> that it may be easier for other users too.

Option (b) is the only correct option in my view. I tried the same example in MS Word and the result was quite strange as step 5 resulted in 'LibreOffice' being bold and the other text being not bold, and step 6 resulted in all the text being bold and no longer looking like step 4.

> My suggestion is [so far] strictly about *the application / un-application
> of default formatting* because it clearly breaks the user expectation as
> currently implemented. It has [so far] nothing to do with changing styles.
> Changing a style is just the easiest way to expose the broken behavior.
> Another way is through the paintbrush as DF plays a role on how it works:

Please provide an example that is only DF, if it has nothing to do with styles, and not using paintbrush, as that opens up a different set of problems.

> 6. Place cursor between "a" and "i" in "Plain". Hit Paintbrush. Hit the "a"
> in "Heading". Nothing happens at all.

this would be a bug in paintbrush in my view.

> 7. Place the cursor between "r" and "c" in "ForcedRegular". Hit Paintbrush.
> Hit the "a" in "Heading". The word "Heading" turns regular.

I hit the "a" and only the "a" turned regular, so i'm assuming you clicked on the entire word.

> When applying Direct Formatting, attributes that end up matching the
> underlying styles [1] should be unset.

I could agree with you and Heiko on this behaviour.

This question is really a throny one and whichever solution we pick, there will be use cases when the result is counter-intuitive, annoying or frustrating for the users. 

So, I propose to add some explanation to the UI that helps the user to understand what is happening. 

I think we could use something that is similar to the DOM inspector in the Developer Tools of the modern browsers (Firefox, Chrome) that explains how Style Sheet rules work.

When the user clicks an element on the web page (places a virtual cursor there) then the DOM inspector shows what rules are applied to that part of the document and how the contradicting rules override each other producing the end result. 

It simply just lists all the rules and their declaration components that are applied to the given position and strikes thruogh the ones that are overridden by some other. After a short learning curve it is quite usable. 

I created a screen shot which shows how LibreOffice could display such a tool in the Styles And Formatting dialog. I called it just Style Explainer. 

Unfortunately this is not a simple change in LO, it is quite a lot of work to implement but it would be awesome to use. Actually, I think it would be a feature that can attarct new users to the LO so maybe it is worth working on it. :)

Created attachment 138839 [details]
illustration for the Style Explainer

(In reply to Yousuf Philips (jay) from comment #5)

> I would close this bug now, but lets hear what Cor, Stuart, and Regina have
> to say.

A can of worms and I expect (b) from comment #3 ..

(In reply to Heiko Tietze from comment #7)
> The only solution is to implement the first option and "forget" all previous
> direct formattings after a style is applied.
This is what I would expect. But I'm one of the rare users that use styles instead of DF as far as possible.

Miklos, Eike, what do you think about this question?

I suppose that the best is to focus on something like described in comment 9. This (or some similar) would *enable* one to see and understand what is going on. Without means to understand, any "resolution" would only confuse another group. Only when there's a view of the formatting structure, can we start to think about Benjamins (because only then can we start to implement easier tooling around the advanced structure viewer).

Testing with MSO16:
Created a new test style with just bold, that applied to a word makes it bold and toggles the toobar button. Directly formatting bold off makes the word regular but keeps the test style active. Applying the style to the whole paragraph keeps the word in regular. Now I set a word in this bold paragraph to regular and apply a character style with italic to another word and switch the paragraph style to standard (with regular font weight). That _toggles_ the boldness of these two words meaning all text in regular but the previously made normal are bold now.

Looks like there is a hierarchy of paragraph style < character style < direct formatting where DF is kept when applying a style. And MSO toggles the DF.

(In reply to Heiko Tietze from comment #13)
> Miklos, Eike, what do you think about this question?

The simplified situation is that boldness is a tri-state: default (inherit from style), true or false. As far as I see pressing bold twice in MSO returns to default, while in LO pressing bold twice results in a still existing formatting. So if users expect us to be more consistent with MSO on the UI (where changing something has no backwards compatibility implications), that sounds fair enough to me.

(In reply to Mike Kaganski from comment #14)
> I suppose that the best is to focus on something like described in comment
> 9. This (or some similar) would *enable* one to see and understand what is
> going on.

Yes a similar concept has already been proposed in bug 90646 (mockup: attachment 115020 [details]). MS Word's Style Inspector dialog is a good implementation of the same concept, while a browser's DOM inspector implementation is way to complicated.

http://img-aws.ehowcdn.com/default/cme/photography.prod.demandstudios.com/9d4dd6bd-c8cf-4fc4-a385-ccd1b671ae6a.png

> Without means to understand, any "resolution" would only confuse
> another group. Only when there's a view of the formatting structure, can we
> start to think about Benjamins (because only then can we start to implement
> easier tooling around the advanced structure viewer).

Benjamins primarily dont deal with styles, so this functionality isnt focused on them.

We discussed the topic in the design meeting and agreed on WONTFIX in regards to change how things are implemented but with the addition of better feedback like proposed in comments 9, 10, 17 and bug 90646. 
Many thanks for starting the discussion, Octavio.

While this bug is closed, it will be impacted by any potential change/resolution of bug 35538. If the silly notion of 4 variants (R, B, I, B+I) is dropped, and if we have a weight scale instead of Bold / not-Bold, things will be quite different.