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