Description: "Title" hierarchy and styles sons are ignored when user change "Font" atribute to root style ("default paragraph style" is parent of ALL styles, including "Title" and their styles sons. Steps to Reproduce: 1. <F11> 2. Right mouse button over "Default paragraph style" 3. Change "font" attribute to "Comic Sans" Actual Results: "Title" style and their sons are not changed to new selected font. Expected Results: "Title" style and sons, should change font to "Comic Sans" Reproducible: Always User Profile Reset: Yes Additional Info: "Title" style and sons are not changed
Paragraph styles has hierarchy Default Paragraph Style => Heading => Title. I can't see a child of PS "Title" But I confirm, that a change of font attribute in Default Paragraph Style doesn't affect "Heading". But if you change font of heading style font in "Title" is also changed. So in general: If you change font of "Default Paragraph Styles" it doesn't affect the following styles: - Endote - Footnote - Heading (with childs) - Preformatted Text Tested with Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f96004096268f5e71120678e32fc8c74055819aa CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Rafael, do you get the same result? => NEEDINFO
*** Bug 141326 has been marked as a duplicate of this bug. ***
(In reply to Dieter from comment #2) > *** Bug 141326 has been marked as a duplicate of this bug. *** You have reason, Dieter. I translate from Spanish "Titulo" to "Title" and in English is "heading". So that's the issue, about Heading. In my case, only "Heading" hierarchy and "Preformated text" are not changed. I could even understan no changes in "Preformated text", cause is using a distinct font than "Default parapraph style", but sure "Headings" should change.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to rafael.linux.user from comment #3) > So that's the issue, about Heading. => NEW Adding design-team in cc, because there might be a reason I can't see, why the current behaviour is the expected behaviour.
The "Title" PS has an own font, Liberation Sans, and changing the parent never overwrites modified attributes. It works as expected for font color, for example, since "Title" still uses 'Automatic'. => NAB
(In reply to Heiko Tietze from comment #6) > The "Title" PS has an own font, Liberation Sans, and changing the parent > never overwrites modified attributes. It works as expected for font color, > for example, since "Title" still uses 'Automatic'. => NAB Just for clarification: So there is the general rule that settings in Tools > Options are "stronger" than style hierarchy, correct?
(In reply to Dieter from comment #7) > Just for clarification: So there is the general rule that settings in Tools > > Options are "stronger" than style hierarchy, correct? Tools > Options > Writer > Basic Fonts defines what font is used by default. Meaning if you set Comic Sans at Default it will be used for Default Paragraph Style. These default values are overwritten by templates. The hierarchy comes later with Liberation Serif used as default for Default and Liberation Sans for Headings. Changing the parent Default will not modify the children Heading.
I think that if that is that way, it should be put clear in documentation. Any user guess that in a hierarchy, changes should work like I supposed to be.At least, "Headings" should not be child of "Default style paragraph", and have its own independent hierarchy tree, IMHO.
Anyway, is not working I open a new writer document based of default template (not mine default template with my own styles, but LibreOffice Writer default Writer template). I then change "Heading" to ComicSans in "Tools > Options > Writer > Basic Fonts", click "Apply" (no changes in Paragraph styles panel (F11) and then "Accept". "Headings" hierarchy is not changed to ComicSans. If fact, if I repeat again the steps: 1 - "Archive, Templates, Manage templates", then select "Default" template and open it 2 - "Tools > Options > Writer > Basic Fonts" and change "Heading" to "Comic Sans" and click on "Accept" .... again, paragraph styles panel didn't change "Heading" and childs font. So, something is not working even in that way.
T>O>W>Fonts work on new documents not templates. What you have to do is to change Headings in T>O>W>Fonts to Comic Sans, make sure no default template is defined (File > Templates > Manage Templates - no checkmark on any item) and then you create a new document. For some reason, the template fonts are taken into T>O>W>Fonts and if you Apply/Okay this tab your Comic Sans would be overwritten. Help is here https://help.libreoffice.org/latest/en-US/text/shared/optionen/01040300.html?DbPAR=SHARED#bm_id3151299, no opinion from my side if this needs improvements ("These settings define the basic fonts for the predefined templates" sounds wrong to me).
I suppose that the status quo (heading styles having an explicitly set font name) is because people want to be able to set defaults without using templates, and that resulted in the (bad IMO, and additionally confusing, mixing default config and changing settings of current document, and duplicating a configuration in an obviously unrelated place without making clear that it's the same as changing a style's properties) Options->Writer->Basic Fonts. So as long as we have that configure, it's impossible to *not* redefine fonts for those groups of styles *by default*. The templates don't have to follow this; and it's possible for template maintainers (:-)) to change that in the templates that we bundle if they consider that useful; but note that as soon as user opens the abovementioned Options page, and does modifications there, it would be changed in the opened document (which is likely wanted if user does that?). (In reply to rafael.linux.user from comment #9) > At least, "Headings" should not be child of "Default style paragraph", > and have its own independent hierarchy tree, IMHO. No. This is not correct, because hierarchy is not limited to inheriting font name. > Any user guess that in a hierarchy, changes should work like I supposed to > be. And it's *supposed to be* that any property defined explicitly takes precedence. Or otherwise the hierarchy would not make sense, because there would be no way to re-define anything in the children.
(In reply to rafael.linux.user from comment #10) > I open a new writer document based of default template (not mine default > template with my own styles, but LibreOffice Writer default Writer > template). I then change "Heading" to ComicSans in "Tools > Options > Writer > > Basic Fonts", click "Apply" (no changes in Paragraph styles panel (F11) > and then "Accept". "Headings" hierarchy is not changed to ComicSans. It's simply not updated its view. If you close it and reopen, it will refresh. If you do not reopen, but inspect the style properties, you will see the changed values.
(In reply to Mike Kaganski from comment #13) (and it's a bug, yes; a different one)
You all have reason: - Is not intuitive the way user need to "force" to not use even "default style sheet" if user want to make effective fonts selected on Writer configuration (thank you Heiko) for the workaround to make it work - Issue is as you say, Mike Kaganski : Writer simply do not update "Styles Panel" (is not the only bug in this panel, I reported another one related to that panel https://bugs.documentfoundation.org/show_bug.cgi?id=141257) after clicking "Apply" or "Accept", as it should Anyway, IMO, the way hierarchy works now, is not "intuitive". User must play "trial and error" to guess how it work indeed. Thank you for all your explanations
I agree that something may need improvement here; but I disagree with > Anyway, IMO, the way hierarchy works now, is not "intuitive". User must play > "trial and error" to guess how it work indeed. Because hierarchy works exactly as it should. Somehow the *size* of text, also set in some styles, does not create such feelings. And overall, *if* the default would be having *different* font name for heading (say, Mono), the hierarchy question would not arise (but then the stylistic question would appear). The problem here is just a case when the overridden value happens to be the same font as in parent.