Background
My use of Styles to manage an entire document has been limited. My new goal is to prioritize the use of Styles. I know how to modify, add new, and assign. But I’m a little fuzzy on the hierachy of Styles, positioning, and the use of Sections versus Frames.
.
So far I have downloaded some LibreOffice templates and examined them.
.
I used the LibreOffice Template Wizard and examined the results.
.
I am slowly making my way through the book, Designing with LibreOffice.
.
My practical “learning” application is going to be full-page recipes that consist of:
.
.
Many of the examples I viewed used Tables to control location. I was leaning towards Sections or Frames, rather than Tables.
.
Lines 02-04, 07-08, 11-12, 15-16 would be Sections with 2 columns.
.
Lines 01 is the main heading and 06, 10, 14, 18 are subheadings above their Sections.
.
Lines 05, 09, 13, 17 are blank lines for spacing.
. Questions
.
Are Sections the right approach to separate the Picture-plus, Ingredients, Steps, Nutritional Information, and Notes?
.
When creating any new Style, do you Inherit always from the Default Paragraph Style and modify the attributes as needed?
.
When I create a new style, I prefix them with a string so I can identify them, plus it makes the name unique. There is a Tip on page 35 of Designing with LibreOffice suggesting something similar.
.
When I first started creating styles I started from the top down, but that created a problem with selecting the Next Style. Is it better to create new Styles from the lowest level on the hierachy so you can reference them in the Next Style field as you move up?
.
How do I add space after a Section? Do I just add an empty paragraph to achieve the blank line or maybe add the space above the subheading?
A recipe is fairly simple and doesn’t need huge amounts of styles. They are different so be prepared to be a little adaptable.
I don’t see a need to use sections. In fact, a recipe is basically a list, first of ingredients and then of how to put it together. The simpler the layout, the easier it is to follow. I would be inclined not to put ingredients in two columns (unless to separate two stages), the same with instructions/steps; it is too easy to to look at the wrong column
This sample does have two lists of ingredients so I used a table GermanApplePancake.odt (72.5 KB)
I try to not create new styles unnecessarily, where possible I adapt existing styles.
If a new style for the body of the document does not [ultimately] inherit from Default Paragraph Style it makes it harder to make global changes to the document. The same applies to Heading styles which should inherit from Heading
The Below paragraph spacing in Indent and Spacing of the paragraph style of the last paragraph in the Section determines the space below the section. In other words for the purposes of spacing above and below the section, just use the paragraph styles spacing above and below. The sample attached is exaggerated for demonstration purposes; try changing to different paragraph styles to see the effects ParagraphSpacingAroundSections.odt (9.7 KB)
Sections in Writer are kind of inline page styles. They are meaningful when you want to temporarily and locally change the page geometry. This mainly addresses margins (section indents), but can be done in a more fine-tuned way with a dedicated paragraph style (translating a difference in semantics) and number of columns. IMHO, only the latter legitimates the use of sections.
Another use of sections aims at changing the location of endnotes, moving them from end of document to end of section. This is an advanced trick.
Try to keep your document structure as simple as possible. Sections introduce complications. It does not matter if your sections are quite small, but as soon as they span pages they cause performance issues (visible when a section extends on several dozens of pages in multi-column).
No.
You can base new styles on any existing ones. Display the styles in Hierarchical view to see the inheritance tree.
Inheritance rules are the basis for very powerful formatting convenience. Built-in styles are organised around a few “sub-root” styles like Heading, Header, Contents, Body Text. When you change attributes in these styles, the change cascades down to dependent styles. Attributes overridden in descendant styles are not modified.
Therefore, when you are in the formatting and layout step, you only need to focus on a reduced number of styles to “massage” the document to your preferred look. According to this scheme, Default Paragraph Style is the ultimate ancestor of all others. Its sole purpose is to set your preferred default attributes. It should never be used to format text. The standard discourse style is Body Text.
However, this method requires careful planning. So, first, learn how to use built-in styles before musing into the feature.
A style name is always unique in its category.
Personally, I don’t like the prefix idea. Probably, because I always display my styles hierarchically. I know which subtree I’ll look up for a style. See next item about my semantic styling approach.
Creating styles is not a linear process. It is iterative, hit and miss.
You first create styles for their semantic value. I insist on the fact that style application does not imply a visual aspect; it is an author’s declaration of significance. Visual aspect comes as a by-product. Look at built-ins. None of them has a visual-oriented name. The name tells something about the value of the words: heading, citation, body text, emphasis, definition, user entry, … You can then change any typographical attribute without creating anomalies. What if your style is “Red right-aligned” and you decide to change red for bold?
The Next Style setting targets another layer in the writing process. It does not belong in the “semantic” hint of the style (though this can be debated). It is a convenience feature to speed up typing to avoid having to apply manually a style when ending a paragraph. When a paragraph of a certain type (e.g. a heading) is always followed by another type (e.g. main discourse), you can record the style change in Next Style.
However, this is not frozen at all. At different moments in your creation, you can change to better adapt to your “local” text. I’d say that Next Style is set after you style collection is created, when you think about how you’ll write your book.
There is no intrinsic spacing above and below for sections.
And there is an unfortunate a bug tdf#137069 in section management where spacing below before the section and at last paragraph are suppressed. You must then workaround it by adding spacing above in the first paragraph of the section and/or the first paragraph after it.
But this may either create spurious new styles only to “fix” the bug and this pollutes your semantic styling, or add empty paragraphs with adequate settings.
Using empty paragraphs is akin to direct formatting. But since they are used only to mitigate a bug, I think it is acceptable.
By the way: empty paragraphs contains no information. Consequently, there should be no empty paragraphs in any document. Remember that vertical spacing is an intrinsic property of the significance of the paragraph; hence it is encoded in the style. Also when you edit and review your document, reflow moves text, including empty paragraphs. They can cause formatting failure and change what is captured in fields, notably when this data is related to outline (heading hierarchy).
These are very helpful comments @EarnestAI and @ajlittoz. Oh, and german apple pancakes are the best. It is very satisfying to watch that batter rise in the oven. Wonderful choice for an example
.
When I was reading, Proper and clean use of document templates and formatting styles it said that certain LibreOffice Styles are hard-wired into LibreOffice functions/features (i.e., Table of Contents). It makes sense to stick with LibreOffice Styles and their sematic meaning rather than just basing everything off the Default Paragraph.
.
Thank you.
making my way through the book, Designing with LibreOffice.