When editing a style, “inherit from” is sometimes grayed out on the Organizer page. Why is that? If I want the style to inherit another style, is there a way to do that?
1 Like
There are many classes of styles in a ‘Writer’ document.
A paragraph style e.g. can only inherit from a paragraph style.
For page styles inheritatage is not implemented. The respective field in the organizer is disabled.
Please give mor details concerning your questions.
Hi Lupp,
From what you are saying, it sounds like the 6 styles (with the exception of pages) can only inherit from the same style. That certainly makes sense.
I created a list style called “Bulleted List in Table.” I want it to inherit from another list style, but the option to do so is grayed out.
This happens from time to time with other styles so I mainly want to understand the general rules that prevent a style from inheriting from another style.
Thanks for your help.
Do LO developers follow this forum? If so, here goes.
I really, really want to inherit page styles. I work on four-abreast pages on my 24" monitor. I get this by taking a 6x9 trade paperback size but cutting off the left and right margins while I write. I use about ten different page styles. With inheritance, I could just change ‘default page’ from 4.2 by 9, no side margins to 6x9, with margins. As is I have to modify ten page styles individually.
BTW, that’s a great answer, ajlittoz.
Feature requests are to post here in the same way as bug reports using “enhancement” for the Severity.
From my experience, paragraph, character and frame styles can inherit from any one of the same category. Page, list and table styles can’t inherit.
Inheritance is statically based on “declarations” within the same category.
- Paragraph styles ultimately are all derived from Default style. Use hierarchical view in the list side pane to see the other intermediate parents as defined in out-of-the box configuration. You can customise it to fit your needs.
This makes sense and is the most useful.
-
Character styles have the same inheritance rule as paragraph styles but by default have no hierarchy (they have no common ancestors). Among built-in styles, some are “special”:
-
Default Style is not a real style (and you can’t modify it! it is protected): it is used to reset all attributes to their state in the current paragraph style
-
Internet Link and Visited Internet Link behave like ordinary styles but are not exclusive to another character style: they are applied over the current style and set (or rather not-reset) attributes override those of the other character style. They are used to confer the link property to the underlying text.
-
There may be other special styles but I have not discovered them, not having the need to study them.
In my opinion, these inheritance rules are easy to implement from a developer’s point of view but are not the most appropriate for the user. A user defines a character style for two usages.
The first one I call absolute sets unconditionally attributes (e.g. a monospaced font like in Source Text because the style reflects a specific semantic intent).
The second one I call relative or contextual can’t be defined in LibreO. In this usage, I’d like to modify an attribute defined in the paragraph style, which is a different category. For example, consider how a word is highlighted in traditional typography: you type set in italics in a roman paragraph and vice versa. Presently, you must define two styles and choose them explicitly knowing what is set in the paragraph style. Toggling the attribute in the paragraph style compells you to chase the character styles and change them for the other one.
Talking about toggling, I do regret that this possibility is missing from currently implemented paragraph and character inheritance rules. An attribute has only two values: reset (i.e. does not change value from “parent” style) and forcing. Toggle would definitely be useful.
Inheritance comes very handy when you define a hierarchy of styles, such as Heading x. They all inherit from Heading but you can customise this inheritance by having “H1” as “H2” parent, “H2” as “H3” parent, etc. With headings, it is common to define font sizes relative to the parent with %-unit (e.g. Heading 1 is set to 24pt, Heading 2 to 80%, converted to 19.2pt). The magic of it is that when I change Heading 1 to 18pt, Heading 2 automatically changes to 14.4pt. This makes relative font sizes not worth consideration. However, relative sizes are useless in a first-level character style because it is does not inherit from ant other character style while I’d like this %-size to be relative to the size defined in the current paragraph style.
I met this situation when I wanted to insert Source Text excerpts typeset with a monospaced font in Body Text paragraphs. To be nice-looking, Source Text font size had to be 80%. But when Source Text was used in notes or headings, result was ugly because the font size was converted to absolute and had no relation with the font size of the surrounding paragraph. This is a consequence of not having a contextual definition of character styles.
- Frame styles have “standard” inheritance rule which at least fit my needs
The other style categories have no inheritance rules.
-
List styles have no inheritance and I think it makes sense because they already define a hierarchy by themselves. They guarantee that all levels of a list will have a consistent look. The “inheritance” is already hinted at in the
PositionandOptionstabs. Don’t forget thatTools→Chapter Numberingis just another list style with a dedicated purpose (the Heading x family) where the levels styling can be finer controlled than other list styles.
I don’t know which usefulness would give inheritance in list styles.
-
Page styles definitely would deserve inheritance. The minimum would be the margin settings but parameters for header and footer are also to be considered to design a consistent set of pages. The main inconvenient of the present situation is the case when you need the same page style except for header/footer content. Lack of inheritance means you have to edit all related styles manually when you change e.g. a margin width. Deriving all styles from Default Style, like paragraph styles, would be a plus.
-
I consider present implementation of Table styles as experimental and not corresponding to my idea of styles. I feel they are rather some templates for inserting “goodies” tables and, once inserted, there is no longer any relation with the so-called style. Said it otherwise, you can’t change the style to cause a formatting change in all the existing tables created with the “template”. This is not yet the behaviour met in the other categories. I hope this will evolve in the right direction.
This may not be the answer you expected as I’m no developer, but I tried to sum up my experience. Cheers.
Note: I edited the paragraph about relative font sizes after answer on this question
Wow. Thank you for taking the time to write all of this information. It will be useful for when I run into inheritance questions again.
You’re welcome
Like @MartinRinehart, I really would like to use inheritance for page styles.
I used it a lot for text styles, but I also absolutely need it for page styles.
For instance, the default page format here is A4.
I often work on booklets that are in A5 format.
So I duplicate the default page style into one that I change to A5 with a specific left/right layout and margins.
But every time I need to create a new page style, for instance one for a page feed that starts automatically on the next right-side page, I have to redefine all the layout and margins manually because I can’t inherit these settings from my “Booklet” page style.
This also means that whenever I do a slight change on the margins, I have to replicate the same change to all dependent page styles because there is no notion of dependence or inheritance for page styles.
Some of these page styles have really one different setting compared to the original “Booklet” style.
I store these styles in templates, but it does not solve this specific issue, some booklets have unique layouts.
I don’t know if page style inheritance will ever be implemented (it would be great), but at the minimum, the GUI should tell the user that inheritance does not work for page styles, for instance via a tooltip on this grayed out option, instead of forcing the user to spend an hour trying to figure out what they are doing wrong (nothing), trying again in different ways, and finally looking up for explanations and finding this thread after many others that are not relevant. ;(
Right now, the user is completely let down, it is a double frustration, that the feature does not work, and that nothing says why.
There is an open bug (enhancement request) concerning page style inheritance for about 8 years now: https://bugs.documentfoundation.org/show_bug.cgi?id=41316.
Comment #14 there by Regina Henschel is shedding additional light on the issue by hinting to a specific flaw (if not there are other hidden problems impacting on the topic / Also see explanations by @ajlittoz above.) in the definition of the ODF file format.
I utterly miss page style inheritance too, for the exact reasons you mention.
By The Way:
Who is user @regina1 ?
Why is a link to Regina (first letter in upper case!) changed to @regina1. The first one is a valuable contributor, the second one is an all-zero-user.