Note that I'm not talking about direct formatting here, but about character styles. For new users, it's quite difficult to find that the only way you have to remove an applied character style is to apply the special character style called "default style" on top of it. The "styles toolbar" have a button to apply this special character style and thus remove any applied character style, but its function is not evident at first glance and anyway that toolbar is not enabled by default. I think a possible alternative is to add in the character style panel of the style editor a button called "remove character styles from selection" or something like that, being that button a shortcut to apply the default character style.
+1, but maybe more than just for Character styles? It seems like there should be menu entry (either Style menu or a Format menu) for the existing UNO controls--".uno:DefaultCharStyle" and ".uno:DefaultParaStyle" used on the Formatting (Style) toolbar. The menu entry(s) would provide reset to default Character style and/or default Paragraph style--i.e. a "Style" corollary to the 'Clear Direct Formatting' control. And I would suggest this pair of actions also appear on the Sidebar Properties Deck, inside the 'Style' Content Panel or better in its Title bar, as a button action to "Clear (or Reset?) to Default". Likewise the same button actions should be added to the Title bar of the 'Style' deck. Intent of reusing controls--menus, Properties deck, and Style deck--being to provide a consistent and obvious way to remove any assigned styles. It would provide a means to get a text selection or a full paragraph back to known state--i.e. no Direct Formatting, no Style other than document default.
(In reply to V Stuart Foote from comment #1) > It seems like there should be menu entry (either Style menu or a Format > menu) for the existing UNO controls--".uno:DefaultCharStyle" and > ".uno:DefaultParaStyle" used on the Formatting (Style) toolbar. So, the .uno:DefaultCharStyle is already on the 'Styles' menu--labeled 'Default Character' but uno:DefaultParaStyle is not; regardless addition to Sidebar decks is needed.
Please don't extend this to paragraph styles. Doing that would emphasize usage of Default paragraph style - which is bad.
(In reply to Mike Kaganski from comment #3) > Please don't extend this to paragraph styles. Doing that would emphasize > usage of Default paragraph style - which is bad. Would it? Not so sure... For most users now--majority of their documents are already going to be in default style(s) as that is what the document type templates open with. While here, goal of having the controls prominent is to get the document content back to a known state--either selecting a word, a text run, a full paragraph, or the full document and resetting its style. Seems the efficient work flow is to first set the selection back to the template defaults for paragraph and character styles (or to the default style(s) as modified in current document). Making it ready to apply new style(s), in a second step if other than defaults is desired.
At risk of being off-topic here (since the request was about character styles(!)), I have to describe my PoV. While the imaginary "Default character style" (internally = don't use any character style, and use what is defined in paragraph style) is perfectly reasonable in any sense (and would be most used in ~any stylistically consistent document), Default paragraph style (an actual style, which might - and often should - be modified - consciously) is a *root* of most pre-defined styles, and thus its direct use is wrong from the proper styles use PoV. Of course, using it is not wrong from the programmatic PoV, but its default use in templates is just an unfortunate implementation detail that needs fixing. So making means to directly use it even more prominent than now is a bad thing. Specifically, using "Default paragraph style" in documents, and then starting use styles, would mean that a novice user has main text in that "Default style", and also applies, say, Heading N; also using headers/footers and tables automatically uses relevant styles in those elements. And when user then wants to edit the main style (Default!), this will propagate inherited settings to all the styles right and left - which might be (and often is) not what user needs. The inheritance levels are there for a reason: e.g., if user wants font face to be consistent across all used styles, user sets that in the lowest possible inheritance level; if user needs some paragraphs have indents or spacings, that wouldn't make sense to do at lowest level. Forcing users to start with base-of-everything Default style provokes each style edit to have too widescale (potentially destructive) consequences. We have too much of that Default paragraph style usage in our controls/templates: being the default in the templates; being set when e.g. Alt+Enter'ing out of a table; resetting to it when using the "Clear formatting" item in style list in toolbar... please don't create another prominent way to promote logically inconsistent workflow! It goes against the overall architecture of LibreOffice being built around using styles; and it makes learning using styles much more difficult for beginners (who try simple things like editing the used styles, and suddenly see unwanted results all over the document, which would cause distrust in the tool).
Even without the "difficulty" and "distrust" feelings caused by unwanted large-scale changes editing the Default style, the obvious consequence of this in user learning is "understanding" that all styles should be "disconnected" from the Default style (user would need to re-define all the properties in inheritance tree leafs), thus making the inheritance concept less useful and more of a hassle ("Why is everything inherited from Default? It makes things so much harder!"). The very first encounter with the style inheritance concept, instead of giving a useful and handy tool to user, becomes "meet this useless and awkward thing that stays on your way" moment.
(In reply to RGB from comment #0) > For new users, it's quite difficult to find that the only way you have to > remove an applied character style is to apply the special character style > called "default style" on top of it. I agree > > The "styles toolbar" have a button to apply this special character style and > thus remove any applied character style,but its function is not evident at > first glance and anyway that toolbar is not enabled by default. I can't find a "styles toolbar". Styles menu doesn't have that option > I think a possible alternative is to add in the character style panel of the > style editor a button called "remove character styles from selection" or > something like that, being that button a shortcut to apply the default > character style. +1
(In reply to Dieter Praas from comment #7) > > I can't find a "styles toolbar". Styles menu doesn't have that option > View -> Toolbars -> 'Formatting (Styles)'
At the first glance I agreed with the "clean CS" button idea. But this would lead the list in a nimbus state (no item selected), which is not achievable except this button. Feels wrong, is bad usability. Plus, it's a new UI control without some kind of whole concept behind that bothers me. OTOH, thinking about multi-selection to make nested CS possible, it's not far-fetched to ctrl-click a selected entry and to toggle it off by that. And last but not least, if the selection goes over some part of the paragraph including Default and <Foo> CS, the Default entry is selected in the Styles menu and the styles sidebar list. In this situation it's absolutely not clear that clicking Default works similar to Clean Direct Formatting.
Hm, if something existing isn't good to use or will not be used regardless of whether it would be useful, then this is an indicator of bad usability of existing tools. Instead of bringing more complexity to an already complex field of possibilities (here: the styles concept) with a new feature, we should allow users to better use existing features. The question is how to make this possible. More help texts? Tool tips? Another arrangement or naming of commands? I'm talking about character styles only and I'm with Heiko in comment 9.
(In reply to Thomas Lendo from comment #10) > More help texts? Help is not very helpful: https://help.libreoffice.org/6.4/en-US/text/swriter/01/05130000.html?DbPAR=WRITER#bm_id4005249 and documentation is not very clear: "Removing or replacing character styles Sometimes, you will want to remove the character style formatting from some text, or change the character style to a different style. To do this: ... 3) Double-click the required character style, or double-click Default Style to remove the character style." (Writer 6.0 Guide Chaper 8, page 9) Either Default style is a character style (in this case documentation should be changed) or "Default style" removes character style and therefor it is not a character syle itself (in this case name "Default Style" should be changed)
(In reply to Dieter Praas from comment #11) > Either Default style is a character style (in this case documentation should > be changed) or "Default style" removes character style and therefor it is > not a character syle itself (in this case name "Default Style" should be > changed) Default *character* style is actually a pseudo-style; a name for "no character style applied". While it might be good to document something about that, I don't think that renaming it is a good idea, because its current name creates some consistency with e.g. paragraph styles, where "default style" exists (and is actual configurable style). For user, it means something basic and simple. Or - if a rename is wanted - it could be something like "Character settings defined at paragraph level" - too long, although correct. You cannot even name it "Paragraph style settings", because "no character style" aka "Default character style" means both paragraph style setting, and *direct paragraph-level formatting* are used for character properties.
(In reply to Mike Kaganski from comment #12) > Default *character* style is actually a pseudo-style; a name for "no > character style applied". After years of using LO and styles, I begin to understand the concept :-( I've spent a lot of time while writing my PhD and defining a character style for each paragraph style. I would like to spare others this. > While it might be good to document something about > that, I don't think that renaming it is a good idea, because its current > name creates some consistency with e.g. paragraph styles, where "default > style" exists (and is actual configurable style). Same name but different meaning? => Doesn't create consistency for me. > Or - if a rename is wanted - it could be > something like "Character settings defined at paragraph level" - too long, > although correct. What about "From paragraph level"?
(In reply to Dieter Praas from comment #13) > What about "From paragraph level"? or "From paragraph settings". Makes sense to me.
(In reply to Mike Kaganski from comment #14) > or "From paragraph settings". +1
+ pro: convenient, self-explanatory (Stuart, Dieter) + con: misleading, adding complexity (Thomas, Heiko) + (multiple) CS could be assigned per toggle on/off at the list item, and we remove the dummy "Default" CS => suggest to resolve as WF
Just to add another perspective from a new user point of view: A while ago I wasn't even aware of the concept of character styles, and so after I pasted in some text that happened to have a "Code" character style, I was confused about why Ctrl + M (Clear Direct Formatting) was changing the font to Liberation Mono instead of Liberation Serif: https://ask.libreoffice.org/en/question/186336/clear-formatting-keeps-reverting-font-to-liberation-mono-instead-default-style-liberation-serif/ Also somewhat relevant: https://ask.libreoffice.org/en/question/135708/clear-direct-formatting-ignores-character-styles/
(In reply to Ahiijny from comment #17) > Just to add another perspective from a new user point of view: The issue is clear. But the requested button to remove a CS is not the solution to a missing understanding (not blaming the user by this but design and workflow) or the awkward way to revert CS by setting Default. Rather feedback is key here- and the proposal is under https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/
(In reply to Heiko Tietze from comment #18) > (In reply to Ahiijny from comment #17) > > Just to add another perspective from a new user point of view: > > The issue is clear. But the requested button to remove a CS is not the > solution to a missing understanding (not blaming the user by this but design > and workflow) or the awkward way to revert CS by setting Default. By the same token, a single "well placed/named/tool-tipped" button action is self documenting and would itself provide some insight for users. > Rather > feedback is key here- and the proposal is under > https://design.blog.documentfoundation.org/2019/11/05/proposal-to- > conveniently-highlight-and-inspect-styles-in-libreoffice-writer/ Well, this should still probably happen, but inspection and highlighting is a much more complex/ambitious "solution" for Style visualizations, while this otherwise a simple requirement for a single .uno action to remove applied Character Style(s) from selection and _simply_ to restore the attributes provided by the applied Paragraph Style. Simplicity for a UX solution now, and pursue more dev interest/effort to fully implement proposed visual manipulation of styles going forward.
How about the toggle idea? I mean you click on _any_ entry in the list to enable or disable this CS. We remove the Default CS and allow at the same time to have multiple CS selected. Intuitive? At least we don't clutter the UI further.
(In reply to Heiko Tietze from comment #20) (Shift|Ctrl)+Click - as usual for multi-selection in list? (But no, that's bad, since simple click on the list then would reset all currently selected styles => bad) Checkboxes to emphasize multiselection idea?
(In reply to Mike Kaganski from comment #21) > (In reply to Heiko Tietze from comment #20) > > (Shift|Ctrl)+Click - as usual for multi-selection in list? (But no, that's > bad, since simple click on the list then would reset all currently selected > styles => bad) Yes, it's a common interaction, eg. in file browsers. > Checkboxes to emphasize multiselection idea? That's one option. The other (simple) solution is to only accept click on item.
Created attachment 161392 [details] A sample file which can be used to experience strange things with different combinations of formatting I wrote the attached file in the past before I came across this thread. Therefore the file is in German. As I see from the participants of this discussion, some of them will understand it. Right now I don't have the time to translate it (even after DeepL would give us a purely translated version quickly, one would still have to apply the formatting quirks to it). The example shown shows some benefits of the strange formatting properties (e.g. setting something to bold by direct formatting is kept bold after applying another paragraph style), but it also shows an inconsitency of extending direct formatting properties if a new paragraph is added to an existing one and if there is direct formatting at the very end of that. The problem came up when I wanted to prepare a text such that it can be spoken by several speakers and that a copy can be printed separately for each speaker such that the text for a particular speaker is formatted differently from those of the other speakers and that the words to be emphasized are printed in bold. The text deals with how those formatting requirements could be met.
(In reply to Adalbert Hanßen from comment #23) > Created attachment 161392 [details] > A sample file which can be used to experience strange things with different... attachment of sample file was not made correctly, please try again
(In reply to V Stuart Foote from Comment 24) This is the attachment which I was talking about in Comment 23. Sorry that it did not get through.
Created attachment 161475 [details] the file which I wanted to attach to comment 23: some formatting oddities not easy to explain
Created attachment 161477 [details] A sample file which can be used to experience strange things with different combinations of formatting Now I had the time to make an English version of my sample of mixing direct fomatting with using character styles. The behavior will surprise novice users of LibreOffice and sometimes it gives hard to explain quirks.
Created attachment 161478 [details] A sample file which can be used to experience strange things with different combinations of formatting This is a translation of the other file to English which I hopefully formatted the same way.
Citing from attachment 161478 [details]: > Unfortunately, the definition of character formats in LO Writer is final: you have > to define all character properties that can be influenced at all. Although you can > change the character format in the style sheet afterwards, which will change all > the places formatted with it consistently, for example, double underline instead of > bold, you cannot say: adopt all other settings from the current paragraph format. This is absolutely wrong. The truth is exactly the opposite: only the things you define in a character style are used to override the settings coming from paragraph formatting level. Of course, *if* you defined the font explicitly (as you did in "fett für Gegenbeispiel") in the style, then it will override whatever you set on the paragraph level. Your style content is shown on the style's Organizer tab. If you go to the style's Font tab, click "Standard" button at the bottom, then make a single click on Bold under "Style:", and close with OK, you will have the style not defining the font name, so inheriting whatever is there in paragraph. > I pressed ENTER at the end of the heading. A normal paragraph (Text Body) began. > But it is still bold, because this headline is bolded by a style sheet, but in > addition it is also directly bold formatted! This is simply confusing: A new > paragraph should start with its default format for the paragraph from the > stylesheet - without any direct formatting! Another wrong statement. A new paragraph inherits all properties of the previous text. Doing otherwise would be most unexpected for all users. A rule that tells that "after this paragraph style, the next paragraph must get that style" doesn't modify anything except the paragraph style - namely, direct formatting is naturally not affected. Anyway, both things are not related to the stated bug topic - which is "create more obvious way to remove applied character styles".
Created attachment 162375 [details] Answer to Comment 29 with several examples and suggestions how to improve formatting with styles A tool button acting like *Default Character Style* under Character Styles in the styles deck would meet the original poster’s objective. If one would provide such new tool on the formatting tool bar, it should appear in the pressed state as long as no Character Style is assigned to the current editing point. This would be consistent with the tools for the bold, italic, underline etc tools, which appear as pressed when the current text is bold, underlined, italic etc. The existing appendices 2 and 4 show examples that will drive a novice to despair. In this new appendix 5 you find some more examples and considerations on how to tackle formatting more systematically and expediently. Presently very cumbersome and error prone things would become much easier with the suggestions contained in this appendix. I have looked up the specifications of odt-files and came to the conclusion that the underlying data structures allows leaving properties undefined such that they can be changed later at the inheriting level. It already works with direct formatting as can be seen from appendix 5 playing with the playgrounds provided in it.
(In reply to Adalbert Hanßen from comment #30) > ... > A tool button acting like *Default Character Style* under Character Styles > in the styles deck would meet the original poster’s objective. If one would > provide such new tool on the formatting tool bar, it should appear in the > pressed state as long as no Character Style is assigned to the current > editing point. This would be consistent with the tools for the bold, italic, > underline etc tools, which appear as pressed when the current text is bold, > underlined, italic etc. > Customize of the Format (Styles) toolbar has a place holder already 'Character Styles'. And it provides a listbox selector--but its UNO command is stubbed back to the Paragraph style -- .uno:StyleApply More work is needed for bug 88512 and bug 106782 but that would allow application of 'Default' character style (as drawn from the applied Paragraph style). Which IMHO a functional listbox including choice of Default character style is more efficient than a toggled Default button. Allowing restyling, including default of paragraph, with one action.