In a Writer document, modify the Default paragraph style to select a custom font, for example Libertinus Serif instead of the "factory setting" which is Liberation Serif. After typing some text, select a portion of it and apply any character style, e.g. Emphasis: the selected text becomes italic respecting the font set for the paragraph style, which is great. Now edit said character style and in the Font tab notice that the selected font is Liberation Serif. Liberation Serif seems to be hard-coded in LibO and, at least for character styles, means something like "if you don't touch this setting the paragraph style font will be used instead, so ignore me." This can be quite confusing, especially for people just starting to use character styles. Some clear way of knowing when the base font will be used and when an explicit font will be chosen instead is needed. For example, in the font list, instead of selecting Liberation Serif, display a line that says something like "Use font set in paragraph" or similar.
On the 'Organizer' of 'Character Style', it's visible 'Inherit from', and below 'Çontains' what it's specific of that style. https://help.libreoffice.org/7.6/en-US/text/shared/01/05040100.html?System=WIN&DbPAR=WRITER&HID=sfx/ui/managestylepage/ManageStylePage#bm_id3145356
(In reply to m.a.riosv from comment #1) > On the 'Organizer' of 'Character Style', it's visible 'Inherit from', and > below 'Çontains' what it's specific of that style. > https://help.libreoffice.org/7.6/en-US/text/shared/01/05040100. > html?System=WIN&DbPAR=WRITER&HID=sfx/ui/managestylepage/ > ManageStylePage#bm_id3145356 Sure, I know that. But that doesn't change the fact that the dialog in its current state is confusing. In fact, I filled this bug report after trying to explain to someone how character styles actually work.
(In reply to RGB from comment #0) > Liberation Serif seems to be hard-coded... CS attributes are independent from PS; the only way to solve the problem is to not being able to change the font on CS. If you make Emphasis, as an example, inherit from Bullets the font will be OpenSymbol; using the PS as default sounds wrong to me. > Some clear way of knowing when the base font will be used... That's what the Styles Inspector was introduced for (the 6th item on the Sidebar). => NAB/WF
(In reply to Heiko Tietze from comment #3) > (In reply to RGB from comment #0) > > Liberation Serif seems to be hard-coded... > CS attributes are independent from PS; the only way to solve the problem is > to not being able to change the font on CS. If you make Emphasis, as an > example, inherit from Bullets the font will be OpenSymbol; using the PS as > default sounds wrong to me. > > > Some clear way of knowing when the base font will be used... > That's what the Styles Inspector was introduced for (the 6th item on the > Sidebar). > > => NAB/WF I hope you agree that if you see one thing on the style editor while creating the style and a completely different thing on the style inspector then you have a consistency problem.
Basically, this is a part of bug 88559. The said bug 88559 is about display of *any* case when any property is not defined in this style; and the specific case when *the whole hierarchy* of styles (of a specific kind) does not define such a property should be resolved together (and character styles are not some kind of an edge case). We definitely need to use *some* font for preview. But the preview can have a tooltip or another notification that "properties not defined in the character style and its ancestors are taken from document's defaults". The fields themselves should have the indication of inheritance (bug 88559) and some indication that no inherited value exist, to address what RGB reports. Note that Liberation Serif is the hardcoded *default* for a new document, and can de changed (with the awful, not intuitive, and actually misleading UI) - see bug 152537. It is *not* the same as Paragraph's Default style's font, but the UI in the Options dialog affects them both. (In reply to Heiko Tietze from comment #3) > That's what the Styles Inspector was introduced for (the 6th item on the > Sidebar). > > => NAB/WF :) Please see bug 88559 comment 10 ;)
(In reply to Mike Kaganski from comment #5) > Basically, this is a part of bug 88559. And there, in bug 88559 comment 17, I argued that the character styles' "some properties unspecified" are a separate issue :-) So this one could be it :)
This particular case is about one attribute of CS that clashes with the same attribute on PS. I wonder if there is more than font name. As a potential solution we could add the font "[Default]" to the list.
(In reply to Heiko Tietze from comment #7) > I wonder if there is more than font name. Every property of a character style can appear in a paragraph style.
(In reply to Mike Kaganski from comment #5) > Basically, this is a part of bug 88559... > Every property of a character style can appear in a paragraph style. How do you think we can show all attributes from the PS in the CS organizer? Can't we use the PS attributes in CS - and solve bug 155113 en passant?
(In reply to Heiko Tietze from comment #9) > How do you think we can show all attributes from the PS in the CS organizer? *I* don't think about it. I try to avoid UI questions ;) because I know that it's can of worms. I just told you facts. Still, you might look at other apps with *complex* UI, for inspiration how they approached similar issues. One of such apps that I know was Symantec Antivirus. It was a centrally managed product, and a sysadmin could lock any setting in it, at which time, a lock icon appeared in the user's dialog for that setting (see e.g. https://www.youtube.com/watch?v=LxbZYG7eh14 at 1:20). Indeed, we are not talking about locking here; but IMO, despite the strong wish to keep the UI simple and "native", the *inherent* complexity of our style management is such, that simply *cannot* be expressed adequately without similar visual clues. > Can't we use the PS attributes in CS - and solve bug 155113 en passant? I don't quite understand this.
(In reply to Mike Kaganski from comment #10) > > Can't we use the PS attributes in CS - and solve bug 155113 en passant? > I don't quite understand this. We use default values like Liberation Serif for the font but since CS takes the attributes from the PS using those could solve many problems. The drawback is of course that you cannot trust in a particular attribute since Serif could be Sans on other paragraphs. But the mentioned bug 155113 requires exactly this, to explicitly set regular font weight for CS to be applied for PS in italic. I would replace the organizer, or rather enhance, by an indicator on the very attribute that is modified. Could be an icon similar to the info button, a different font color, or an asterisk added to the label. Alternatively, all attributes that have not been set could become a tristate as known from checkboxes. In case of list we need [None], or the like. Quite some effort.
(In reply to Heiko Tietze from comment #11) > (In reply to Mike Kaganski from comment #10) > > > Can't we use the PS attributes in CS - and solve bug 155113 en passant? > > I don't quite understand this. > > We use default values like Liberation Serif for the font but since CS takes > the attributes from the PS using those could solve many problems. The > drawback is of course that you cannot trust in a particular attribute since > Serif could be Sans on other paragraphs. We use defaults from the document. What you suggest is to change the defaults source - using *some* paragraph properties - which? selected? but what if you have multiple paragraphs selected? And note, that a given character style may be applied not only atop of a "clean" paragraph, but also on top of some character direct formatting, or even on top of another character style (see bug 115311 for discussion of a basically missing UI for that, but still there is a Shift-DoubleClick method). So - I don't see how choosing one default or another could solve anything at all, when the fact is: when you define a character style, any property that you do *not* define directly in the style or one of its ancestors is *undefined*, and the actual value used by a text to which this character style is applied will depend on *other* factors, so not possible to see here in the style dialog. > But the mentioned bug 155113 requires exactly this, to explicitly set > regular font weight for CS to be applied for PS in italic. I do not see how bug 155113 is relevant here at all. They do *not* require there *anything* related to how unset properties are displayed in the style. What they request there is a way to set the Regular as "not Italic, nor Bold" in a style explicitly. Completely unrelated.
Understanding style inheritance (within a category PS or CS) and interaction (when applying CS over PS) is already difficult enough so that you must not add any complexity to the present dialog(s). What is needed (requested?) is a visual clue that an attribute has not been explicitly set or unset. Checkboxes already have a long-recognised aspect for tri-state: no tick, ticked and grayed. This is not used in LO but could be, provided some hint mentions in built-in help that gray does not mean "disabled" but "inherited". For lists, you could display the values gray and the selected one standard (black). Clicking on another item selects it. Clicking on the selected one deselects it and sets it to "inherited", i.e. gray again. I suggested gray but if you have a better idea, notably to avoid confusion with "disabled", you're welcome. Everything else can remain as is. RGB complains about sample display in CS. Unfortunately, nothing can be done about it. CS can be applied over ANY PS. Therefore, we know nothing about effective font face (unless it is overridden in CS inheritance). Using application-wide or document-wide default for sample display makes perfect sense. The problem here is understanding of the style feature by newbies. Unless they read documentation, which very few do.
(In reply to RGB from comment #2) > Sure, I know that. But that doesn't change the fact that the dialog in its > current state is confusing. It's both confusing and wrong. > CS attributes are independent from PS; the only way to solve the problem is to not being able to change the font on CS. Huh? > Some clear way of knowing when the base font will be used... That's what the Styles Inspector was introduced for (the 6th item on the Sidebar). No, it isn't. The Inspector summarizes and makes things exact. It is not intended to countermand/override what's said on other tabs.
(In reply to Mike Kaganski from comment #5) > Basically, this is a part of bug 88559. The said bug 88559 is about display > of *any* case when any property is not defined in this style; and the > specific case when *the whole hierarchy* of styles (of a specific kind) does > not define such a property should be resolved together (and character styles > are not some kind of an edge case). I'm not sure it's the same bug. One issue is _which_ font is displayed for Emphasis in OP's scenario, and another question is whether the inheritance is clearly indicated in the UI for choosing the CS font. While OP's complaint focuses on the lack of indication - which indeed seems covered bug bug 898559 - he also tells us the font chooser shows Liberation Serif - which is not what the Emphasis CS inherits from the Default PS. > Note that Liberation Serif is the hardcoded *default* for a new document, > and can de changed (with the awful, not intuitive, and actually misleading > UI) - see bug 152537. That bug asks for too little. The fonts used for previewing a CS should be the Default PS' fonts. > We definitely need to use *some* font for preview. > ... > It is *not* the same as Paragraph's Default style's > font, but the UI in the Options dialog affects them both. That's part of the bug here.
We discussed the topic in the design meeting. First of all it depends on the workflow what you in the CS dialog. Starting from the Stylist per "Modify" takes the default value, using "New from Selection" the attributes from the selection, and the same of course when running per Character... at the document (and direct formatting). If the selection spawns over multiple paragraphs varying attributes become blank in the CS dialog. This is straight-forward and easy to understand. Better feedback for altered attributes is requested in bug 88559. The suggestion is to show an indicator next to the control, visible if changed, and with the opportunity to switch it off (bug 89826).
(In reply to Eyal Rozenberg from comment #15) > (In reply to Mike Kaganski from comment #5) > > Basically, this is a part of bug 88559. ... > > I'm not sure it's the same bug. ... Please do not bring back parts of comments that the poster himself told to be incorrect - see comment 6. Bringing obsoleted pieces back clutters the issue, and makes it difficult to understand what is the current state of discussion.