Is there a reference document that contains all the standard styles?

I’m sure someone did this already, but I’m looking for a document that contains all the the styles in them, so I can save it as my default stye and, if I want to modify them later, I can automatically see everything that will happen with the modifications.

I searched but didn’t find one. I understand that I can do it, but if one xoists already, I would rather leverage that.

L

This is indeed something which would be very useful to everyone.

If your goal is only to list all built-in styles, use the Navigator. To see the relationships between styles, choose Hierarchical from the drop-down menu at bottom of list.

For example, you’ll see that changing font face in Heading will have effect on all Heading n, Title and a few others; similarly Index will impact all Contents n (TOC styles) and tables of xxx …

  • You are probably accustomed to paragraph styles and their hierarchy.
  • Character styles are all independent from each other but you are free to restructure them.
  • Page styles can’t be organised hierarchically.
  • There are very few factory frame styles. They are mainly used in connection with insertion of formula, text frame or image as a default (hard-coded style applied). I prefer to create derived styles to fit my various particular needs. Yes, frame styles can be hierarchical. Frame styles are very important to centrally control “illustrations” but inserted objects are even more sensitive to direct formatting than paragraphs or characters. The mere smallest suspicion of direct formatting is enough to defeat styling.
  • List styles are independent from each other (hierarchy here makes absolutely no sense: what would me to link one sequence counter to another one?). Consider them as examples. From my experience, they must always be customised (it is unnecessary to add new styles unless you have exhausted all of them – in this case, I’d question your understanding of the abstract semantic notion of a list).

What is really needed is developer's or TDF explanation about intended usage of built-in styles. This is approximately obvious for list, frame and page styles.


There are a few ambiguities in character styles. For example, what is the difference between Teletype and User Entry? Or rather, in which kind of document would they be used simultaneously? (in interactive CLI applications, they are roughly synonymous)

It is clear that paragraph styles can be grouped into several “collections”:

  • letters; Addressee, Complimentary Close, Sender, signature, …
  • technical auxiliary data in document: Header & Footer + children, Index + children (TOC and others), …
  • core discourse: Body Text + children, Heading + children, …

But there are several interpretations for a number of them. Take the example of the list-intended styles. They come in groups: “bare”, Cont., End and Start. End and Start are rather obvious. However how should the “bare” variant and Cont. be used? There have been several questions on this site about them with diverging opinion. It turns out there is no shared consensus about them.

And even Start and End are debatable in the light of my new way at handling list instances.

1 Like

Thanks! For me the intent is not (as) important as the look of the style. A single document that contains all of them would help. I asked an IA to generate a Python program to create one. I’m running into some execution issues. If I have more time later today, I’ll try to fix it. But in the meantime, I’m still OK with someone sharing a link.

Then again, I could make the Python code available on GitHub… which I did, here:

It meets my needs but is not complete. There file contains no styles. So you can build your styles completely from scratch.

My planned usages is to save the ref doc as my default template and modifying it when I need to.

Do you mean you want a sample of the default look of all of them? I don’t think it is really meaningful.


Styles are organised hierarchically, with children inheriting attributes from their parent and overriding some.

What would be useful is an expanded view of what is offered by the Style navigator pane in hierarchical view, plus a list of style configuration, same as General tab.

This tab shows the parent name in Inherit from and describes what is changed in Contains section (overridden attributes, though the very concise wording makes it sometimes difficult to understand).

Since built-in styles cannot be deleted, a really “blank” document would rather be one with overridden built-in styles to your liking. Then it can be saved as your preferred default template.

Exactly. That’s what I did with my Python thing. For now, it just puts all (most?) of the styles in a truly blank document. There is no formatting at all in it. So then, you modify the styles to your liking and the document updates so you can see what things will really look like.

It’s not perfect or complete, but it pretty much has everything I want (except the TOC formats) in it as it stands.

I experimented on the idea: I saved a completely blank document as .fodt and opened it in a text editor.

To my surprise, it contains nearly no style at all, except Standard (for Default Paragraph Style used in the empty initial paragraph), Heading, List, Caption and Index because they are customised from Tools>Options, LO Writer>Basic Fonts (Western) which I modified.

Curiously, all built-in page styles are present.

From this observation, I assume that a “blank” document will contain only modified/overridden built-in styles. These modification can be brought by Tools>Options as in the case of default font face and size above or from user profile (or OS context ?) for page format, impacting all page styles.

If you modify built-in styles, the revised version is included in the blank document, as well as all user styles.

And as soon as your document has contents, used styles are also saved for formatting stability (just in case built-in styles change after current session).


BUT: when I turn the “pure” blank (no style override, no contents) into a template, all style definitions are wiped out.

I assume then that we should consider built-in styles always exist in the background. These can be overridden by a definition in the template. And ultimately, overrides in the document win all.


So, your idea of inserting styles with macros may not be reliable or stable. You get a snapshot valid at time of creation but immune to any change made to built-ins or template. And I wonder if some so-styled paragraph is not necessary to copy the definition into the XML.

We’re back to the “official method”: customise built-ins into a personal template.