It appears that all builtin Character Styles inherit from "None" as their default (or more precisely, that is what is shown in the Organizer tab). What is the expected behavior in the Character Style dialog, when using the "Standard" button (if Inherit From is "none")? If the source code is treating "Default Character Style" as the Inherit From for builtin Character Styles, then it should be shown in the Organizer tab as such instead of "None". One test that is consistent the hypothesis that Default Character Style is the Inherit From. 1. Edit "Strong Emphasis" 2. Change Font style to "Bold Italic" 3. Press "Apply" 4. Press "Standard" Actual: Font style changes to "Regular" Expected: Hard to say. Organizer says "Inherit from "None". o Could expect Standard to - revert to "builtin" default Strong Emphasis (because no inherit) - do nothing (because no inherit) No strong opinion offered here about what to do. But, as a first step, if "Default Character Style", is in fact the actual "Inherit From" for the builtin Character Styles, then it should be shown that way.
"Default Character Style" is not a style, but is the action to remove a reference to a character style from a text range. That text range will then use the character related settings in the paragraph style. So it is nothing, from which you can inherit a style. The current UI is bad in that it does not have a separator between "Default Character Style" and the true styles, and in that the term "Default Character Style" does not reflect, what this item does. A style belongs to a "family", see https://docs.oasis-open.org/office/OpenDocument/v1.3/cs02/part3-schema/OpenDocument-v1.3-cs02-part3-schema.html#__RefHeading__1417906_253892949 For character styles it would be family "text". LibreOffice writes a style "Standard" for family "paragraph" which is used as root for all predefined paragraph styles. A similar style does not exist for family "text". But I would not even try to define a "Character-Standard" style as root. Because in that case, the attributes, which are missing in a character style would not get their values from the paragraph where the text range resides, but from one common root style. For example: If you based the character style "Emphasis" on a common root style, then it would get font, font size and language from there. But you want, that "Emphasis" applied to a text range in a heading still uses font and font size of the heading, or applied to a German quote in an English text will still use German as language. In other words, you want that a character style will use the settings of that paragraph where the text range resides, to which the style is applied, for all attributes, which are not explicitly set in the character style. To achieve this, a common root style would need to be designed _not_ to set any attribute values. But then such style would be empty.
(In reply to Regina Henschel from comment #1) Thank you for the interesting, detailed helpful explanation. > "Default Character Style" is not a style So maybe it was a mistake (or unfortunate) that this entry in the Styles sidebar was renamed to "Default Character Style". From your description, it sounds like "No Character Style" might better express its "nature", which might also address your critique of the current UI. Similarly, in the Styles menu, the "Default Character" command should be renamed to something like "No Character Style"? (comparable to the new "No List" command for Lists). > LibreOffice writes a style "Standard" for family "paragraph" which is used > as root for all predefined paragraph styles. A similar style does not exist > for family "text". Ok. Just to check then about the "Standard" button in the Character Style dialog (which is now named "Set to Parent"). 1. It is still possible to make a Character Style that "inherits from" another character style. Pressing the "Set to Parent" button in that case does (and should) cause the tab in view to revert to the settings for the parent. (i.e., same behavior as a paragraph style). 2. But what about Character Styles that have 'None' as their 'Inherit From' and "Set to Parent" is pushed? Won't that have the same effect as a Character Style that has "Default Character Style" as its 'Inherit From'? That is, all character-related settings are removed (except for Font Type and Font Size, which are set in the Writer Options (for Basic Fonts). If this analysis is correct, then: A. "Default Character Style" should be called "No Character Style" B. Builtin Character Styles should have "No Character Style" as their "Inherit From" instead of "- None -". C. The "- None -" option should be removed from the 'Inherit From' choices Then it might be possible and meaningful to use the same tooltip for the "Set to Parent" button in both Paragraph Style and Character Style. (will modify summary accordingly)
(In reply to sdc.blanco from comment #2) > > "Default Character Style" is not a style > So maybe it was a mistake (or unfortunate) that this entry in the Styles > sidebar was renamed to "Default Character Style". From your description, it > sounds like "No Character Style" might better express its "nature", which > might also address your critique of the current UI. > > Similarly, in the Styles menu, the "Default Character" command should be > renamed to something like "No Character Style"? (comparable to the new "No > List" command for Lists). Yes, the term "No Character Style" would be a lot better. > > > LibreOffice writes a style "Standard" for family "paragraph" which is used > > as root for all predefined paragraph styles. A similar style does not exist > > for family "text". > Ok. Just to check then about the "Standard" button in the Character Style > dialog (which is now named "Set to Parent"). > > 1. It is still possible to make a Character Style that "inherits from" > another character style. Pressing the "Set to Parent" button in that case > does (and should) cause the tab in view to revert to the settings for the > parent. (i.e., same behavior as a paragraph style). Yes, that is the purpose of that button. But "Set to Parent" does not exactly describe, what this button does, see below. > > 2. But what about Character Styles that have 'None' as their 'Inherit From' > and "Set to Parent" is pushed? Won't that have the same effect as a > Character Style that has "Default Character Style" as its 'Inherit From'? > That is, all character-related settings are removed (except for Font Type > and Font Size, which are set in the Writer Options (for Basic Fonts). You cannot have "Default Character Style" as parent, because it is not a style. A character, which has no character style applied, uses the character related settings of that paragraph, to which the character belongs. That is the reason, why a paragraph style has the tabs "Font" and "Font Effects" at all. The Writer Options are bound to the paragraph style "Default Paragraph Style". When you change the font in the Writer Options it will change in the "Default Paragraph Style" and vs. > > If this analysis is correct, then: > > A. "Default Character Style" should be called "No Character Style" Agree. > B. Builtin Character Styles should have "No Character Style" as their > "Inherit From" instead of "- None -". No. The list, which will contain "No Character Style", refers to the object, which gets a style applied, or in this case, which gets the style erased. But the "Inherit From" refers to the definition of a style itself. That are different contexts. > C. The "- None -" option should be removed from the 'Inherit From' choices No. It indicates, that the style has no parent style. That option is available for all styles, which allow a hierarchy, and has always the same meaning. > > Then it might be possible and meaningful to use the same tooltip for the > "Set to Parent" button in both Paragraph Style and Character Style. The button does in both cases the same. It removes the properties in that dialog tab from the set of properties, which get a value by this style. The result can be seen in the Organizer tab. If a property has no value in the style, which is applied to an object, then LibreOffice needs to get the value from somewhere else. The mechanism for that is described in detail in the standard. https://docs.oasis-open.org/office/OpenDocument/v1.3/cs02/part3-schema/OpenDocument-v1.3-cs02-part3-schema.html#__RefHeading__1416274_253892949 The problem is, to explain the inheritance mechanism to the user. And it is obviously difficult to explain, why it is useful, that the character styles are not inherit from a common root style, but the paragraph styles have a common root style.
Seeing the paragraph as the bigger a.k.a master entry "Default Character Style" seems to be the appropriated notation. But the entry is not self-explaining. I suggest we rename it into "Set to Paragraph Default" or shorter "Set to Paragraph". "Clear Character Style" is same wrong as it also does not suggests that the characters will inherit from the giving paragraph.
(In reply to Regina Henschel from comment #3) Thanks again for further clarifications and precisions. (and I accept your analysis about leaving - none - etc.). > The [Set to Parent] button does in both cases the same. It removes the > properties in that dialog tab from the set of properties, which get a value > by this style. Good. Then my objective is to find a tooltip that expresses this accurately. When "Inherit From" refers to another Character Style, then it is clear that "Standard" returns the values of the parent Character Style. But how would you describe what happens when "Inherit From" is "None". My guess: When "Inherit From" is "None" then values specified in "Contained" are removed.
Created attachment 170276 [details] Document to examine character styles (In reply to sdc.blanco from comment #5) > But how would you describe what happens when "Inherit From" is "None". It follows the algorithm described in the ODF standard. https://docs.oasis-open.org/office/OpenDocument/v1.3/cs02/part3-schema/OpenDocument-v1.3-cs02-part3-schema.html#element-style_style Example Border color and style: Examine style RedBoldAndBorder in the attached file, look in section Contains in the Organizer tab. <quote> The determination of the value of a formatting property begins with any style that is specified by an element. If the formatting property is present in that style, its value is used.</quote> So the text range to which this style is applied (the word "dummy" in line E, F, G, and H) has a red, dashed border at its bottom. Example font color: Examine style RedBoldAndBorder: The style contains nothing about font color. <quote> If that style does not specify a value for that formatting property and it has a parent style, the value of the formatting element is taken from the parent style, if present.</quote> Example font color continue: The parent (which is in 'inherit from') is style RedBold. Looking there in the Organizer tab we see 'light red' and so that is taken as font color. Example font size: Neither RedBoldAndBorder nor RedBold contain values for the font size. <quote> If the parent style does not have a value for the formatting property, the search for the formatting property value continues up parent styles until either the formatting property has been found or a style is found with no parent style. </quote> Example font size continue: RedBold has no parent (its 'inherit from' is 'None'). So we cannot go further up in the ancestor hierarchy. But the standard has further rules: <quote> For styles with family text which are applied to elements which are contained in a paragraph element 6.1.1, the search continues within the paragraph style that is applied to the paragraph element, and continues in its parent styles. </quote> Example font size continue: Take the text range in line G, which RedBoldAndBorder applied, for example. It is in a paragraph with paragraph style "Preformatted Text". We examine "Preformatted Text" and find "10pt" in the 'Contains' section. So this text has font size "10pt". Now take the text range in line E. That paragraph has style "Heading 1". We examine it and find font size "130%". The percent value refers to the size in the parent style, which is "Heading". And there you find "14pt". So the text has 18.2pt (=14pt*1.3) font size. So when a character style has in its 'inherit from' style the value 'None', it has no character style parents. If a property has no value specified directly in the character style, then the search continues in the paragraph style. So in this case the text range "dummy" has font size "10pt" in line G, and has font size 18.2pt in line E, although in both cases the character style RedBoldAndBorder is applied. Same for lines A, B, C and D where RedBold is applied. And this examples shows you, why it is useful to permit, that a character style has no parent character style. That allows, that properties for which values are not directly defined, take their values from the environment in which the character style is used. > > My guess: > > When "Inherit From" is "None" then values specified in "Contained" are > removed. No, see style RedBold. It has "None" but still defines values for the font color. I have constructed RedBold and RedBoldAndBorder so that RedBold is the parent of RedBoldAndBorder. You can test, that the inheritance really works. Set the font color in RedBold to Blue. Now all "dummy" texts are blue, because style RedBoldAndBorder inherits the font color from RedBold. But border color is still red, because that is directly defined in style RedBoldAndBorder. It is indeed a challenge, to describe this behavior in tooltips and to use adequate labels.
(In reply to Regina Henschel from comment #6) Thanks again for the detailed example. > > When "Inherit From" is "None" then values specified in "Contained" are > > removed. > > No, see style RedBold. It has "None" but still defines values for the font > color. Actually I think I am right here. Edit "RedBold" CS, go to Font Effects tab and press "Standard". Font Color becomes Automatic (and Light Red no longer appears in Contained). Similarly, on the "Font" tab, press "Standard" and Font Style changes to "Regular". If you do both actions, then you will see that Contains becomes empty for "RedBold" -- which is what my proposal says. I also tried "Standard" on the "Borders" tab for "RedBoldAndBorder". I believe it should inherit "RedBold" borders value, but I was not surprised that it did not work because of bug 136339 (for Area and Highlighting). (I thought there was also a bug report for Borders, but I could not find it, if it exists). Because "Standard" only applies to a tab, maybe I should modify the formulation to: When "Inherit From" is "None" then any values on this tab, which are specified in "Contained" are removed. fwiw, I studied 16.2 <style:style> carefully before making my proposal, which was motivated by the logic described in 16.2 <style:style>. But I am happy that your detailed example is consistent with my auto-didactic understanding, and also that my tooltip proposal "survived" the first empirical challenge, presented by "RedBold". But in this case, when the logic is specified, it seems better to follow that, rather than work empirically (especially given the bugs). My reasoning for character styles is that they are not applied to paragraphs (because they are style definitions), so they will always end up with "none" for paragraphs. But if paragraph styles do not define a property, then "an implementation-dependent value is used." Here I admit that I trusted/guessed that the implemented values for Character would match the implemented values for Paragraph at the "bottom". And was wondering if it would be better if LO used a <style:default-style> for text family, which is permitted, but inspection of an LO .odt file indicates that LO does not use it. > It is indeed a challenge, to describe this behavior in tooltips and to use > adequate labels. The goal is only to describe accurately what happens when Standard is pressed (independently of whether it communicates "why").
We have the proposals "No Character Style" and "Set to Paragraph Default" (quite a challenge for translators to pick up all the implicit thinking).
Topic was on the meeting agenda but did not receive further input. I guess "No Character Style" is easier to understand and less challenging for translators, at least.
(In reply to Heiko Tietze from comment #9) > "No Character Style" https://gerrit.libreoffice.org/c/core/+/112311
"Remove Character Style" ? "Clean Character Style" ? <- more consistent with "Clean Direct Formatting, Ctrl+M" My 2 cents.
(In reply to Olivier Hallot from comment #11) > "Clean Character Style" ? <- more consistent with "Clean Direct Formatting, Interesting, at least unless this option is not enabled for plain CS.
(In reply to Heiko Tietze from comment #12) > > "Clean Character Style" ? <- more consistent with "Clean Direct Formatting, As a matter of clarification: Isn't that a proposal for a .uno command? The OP here is about the label shown in the Styles deck for Character Style. These seem like different things. Or have I misunderstood?
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b2b99a4ce105e1c1627e923f2fc4e9bf488dff2b tdf#140818 "Default Character Style" -> "No Character Style" It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Resolved. Now it's: "No Character Style" Verified in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 1a99b4e44190e182d56a04678850d62635d74c65 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/f6d93aeda80f5a1f24e6fd162c43143a0373add3 (related tdf#140818) update to "no character style" in help