Revision history [back]

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.

Another shortcoming of inheritance rules is the use of percentage font sizes. They are converted to absolute as soon as they are entered (I don't remember exactly against which reference, but that makes them unconvenient). When building a hierarchy of heading style, I would like to express my font size relative to the one in effect in the parent heading but this is not possible (e.g. Heading 1 is set to 24pt, Heading 2 to 80%, converted to 19pt; when I change Heading 1 to 18pt, I'd like Heading 2 to automatically change to 14pt but it stays to 19pt because it was converted to absolute). This makes relative font sizes not really worth consideration. The situation is even worse when relative sizes are use in a first-level character style because it is not related to any 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 Position and Options tabs. Don't forget that Tools->Chapter Numbering is 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 definitel 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.

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.

Another shortcoming of inheritance rules is the use of percentage font sizes. They are converted to absolute as soon as they are entered (I don't remember exactly against which reference, but that makes them unconvenient). When building a hierarchy of heading style, I would like to express my font size relative to the one in effect in the parent heading but this is not possible (e.g. Heading 1 is set to 24pt, Heading 2 to 80%, converted to 19pt; when I change Heading 1 to 18pt, I'd like Heading 2 to automatically change to 14pt but it stays to 19pt because it was converted to absolute). This makes relative font sizes not really worth consideration. The situation is even worse when relative sizes are use in a first-level character style because it is not related to any 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 Position and Options tabs. Don't forget that Tools->Chapter Numbering is 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 definitel 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.

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.

Another shortcoming of 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 rules is the use of percentage by having "H1" as "H2" parent, "H2" as "H3" parent, etc. With headings, it is common to define font sizes. They are converted to absolute as soon as they are entered (I don't remember exactly against which reference, but that makes them unconvenient). When building a hierarchy of heading style, I would like to express my font size sizes relative to the one in effect in the parent heading but this is not possible (e.g. with %-unit (e.g. Heading 1 1 is set to 24pt, 24pt, Heading 2 2 to 80%, converted to 19pt; 19.2pt). The magic of it is that when I change change Heading 1 1 to 18pt, I'd like Heading 2 to 2 automatically change to 14pt but it stays to 19pt because it was converted to absolute). changes to 14.4pt. This makes relative font sizes not really worth consideration. The situation is even worse when However, relative sizes are use useless in a first-level character style because it is does not related to any 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 Position and Options tabs. Don't forget that Tools->Chapter Numbering is 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