Re: [GSoC] Getting started with Implementing Table Styles in Calc

Hi Heiko, Eike,

Thanks for your mails. I'd like to get involved in this project idea.

> 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.

How does setting the style as a hard cell attribute bloat the document
size ? Do the hard cell attributes get stored for each cell ?

> 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.

Yes, similar thing happens in table styles in writer as well. Each
time any  cell in the data range are changed we can recalculate the
style for the whole table?

> 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.


A data table style can be stored as a enum or something like that, of
which only the selected instance is present, and the affected cells
can refer to it for setting the attributes.
This might also help in saving up space, as cells would no longer need
to store the attributes redundantly?

What I mean is, maybe we can have a shared struct which can hold the
data table style values, and cells in data range can refer to it.

> One thing I forgot to mention is that within one data table style there
> are hierarchical relations between some areas, such as the whole table
> has one style, which is the parent of other styles if a feature of
> a table style is activated, such as if banded rows are activated there
> will be two row style alternating, of which each row style is a child of
> the whole table style; or the header row style will be a child of the
> whole table style, and the first header cell and last header cell will
> each be a child of the header row style.

What is the need of hierarchy in a table style? Wouldn't each style be
independent on its own?
Do you mean hierarchy as in different layers of style when defining a
table style?

I also went through Heiko's mail. I have some doubts on that too. What
is the real focus of this project? I am particularly referring to bugs

tdf#101757- Import and export OOXML table styles
tdf#105933 - Means to modify existing table styles in a dialog

Would this project also involve creating features to add custom table styles?

Also do you think its a good idea to start working on as Heiko pointed
out that its important to fix this serialization issue before going
further with this project.

tdf#49437 - Writer/Calc: Use XML for serializing table autoformats
instead of the current brittle binary format

As this project was under "hard" difficulty, I'd like to have an early
start. Currently I am going through the code related to how cells
attribution works and how current AutoFormat styles work.
If any related bug comes to your mind please let me know, I'd like to
work on it.