[GSoC] Getting started with Implementing Table Styles in Calc

Eike Rathke erack at redhat.com
Wed Mar 7 15:03:08 UTC 2018 

Hi Abhishek,

On Saturday, 2018-03-03 23:49:28 +0530, Abhishek Shrivastava wrote:

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

Great I didn't scare you away ;-)

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

Depends on.. they are stored in memory for row ranges within a column,
but the problem here are alternating row attributions. These lead to
different patterns for each row within a column, thus a pattern 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?

With the current mechanism that would have to be stored in the attribute
patterns, something that is to be avoided. For the new data table styles
the effective attribution for a specific cell should be calculated on
the fly when displaying or printing.


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

Rather some ID than an enum, but yes, basically that's it.

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

That's the idea behind it, yes.


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

No. Within one data table there can be several "features" activated, for
which each inherits a parent style and only overrides the attributes it
defines, all other attributes are taken from the parent. Let me line
this out:

* Data Table
  + Whole Table Style
    direct or indirect parent of all other styles within a Data Table
  * Banded Columns feature
    * number of columns in Column Stripe 1
    * number of columns in Column Stripe 2
    + Column Stripe 1 Style
      child of Whole Table Style
    + Column Stripe 2 Style
      child of Whole Table Style
  * Banded Rows feature
    * number of rows in Row Stripe 1
    * number of rows in Row Stripe 2
    + Row Stripe 1 Style
      child of Whole Table Style
    + Row Stripe 2 Style
      child of Whole Table Style
  * First Column feature
    + First Column Style
      child of Whole Table Style
  * Last Column feature
    + Last Column Style
      child of Whole Table Style
  * Header Row feature
    + Header Row Style
      child of Whole Table Style, is parent of First Header Cell Style
      and Last Header Cell Style
      + First Header Cell Style (top left)
        child of Header Row Style
      + Last Header Cell Style (top right)
        child of Header Row Style
  * Total Row feature
    + Total Row Style
      child of Whole Table Style, is parent of First Total Cell Style
      and Last Total Cell Style
      + First Total Cell Style (bottom left)
        child of Total Row Style
      + Last Total Cell Style (bottom right)
        child of Total Row Style

I hope this clarifies.


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

The focus of this GSoC project is to
* implement the core features, structures and algorithms to handle
  a data table style (with a set of styles each) in Calc
* handle its attributions whenever the attributes of a cell are queried
  (with the proper level of precedence: cell style, data table style,
  conditional formatting, hard attribution)
* do the necessary associations with database ranges (Data -> Define
  Range...) and the existing properties like column headers
  * define additional properties at database ranges if necessary for
    data table styles
* read/write data table styles from/to OOXML and ODF

Bonus points if the implementation also provides an UNO API ;-)


> I am particularly referring to bugs
> 
> tdf#101757- Import and export OOXML table styles

That is related, though the bug/RFE is specific to Writer and maybe not
directly applicable to Calc, depends on how OOXML SpreadsheetML actually
stores these things. Once we support table styles we of course also want
to be able to import and export them from/to OOXML and ODF (for which we
probably will have to define a file format extension). So it may be good
to look at how OOXML SpreadsheetML stores data table styles to not miss
a feature in our new implementation.


> tdf#105933 - Means to modify existing table styles in a dialog

That's quite unrelated to this first Calc and GSoC task, but of course
we want to be able to edit a set of styles related to one data table
style in a way convenient for the user. I'd rather say that if you want
to continue to work on this after GSoC then this would be welcomed.


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

If there's time for it.. what we first need is all the core work to make
these things fly and be able to store it in ODF and OOXML.

> 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

No. Implementing a proper serialization to provide a set of predefined
table styles can be done anytime. Furthermore it doesn't make much sense
to start with that before it isn't known what exactly will be needed
there. Specifically, that bug/task is about redefining the existing file
format for attributes used in the existing AutoFormat, of which we want
to get rid off in favour of data table styles.


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

Don't focus too much on the existing AutoFormat stuff. It's good to
understand how it works on the attribute level, but the new data table
styles will be something completely different.

  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/20180307/f4120988/attachment.sig>

More information about the LibreOffice mailing list