[GSoC] Getting started with Implementing Table Styles in Calc

[Eike Rathke]

Hi Abhishek,

On Sunday, 2018-02-25 03:46:16 +0530, Abhishek Shrivastava wrote:

> I would like to get involved in the calc related GSoC project
> "Implement table styles", it would be great if anyone could point me
> to the areas in code I should be looking at to better understand this
> problem and how to fix it.

Welcome and thanks for your interest in Calc data table styles!

> Also, what code parts to look at to understand how the Table Styles
> are implemented in Impress?

Implementation in Impress probably wouldn't be of any help because
things in Calc work quite different.

To clarify a bit, one needs to know that there are different layers of
cell attribution, each overriding the other if the same attribute
(background color, number format, ...) is set, from top to bottom:

* hard cell attribute
* conditional format
* cell style

So if for example a background color is set as hard attribute, it
overrides any background color attribute that is set in a conditional
format or cell style. Code looking up the current attribution of a cell
has to evaluate the precedence of cell style, conditional format and
hard cell attribute.

Hard cell attributes are combined into patterns of SfxSetItem in an
SfxItemSet, and a row range within a column formatted identical shares
one pattern, a ScPatternAttr, see sc/source/core/data/patattr.cxx

The current implementation of applying Format -> AutoFormat Styles...
creates hard cell attributes with colors and number formats and borders
(or any other cell attribute), which has several disadvantages.

First, alternating formatting for even and odd rows creates alternating
patterns, which can be a waste of memory for large table ranges and
slows down lookup of pattern ranges.

Second, specifically the alternating rows formatting doesn't follow the
visual expectation if for example one row is hidden, which also just
hides the attribution of that row instead of dynamically adjusting the
display to the data table style.

Third, inserting rows should apply the correct formatting of alternating
rows (if set in the style) and adjust following rows, similar for
deleting rows, but they don't.

What we actually need is another layer with a precedence order of

* hard cell attribute
* conditional format
* data table style
* cell style

The data table style shall be implemented such that it takes *one*
attribute in the pattern (just which data table style is in use), so
a row range within a column can share one pattern (unless hard
attributes are present as well). Displaying a cell with the data table
style will have to evaluate how to actually display the cell in
question, depending on its position within the dynamic table.

Possible might also be to not have the data table style attribute in the
cell attributes but hold another structure at the column, only present
if at least one data table style is applied, but that of course also
needs to handle insertion/deletion into/from ranges and move of ranges
and the like.

Cell ranges / data tables formatted with such data table styles should
also be a defined Database Range (see Data -> Define Range...) to handle
the overall cell range and properties like whether a header row (column
names) is present and total row and the like.

One data table style would be quite similar to a conditional format in
the sense of how it could be handled at the document, keeping a list of
data table styles, each having one SfxItemSet for the various properties
each, such as top row, banded rows/column, column stripes, row stripes,
leftmost column, rightmost column, total row, ...

Implementation of obtaining the actual attributes relevant for display
or to forward to the EditEngine would be quite related to how
conditional formats are handled, so it's worth to take a look at
functions that use a SfxItemSet* pCondSet like in many
sc/source/core/data/column*.cxx functions or in
sc/source/core/data/patattr.cxx, these probably need to handle an
additional SfxItemSet* for the data table style.

I hope this gives you some ideas to wrap your head around :-)

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20180227/fb65b67d/attachment.sig>