How to remove settings or define wildcards in paragraph templates

(Please bear with me; I was looking around but due to complexity and probably lack of a simple way to describe the problem I did not find an answer anywhere.)

It is possible to create paragraph templates (but I suspect this is the same for any other hierarchical template) that derive parts (or all) of their settings from their parent template. I chose to create a template “Heading” and assigned it a specific font and derived a “Heading 1” form that parent, using it to create “Heading 2” and more further down the tree. I never changed the font in any of the children. This is working as intended.

If some dummy is setting any unspecified parameter in one of the derived children (e. g. setting the font name) it seems to be impossible to reset this parameter to “unspecified, take it from your parent” again (either due to me being too dense to find out from the menus and the available help or the function really missing from the UI). The only workaround I have found is recreating this template and replacing the modified template with the new one or using Word or Textmaker to edit the file (having the usual side effects). Neither seem to be a good solution.

Is there any other way to reset parts of a template to the “unspecified” state?

It seems to me that you mean that you derive Heading 1 from Heading, then Heading 2 from Heading 1, then Heading 3 from Heading 2 and so on. I just checked; the inbuilt styles Heading 1 through Heading 10 are directly derived from Heading 1. And I don’t really see why you’d want to make such a cascade if you know in advance that at some point you will want to revert to the parent of the base type of your last style. Aren’t you just mixing up the logical hierarchy of styles used in a document, like Heading 1 for chapter, Heading 2 and further down for sections, sub sections, sub sub sections and so on, with the hierarchy of how the styles are defined, which is purely a matter of efficiency? You use inheritance so that you won’t have to define all elements of a style over and over. But you don’t need to do so, you can have your Heading 1 through Heading 10 all without parent type, you just have more work designing them, but it won’t have any effect on how the styles work in your document.

1 Like

There is a very bad choice of labels for the buttons in the styles (what you call “template” but template in Writer parlance is a totally different thing) dialog.

To reset the settings in the present tab of paragraph or character style definition, press the Standard button. Here, “standard” means reset everything to parent’s state, meaning: remove any overriding setting.

Remark

I don’t think it is a good idea to daisy-chain Heading n as you describe. I did so but it brought more difficulties than comfort. It is better to follow the built-in structure where Heading is the common ancestor used to define common default attributes for the whole family and have each Heading n to descend directly from Heading.

It’s the only way to define things in relation to its predecessor (e. g. base font, relative character size or numbering (style)) without having to change multiple objects and forgetting at least one. As I’m doing most of my writing using MarkDeep (and doing the semantics to typography mapping using cascading (sic) style sheets I’m used to doing it that way.

I’ll probably use door #3 by unpacking the documents, modifying the damaged styles using vi and laughing a bit about that obvious omission in the UI (and wondering if I am the only one who would like to set a certain parameter to “inherit this from your parent”).

I might have been misunderstood.


Reset everything to “unspecified state” (i.e. to inheritance values): Standard button


Heading styles relationship

Your scheme is

 Heading → Heading 1 → Heading 2 …

What I suggest (and is implemented in built-in styles):

 Heading -+- Heading 1
          |
          +- Heading 2
          |
          +-…

You still define the base font face and size in Heading. Individual fo,t size are defined in % units, so that when you change Heading size, all other sizes are recomputed, thus always giving you consistent results. Study the built-in configuration.

Also, numbering for built-in Heading n is configured by Tools>Chapter Numbering. This list style is reserved exclusively for Heading n so that you can’t use it for any other purpose and are guaranteed to never botch chapter numbering (e.g. by interference with lists).

I don’t understand your argument about MarkDeep. If you’re composing your documents with MarkDeep/MarkDown formatting directives with Writer, you’re probably using the wrong tool. Also, what I exposed for the relationship/inheritance of styles is not incompatible with CSS. It’s just a different structure: tree-like vs. linear chain.

Which is not the same as having a way to unset a single value; it might be an emergency measure but as you can’t scroll on the (whatever it is really called) inspection tab that shows you all active (and stacked) style parameters to redo all the other things that were modified this is also a way to create chaos. A token “” might be the only way to do it cleanly.

It’s not only size; the idea is that a font change at “heading n” level will be applied to all levels below that (unless someone is adding another change further down the chain).

That’s exactly what we’re currently doing with our preferred tool (MarkDeep) where we are basing each Heading style on everything we did to the level above.

If some dummy is setting any unspecified parameter in one of the derived children (e. g. setting the font name) it seems to be impossible to reset this parameter to “unspecified, take it from your parent” again (either due to me being too dense to find out from the menus and the available help or the function really missing from the UI).

No, you have found the solution, because that is exactly how it is. Once specified, always specified.

The only workaround I have found is recreating this template and replacing the modified template with the new one …

Right.

…or using Word or Textmaker to edit the file (having the usual side effects).

You’d better not do that, because then chaos is preprogrammed.

Is there any other way to reset parts of a template to the “unspecified” state?

No.

I obviously forgot the obvious question: Would there be a chance of success if I asked for that feature to be added or did developers already state why it isn’t there? I can’t be the only one thinking in cascading styles for the last two decades.

If you would like to submit an enhancement or requirement suggestion, you can do so on Bugzilla. This is the right place.

How to Report Bugs in LibreOffice

Good luck.


You can post the error number here then, maybe someone would like to reinforce the request.


Would there be a chance of success…

You have a chance only if you make an entry. But I cannot tell you how big this chance is.