Description: I have a multi-page table which I originally created using the autoformat style Elegant. I've color coded groups of rows to distinguish them. I need to insert a row. When I do so all the color coding is removed and the font color reverts to Automatic for the entire table. While that's the my noticeable problem, it appears that other table properties are also lost. For example, header rows no longer appear at the top of pages 2, and so on. Steps to Reproduce: 1. Create table using autoformat style Elegant. 2. Insert text. Color it. Change other table properties. 3. Insert a new row. Actual Results: Entire table reverts to Automatic color text. Edit -> Undo does not help -- all text remains Automatic color. Table headers are forgotten, and do not appear at the top of subsequent pages. This may be related to Bug 83667. Expected Results: Customized table properties such as colored text and headers are unaffected. Workaround is to reapply customizations and hope I need not insert another row. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.1.2 Environment: CPU threads: 2, OS: Linux 5.4 User Inteface: UI render: default; VCL: gtk3 Locale: en-US (en-US.UTF-8); UI: en-us Misc: Ubuntu package version 1:7.1.2_rc2-0unbutu0.18.04.1~lo1 Calc: threaded Linux Mint Tricia 19.3.
Applying Table Autoformat indeed removes any possibility for manual formatting. That means, it may be there at first, but as soon as the table is edited, it is reverted. Wider issues with the current implementation of "Table Styles" (Autoformat) include 1) You cannot customize an applied Table Style 2), even worse, once an Autoformat is applied, it is impossible (as of LO Writer 7.1.2.2) to remove the autoformat. It can only be changed.
*** This bug has been marked as a duplicate of bug 126008 ***
Thank you for your attention to these problems. It seems like some of the behaviors are design decisions. For example, re-applying the autoformat style after an edit may be what the original implementor wanted. If that's true this becomes a documentation issue. The documentation for LibreOffice V7.1 does not discuss how tightly tables adhere to the autoformat style originally applied to them. There's a discussion and proposal for change in the way autoformatting applies at https://design.blog.documentfoundation.org/2015/12/13/style-your-tables/ . It may be that the proposal involves more work than is worth the trouble, but it's at least interesting and it might give a one-up advantage against competitive word processing applications.