Summary: most style parameters could be hidden by default, and calculated from a small number of global parameters set by the user. This may seem a radical proposal, but discussing spacing just happens to be the easiest way of introducing a different approach to style management that eliminates the difficulties of the present arrangements. For example, if you want to modify Heading 2, you are provided with 3 horizontal indent settings (in cm by default) and a tick-box labelled Automatic. For vertical spacing you have 2 parameters in cm and another tick-box. You can also choose the line spacing. That's just the Indents and Spacing tab, for just one Heading level. Change the font size (or even only the font) at that level or somewhere upstream makes these settings inappropriate, particularly the ones in absolute units like cm. While working on Heading 2 you can't see what you may have already done to Heading 1 or 3, so there is no way of visualising quantitatively to what extent your style scheme is internally consistent. What's more, there isn't much in the style modification window, with all those tabs that jump around, to tell you where the font and other parameters were first defined, nor what effects your changes will have downstream. Not surprisingly, very few LO Writer templates are available on the web, though no doubt big users like the French Gendarmerie have expert development teams for that. The current style structure really needs to be presented as a unified organisation chart that shows the dependencies. In fact, end users and enterprises should rarely have to think about such matters. Typography is an art and a skill where the sizes of characters and their spacing are a matter of proportion. Proportions would best be decided by experts familiar with different national typographical conventions. If we take this argument to its logical conclusion, nearly everything could be calculated from what we could call a style policy file, to which the end user would have to provide only a few parameters. Individual styles would, by default, be left with very few settings and users who don't know what they're doing would be discouraged from using advanced settings. There's nothing innovative about that: it's the way LaTeX works. LaTeX was introduced in 1977, mainly for academic publishing including maths; it pre-dates most wordprocessors but is still very much in use. LO Writer has a LaTeX export function, giving access to multi-language environments and printing to professional standards. I'm not proposing that the majority of LO users will need LaTeX, which never was much fun in the office. The point to be made here is that the conceptual basis for what are now conventional wordprocessors has taken an unfortunate turn. In other words, it would be time for LO to stop trying to clone Word and adopt a different model. In the beginning, LaTeX had only one font, it's own. That restriction has been lifted and there are now several fonts specifically configured for the full range of typographical tools. At the most basic default level, the user indicates nothing but the basic font size and the language(s), leaving the software to scale all styles accordingly. Not everyone needs to diddle individual style parameters, though people often use the command \linespread to globally stretch or shrink the preset line spacings. On the other hand you can change anything you want if you use the plethoric help on the web to find and configure a package (sort of plug-in) among the hundreds available. LO is used for more varied and often less serious purposes than academic documents. However, the proposed LaTeX-like style "policy" file should not need very much user input. An example of a key stylistic choice is between indenting the first line of paragraphs, or not indenting but adding space after. Also, unlike out-of-the-box LaTeX we may declare 2 or 3 serif and/or sans-serif fonts for text, headers and some other items. Scaling of styles should depend on font metrics as well as the nominal size. You could imagine a few other global parameters, for example to vary the rate of variation of relative font size, case and character styles of headings as a function of their depth. But that's about all. Lists may be an exception worth more attention as a separate development. User requirements vary from firing bullets at subordinates to the smooth but stepwise presentation of a subtle and complex argument. Lists are difficult to manage in LO because the list styles get tangled up with paragraph styles and they require separate program menu items to set levels and turn them on and off. I note that LaTeX has the powerful enumitem package for setting up lists. This is easier than the LO facilities because it knows the width of symbols, characters and labels, so spacings can be calculated. Sadly, it lacks a GUI.
Created attachment 117651 [details] Attempt to illustrate Writer template design sheet concept This spreadsheet may help visualise the proposed approach to designing templates. It's also on GitHub: https://github.com/crlMIDI/LO-template-design-chart
<rant> sigh, sorry... this type of reports will never bring us anywhere. I some skilled dedicated people working with and active around LibreOffice Writer for longer time, knowing about use, design, code- and ODF implications work in a project and come with a balanced realistic proposal, fine :) </rant>