Style your tables

Introduction

Tables are one the most frequently used objects in documents. If you want to present data in a structured way with, for instance, small gridlines, a nice header, right aligned numbers, and highlighted totals- that’s a table. And if you need a unique branding defined by your company or just want to have a consistent look and feel you have to apply all those formattings exactly for each table. But that’s not how text processors work. And of course Libreoffice has a table style right now, or rather kind of, but well hidden and not really accessible.

Current situation

In order to apply a style to a table you have to select it, go to the main menu > table and click autoformat (actually it is labeled incorrectly with camel case as AutoFormat). The dialog offers some presets along with checkboxes where you can uncheck the properties you do not want to apply.

Figure 1: The dialog ‘autoformat’ handles table styles today.

In order to add your own table style you have to format a table as you like, start the autoformat dialog and click add, which allows to store the own configuration. Unfortunately there are some snares…

ODF Specification

The OpenDocument Format specification provides the necessary tags needed to implement table styles under the <table:table-template> element which goes in <office:styles> in styles.xml. Below is the list of tags sorted in the order of priority of it being applied to a cell

1. First column style: <table:first-column>
2. Last column style: <table:last-column>
3. First row style: <table:first-row>
4. Last row style: <table:last-row>
5. Alternative row style: <table:even-rows> and <table:odd-rows>
6. Alternative column style: <table:even-columns> and <table:odd-columns>
7. Base style: <table:body> and <table:background>

Other useful tags related to table styles include <style:table-properties/>, <style:table-row-properties/>, and <style:table-cell-properties/>

Issue

This current solution has several drawbacks. First of all it is actually not a style but applies as direct formatting to the existing table. That means it would need to be reapplied if the table was modified (e.g. if a new row was added). This is true for Writer and Calc but not Impress. This program has a ‘Table Design’ section in the properties tab of the sidebar, which allows the users to select from 11 table styles and then tweak the style by enabling or disabling various sections of the table. Unlike autoformat, that style is attached to the table and it does not suffer the same problem of the style not adapting to a change in the number of rows in the table.

• No common dialog and workflow (tdf#34391, aoo#11121)
• Style should be independent from the content, e.g. for alternating rows
• There is no access from sidebar in Writer and Calc (tdf#95279, tdf#86177)
• Styles are not imported and not preserved after Roundtrip (tdf#94076)
  

Proposal

First drafts included not only options to change a style but also the list of all predefined styles in order to apply it to the table. But actually that makes no sense because this dialog does not aim to switch between styles – this function is preserved for the table format dialog and the sidebar. The table styles dialog would be opened to manage the style only not to modify the actual document.

Since we anticipate that only a few properties of an existing table style will be changed it makes sense to introduce inheritance. That means, for instance, to load the Blue style and modify the footer row only. Doing so you may want to know from what style the current design was inherited and which properties have been changed actually.

That’s the summary we show on the left hand of the mockup. You can rename the style and you get the summary of changes plus the WYSIWYG preview. The content area contains of a dropdown to select the elements (odd/even row/column, header, footer, first and last column) with all respective properties below. The checkbox enable controls whether or not this element is part of the style.

Figure 2: Mockup for the table style properties dialog.

Quick access to the predefined styles is available from the sidebar (and perhaps also via context and main menu). To apply a table style you would go to the styles section of the sidebar and select tables there. Per double-click or apply from the context menu you activate this style (not effective respectively disabled when no table is selected). Per new or change you access the properties dialog, the second with inheritance.

Furthermore, the paragraph tab would get another content panel for tables where you have access to the styles (perhaps also with the option to add or change a style). For convenience there are the major relevant functions available, that is add/delete rows and columns as well as merge and split cells (of course the themed icons should be used later). And last but not least tweaking the most frequently changed property – cell background – is possible here as well.

Figure 3: Mockup for the table style sidebar sections.

Finally we should also think about having access to table styles from the common table format dialog.

Figure 4: Mockup for access to table style from the table format dialog.

Discussion

The proposal deals with a couple of ideas to improve the handling of table styles. First of all the style needs to be applied as such (work has begun). Depending on what is possible in respect to the ODF specification we suggest to inherit a style from another, similar to what is known from paragraph style. We tried to achieve consistency for the dialog- the two column layout, a WYSIWYG preview, and a predefined placement of controls should become the default, where possible.

What do you think about this proposal? Code in haste, repent at leisure is what we want to avoid. So don’t hesitate to dump your opinion.