Created attachment 164402 [details]
Example file

Not a bug, parts of the text are directly formatted with the same background color as Default. Double-check this by removing the direct formatting (ctrl+M or Format > Clear DF). 

Please try the newly introduced Styles Inspector, it's made for users like you to get insights to the actual formatting.

(In reply to Heiko Tietze from comment #2)
> Not a bug, parts of the text are directly formatted with the same background
> color as Default. Double-check this by removing the direct formatting
> (ctrl+M or Format > Clear DF). 
> 
> Please try the newly introduced Styles Inspector, it's made for users like
> you to get insights to the actual formatting.

Not the point.

If you highlighting a part of a text and you want to 'remove' the highlighting.. What do you do? Use CTRL+M (even with more DF set to it?). Or select the highlight tool and set it to no fill. 

I - benjamin - mostly set it to no-fill (as this the only option available in the drop down). Assuming non file meaning; 'remove' delete highlight color. 

Which is obviously not the case. However I'm still clueless how to actually disable highlighting. Instead of switching from color to no-fill.. So to remove the the Highlighting as Direct Formatting, without removing all formatting (CTRL+M). 

This is most prone case here. Not sure what Bold/Italic/Underline does. So after enabling BOLD. You can untoggle bold, but there is still DF present, set to non-bold. Doesn't seem that way, DF non-bold with a bold default paragraph style when switching styles

The lovely combination of DF/Styles. So no problem with 'no-fill', as such. But needs an addition to 'remove' highlighting next to it (also accessible from highlight tool drop down). 

In the current implementation there is no turning back (except CTRL+M), but that's last measure; removing all DF.

*If* you use DF, you need no special "remove part of DF" function.
*If* you use styles, Ctrl+M is enough.

No use for the advanced feature to remove parts of DF; but potentially could be part of Styles Inspector, where DF entries could have a way to be removed (context menu? Del?).

(In reply to Mike Kaganski from comment #4)
> *If* you use DF, you need no special "remove part of DF" function.
> *If* you use styles, Ctrl+M is enough.
> 
> No use for the advanced feature to remove parts of DF; but potentially could
> be part of Styles Inspector, where DF entries could have a way to be removed
> (context menu? Del?).

This is better compared to nothing. 


CTRL+M is a last resort. It removes all DF, including maybe intentional formatting. So rather frustrating to use. As you need to redo the intended part 
This because you can't "undo" highlighting/font color setting; there is no contrary action; If you DF Font color/ highlighting there is no way back/ out (except for CTRL+M) As no fill/automatic font color is seen as DF in the model. Which works for undoing styles formatting by using DF formatting.

And removing DF using Style inspector bit cumbersome way. As far I have seen this isn't still not as fancy as this. 
https://design.blog.documentfoundation.org/wp-content/uploads/sites/2/2019/11/20191105_SI2.png

@Luke
Not sure if you have an opinion on this. However you where included in some of thee styles and direct formatting topics. And this benjamin here finds they direct formatting, paragraph formatting still confusing.

As I do combine DF and Paragraph styles, but not being have user of character styles. And if i highlight something I use the Highlighter, as I'm intending to highlight sections.. not whole paragraphs.. area which need some attention. 

But not sure if you ran in this type of issue..

(In reply to Telesto from comment #5)

No. Ctrl+M is *not* a last resort. There are hundreds of possible pieces of manual formatting. They interact in different ways to result in what you see, with no easy way to know which specific manual setting produced this effect. If you took time to learn e.g. rationale for styles inspector, you would know that. Introducing those hundreds of tools for a task that is not going to be used is just useless.

WF imo.

Created attachment 164990 [details]
Example 2 (bold)

(In reply to Mike Kaganski from comment #7)
> (In reply to Telesto from comment #5)
> 
> No. Ctrl+M is *not* a last resort. There are hundreds of possible pieces of
> manual formatting. They interact in different ways to result in what you
> see, with no easy way to know which specific manual setting produced this
> effect. If you took time to learn e.g. rationale for styles inspector, you
> would know that. Introducing those hundreds of tools for a task that is not
> going to be used is just useless.
> 
> WF imo.

I'm not asking for hundreds (or thousands of tools). I'm only taking about the formatting toolbar. My major problem is that if you started using direct formatting, there is no to they untouched state for a specific direct formatting. They direct formatting will keep interfering with styles.

Another example
1. Open the attached file
2. Select World
3. CTRL+B
4. CTRL+B
5. Change paragraph style to Default paragraph style

-> In this case BOLD is DF.

This makes the usage of styles quickly hard and confusing. The opposite of what's intended. And doesn't result in the quick and easy layout changes as advertised. You need to be very very disciplined not to use DF somewhere, at some point.
And the whole idea of quickly changes a style becomes quite a check, double check, triple check the document again (as there might be DF at at a place it should be)

And LibreOffice is surely not design to prevent or easily correct such a mistake without CTRL+M (throwing all formatting - even the intended stuff - away). 
No someone starts with .. you should have used Character Styles.. but applying those is cumbersome. CTRL+B is faster.. or for the ones who love markdown *bold* (still DF). And no, you might not interested in changing the look of the DF text, again. So usage of those styles rather pointless (a contrary to the Paragraph styles)

A similar problem arises with 'no-fill'. If you highlight some (direct formatted text, font type bold etc) text with yellow, and want to remove it, you use no-fill. Which works with the DF paradigm. However "no fill" is literally no fill in the page style paradigm. So if highlighting being able in a style, no fill overrides the style if it has highlighting in it

Something similar with font color automatic. I assumed, back to 'style inheritance', but this is not the case.

They Style Inspector reliefs some of black box effect. But feels more after the fact tool, instead of mitigating the cause (pre-emptive). If you make a mistake with DF, it will hunt you.. there is no leniency

And I personally tend to Write first an care about the layout in a later stadium. So surely use some DF in the process. Maybe even undo afterwards (disabled bold), but still lingering in the background.

CTRL+M removes all direct formatting (except as it seems the language setting?); which is rather excessive number of cases. If you 'want to remove the bold' DF, but keep the Italic. 
If I used different fonts in some sentences with and also applied a font color (which being reverted to automatic), it can't be managed by styles anymore. 

And it's already hard to see bold highlight up in the DF formatting toolbar with if this actually being caused by a paragraph/character style. And if you unbold/bold again, you applied DF.

This this makes styles rather fuzz to use. Confusing, tiresome to manage/ and keep track off. You simple drop the styles, as and do it the old an dirty DF way. Except for areas like Headings. Because the style causing way to much strain to be used in the whole document. Only to hardcore users remain; instead of being useful in general.

For the Italic/Bold/Underline area you use one button to things. As DF toggle button. And as button to show the current active style formatting. In exact the same way... with the same button (which is a mistake)

In extension of that, if you have default paragraph style and press bold button, the non-bold becomes bold. Press Bold button again it it's unbolded. But not back to paragraph style, now it's unbold as DF. 
Visa versa. If paragraph style is a bold, the BOLD button in the toolbar will be highlighted. And you press unbold, a DF unbold is applied. And the button becomes de-activated. Press BOLD again, button become active (as at the start) and text will be bold, but this is DF bold, not style bold. (So GUI is not informative at all). And secondly there is no way to get rid of the direct formatting again.. (problem two)

There is CTRL+M; however actually removes all formatting. In theory a 'special remove formatting' dialog could be created, where could be selected which DF should be removed. In some sense as the Special Paste dialog in Calc. This would make it possible to pick the stuff you want to remove, instead of all or nothing. However still patch on a wound.

Next to it you have the 'no-fill' and 'automatic' terminology. No fill effect means something different in they DF world compared to they PS world. And there is even no alternative offered, next to no fill. Automatic has for me the 'default/PS meaning' but that's true either. And also here no alternative.

A solution would that bold;italic/underline and such shouldn't be binary toggle on/off but have tripple state. Bold/unbold/off (style based). While Style Based Bold button have different look different, compared to DF Bold. Border around the button or whatever to make it distinct..

If the objection should be people get confused by tripple states or whatever; start with additional toolbar offering this. And propagate that one to be used when using styles [and can be added to the initial configuration 'wizard' the customize LibreOffice first launch/or being accessed later on. There quite a number 'disputable' defaults. From tabbed dialog to markdown or spell checker ignoring numbers in words as wrong spelled.]. Most of those setting are now at forced on say 50% of the user base. Causing questions & frustration. And no, I don't automatically setting, and if so, I don't know how it's called nor where to look]    

Related to highlighting and font color an additional 'off' button should be offered. 

FWIW, I'm not intending to 'solve' all the DF issues. And CTRL+M might be still useful, but it currently needs to be used far to often. This simply should be needed for the most applied formatting options (as shown in the formatting toolbar). This simply a UX/design flaw. That users don't grasp the styles concept or having trouble with it, is caused/aggravated by how it's implemented in LibreOffice.

(In reply to Telesto from comment #8)

"I'm not asking for hundreds (or thousands of tools). I'm only taking about
this function. And that function. And also that one. And this. And I don't realize that that is just my list of favorites, and others have different lists; and also many have consistency in mind; so having *some* set of tools to reset special DF, the question arises to make other DF to have those counterparts, too. And I have that delusion that I can create a workflow "using styles", where DF fits."

No, it's true that "You need to be very very disciplined not to use DF somewhere". And no, it's not that "using Ctrl+B is faster", it's "I need t learn how to set up my key combination to use styles instead of DF". There's no efficient workflow that includes both DF and styles, not because there are no "reset specific DF" tool, but because they are just ideologically mutually exclusive. And too often I see people here have ideas like "I see this small problem, and I have this great idea, and I am sure it's nice to have, and I don't want to learn to see the whole picture, to see that this local solution would maybe allow some specific thing, but in the expense of much greater problems, not only because of much greater complexity in the software and maintenance, but also promoting not what I think it will (using styles), but a different and very problematic - using DF".

Just a small addition. If you think there are benefits of using DF over styles in any scenario, you should not look for ways to make the hybrid. What *is* the problem in that case is that there is actually a usability problem in using styles, which needs addressing. So that using styles becomes not cumbersome, and not less easy than using DF.

(In reply to Mike Kaganski from comment #9)
> (In reply to Telesto from comment #8)
> 
> "I'm not asking for hundreds (or thousands of tools). I'm only taking about
> this function. And that function. And also that one. And this. And I don't
> realize that that is just my list of favorites, and others have different
> lists; and also many have consistency in mind; so having *some* set of tools
> to reset special DF, the question arises to make other DF to have those
> counterparts, too. And I have that delusion that I can create a workflow
> "using styles", where DF fits."
> 
> No, it's true that "You need to be very very disciplined not to use DF
> somewhere". And no, it's not that "using Ctrl+B is faster", it's "I need t
> learn how to set up my key combination to use styles instead of DF". There's
> no efficient workflow that includes both DF and styles, not because there
> are no "reset specific DF" tool, but because they are just ideologically
> mutually exclusive. And too often I see people here have ideas like "I see
> this small problem, and I have this great idea, and I am sure it's nice to
> have, and I don't want to learn to see the whole picture, to see that this
> local solution would maybe allow some specific thing, but in the expense of
> much greater problems, not only because of much greater complexity in the
> software and maintenance, but also promoting not what I think it will (using
> styles), but a different and very problematic - using DF".

I agree.

I may also have had a brilliant idea.

Let me first recap to check my understanding:

   Once you have used DF, nothing will get the text back to non-DF except Ctrl-M.

The DF commands that appear to toggle, don't - I think that's the major source of the problems caused by the design of DF in Writer.  When you have used DF to change back to the default appearance, the text is still DF. That's the heart of the problem.

I think a more natural semantics for Writer would be that if a piece of text's properties equals that of the text adjacent to it on the left or right, its style should be automatically changed to that style rather than leaving it marked as DF.

I think that would solve many of the usability problems and user confusion around DF, at a minimal run-time cost of some extra code run after DF is applied, to try to simplify (minimise) the styles.  In other words, to actively work to clear a DF indication if the text's properties makes it LOOK identical to the text it's adjacent to either on the left or the right.

But that's not my possibly-brilliant idea, which I'll sketch out now.

I was thinking of one added new function for the user - let's call it Simplify - that's similar to Ctrl-M in ONE respect: it removes DF in any selected text.  
But what this new Simplify function does is that it makes no change to the text's appearance, instead finding styles that exactly match the text's appearance.

Method:
It iterates over the characters in the text in a single pass.
It gathers each character into a run of text of the same text properties, trying to make the longest run of text it can.
For that run of text, it then looks through the defined styles, for an exact match.
If it finds an exact match, it clears DF and sets the run of text to use that style (or combo of character and paragraph styles).
If it cannot find an exact match, it creates a style (Simplify<N> and increments N), and assigns that to the text, and clears DF.
It then continues, building the next run of text.

In this way, all DF is removed from the selected text, the text has no visual change, and a minimal set of styles are used or created, putting the document in good shape for further work.

What do you think?

(In reply to Luke Kendall from comment #11)
> The DF commands that appear to toggle, don't - I think that's the major
> source of the problems caused by the design of DF in Writer.  When you have
> used DF to change back to the default appearance, the text is still DF.
> That's the heart of the problem.
Yes, that sounds like a problem to me - if that is true. If the direct formatting matches the inherited formatting (from styles etc), then the direct formatting should be removed. (Of course, there are probably exceptions needed for that rule too.)

[I usually get lost when debugging this deep, but it seems to me that there are already attempts to avoid setting a property if it matches the parents - at a fairly low level.]

(In reply to Luke Kendall from comment #11)

This is wrong. This is not converting a document into "using styles", it abuses styles to create a new set of DF - named "Simplify<N>".

Styles are not just a random set of attributes with a name. They are designed to introduce structure into documents. And that largely means using *semantics*, not formatting. Two *different* styles may perfectly happen to have the same set of attributes, still absolutely different semantical meaning. E.g., you may want your quotes in a text to be highlighted the same way as emphasis; yet, they have different meaning. DF cannot give you that semantical meaning - you would e.g. simply make both emphasized text, and quoted text, italicized and monospace. Then you would have hard time when you decide to make quoted text (but not emphasized text) different size. Styles, when used properly, give you that ability - and that they happen to have same formatting at a given moment, does not break your ability to differentiate them, or separately change their formatting at a later time.

Your "Simplify<N>" has absolutely nothing to do with the idea of using styles. So it's just another direct property of texts, not creating any structure, but implemented using style mechanism - still I repeat: they are *not* styles as they designed to be.

(In reply to Mike Kaganski from comment #9)
> (In reply to Telesto from comment #8)
> 
> "I'm not asking for hundreds (or thousands of tools). I'm only taking about
> this function. And that function. And also that one. And this. And I don't
> realize that that is just my list of favorites, and others have different
> lists; and also many have consistency in mind; so having *some* set of tools
> to reset special DF, the question arises to make other DF to have those
> counterparts, too. And I have that delusion that I can create a workflow
> "using styles", where DF fits."

I know.. something about unwanted scrolling comes to mind ;-). Where this happened, and surely not the first time.. 

So I understand the 'objection';

> And too often I see people here have ideas like "I see
> this small problem, and I have this great idea, and I am sure it's nice to
> have, and I don't want to learn to see the whole picture, to see that this
> local solution would maybe allow some specific thing, but in the expense of
> much greater problems, not only because of much greater complexity in the
> software and maintenance, but also promoting not what I think it will (using
> styles), but a different and very problematic - using DF

There are misunderstandings & different idea's for sure. I surely assume my idea being THE solution. Only an attempt/direction. 

However the first task is the identify if there is a problem; and what the problem is or the problems are. 

I'm don't what push something through. But I can't be rather persistent if I have the impression something is not right. The usage of styles is not that easy as it in my perception could be, IMHO


(In reply to Luke Kendall from comment #11)
> The DF commands that appear to toggle, don't - I think that's the major
> source of the problems caused by the design of DF in Writer.  When you have
> used DF to change back to the default appearance, the text is still DF.
> That's the heart of the problem.

That's indeed the heart of the problem (related to the toggle buttons as bold). Same issue exists also for font color/font highlighting


---

To start with; there are number of combinations possible
1) Direct formatting only
2) Paragraph style + Direct Formatting
3) Paragraph style + character style
4) Paragraph style + character style + direct formatting

--

Quote: "There's no efficient workflow that includes both DF and styles, not because there are no "reset specific DF" tool, but because they are just ideologically mutually exclusive."

In pure form there might 'exclusive'. But practical this isn't true. Two paradigms/ ideology's a entangled in the GUI and functionality

For me it's floating scale.. Not exclusive paradigms. You can apply DF to a paragraph style. There is always a paragraph style (the default paragraph style); even if ignore that fact and use DF for formatting only.

In the past I used Heading (style) for numbering, and never cared about other styles (so used Default style with maybe DF). And limited to use for PS to headings style. And I lived.

Working with paragraph styles + direct formatting is pretty conformable/practical for me. As being easy/ prominent accessible. And not seeing the benefit of Character Styles. Maybe even quite cumbersome to manage, if you use different direct formatting a say a single time. 

And there is not really an incentive to do this otherwise. For example CTRL+B doesn't apply Character style BOLD, but DF BOLD. But not sure what CTRL+B and CTRL+U would end up with. A single BU style. But what if there are identical styles with same setting; different name. I'm already having trouble to see difference between the styles Strong Emphasis and Main Index Entry (visually). They look the same to me. Supposed to used somewhere else based on the name. But the difference being?.. Have to compare both manually  

One of the reason Character style mind boggling for me. I highlight text pretty often, do I need to configure a style for every color? And If I also mark part bold, should I create a style for every color unbolded and bolded?

So in theory Character Styles might be 'better' practical you could excessive amount of styles, without practical usefulness. 
And if we also export this stuff to DOCX you end up with even more styles with lovely non-descript names. The number of created PS mostly oversee able, however number character styles become rather explosive. And hard to maintain with shortcuts (say I have 30 character styles; some hierarchical; I even find 30 shortcuts.. how I'm  I supposed remember all that. What every character style is about; at which level it's set etc. I surely get lost.

And another problem with character styles is you have no way of knowing (similar to PS). You can't tell is this DF, PS, CS. And you can't also not see which CS it actually is. And you can't see PS/CS in the sidebar at once. It's or/or. 

So Character styles might be 'addition' to DF, I don't see it as a replacement of DF. So the whole mutuality distinct stuff doesn't hold in practice if you ask me.

Currently I observe two issues
1) Activated PS style formatting is shown in DF toolbar: which makes it look like DF (but it isn't)
2) Applying DF means the opposite of what the Style does. So if the style is BOLD pressing the bold button (which is activated by styles) will:
* Unbold
* Activate DF formatting. Pressing BOLD again it still DF formatting 

Font color/font highlighting are suffering from the same problem.

The current implementation is over-complicating the matters for my taste. One formatting toolbar (used by PS styles and DF without visual feedback). Without any visual difference between DF bold or PS bold. 

If you want to use a single toolbar, be more explicit. So B button showing PS or DF in the button somewhere or border or different highlight color whatever.. (the solution touches the area of accessibility; color blind probably dislike a different colored button highlighting). This solves the knowing what you're doing part.

The second issue is there is no way rid of specific Direct Formatting, except CTRL+M. Which eradicates all DF; so can't be selective at all). So pressing a DF button, it's toggled on (and can't be turned off). And you can't see in document different between DF/PS (except now with the style inspector). But it still doesn't "highlight" the areas with DF; you need to walk through the document and look at what's popping up in the style inspector

So say I press CTRL+B; in a line, press CTRL+B to undo. It's still DF. If I press CTRL+Z instead it will be OK. If you don't correct it immediately I you might run into it later on.

And the easiness of changing a style makes to whole document look different with few clicks is ruined; as there might be some unintended DF somewhere in side the document next to intended DF. So even with the style inspector, you still need to look closely. Yes, this could be avoided by Character styles. But now you're at risk of having used the wrong 'character style' somewhere. So applied  Main Index Entry (by shortcut) which looks the same as Strong Emphasis initially (so no reason to check), but at the point you change Strong Emphasis, this will appear. And you again need the check the whole document..

You need to very very disciplined to use DF/CS faultless to pick the fruits of it. You need to have already an idea of the formatting in advance. A structure. And you need to apply it really  consistently. And can be quite a time consuming business. 

PS simply useful, as long as you don't outdo you're self with a the number of styles. Character styles can be useful, depending on the situation but not a holy grail (can't/won't replace DF).

I personally still convinced there must be something done to optimize this. Without ruining the model. Or making a to hard to maintain for dev point of view. But should usable from user point of view. 

Of course you may defend the PS/CS style. However there some view around which sees styles as superior to DF in every case/setting; and as a holy grail. I'm not convinced this is true. PS/CS is tool as DF. PS/CS can't replace DF. Both need to life next to each other. They are not mutual exclusive as someways stated. And should be either.

I see a problem here; I did some suggestions how to approve things. They might not be desired.. but if acknowledge there is a problem, something should be done about it.. Or another solution must be found. They Style Inspector is useful, but doesn't solve the "core"/ the heart of the problem(s) at stake. 

Already struggled with the formatting thing quite a while. The current implementation doesn't land. It's counter-intuitive/unnatural in some ways. I really have to focus/concentrate on the styles/formatting. It really costs mental effort. And you can easily drown (hierarchical relations between styles at the same style level (say PS). Interaction of styles at PS and CS level. Number of styles). So if really want to those big time, you really need to now what you're doing or you get surely lost. And don't everybody being able to handle that properly.

(In reply to Mike Kaganski from comment #13)
> (In reply to Luke Kendall from comment #11)
> 
> This is wrong. This is not converting a document into "using styles", it
> abuses styles to create a new set of DF - named "Simplify<N>".
> 
> Styles are not just a random set of attributes with a name. They are
> designed to introduce structure into documents. And that largely means using
> *semantics*, not formatting. Two *different* styles may perfectly happen to
> have the same set of attributes, still absolutely different semantical
> meaning. E.g., you may want your quotes in a text to be highlighted the same
> way as emphasis; yet, they have different meaning. DF cannot give you that
> semantical meaning - you would e.g. simply make both emphasized text, and
> quoted text, italicized and monospace. Then you would have hard time when
> you decide to make quoted text (but not emphasized text) different size.
> Styles, when used properly, give you that ability - and that they happen to
> have same formatting at a given moment, does not break your ability to
> differentiate them, or separately change their formatting at a later time.
> 
> Your "Simplify<N>" has absolutely nothing to do with the idea of using
> styles. So it's just another direct property of texts, not creating any
> structure, but implemented using style mechanism - still I repeat: they are
> *not* styles as they designed to be.

I completely disagree with you.

My reasoning is that I think you're claiming my proposed function could never introduce new styles that have semantic meaning.

I completely reject that because it depends on the user's intent. In my case, and I would argue many others, the visible style matches the semantic intent.

I am not trying to claim that such congruence is always true, just that it can be.  Therefore a function that would produce such automatically-created styles would be true styles, not DF+style, when used on documents for which that congruence was true.  Note that it's a user choice.

Further, a document that had been "Simplified" would then require little work to find text of a certain style and change it if that case had some special semantics.  The effort of turning a document with a mess of DF into a well structured document would be moderate, instead of a Herculean undertaking.

(In reply to Mike Kaganski from comment #13)
they are *not* styles as they designed to be.

FWIW: it's partly about what they design; what's being practical. Of course there need to be a model/a design. But if the design results something less workable, move to being pragmatical. Exceptions on the rule.

I do see issues to Luke proposal. Same look on screen (font/bold/underline) based on two different styles.. So merging DF to a style is not directly possible. Which one to pick. Something else is doing a suggestion.. This DF formatting matches styles XYZ. Adjust too. 

Not saying this technically possible dev point of view; or ideal from user point of view. Of UX agrees.. But I do understand what Luke is saying.. Even though I'm more issues with they UI (PS/CS shown in a DF toolbar). And no way to disable DF.

But other dimension/side of current model is indeed the harmonizing with styles part. The to paradigms need to grow to each other; not be implemented as mutual exclusive; as this isn't in line with daily reality. Or I assume it isn't. 

I can only give my personal view on this. And even if the participation stuff is going the fly (Board mailing list). I still believe we would have a hard time structuring the discussion. As there plenty of ways to optimize/ adjust/ tweak. Say: remove formatting in at Style Inspector level. It's something.. And surely better compared to nothing. But would be wipe for bleeding (Dutch expression; not sure what the native equivalent is)

(I wish I could edit my previous comment.  Here's what I meant to say.)

(In reply to Telesto from comment #16)
> (In reply to Mike Kaganski from comment #13)
> they are *not* styles as they designed to be.
> 
[...]
> I do see issues to Luke proposal. Same look on screen (font/bold/underline)
> based on two different styles.. So merging DF to a style is not directly
> possible. Which one to pick. Something else is doing a suggestion.. This DF
> formatting matches styles XYZ. Adjust too. 

I think the Simplify function even helps with this, because once the DF has been removed and replaced with a minimum set of auto-created styles, it's then tractable to go through and find text by style and make a conscious decision to change the style to an alternative style that has the same look but different semantics.

So I believe my proposed new functionality:

1) will make styles more understandable to more users
2) makes it practical to clean up a messy unstructured document and turn it into a clean well-structured one, and 
3) solves some (many?) issues around DF.

(In reply to Luke Kendall from comment #18)
I'm probably thinking in a different direction.. I was more thing about.. selecting a text (with DF).. and sidebar showing style alternatives.

But of course, the whole style stuff is rather 'hard'. Basic formatting at PS level (say font), some overlay at CS level (bold).. accompanied with DF (say highlighting). What should auto-style produce here.

However it seems that at we both agree that working with styles or converting DF to styles being Herculean undertaking once in a while. With the impression that this should be optimized/ streamlined somehow. And that the current implementation being sub optimal. 

What should be changed, how it should be changed and what's feasible different matter. I love to come at a understanding about what needs improving (or not); next a list of possible options..

For the record I'm trying to burn down styles or the whole concept. But should be working a little better next to DF. Sometimes I think is the whole half heated implementation created to force people not using DF if they use styles. And make life of people who end up with DF and styles for one reason or another pretty hard.

(In reply to Telesto from comment #19)
> (In reply to Luke Kendall from comment #18)
[snip]
> But of course, the whole style stuff is rather 'hard'. Basic formatting at
> PS level (say font), some overlay at CS level (bold).. accompanied with DF
> (say highlighting). What should auto-style produce here.

I'm not sure I understand.
Do you mean, should the CS style (e.g. bold) be just a Bold style, or should it be a style that copies all the properties of the PS and then adds Bold to that and creates a PS, or is it just a CS style (e.g. StrongEmphasis, or SimplifiedCharStyle2 or whatever) applied on top of the PS?

I think to try to keep the number of styles to a minimum, it probably means you use the PS and just create a new CS.

Similarly for the section highlighted - should that be one of the above two options, plus Highlight?

(I just realised I don't know if Highlight is a character attribute that could be turned into a style, PS or CS...? I just tried, and couldn't find a way to set a character style to do that.  So I think it's saying, if you highlight, that can only be done with DF.)

> However it seems that at we both agree that working with styles or
> converting DF to styles being Herculean undertaking once in a while. With
> the impression that this should be optimized/ streamlined somehow. And that
> the current implementation being sub optimal. 
> 
> What should be changed, how it should be changed and what's feasible
> different matter. I love to come at a understanding about what needs
> improving (or not); next a list of possible options..
> 
> For the record I'm trying to burn down styles or the whole concept.

I'm guessing you meant to have "not trying" there.

> But
> should be working a little better next to DF. Sometimes I think is the whole
> half heated implementation created to force people not using DF if they use
> styles. And make life of people who end up with DF and styles for one reason
> or another pretty hard.

I empathise. I doubt it's true, but I understand what you mean.

(In reply to Luke Kendall from comment #20)
> > But of course, the whole style stuff is rather 'hard'. Basic formatting at
> > PS level (say font), some overlay at CS level (bold).. accompanied with DF
> > (say highlighting). What should auto-style produce here.
> 
> I'm not sure I understand.
> Do you mean, should the CS style (e.g. bold) be just a Bold style, or should
> it be a style that copies all the properties of the PS and then adds Bold to
> that and creates a PS, or is it just a CS style (e.g. StrongEmphasis, or
> SimplifiedCharStyle2 or whatever) applied on top of the PS?

A CS style is simply a style applied on top of the PS (so overruling the PS, as far as the CS differs from PS). And DF formatting is overrules PS and CS (so DF is always on top of everything). It isn't possible to stack different CS layers on top of each other (not saying this should be possible; only noting)

Of course the implementation is again unfinished/confusing. A line of text. Set the paragraph style default font to lets say: Linux Biolinum G. Select a part of the text go to sidebar -> Character style & apply Strong Emphasis. Now right click Strong Emphasis and click modify. Font tab -> Notice font shown being "Liberation Serif". However it simply inherits the PS font (as expected from design point of view) However the dialog is showing something else.. so in that way unexpected. As styles already being complex by itself, those flaws are pretty annoying. I would expect it showing 'inherited' instead of any font (as there can be a multitude of different fonts where they style can be applied). Same holds true for all other areas.. As Inherited probably to long, * symbol?)

Also it's possible to reset/remove CS style by Applying Default Character style (which can't be modified)

---
As with the issue with all styles and formatting you can't see what is formatted using what. So if BOLD highlights in the formatting toolbar. It can caused by PS, CS or DF. (Same for font, font size, font color, highlight color)

And you can't manage PS/CS styles at with the sidebar If style Inspector being active. If people don't want to meddle with the formatting toolbar, I would like the Inspector to be in the properties deck? So while editing you can see at minimum how the formatting is build up?

The Style Inspector does improve things.. However it doesn't highlight all area's with certain (and no way of doing that, I think). So double clicking DF BOLD highlighting all area's with BOLD applied by DF. [Not sure if it would be workable (if edit a certain place, all other stuff is hidden again. You could consider pressing highlighting bucket.. to make it 'temporally permanent' for clean up purposes.. but if some BOLD DF shouldn't be replaced, you can't remove the highlighting.. as you introduced highlighting DF; which can't be removed (except by CTRL+M). 

If the mock-up will become reality this might not be an issue. But not so sure this will happen as initially advertised: https://design.blog.documentfoundation.org/wp-content/uploads/sites/2/2019/11/20191105_SI2.png

And showing DF simply won't work with the current Writer comment perf issues. It simple can't handle massive amount of comments

So much text and so much complexity in this discussion.
I assume a new feature like 'SimlifyXYZ' would it make more complicated for users.

I want get back to the original idea: If you use a command (e.g. the highlight color button in the toolbar) then the "no fill" option should delete the whole formatting from the file. Now instead of a visible highlight color it gets a transparent/invisible highlight color. You can see that perfectly in the new styles inspector or you open the content.xml of the ODF and search for something like <style:text-properties fo:background-color="transparent" loext:char-shading-value="0"/> in the <office:automatic-styles> area.

Resolution should be:
Every command that adds formatting to a text should remove that formatting completely when a 'automatic' or 'no fill' or 'undo format' option was choosen by the user. Now the xml file is swamped with style attributes.

The only workaround now is to use Ctrl+M.

I doubt that nobody has reported something like this issue in the past. Searching to avoid duplicates should be the work for the reporter, not for QA. So I don't do it.

For your information, there are many bugs out there around handling of styles and direct formatting.

* Bug 130930 - Ability to remove one specific direct formatting
* Bug 107095 - FORMATTING: Means to convert direct formatting into styles
* Bug 106556 - Add functionality that highlights all directly formatted text
* Bug 117022 (Writer-Toolbar-Formatting-Styles) - [META] Style-focused formatting toolbar
* Bug 127250 (Formatting-Text-Diverse) - [META] Text formatting issues when inserting or overwriting
* Bug 38194 - Style indicator in document margin
* Bug 128960 - Editing: Add a more direct way to clear character styles
* Bug 108015 - Using Ctrl + Shift + B and Ctrl + Shift + I for Emphasis and Strong Emphasis character styles
* Bug 89826 - Allow removal/reset of individual style attributes
* Bug 98381 - Pasting text at the beginning of a style changes the style to that of the pasted text
* Bug 88559 - Display of inherited attributes from parent styles in Styles dialog
* Bug 90646 (Sidebar-Styles-Improvements) - Improving the "Style & Formatting" sidebar tab
* ...

* Bug 89829 - Updating character style to match selection does not remove direct formatting
* Bug 89960 - Suggestion to Change Style Behavior in Relation to Direct Formatting

(In reply to Thomas Lendo from comment #22)
> I want get back to the original idea: If you use a command (e.g. the
> highlight color button in the toolbar) then the "no fill" option should
> delete the whole formatting from the file. 

I surely would welcome this :-). However, no-fill makes in the perspective where the default paragraph including highlighting. Except no-fill does optically the same thing when used at DF highlighted text (with a paragraph style without highlighting set)

And the same problem is also there with bold on/off (DF still present). So in think the original idea isn't working either :-(


So maybe CTRL+M should trigger a dialog to 'remove' DF selectively? And a introduce a new shortcut for remove all? Or the dialog with a new short cut. 

Or any other solution workable :-)

(In reply to Telesto from comment #24)

Now think about this. Apply "Strong Emphasis" character style to text; then press "B" toolbar button.

(In reply to Mike Kaganski from comment #25)

That was in reply to Thomas Lendo from comment #22, sorry.

As I'm not totally happy with the CTRL+M. Even with dialog options to remove selectively, as it doesn't fix the 'core' issue of generating plenty of DF  which can be disabled, an new proposal (only brainstorming).

Formatting toggle buttons (like bold) get visual distinct if activated by PS/CS (which means: where it different from baseline (Untouched/Stock Default PS/CS)
DF is toggle on/off button. So clicking the toggle bold (with default PS) enables bold. Pressing the button again and it disabled (not unbold). If a PS has bold enabled (different from baseline), bold turned on (with indicator being caused by PS/CS). Pressing the activated toggle button causes unbold (DF). 
What should happen in the case of modification; say bold enabled in PS/CS, and disabled in DF and next they PS/CS gets modified (disabling bold) is an open question. I would say removing DF. There is of course the case of a bold PS style with overruling bold CS style. With DF formatting unbolding. So they unbold makes still sense if bold gets disabled at PS level. Or visa versa at CS level. However you could argue people shouldn't use to much DF if relying on PS/CS workflow. As DF not fitting in the paradigm to well. 

Something similar with font, fontsize. Some indicator in DF toolbar that the setting is based on PS/CS (so in essence all the time). Say Liberation Serif*. Next to Liberation Serif* is Liberation Serif (equal to manual; DF). If Liberation Serif* gets modified it will change to new style. If Liberation Serif (without star) it’s DF.

Highlighting. No-fill with PS/CS highlighting activated (so diverging from baseline), causes DF no-fill (overruling PS/CS). In case where PS/CS highlighting is the same as baseline (untouched default style) no-fill means disable highlighting. This would mean you can't set 'no fill' as DF in document before PS/CS has a setting on highlighting set. It's bit pointless to set DF no-fill without PS/CS defining a highlighting.  An additional 'color * should be added) for resetting the highlighting to the original PS/CS style. Say PS has highlighting yellow set. This overruled by DF purple. No you want to go back to PS behavior (no-fill would mean, blank). Clicking yellow would mean manual mode. 
So button inherited is needed. Alternatively this might be done with CTRL+M. Don't think this really common case (but might mistaken)

(In reply to Telesto from comment #27)
> new proposal (only brainstorming)...

Overloading the toolbar with unfamiliar tweaks might not solve the confusion fromn the beginning. It would be helpful for you (and I have to admit it's a tempting idea for me too) but Benjamin has no idea why the bold button becomes "stylish".
But let's do a step more: How about a special deck that gives feedback why bold is set. Maybe with a tree to illustrate the hierarchical relation...

(In reply to Heiko Tietze from comment #28)
> (In reply to Telesto from comment #27)
> > new proposal (only brainstorming)...
> 
> Overloading the toolbar with unfamiliar tweaks might not solve the confusion
> fromn the beginning. It would be helpful for you (and I have to admit it's a
> tempting idea for me too) but Benjamin has no idea why the bold button
> becomes "stylish".
> But let's do a step more: How about a special deck that gives feedback why
> bold is set. Maybe with a tree to illustrate the hierarchical relation...


Benjamin doesn't touch styles, so everything will be the same for him :-). 

So we are already talking about users (Eve) who does use styles. And in the current implementation it's hard to tell if something is a style (say bold by CS Strong Emphasis) or bold DF. You can't see it except, sidebar is at CS styles deck or with Style inspector. 

So bold having a 'stylish' indicator only shows with PS/CS with bold turned on. And as far I'm cornered it's only a dot * in right corner of the bold button (but not a designer).

If you toggle bold to unbold, DF is set overriding PS/CS. If you toggle unbold to bold again DF is removed (which surely an improvement above the current situation) and toggle button will show B*. The indicator is only an aid (it does still work the same). Except if bold being disabled in PS/CS setting bold DF is toggled; and removing it again when untoggled. Visa versa if BOLD being enabled in PS/CS, the bold toggle we be active (with PS/CS indicator aid), pressing it will unbold (with DF). Pressing it again and it's back to PS/CS style (without DF)

The major change would be that when bold (DF) is reverted to unbold, they 'bold' DF gets removed, instead of being changed in an active unbold DF.

And the system pretty idiot proof. There is no change in behavior without indicator. Is only an aid. So if Bold* appears, Benjamin might not know what it means, but shows up right.

Benjamin can even mishmash Liberation Serif* and Liberation Serif (without star) without consequences. Except if he starts formatting with PS/CS. At that point he will notice that Liberation Serif is a manual DF style and Liberation Serif* being automatic style.

The currently situation is worse. Say Liberation Serif is set. You change it to Liberation Mono and back to Liberation Serif. This isn't Liberation serif* (so PS style anymore). It's DF formatting looking like PS style, but without being the case. And even worse, you can't 'return' to PS/CS except by CTRL+M (removing all DF). So it makes for more easier to manage for people who do want to work with styles.

The whole *thing would also by useful for bug 88559 or bug 136433. Those dialogs suffer from the same problem.

So I'm not seeing any usability problem; I certainly don't want more decks :-). CS being on a different deck compared to PS is already an issue :-). Even more flip-flopping around. And doesn't solve the matter of ODT being riddled with DF; nor solves it the 'styles setting problem'.

So this squeezes quite a number of issues. And matches even Thomas Lendo his proposal. No-fill keeps being called no-fill (in both cases). And automatic automatic.. So this in my perspective rather small low key 'tweak' in behavior and rather natural.

Of course the DEV department must be able to implement this. However would love Thomas his view :-)

However, in contrary of what I stated, there is a need for a no-fill alternative for highlighting. Else you can't revert to inherited in the Page Style dialog (in child parent relations) where the child has been changed.. and someone wants to return to 'inherited from parent'.

(In reply to Telesto from comment #29)
> Benjamin doesn't touch styles, so everything will be the same for him :-). 

OMG. How much do people think like that when discussing UX?
Benjamins get documents from anywhere. The documents/templates may get from different sources: co-workers, contractors, gov't sites ... and Benjamins need their work done, without telling them "you can't work on this document until you learn styles". Period.

(In reply to Mike Kaganski from comment #30)
> (In reply to Telesto from comment #29)
> > Benjamin doesn't touch styles, so everything will be the same for him :-). 
> 
> OMG. How much do people think like that when discussing UX?
> Benjamins get documents from anywhere. The documents/templates may get from
> different sources: co-workers, contractors, gov't sites ... and Benjamins
> need their work done, without telling them "you can't work on this document
> until you learn styles". Period.

But please comment on the whole topic instead of quite reading after maybe 'naive' comment. And we should define types of benjamins.. Grandma running LibreOffice twice a month. Something else as Benjamin is working professionally. Not sure if UX has the typology say 40 type of users with background story? Would make it easier to for see problems. My quote makes "sense" for Grandma. Or at least in my view. Or all other users who use LibreOffice as Wordpad equivalent. 

The current implementation is also "half-baked" IMHO (see also bugs floating around) which raises the same question. OMG, who invented this. Have the actually tried to use it heavily? It simply unnecessary hard to work with (if you ask me).  

BTW, it's also hard to where somebody stands. Is he agreeing of an usability issue being present (or does he actually not see any problem with the current implementation at all (but simply shooting at the solution). Or *only* disliking the solution, but acknowledging something being off.

The next topic being 'what's wrong'. So document riddled with DF styles (as Thomas stated). Or a GUI issue (able to separate DF from CS/PS). Or parent/child inherit relation not being noticeable.  Or no way to revert back to "no DF"

And if you 'only' dislike the solution. Please explaining where the pain is. Confused user? or development/ maintaining issues. Also some different suggestions would be nice if you only object against the suggestion. If you like the current implementation, please say so & with some arguments.

As said 'there' is no 'effective' change'. So everything is working as before. Except there is font* fontsize*. bold* italic* underline*. You can actually don't show for bold/italic/underline/highlight or no fill and it would still work the same (for superficial standpoint of view)

(In reply to Telesto from comment #29)
> I certainly don't want more decks :-)

It was meant as subtle hint how we solved the issue: with the Styles Inspector deck listing the changed attributes.

(In reply to Heiko Tietze from comment #32)
> (In reply to Telesto from comment #29)
> > I certainly don't want more decks :-)
> 
> It was meant as subtle hint how we solved the issue: with the Styles
> Inspector deck listing the changed attributes.

Didn't get that; obviously. But still, how do you search a whole document filled with 'actual needed' and unneeded DF. Walking a 200 pages text line by line? I personally prefer to avoid a document being riddled by DF advance. Especially if it can be prevented rather easily (if you ask me). It's certainly not obvious bold toggled on and off again does result unbold DF instead of disabled bold DF

The current design makes it unnecessary hard to manage DF/styles. Or to even correct mistakes.  

So I don't see the The Inspector as a solution the problem at hand. Say PS is unbold.. you have to walk through the whole text to find snippets with unbold DF. If toggling bold of would remove the DF, you simply no need to search for 'unbold DF'. Or no-fill highlighting. Removing herculean task. It's would also make it more noticeable of someone used Strong Emphasis CS with Italic DF or say bold + Italic or Emphasis CS with bold DF (even without Styles CS dialog open or Style Inspector deck). 

The toolbar "notification" might be the reason to look at they Style Inspector (to see what's going on)

FWIW: only giving my view. Currently I seeing more advantages as objections. I'm  maybe biased as I propagate something.. But propagating and being devils advocate at the same time rather hard

-> OMG. How much do people think like that when discussing UX?
For the record, this happens far more often than you think. Maybe not saying it out loud, but in the meantime.. Discussions are not clear. They Adam/Eve/Benjamin persons are not defined. Even the workflow scenario's not being written out. So it's hard to know what a Benjamin looks like. So my representation of Benjamn is different compared to yours. And my Benjamin is also bit unstable personality, I tend to bend him around into making my point. 
There are people dedicated to UX as a profession (so surely not simple) 

Also the argument of not being used is used pretty often. I complained about 'core' stuff being broken, dismissed by not used by not a problem for the general user. They use Writer at Wordpad level. Which of course ends up with the question why did you implement it in the first place. Take track & Changes or table styles. 

Where we end up who is the actual audience etc.. What the intended user. So we land in the area of the Business Plan, Marketing Plan. Project/Product vision etc. The define the target user. TDF public might be somewhat different compared to they targeted eco-system partners public (yes, of course there is overlap). As there is no single public (there simply different groups of users). For Writer itself, and even for the Office Suite as such. A group mostly uses Calc, Calc being utmost important. Say they use Pivot tables all day. Others use mostly Writer (being the utmost important part). Others are designers using Draw.. 

Going into off topic mode
There are reasons for it of course. Table styles being outdated.. not maintained in years. So GSoC project to make more modern. However underestimated the complexity etc. so GSoC ended, but the table style project wasn't finished. So 'half-baked' table styles implementation even more prominent in the dialog, but not working properly. A topic of awful code; no budget; no developer responsible; no customer paying. LibreOffice being a project (not product) (so nobody has to look at it). So everybody looking in another direction. If you start 'pushing' it becomes a pet bug. Or do it your self project. 
 
I still think there is a need to get certain bugs/flaws/limitation on an agenda under the heading (UX) Quality Assurance (Committee). To prioritize (and order) certain 'core' issues (UX/bugs). Ideally with 'some budget' or lobbying power to get certain things done. So a bit more coordinated approach structuring priority's instead of 'fixing' bugs at random (it's likely more nuanced). Or waiting until for some magic reason it gets attention (say paying customer).
As they bug tracker is slightly to large having the oversight of what's seen as  more important and less important (or large/smaller in scope). So Committee is more or less intended to show certain things are on the table somewhere (instead of drifting in a large bug tracker).

The (TDF QA/UX) Committee wouldn't replace the current way of working, but more an addition. to monitor progress on certain flaws and raise attention once in a while (and doing some lobbying as it know to channels to do that). So more somewhat like MAB. [Likely wishful thinking; proposing is a lot easier compared to doing]

(In reply to Telesto from comment #31)
> (In reply to Mike Kaganski from comment #30)
> 
> But please comment ...

No, your expectations on what I should or should not are unreasonable. While I assume your attitude ("I know there's a problem, and *there MUST be a proper way* better than this, just because my workflow seems sub-optimal", and also "I am sure I can be productive without thinking of the possible problems, and so without learning") to be generally wrong, I don't mind if there is a discussion and possibly some (hopefully good) result. But that doesn't mean that I should spend much time on this, other than block outright bad options.

(In reply to Telesto from comment #33)
> ... how do you search a whole document filled with 'actual needed' and 
> unneeded DF. Walking a 200 pages text line by line?

That's the use case of "Where is a certain formatting" while the Styles Inspector addresses the "Why is the text formatted in a certain way", which is the question here. The "find me all DF" ticket and similar are discussed in the blog post that lead to the SI where we didnt find a student for the second part (Styles Highlighter). 

"Highlighting no fill is not the same as no fill" this is wrong => NAB
It's also wrong to remove a formatting by unsetting it => WF
Removing individual attributes is requested somewhere else => DUP
Your idea of showing overridden attributes might work but we decided to go with the SI that also has many more advantages

Bug 134554 comment 11 (Luke Kendall)

Am I right in thinking that if I use Ctrl-I to directly format a word, and then at the end of the word use Ctrl-I again to (from the naive user's perspective) toggle back to regular style, that instead DF is still "turned on"?  In other words, that I'm kind of in a DF 'mode'?

If that's the case, it would explain why massive sweeps of text in my books (and perhaps many other users' documents), are directly formatted.

If so, should I submit an enhancement request?  It seems a huge usability trap to mark all subsequent text as DF just from turning on italics and then (*apparently*) off via an apparent toggle, instead of knowing and remembering to clear the 'hidden mode' via a Ctrl-M.

It was only just now that this possibility dawned on me, even though I've been 

----
-> ouch (didn't even realize that; but not funny IMHO)

Let me try to express it another way.

People who try to show this behaviour as a bug are trying to think about document structure when working with DF. This is a nonsense, and they trying to display it as "Benjamin's" problem is absolutely wrong. They declare Benjamin as someone who is thinking about structure (see comment 36 - "to (from the naive user's perspective) toggle back to regular style"); they try to split Benjamins into sub-types (see comment 31 - "And we should define types of benjamins.. Grandma running LibreOffice twice a month. Something else as Benjamin is working professionally. Not sure if UX has the typology say 40 type of users with background story?").

But this is just wrong. DF is not about (even naive) ideas about document structure (styling, or internal representation); Benjamin is not about backgrounds, professional vs home, or even not using styles. Benjamin is a person who may have whatever end goal or background; they use whatever tools are there in the UI, but the big difference from Eve is that *they don't know or think about structure*; they use the tools to express *immediate wish* to change something to look as they want. DF must make that immediate idea happen: "from now on (or for this selection) I want it to be bold"; "from now on I want it to be not bold", etc. No more involved thinking here: just "make it look as I want it". If a tool is doing what Benjamin wants, they use the tool; so that may use styles (e.h., paragraph styles from the toolbar drop-down) without thinking about structure. They may know that Heading 1 makes it large and bold, and they only think about this formatting when use that tool, making something bold and large; then they see that more than few words in the sentence become bold, and use toolbar "B" button to make the rest of the sentence not bold; and that must work for them in the way they expect - even though that workflow is creating a mess of a structure. And that means that DF must be robust and efficient in making unconditional changes: "not bold" or "not italic" must mean "not bold *unconditionally*, no matter what", not "not bold *unless* there are some things that Benjamin doesn't care or realize even existing, like styles and their inheritance and structure and anything".

What Telesto and Luke are talking about is a bad mix of using DF and caring about document structure. Document structure is *not* possible to use when using DF, ever. Styles are for that.

That said, I am all ears about good proposals to make DF better in that regards; but *any* such proposal *must* take into account *real* Benjamins - see above - not those chimeras that Telesto and Luke are talking about, in the first place: i.e., every such proposal must keep real Benjamins safe to keep using those DF tools (mixed with styles used unconsciously, or coming from outside) to make their work done, simply by pressing a toolbar button over a selection or in a current position, and have the rest *look* as expected, without caring about internals.

In other words, Telesto and Luke show this:

"At first, I was a very basic user. I used DF, without any consideration of document complexity; it was enough for my simple needs then. I grew some habits then; and of course, I got used to use DF tools.

Now I grew to see shortcomings of the tooling I use. I started to realize importance of some aspects that I was not aware initially; I now care about structure of my documents.

But being a naturally lazy person, I dislike the idea to change my habits. I prefer my tooling to stay, just change with myself; I now want to make those same tools that I was using when was doing it simple, to follow my growth of understanding, and now start doing something different.

And since I might even not realize the change in my own perception of the problem (caused by my new experience and knowledge), I might not realize that my proposals would break my old workflow - i.e., it would disallow me doing what I did back then, when I didn't have that experience and knowledge.

So instead of becoming Eve by learning the toolset created specifically for those who grow to realize shortage of DF, I want DF to become style-like."

Typed 'before' the collision 

(In reply to Mike Kaganski from comment #37)
I'm still trying 'grasp' the whole thing you're saying :-). Heiko uses stereotype users once in a while to make an argument. In this case you have people using Default PS styles (their is the default style & default style for footer, which are set automatically) and are adjusting everything to their needs using DF. There is also a group who tends to avoid DF as far as possible and create the formatting they want with PS/CS.

If someone who avoids DF as far as possible to somebody who get is work done with DF, you get a nice mess. 

There are 'to cases'. 
* DF formatting while typing. Turning bold on (CTRL+B) starting typing, Unbold (Press CTRL+B) keeps going on with DF unbold (instead of disabled)

* DF at the end. Selecting a line of text, pressing bold/ followed by unbold. (Text looks back to PS style, but it's actually DF).

Practice is of course that both are done together. Also there are plenty of ways how DF can be introduced (say copy/paste RTF/HTML). You disable it in the toolbar, but still DF formatting being present. 

Negative effects:
* The document being riddled with (function-less; and likely even unintended)DF formatting in the XML (Thomas Lendo). This is not a visible problem; but plays in the background.
* The ideal of quick Styles changes is practically undone in real life. You have to use the a Style Inspector/Style viewer the get rid of the evil. Not as small clean up, but as a Herculean task. So the advantage of PS is nearly gone.

-- 
The whole point is, unbold DF is invisible/pointless in an unbolded paragraph style. Similar as no-fill is being pointless in a not-highlighted text. This becomes only noticeable after PS change. Or walking through they document with Style Inspector.

I'm still not exactly clear to me in what pitfall i'm trapping. Where the 'bad idea' begins.. Following are examples i used.

1. Press CTRL+B
2. Type AAA
3. Press CTRL+B: result DF unbold for the up following text. Expected bold disabled
4. Select AAA; press unbold again. Expected bold DF formatting removed of the area AAA. Actually: unbolded (DF)

New document
1. Default PS Style -> Modify -> Font -> Enable Bold
2. Type AAA
3. Press CTRL+B: result DF unbold for the up following text (fine)
4. Select AAA
5. Press CTRL+B again: result DF bold for AAA. Expected: Removal of the unbold DF

So they only thing I said was; if PS is unbolded, Pressing CTRL+B enables bold; Press CTRL+B again and it get turned off, instead of unbold. The result will be the same as always. This is only relevant for PS/CS

The question is of course what should happen here:
1. Open new document
2. Type AAA [SPACE] [CTRL+B] BBB [CTRL+B][SPACE] CCC
3. Default PS Style -> Modify -> Font -> Enable Bold -> what should happen with DF formatting here. 
A) Nothing
AA-> What happens when selecting AAA and pressing BBB here (removal of bold or unbold?). Naturally would be unbold.
B) Inverse (unbold)
C) DF should get removed (seems easier, but what if people messing around. So enabling bold.. applying and resetting it to regular.. The DF would be gone. Undesired, IMHO

I might have missed something; however I'm not seeing a clear issue with this approach. Where this doesn't deliver the expected results. 

BTW, you might be misconceived by they way i presented this. I'm fan of getting things done; I'm surely not structuring my formatting in advance. So I surely don't think in document structures (i'm would even declare myself a Benjamin user who wants to desired result on screen without caring about technicality's ). Or advanced knowledge of styles. 

The problem 'started' at the point where you want to try PS/CS. It simply doesn't work because the document is riddled with DF. Which couldn't see in advance (yes you can now). And the hidden DF isn't intended nor needed. 

I read the same problem n Luke & Thomas their comments. However, this plays not only for simple toggle button.. but is also the case with font/ font size drop down or the highlighting/font color. And those need slightly different modification to get the same result as with the bold toggle button.

(In reply to Mike Kaganski from comment #38)
> Now I grew to see shortcomings of the tooling I use. I started to realize
> importance of some aspects that I was not aware initially; 

Trye

> I now care about structure of my documents.
Depends on what you mean with structure. I'm very sloppy PS/ CS style user :-). 

> But being a naturally lazy person, I dislike the idea to change my habits. I
> prefer my tooling to stay, just change with myself; I now want to make those
> same tools that I was using when was doing it simple, to follow my growth of
> understanding, and now start doing something different.

I prefer to grow gradually, instead of a disruptive switch. I'm working with DF formatting.. And start to play with Styles. And this working so nicely, so a start using Styles even more. However the reality is that document is riddled with unnoticable DF formatting (they bold button turned off suggested Direct formatting is turned off. Currently it means: bold button turned off could mean: A) there is no DF formatting at all or B) there is DF, namely unbold. They problem: A you can't tell. B) it's intervening with usage of styles in an unproductive manner. 
 
> And since I might even not realize the change in my own perception of the
> problem (caused by my new experience and knowledge), I might not realize
> that my proposals would break my old workflow - i.e., it would disallow me
> doing what I did back then, when I didn't have that experience and knowledge.

I certainly want to do what I did back then.. i'm surely not 'converted' to a PS/CS user. The OLD DF work-flow must stay as it is :-). They only thing I want is to make the switch between DF and PS/CS easier without any change to the DF experience. Which is the case.. They only group who is affected are PS/CS users who press CTRL+B (2x), because the might want to change the PS/CS style to BOLD in the feature, but the text in question should be unbold in any case.

However this never worked.. As unbold text means, DF unbold in the whole document (as Luke pointed out)

Your idea "let's "B" behave conditionally depending on where it is used" will make behaviour of the result very confusing for Benjamin.

He has some text, where some parts are bold - because of DF on char level; some parts bold from DF on paragraph level, some parts bold from styles - both character and paragraph.

He uses the same "B" tool to make it not bold. Currently, this applies "no bold" explicit attribute in all these cases. You suggest to make the result conditional, making those places that were bold because of character-level DF to simply loose "bold" attribute; so your suggestion would make new non-bold parts being different - some having explicit "non-bold" attribute (where that is above e.g. paragraph-level formatting), some no bold attribute at all.

Then user copies and pastes the text to new places - say, where paragraph defines bold attribute. The texts - that user formatted the same way, unpressing "B" - start behaving differently. This is unexpected, and *breaks workflow of Benjamin*, who is the intended audience of DF feature. No matter how would it benefit users like you, who cares about document structure (yes, I mean it in broad sense: styles are just the way to express the structure in LibreOffice; users first start to realize that their documents have structure, then learn that the structure can be defined using styles).

Created attachment 165712 [details]
Example file

(In reply to Mike Kaganski from comment #41)
> Your idea "let's "B" behave conditionally depending on where it is used"
> will make behaviour of the result very confusing for Benjamin.
> 
> He has some text, where some parts are bold - because of DF on char level;
> some parts bold from DF on paragraph level, some parts bold from styles -
> both character and paragraph.

-> Some parts bold from DF on paragraph level; Is this possible? PS affect the whole paragraph?
> 
> He uses the same "B" tool to make it not bold. Currently, this applies "no
> bold" explicit attribute in all these cases. You suggest to make the result
> conditional, making those places that were bold because of character-level
> DF to simply loose "bold" attribute; so your suggestion would make new
> non-bold parts being different - some having explicit "non-bold" attribute
> (where that is above e.g. paragraph-level formatting), some no bold
> attribute at all.

I dislike using 'conditional' without explicit context. It's rather confusing


1) The paragraph formatting pretty conditional. Copy/paste text with default PS to a different paragraph with Preformatted Text. Formatting will change :-)

2) DF isn't even conditional all the time in my model. Say, select a line of text & press bold. Now change page style and apply bold. The 'bold' of the DF isn't gone. 

3) Open a document, select a part of the text. Press CTRL+I. Now go to sidebar styles - cs -> Apply Emphasis. The direct formatting is gone and replaced with CS. 

4) Open the attached file. Select the first three lines and drag after sidewalk (bold bottom). A part won't be highlighted (because of DF unbold present). This Benjamin doesn't like that either. 

5) Open the attached document, Select the first 3 sentences. Sidebar -> Styles -> CS style emphasis (strong emphasis disappears) because based on CS style (not DF) [bit off topic, but you simple can't tell the difference on screen]

6) Open the attached file, Select "That didn't bode well." press bold toggle button (unbold) and again (bold). They CS style is still set (see sidebar cs styles), they layout still matches CS (but is ruined by DF).  

So I don't see the 'current' implementation not having the same deficit, as 'expected' of mine. The issue is already present. And as far I concern even more obvious. Because using DF somewhere in the text and go on typing.. it the whole text gets DF (example of Luke). 

So if i'm weighting the 'downsides' of the current implementation. Compared to the downsides of my proposal, I assume a 'win' situation. Yes, there will be formatting issues. But this is the case already; so nothing new on the horizon, IMHO. Layers of formatting is per definition hard to follow :-). A reason for me simply avoid CS styles. I'm able to follow the concept of PS + DF. Adding CS to the mix, and i'm out (as I really don't know where the formatting is coming from. Because it matters in which order the stuff gets applied. Italic DF gets removed by CS Emphasis etc 

Again, based on what I can see. Quite a number of variables. They styles hierarchy, order of applying formatting. Copy/paste etc. So might overlook the obvious? So would love some STR's where this works worse (compared to current case). Based on what I see I assume the current way of doing things is even more prone to formatting surprises for Benjamin (as long as modified styles are involved). Without deviating styles present, this not interesting at all.

The whole advantage of 'quick' changing formatting is pretty ruined by the DF debacle, IMHO. And pretty unnatural. BOLD toggled off but still being on etc. 

But I must admit, I mostly discover the flaws/ thinking mistakes after the fact.. When playing around etc

(In reply to Telesto from comment #42)
> 1) ...

tl;dr - but anyway: *if* you see current implementation of a feature targeted at Benjamin to already create problems to Benjamin, this is *not* a permissions to create other problems to Benjamin, but to fix existing problems in a way that is, again, targeted at Benjamin, not at you.

(In reply to Telesto from comment #42)

And now, that I have checked your steps: again, no. You are comparing oranges to apples.

You are writing about problems that Benjamin sees when working (a) with data coming from others - using styles; (b) using styles (we assume that Benjamin does that cluelessly). And those problems are absolutely unavoidable. You can't make Benjamin not have those in one way or in another.

What I was talking about is consistency of Benjamin's work when he *uses the tools designed for him* - i.e., using DF. He might have someone other's document, and see something unexpected/unexplainable to him there; he might use styles (tools not designed for him) and see something unexpected/unexplainable; but he needs a set of tools (DF) that *he* applies, and *then* he sees consistent results.

(In reply to Mike Kaganski from comment #43)
> (In reply to Telesto from comment #42)
> > 1) ...
> 
> tl;dr - but anyway: *if* you see current implementation of a feature
> targeted at Benjamin to already create problems to Benjamin, this is *not* a
> permissions to create other problems to Benjamin, but to fix existing
> problems in a way that is, again, targeted at Benjamin, not at you.

No, this of course not intended argument for a change. And yes, I know people can twist and turn arguments around, to get something 'through' for their own preference for (very) wrong reasons. 

However, I'm attempting to put you're argument in perspective. You have a very strong argument if it would work perfectly without a change.. and be broken afterwards.

However this isn't the case. I'm only stating the the issue is already present, so to objection 'Benjamin' getting some formatting problem isn't saying that much. This is inherit to the whole DF/PS/CS system. 
So my target is it must at minimum not become worse for Benjamin, compared to the current situation.. in the overall outcome. Not on single cases basis. Their could be some 'drawbacks'. If they overall count is positive (in the most common cases) I call it an overall improvement.

So yes, if any 'regression' is an objection.. development would come to an halt. 
Replacing problems isn't desired. However in this case they general outcome is for the better.. So the solution isn't perfect. But the whole PS/CS/DF system isn't perfect. As long as Benjamin isn't worse off in overall experience (and common cases); it's acceptable to me. So opting for the "Utilitarianism" view. The 'great good'. However I don't think it's that binary (lose-win). Benjamin will profit from this too.

Using styles with DF everywhere makes using styles pretty useless. And it's simply confusing. I'm still having issues with wrapping my mind to it. 

I currently don't see an major case, where the behavior substantial different. I tried to follow you're steps, but I don't notice the issue. 

So for the record:  I'm not trying to get my wishes implemented of the back of others. And making others worse of. I actually don't care that much (and Office suite is an commodity, there are alternatives). I'm only pointing out a topic, which I have struggled with a long long time. And I simply don't get.  Luke made it even more clear to me why this is simply not working. 

I'm not a heavy user. I'm only give my opinion based on what I have noticed. However, you should ask people who actually are correcting formatting and how often they need to do that. And if this a cumbersome job etc. 

I'm more they type of experiments.. Worse what can happen is a 'revert' (and some wasted time/ money developing it). However we get feedback/ and data/ experiences. Not that ever idea has to become an experiment.. arguments are fine.. but some point 'experiences' matter. 

So main question is what are the 'cost' / (expected) benefits. This look like a 'small' change to me. However the simple things are mostly more complex :-(.

Without change their is no progress :-). Again not invitation to 'change everything all the time'. However also not a fan of long term doing nothing strategy. They Ribbon is more or less a success after all. Similar to they Windows 8.0 start menu debacle (which worked fine on tables/phones). It implemented differently now day's but has still reminiscence of that time. 

For the record, I love a large audience. To get so more insights/ perspectives/ visions etc.  

(In reply to Mike Kaganski from comment #44)
> (In reply to Telesto from comment #42)
> 
> And now, that I have checked your steps: again, no. You are comparing
> oranges to apples.
> 
> You are writing about problems that Benjamin sees when working (a) with data
> coming from others - using styles; (b) using styles (we assume that Benjamin
> does that cluelessly). And those problems are absolutely unavoidable. You
> can't make Benjamin not have those in one way or in another.
> 
> What I was talking about is consistency of Benjamin's work when he *uses the
> tools designed for him* - i.e., using DF. He might have someone other's
> document, and see something unexpected/unexplainable to him there; he might
> use styles (tools not designed for him) and see something
> unexpected/unexplainable; but he needs a set of tools (DF) that *he*
> applies, and *then* he sees consistent results.

Please give one or two concrete STR examples which you have in mind where this would occur; instead of general notion "He might have someone other's document, and see something unexpected/ unexplainable to him there". 

Not because I want to be annoying or keep you busy. I simply not able to come up with a clear cut case where this is obviously be problem. A case where Benjamin would struggle more compared to the current implementation. There might be; and my thinking might be flawed... however I simply don't see it. 

I only read about 'concerns'. That they Benjamin should be able to do is job with DF is a of course valid argument. However need some 'proof' of actual cases where they issue is actually demonstrated. Based on your statement this is pretty obvious problem (and I'm feel pretty stupid not noticing it). So please help me understand me with one or more examples.. 

More effective compared to say i'm comparing apples with oranges.. except explaining the difference between them. I'm might be that I'm one on those blind men: https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
 
For the record: I don't propose 'merging' formatting if DF and PS/ CS are the same. So If I apply bold to some text and set PS style to bold, the DF bold stays. If I apply DF bold, Change the PS to Bold.. and UNBOLD a certain area.. The Unbold formatting; stays.

If in the case where PS style is bold, CS style normal, and DF bold nothing changes

This in different in the case where BOLD DF is present, and overruled by CS including bold (but that's not different from today).

Created attachment 165739 [details]
A sample with some bold text

(In reply to Telesto from comment #45)

The attached document contains four sample lorem ipsum paragraphs, followed by two dummy text paragraphs.

The first sample paragraph uses "bold" PS. The second one has one sentence using "bold" CS. The third one uses paragraph-level direct bold formatting. The fourth one has one sentence with character-level direct bold formatting.

The first dummy text paragraph has Default PS. The second one has "bold" PS.

The scenario is that a Benjamin gets this document, and needs to work with some formatting.

Initially the demo of natural, fundamentally unavoidable problem that Benjamin sees when working with the document. We copy a single bold word from sample paragraphs into *non-bold* dummy paragraph.

1. Select "ipsum" (double-click it) in the first paragraph, Ctrl+C, click between "He" and "heard" in the first (non-bold) dummy text paragraph, Ctrl+V.
2. Select "nec" (double-click it) in the bold sentence of the second paragraph, Ctrl+C, click between "heard" and "quiet" in the first (non-bold) dummy text paragraph, Ctrl+V.
3. Select "velit" (double-click it) in the third paragraph, Ctrl+C, click between "quiet" and "steps" in the first (non-bold) dummy text paragraph, Ctrl+V.
4. Select "cursus" (double-click it) in the bold sentence of the fourth paragraph, Ctrl+C, click between "steps" and "behind" in the first (non-bold) dummy text paragraph, Ctrl+V.

This shows that the first bold word became non-bold when pasted to the target. That is because paragraph styles are in play here; the copied word does not bring its source paragraph's style to the target, and takes formatting from the style of the target one. Benjamin has no clue why; that's a natural confusion (he operates text created by someone else, using tools unknown to him, with concepts unknown to him). This is not a bug, and should not change.

Now let's see how this changes when Benjamin starts using *his* tools. Let's copy the same four words into the second dummy text paragraph (the bold one), but first make each word not bold prior to copy.

5. Select "ipsum" (double-click it) in the first paragraph, Ctrl+B, Ctrl+C, click between "He" and "tried" in the second (bold) dummy text paragraph, Ctrl+V.
6. Select "nec" (double-click it) in the bold sentence of the second paragraph, Ctrl+B, Ctrl+C, click between "tried" and "to" in the second (bold) dummy text paragraph, Ctrl+V.
7. Select "velit" (double-click it) in the third paragraph, Ctrl+B, Ctrl+C, click between "to" and "nervously" in the second (bold) dummy text paragraph, Ctrl+V.
8. Select "cursus" (double-click it) in the bold sentence of the fourth paragraph, Ctrl+B, Ctrl+C, click between "nervously" and "tap" in the second (bold) dummy text paragraph, Ctrl+V.

The Ctrl+B step makes the selected text explicitly non-bold *in all cases*. Benjamin may be sure, that no matter what magic was used to create the text that he is facing, he may use this tool, and the text after that tool will behave consistently with his expectations: it will be non-bold, no matter where it arrives.

For comparison, let's see what would happen if, instead of applying explicit non-bold attribute, Ctrl+B would just clear (remove) bold attribute in the fourth sample paragraph (from where we have copied "cursus"). The first sentences of the fourth paragraph don't have the explicit non-bold attribute, so words in those first sentences are the perfect example what would result from your proposal.

9. Select "ipsum" (double-click it) in the non-bold first sentence of the fourth paragraph, Ctrl+C, click between "nervously" and "tap" in the second (bold) dummy text paragraph, Ctrl+V.

I.e., if Ctrl+B in the fourth paragraph would just clear the bold attribute, then Benjamin would face the situation, that after using a tool "B" he would still have the result behave unexpectedly/unexplainably to him (you can't explain this behaviour unless you understand styles).

So the current status is:

 - Benjamin might have some difficulty working with other's documents (or after using advanced tools cluelessly); but there are tools that he may use, to get a simple behaviour expected by him.

Your proposal is:

 - no matter what tool Benjamin would use: without understanding of styles, the behaviour of the result of *his* actions would still behave unexpected to him.

(In reply to Mike Kaganski from comment #46)
> 9. Select "ipsum" (double-click it) in the non-bold first sentence of the
> fourth paragraph, Ctrl+C, click between "nervously" and "tap" in the second

must had been "between "tap" and "sodales"

> (bold) dummy text paragraph, Ctrl+V.
> 

Here I omitted the observable result: the non-bold word (which, as we imagine, was explicitly made not bold by Benjamin prior to copy) became bold after arriving into the target paragraph.

> I.e., if Ctrl+B in the fourth paragraph would just clear the bold attribute,
> ...

Created attachment 165744 [details]
Example file

(In reply to Mike Kaganski from comment #46)
> Created attachment 165739 [details]
> A sample with some bold text
> 
> (In reply to Telesto from comment #45)
> 
> The attached document contains four sample lorem ipsum paragraphs, followed
> by two dummy text paragraphs.
> 
> The first sample paragraph uses "bold" PS. The second one has one sentence
> using "bold" CS. The third one uses paragraph-level direct bold formatting.
> The fourth one has one sentence with character-level direct bold formatting.
> 
> The first dummy text paragraph has Default PS. The second one has "bold" PS.
> 
> The scenario is that a Benjamin gets this document, and needs to work with
> some formatting.
> 
> Initially the demo of natural, fundamentally unavoidable problem that
> Benjamin sees when working with the document. We copy a single bold word
> from sample paragraphs into *non-bold* dummy paragraph.
> 
> 1. Select "ipsum" (double-click it) in the first paragraph, Ctrl+C, click
> between "He" and "heard" in the first (non-bold) dummy text paragraph,
> Ctrl+V.

PS bold; pasting into PS Default. Result: unbold

-> Confusing for Benjamin. He pasting bold text to different paragraph, and suddenly becomes unbolded. What the...
Wouldn't change with the different model

> 2. Select "nec" (double-click it) in the bold sentence of the second
> paragraph, Ctrl+C, click between "heard" and "quiet" in the first (non-bold)
> dummy text paragraph, Ctrl+V.

PS default; DF bold. Pasting into PS default; without DF.
Result BOLD paste. However would be unchanged

> 3. Select "velit" (double-click it) in the third paragraph, Ctrl+C, click
> between "quiet" and "steps" in the first (non-bold) dummy text paragraph,
> Ctrl+V.

PS default; DF bold. Pasting into PS default; without DF.
Result BOLD paste. However would be unchanged


> 4. Select "cursus" (double-click it) in the bold sentence of the fourth
> paragraph, Ctrl+C, click between "steps" and "behind" in the first
> (non-bold) dummy text paragraph, Ctrl+V.

PS default; DF bold. Pasting into PS default; without DF.
Result BOLD paste. However would be unchanged

> 
> This shows that the first bold word became non-bold when pasted to the
> target. That is because paragraph styles are in play here; the copied word
> does not bring its source paragraph's style to the target, and takes
> formatting from the style of the target one. Benjamin has no clue why;
> that's a natural confusion (he operates text created by someone else, using
> tools unknown to him, with concepts unknown to him). This is not a bug, and
> should not change.
> 
> Now let's see how this changes when Benjamin starts using *his* tools. Let's
> copy the same four words into the second dummy text paragraph (the bold
> one), but first make each word not bold prior to copy.
> 
> 5. Select "ipsum" (double-click it) in the first paragraph, Ctrl+B, Ctrl+C,
> click between "He" and "tried" in the second (bold) dummy text paragraph,
> Ctrl+V.

PS bold. DF unbold after pressing CTRL+B. Pasting into PS Bold

Result unbold (difference).

->


> 6. Select "nec" (double-click it) in the bold sentence of the second
> paragraph, Ctrl+B, Ctrl+C, click between "tried" and "to" in the second
> (bold) dummy text paragraph, Ctrl+V.

PS Default; DF Bold. Switching to unbold. Pasting into bold PS. Result: unbold.
In make case bold would be turned off

> 7. Select "velit" (double-click it) in the third paragraph, Ctrl+B, Ctrl+C,
> click between "to" and "nervously" in the second (bold) dummy text
> paragraph, Ctrl+V.

PS Default; DF Bold. Switching to unbold. Pasting into bold PS. Result: unbold

= Change would mean. Bold paste, instead of unbold


> 8. Select "cursus" (double-click it) in the bold sentence of the fourth
> paragraph, Ctrl+B, Ctrl+C, click between "nervously" and "tap" in the second
> (bold) dummy text paragraph, Ctrl+V.

PS Default; DF Bold. Switching to unbold. Pasting into bold PS. Result: unbold
= Change would mean. Bold paste, instead of unbold

> 
> The Ctrl+B step makes the selected text explicitly non-bold *in all cases*.
> Benjamin may be sure, that no matter what magic was used to create the text
> that he is facing, he may use this tool, and the text after that tool will
> behave consistently with his expectations: it will be non-bold, no matter
> where it arrives.

True;

> For comparison, let's see what would happen if, instead of applying explicit
> non-bold attribute, Ctrl+B would just clear (remove) bold attribute in the
> fourth sample paragraph (from where we have copied "cursus"). The first
> sentences of the fourth paragraph don't have the explicit non-bold
> attribute, so words in those first sentences are the perfect example what
> would result from your proposal.


> 9. Select "ipsum" (double-click it) in the non-bold first sentence of the
> fourth paragraph, Ctrl+C, click between "nervously" and "tap" in the second
> (bold) dummy text paragraph, Ctrl+V.

Default PS; pasted in Bold PS. Inheriting formatting

> 
> I.e., if Ctrl+B in the fourth paragraph would just clear the bold attribute,
> then Benjamin would face the situation, that after using a tool "B" he would
> still have the result behave unexpectedly/unexplainably to him (you can't
> explain this behaviour unless you understand styles).

Created attachment 165712 [details]
Example file

Open the attached file. Select first paragraph. Drag or copy past it after the bold paragraph. Result: That didn't bode well. is unbolded because DF unbold.

> So the current status is:
> 
>  - Benjamin might have some difficulty working with other's documents (or
> after using advanced tools cluelessly); but there are tools that he may use,
> to get a simple behaviour expected by him.


> 
> Your proposal is:
> 
>  - no matter what tool Benjamin would use: without understanding of styles,
> the behaviour of the result of *his* actions would still behave unexpected
> to him.

------------------------------------------

> This shows that the first bold word became non-bold when pasted to the
> target. That is because paragraph styles are in play here; the copied word
> does not bring its source paragraph's style to the target, and takes
> formatting from the style of the target one. Benjamin has no clue why;
> that's a natural confusion (he operates text created by someone else, using
> tools unknown to him, with concepts unknown to him). This is not a bug, and
> should not change.

I really don't understand how 'this' is accepted.. And 6-9 which in effect is about the same thing, not. And even worse, if Benjamin even expects styles to be inherited, but it's not the case because some 'DF unbold' is floating around (Luke Kendall)

So yes, the downside is that Benjamin will lose unbold text. But this is also happening when moving PS bolded text to unbolded PS text. 

And tri-states (off, unbold, bold) is harder to 'grasp' compared to bold (on) bold (off). 
It's easy to solve with Benjamin tools (and even rather easy to explaining; I think).

I still think it's evil trade-off. Especially with copy from style to another cases formatting changes being acceptable. So in essence exact the same thing. Also needing the same background knowledge about styles. I really don't see the difference. Instead of 'being consistent' we make an exception in the logic behave of Benjamin. 
* Which makes the logic of the concept harder to grasp. It's pretty straight forward without. 
* They issue occurs in the opposite direction. So partly unbold DF text in unbolded PS style.. pasting to different page style
* It makes the learning curve for styles harder (he starts making changes to style but with not desired effect with DF unbold floating around in unbolded PS). 
* Creating all sorts of untended side-effects for people who try to be style conformant
* Ruining the whole concept of quick in easy style changes (for the "advanced" user). 
* People having herculan task to clean up certain documents 
* We already in the area where PS styles are actively modified. 
* We pretend every thing is happening same level. So toolbar highlights 'bold' independent of the source (PS/CS/DF). Which is making the communication about 'styles' and the working any easier. Even I press CTRL+B at Strong Emphasis Bold, because I can't see the difference between DF Bold or CS Bold. Page Styles are of course more obvious.
* They ODT get riddled with unnecessary DF formatting

So they current approach is - no offence - over-complicating things massively; IMHO. No, I don't have years of experience in teaching LibreOffice. However I do like programs which are design you 'learn' they workflow also in a natural way. And exceptions 'on rules' don't make it easier. And not being able to turn off DF after enabling simple unexplainable.  

And here I land into they UX-principles
ux-error-prevention -> Nope the whole document is riddled with unintended!! formatting as BOLD toggle off isn't equivalent to OFF; Worse it can't be turned off (
ux-implementation-level -> this works both ways. Currently Benjamin also Eve has to cope with the problem. Or put it differently; even with knowledge about styles the experience is still ruined
ux-control -> If I turn on DF, you can't turn it off again!


UX-feedback -> Nope. The formatting toolbar highlights without indication of the source of the formattting
ux-discovery -> Discovering the system is hard, because of exception in the rule which should make it easier for n00b Benjamin (questioning if this is actual the case) but will eventually hinder his progress in understanding the program in depth. And if he managed that hurdle, he has to work with mutilated functionality. So so reaching the point of full awareness ends in a frustration of incapability. While at the same time the 'adjustment' to make life for Benjamin easier doesn't even cover the whole spectrum. So he will encounter the same issue even with the adjustment made; where we say yes, we know but that's the 'natural confusion'. However the 'exception' makes that the confusion never stops.

I simply dislike trade-off. The current workflow is done with best intentions - sure - for accommodating Benjamins, but is this really worth it? It's not in the interest of Benjamin (in the long haul; learning to understand) nor making Eve really productive.

Consequent behavior (so no exceptions); makes far easier to grasp the system. Or if Benjamin isn't in the mood, he is surprised, pressed Bold again.. and it will work. So he will life and be productive too.

Of course my opinion.. It's clear we both disagree in principle. So a lovely gridlock situation. And people are (unusual) silent about this (hairy) topic. And it's likely come up in the past. 

Anyhow, I'm not in the position making a anyhow ;-). Nor in the position the person in charge. So this gets picked up some time, some day. Or stays as it is in the current form.

(In reply to Mike Kaganski from comment #48)
> (In reply to Telesto from comment #45)
> > I'm not a heavy user. I'm only give my opinion based on what I have noticed.
> > However, you should ask people who actually are correcting formatting and
> > how often they need to do that. And if this a cumbersome job etc. 
> 
> And I have ten years of experience using MS Office, and then another ten
> years of experience using, deploying LibreOffice in a real commercial
> company; training people; creating templates; helping them solve problematic
> situations related to creating new documents with really complex text
> formatting (see GOST 21 at [1]), and to documents received from those using
> MS Office; and sending our documents to parties using MS Office, etc. That
> was prior (and the reason) to my joining development of LO.
> 
> Don't assume that your opponents have no clue what real users use and what
> problems they see.

I didn't intend to offend or intimidate, or discredit your knowledge. And of course it's hard to know somebody's background/experiences. I only stating my 'gut' feeling. And I assume there are more people who run in to certain issues with DF (and styles). I'm surely not representing the whole world, not even an explicit group. Only giving my view :-). And have seen comments by Luke/Thomas related this matter (so not such big audience either :-).

I do know it isn't easy for my to get to the bottom of DF formatting (and CS/PS). So DF bold being overwritten by CS Strong Emphasis. Or changing PS throwing out certain DF (reported that). If DF is always on top, Strong Emphasis shouldn't throw CS Strong Emphasis out. Or if this is desired .. I want to be able to tell the difference between DF bold and CS Strong Emphasis bold (at formatting button level). To be able to tell what I have in front of me.


> 
> > I'm more they type of experiments.. Worse what can happen is a 'revert' (and
> > some wasted time/ money developing it). However we get feedback/ and data/
> > experiences. Not that ever idea has to become an experiment.. arguments are
> > fine.. but some point 'experiences' matter. 
> 
> As I already stated: this is bad. Any "battle-testing" would only attract
> people who have problems with the change, and only part of those. The people
> would be vocal; the reports would never show you how many have benefitted;
> how many have problems with the change (only would show how loud those who
> report are).

This will always be never ending topic. I assume there are many more bug out there than in the bug tracker. People don't report it for various reasons (don't notice, don't know what happened, have not time, not interest etc). 

I always assume someone else will report an certain issue. Or the QA department of TDF will figure it out.. 
 
> And in this special case, your proposal for battle-testing is even worse.
> You are making a change that presumably might (I say will) hurt those who
> are the beginners, those who might as well assume their problems are due to
> them being newbies. Such a change would hurt them, but would not result in
> proportional increase of reports - only in proportional abandoning the tool
> that was tested, and proven not suitable.

Yes, ideally an separate experimental version :-). Or some 'advanced' setting etc. But than people won't use it. So this topic will go in circles. 

There is always an unrepresented groups. Most people don't have the time, interest etc to care. They want a working product; and the take what fits their needs. 

And I love to bring up markdown. I still can't believe (no data; can't proof anything] this is 'wanted' by majority. But somehow it got (a) implemented (b) turned on by default. The only thing I can argue is that add additional UX-principle. LibreOffice should restrict itself to 'core' functionality being enabled by default [not sure what the rules are about new functions etc; embedded or extension]. 

And of course somehow we need to end up with a decision :-). They organ in charge being UX-department. A understaffed, black box department. Still disagreeing on certain decisions (arguments), but at least a decision is made

(In reply to Telesto from comment #50)

Oh.

I tried hard to explain the problem to Telesto. Tried to explain the idea behind the feature; its intended user base; who exactly is the model user. In the end, answering Telesto's request for simple steps, I wrote roughly this:

> See: here is a complex functionality, with involved mix of inheritance,
> layers, dependencies, etc, which is very useful, but from Benjamin's PoV,
> behaves almost randomly.
> 
>  =========> But here is the button created for Benjamin <=========
> 
> after pressing which, the function becomes simple for Benjamin, at the cost
> of masking all the complex machinery beneath.
> 
> Now Telesto wants to break the behaviour of the button, in such a way that
> using it results in another complex behaviour, potentially useful for some
> power users, but still confusing for Benjamin.

I hoped that it's rather clear for anyone, that if there is a functionality is created for some user base, then breaking it exactly for that user base is a no-go.

Well, the reply is:

> Yes, it's correct; but I fail to see why you say that it's OK above the
> "=========> But here is the button created for Benjamin <=========",
> but having the same below the line is inappropriate...

Am I the one who, respectfully assuming due intelligence in the opponent, starts suspecting being trolled?

I am done here, trying to "discuss" something with a troll and spammer, who floods Bugzilla with zillions of low-quality "reports" (unlike in the beginning); making one who sees "this bug authored by Telesto" to react like "ah, this is safe to skip".

You made your point clear; I mine. We are simply weighting the priority differently. 
You say its worth it, I say it isn’t.

Same thing with political party’s. They have some fundamental different opinions.

I attempted to get to the bottom. There is not much to investigated. And yes, I understand the frustration. It’s mutual.

However going into the victim role: being trolled. Or discrete the opponent (troll/spammer/zillions) Or threaten I will ignore (written by). Or generalise (100 reports where junk, so this one is too) is superfluous and and undermining/weaking your position. It can be interpreted as he can’t “win” the argument, so he is moving to attacking the opponent. 

Aside from not being nice. But yes, my reports don’t always live up the ideal template for reporting or being always helpful.

And yes, I agree there is not much to be added. We both made our stances pretty clear. 

Of course thank you for your time and effort to respond and explain.

(In reply to Luke Kendall from comment #54)
> I sure hope the above isn't referring to me?  I would be surprised if you
> were, because I spend valuable time reporting bugs in the hope they're of
> some use.

Absolutely no! I am really sincerely grateful for all your effort!

> I'm hoping he doesn't think I'm trolling - I would be shocked if he did.

I don't think so. I am sorry if I made such impression.

*** Bug 135878 has been marked as a duplicate of this bug. ***

(In reply to Mike Kaganski from comment #25)
> (In reply to comment #22)
> Now think about this. Apply "Strong Emphasis" character style to text; then
> press "B" toolbar button.
Hm, that's something I never understood. This mixing of effectiveness of style and direct formatting. When using a style bold command I wouldn't expect that this also means that the direct formatting bold command is also activated.

This results in the situation we have now that the ODF xml files are crowded with formatting tags that say e.g. "transparent background" instead of nothing (--> result of direct formatting colored background and then no-fill formatting to delete the background color), as transparent already is the base formatting.

   Actually, there is a simple solution to this. Highlighting does nothing more than to change the background color of the selected area. Now background color is property of both paragraph and character styles. If you want to highlight a paragraph, create a new paragraph style with this property. (Right click the style that was used before the highlighting. Select New > Area > Color. Select the color you want, or create a new color. Name the new paragraph style.) Select the paragraph to be highlighted, and double click the new paragraph style. A character style for each highlight color can be created the same way.
   In other words, do not use things like highlighting, font color, etc., or any other button which duplicate what styles can do.

(In reply to Dan Lewis from comment #58)
>    Actually, there is a simple solution to this. Highlighting does nothing
> more than to change the background color of the selected area. Now
> background color is property of both paragraph and character styles. If you
> want to highlight a paragraph, create a new paragraph style with this
> property. (Right click the style that was used before the highlighting.
> Select New > Area > Color. Select the color you want, or create a new color.
> Name the new paragraph style.) Select the paragraph to be highlighted, and
> double click the new paragraph style. A character style for each highlight
> color can be created the same way.
>    In other words, do not use things like highlighting, font color, etc., or
> any other button which duplicate what styles can do.

Thanks for the different approach/workaround. However I wish it where that simple. Not the case, IMHO :-(

If I have bold text with CS style, this will be removed by the CS highlighting style. Except if I create a CS highlighting + bold style.

I'm one of those who 'paints' documents. So surely using 8 colors once in a while. 
* So first pain is having to create all those CS for every document. Solution: create a template. True, but template can't use for documents of others.
* And creating a CS style for all of those combinations, will become a unpractical long list
* You must be pretty selective. So a selection with partly bold text in it must be split in parts to apply to proper highlighting.
* And keep in mind that - at least I - use highlighting only temporally. So isn't intended to be around for ever. And 'styles' are for structural layout, not for temporally stuff? And unwinding (removing all superfluous styles will be painful
* An last problem I see, they lovely style names are lost on DOCX export. So doing this in DOCX isn't fun either. 
 
And for the record: the topic is limited to highlighting (which this topic started about, but not totally adequate). This does also apply for formatting like BOLD/UNBOLD. This could be done with styles to. But CTRL+B pretty common short cut and markdown autocorrect doing it wrong too.

I could say, every DF combination should create a new CS style. However that isn't desired either. 

Or formatting must become tristate or (say bold/unbold/disabled). Or pressing UNBOLD button with PS BOLD, unbolds. And gets deactivated pressing UNBOLD again. However what happens in case of PS BOLD, pressing UNBOLD, changing PS BOLD to UNBOLD. The DF isn't obvious on screen.
And pressing BOLD should activate bold (not disable unbold).

Being logically possible to implement, but of course harder.

So a indicator if in the toolbar if BOLD active by means of (DF) or (PS/CS). Similar for UNBOLD by being (non), DF, or PS/CS. And now somebody says, some people will not get that.
  
Non doesn't show a symbol. It on if 'DF' and PS/CS are active at the same time. Where DF in principle being on/off switch (except for the PS/CS change). Where Unbold DF can be active while unbold at PS level is active too.

But maybe I'm missing/overlooking something essential here.

I don't want to read the whole "book", but just want to ask you, Telesto, if the situation is still the same with LO 7.5. And perhaps it is possible for you to summarize previous discussion.

=> NEEDINFO

(In reply to Dieter from comment #60)
> I don't want to read the whole "book", but just want to ask you, Telesto, if
> the situation is still the same with LO 7.5. And perhaps it is possible for
> you to summarize previous discussion.
> 
> => NEEDINFO

Still the same

(In reply to Telesto from comment #62)
Telesto, any chance to summarise previous discussion and provide some fresh set of steps to reproduce?

Dear Telesto,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp