LO 5.3.6.1 , experimenting with table styles
It looks like Auto-format Styles store only settings from Boders and Background tabs of table properties.
Number of rows and columns must be set when creating the table. Also spacing "around" the table (left, right, above, below and others in Table tab) is not part of the auto-format style.
These shortcomings seriously impede the usefulness of table styles. This is even aggravated by the impossibility to modify the style once created, or even to create a new style with right-click in the styles panel (auto-format style can only be created from a table, not from scratch).
The question is: what are table styles intended for? I'd hope to use them just like paragraph styles, so that table maintenance reduces to tuning the table style whose changes propagate to all tables controlled by this style.
Are table styles a still experimental feature which will improve in future versions? Should I fill in a feature request in TDF to draw developers attention on it?
EDIT 2017-10-8 (it's rather a comment on @Regina's answer but I'm too limited by the available length of an "official" comment)
Erst, danke sehr für Ihre wertvolle Antwort.
I skimmed through the ODF specification and read the rich features available for table ornamenting. However, though the authors went very deep into inside formatting (which can partly be handled with paragraph styles in the simplest cases), they totally missed outside formatting.
When you typeset an element in a document, you care both for intra-preperties (font and its variants, line spacing, colour, background, …) and for extra-properties (margins, space above/below, text flow: keep-with, nreak, widow/orphan, …). The outside properties contribute heavily to the pleasant look of the final copy (think of a book without space between paragraphs, even heading) and it is very conveninent to tune that from a single location (after all, this is what styles are intended for).
Table styles should control all properties from Table->Table Properties…, including spacing around the table. In short, they should be a shortcut for setting everything out of this dialog. On a practical side, I wonder if these style should define the number of columns because there are semantic questions associated with it, for example:
- what happens when you create a table? You first insert a blank table, then style it. Should the
column columns suddenly appear? - if you restyle the table, should extra columns be deleted, kept or added
of if the new style has a different number?
Personnally, on first thought, I'd be in favour of including the number of columns in the style, thus allowing to set accurately their width for all instances, but my opinion could change with experience.
For convenience, the style should impose a minimal number of rows equal to n+1, where n is the number of heading rows, and never reduce the number of rows on restyling.
A true table style is more than just a template: the table retain the association with the style so that when the latter is modified, table appearance is instantly changed for all instances linked to the style. Modifying a template (I'm not talking about document templates .ott), does not change the existing instances; it will affect only future uses.
Such table styles would solve some of my concerns (and certainly others') like changing the spacing around similar tables or their border theme without the risk of inconsistency. The ODF specification is great for describing the computer representation of a document but it does not encompass the use cases (it is not its purpose). The authors must keep in mind user expectations (whic are limitless!) so as not to reduce too severely the versatility of the final application while users must accept some limitations to allow the application to remain technically relatively simple and easy to maintain.
Well, that's dreaming aloud, but I'm aware of the difficulties and I'll be patient.
Tschüss!
