Hey Tomaž, On Wed, Aug 13, 2025 at 4:13 AM Tomaž Vajngerl <qui...@gmail.com> wrote:
> Hey Markus, > > On Sun, Aug 10, 2025 at 10:55 PM Markus Mohrhard > <markus.mohrh...@googlemail.com> wrote: > > > > Hey all, > > > > I have been playing a bit with an implementation for Calc table style > support including OOXML support. I'm not too happy with some of my design > decisions so wanted to see what other people think before I spend any more > time on this. > > > > The code can be found in the branch feature/calc-table-styles > > > > Attached are two screenshots showing a comparison between the MSO Excel > rendering of my test document and the current Calc rendering. > > > > Note that this also includes a number of related database range > improvements, including a small sidebar section with database range/table > style properties, a handle to change the size of database ranges when they > are selected and a script to generate the OOXML default style information > in a way that we can use them easily from code. > > > > My current code has the following limitations that I'd like to fix > before this would be ready to merge: > > > > font formatting is not implemented at all. Font handling is a lot more > complicated than background and border handling > > border handling is per cell right now but it should be based on the > property that provides the border definition, e.g. if the border definition > comes from row striping the left border only applies to the left edge of > the table and not each cell in the corresponding row. > > > > The dxf handling for vertical and horizontal border definitions got > added already but not the rendering part > > > > unit tests are completely missing > > link between table style and DB goes through the name instead of a > reference to the actual table definition > > The autoformat feature should be removed and folded into the table style > implementation which would also provide a UI for modifying table styles. > > merged cells are not handled at all right now > > some UNO interfaces to interact with this feature > > > > > > Additionally, I might fix the following database range related issues > before merging if I continue with the current design: > > > > the subtotal row does not move when the database range gets expanded > > the filter buttons can disappear when in tables without headers. MSO > does not allow filter buttons on rows without headers but Calc supports > this. As soon as the filter buttons disappear you can not remove the filter > without using the show hidden rows feature. If you use the feature the > filter settings and the document behavior are no longer in sync. > > the ability to change the database range name and automatically adapt > all the formulas referencing the range. We have an UNO API to change the > name but it breaks all structured references > > > > > > Now to the part that I'm not happy with and why I think someone else > might want to have a second look at the ideas behind this change: > > > > Storing the table style information purely on the ScDBData makes some > operations quite easy but at the same time makes the code in > ScDocument::FillInfo a lot more complicated. At the same time I have not > come up with a design that would allow us to avoid the position dependent > property lookup during FillInfo. We could store a reference to the table > style in the ScPatternAttr but then we need to keep the ScDBData range and > the ScPatternAttr in sync. In my mind the table style information is not a > cell attribute until the rendering stage. > > Adding font handling is going to be painful as the font lookup is > delayed until the actual drawing > > > > My current idea would be to store a reference to the table style and a > struct storing the style lookup information, e.g. this cell looks at first > column stripe, second row stripe and whole table item sets. This way the > information only needs to be computed once and the lookup for all the font > properties can be done reasonably quickly. > > Potentially this could also be done by combining the handling of > conditional formatting and table styles. In theory a slightly cleaner > approach would be to have a list of SfxItemSet instances that are checked > in order until an explicitly set item was found. That way there is no need > to encode application layer information into the rendering code. > > > > The fix for the border drawing issue mentioned above requires the > dynamic generation of new border items that can be passed through > ScDocument::FillInfo to the rendering code or a rework of the border > rendering. > > > > I'd appreciate feedback from some other Calc developers about the design > and whether it is worth continuing with this design. > > That's awesome! I'll check it out - I just need a bit of time. So far > I checked the first 2 changes and it seems they could already be > merged to the master as they seem to be independent changes. > The database range changes in that branch are tightly related to the table style changes. They are often consequences of improvements that I came up with to make dealing with the table styles a lot easier. Once everything is working I will land the changes in steps but for now these are often changing in lock step. Cheers, Markus > > > Cheers, > > Markus > > Best Regards, > Tomaž >
