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
Attachment:
signature.asc
Description: PGP signature