Bug 126008 - TABLES STYLES: Inserting a row/column changes entire table's formatting (see comment 5)
Summary: TABLES STYLES: Inserting a row/column changes entire table's formatting (see ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: highest major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 120068 120634 134462 136424 136532 140819 141462 143347 144046 144383 146104 149105 149299 150152 150528 150870 151601 (view as bug list)
Depends on:
Blocks: Writer-Tables-Style Cell-Add-Delete
  Show dependency treegraph
 
Reported: 2019-06-19 16:47 UTC by Michael Robinson
Modified: 2022-11-25 05:34 UTC (History)
37 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
screen capture of table after insertion (108.38 KB, image/png)
2019-06-19 16:48 UTC, Michael Robinson
Details
Writer document showing the bug (40.41 KB, application/vnd.oasis.opendocument.text)
2019-06-20 17:05 UTC, Michael Robinson
Details
Writer doc which shows change in table header and cells when adding new row (10.13 KB, application/vnd.oasis.opendocument.text)
2019-07-18 21:14 UTC, Gerhard Weydt
Details
table styles reset when adding a new row in the writer (16.12 KB, application/vnd.oasis.opendocument.text)
2020-07-25 16:21 UTC, Sahraiee
Details
Example 3 - document which can be used to replicate the bug (13.69 KB, application/vnd.oasis.opendocument.text)
2021-10-29 16:12 UTC, Ann
Details
Loss of font formatting in Writer tables. (148.78 KB, image/png)
2022-10-04 15:00 UTC, João Pedro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Robinson 2019-06-19 16:47:00 UTC
Description:
When I insert a row above an existing row within a table, LibreWriter reverts the selected existing row to the default format. This is repeatable in multiple documents and different tables. I am using LibreOffice 6.2.4.2 (x64).

Steps to Reproduce:
1.Select row (highlights the row)
2.Click Table | Insert | Rows Above
3.

Actual Results:
A new blank row is inserted above the selected row. 
Before insertion, the selected row is formatted with Liberation Serif 10 and all columns but the first are centered.
After insertion, the selected row is formatted with Liberation Serif 12 and all columns are left justified(this is the default format)

Expected Results:
I expect there to be no change in the formatting of the selected row.


Reproducible: Always


User Profile Reset: No



Additional Info:
This occurs in separate installations on my desktop and laptop computers, both of which are kept completely up-to-date in software. Thus I don't believe it is necessary to confirm that my user profile is not corrupted. I don't have OpenGL enabled.
Comment 1 Michael Robinson 2019-06-19 16:48:55 UTC
Created attachment 152291 [details]
screen capture of table after insertion
Comment 2 Dieter 2019-06-20 06:35:04 UTC Comment hidden (obsolete)
Comment 3 Michael Robinson 2019-06-20 17:05:21 UTC
Created attachment 152316 [details]
Writer document showing the bug

Look at line 4. I have just inserted a line above it. Before insertion, line 4 used Liberation Serif 10. Now it is Liberation Serif 12. Also, columns 2-5 used to be center-justified just like the rest of the table. Now they are right-justified.

None of those changes should have happened.

This has been happening for a long time, i.e. not just on Version 6.2.4.2. I am flummoxed about you not being able to reproduce it. There is nothing special about my LibreOffice installation. As I said before, it happens on two separate computers, both running the same version of Windows 10 (latest update).

If even after seeing this example you are unable to confirm the bug, then please terminate this bug report. I will just live with the problem.
Comment 4 QA Administrators 2019-06-21 02:54:23 UTC Comment hidden (obsolete)
Comment 5 Dieter 2019-06-21 06:38:38 UTC
I can confirm it with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

I found the reason: Table has table style "Default Style". If you add a row, the table changes back to setings of default style.

I created a new table without a style in comment 2 and so I couldn't reproduce it.


Steps to reproduce:

1. Create an empty table
2. Choose table style "Default Style"
3. Mark all and change alignment to center and font size to 10
4. Put cursor in one cell and add a row or a column

Actual result:
All cells change alignment and font size (Undo doesn't change this)

Expected result:
Only the new row or column has style of "Default Style".

You recieve the expected result, if you mark the whole row or column.
Comment 6 Dieter 2019-06-21 06:39:49 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2019-06-28 14:08:10 UTC Comment hidden (obsolete)
Comment 8 Dieter 2019-06-28 14:56:50 UTC Comment hidden (obsolete)
Comment 9 mini-matze 2019-07-01 09:35:58 UTC
I can't reproduce the problem with your document too, but I have the same problem with another document. After insertion all formattings are replaced by "Liberation Serif 12" - just like yours.

I think this bugreport could be a duplicate to https://bugs.documentfoundation.org/show_bug.cgi?id=120068

I created a comment there and had add an attachment. I hope this file could show the problem to others... I don't want to spam by posting all twice now. So I hope you could switch to the other bugreport to...
Comment 10 Gerhard Weydt 2019-07-18 21:14:54 UTC
Created attachment 152866 [details]
Writer doc which shows change in table header and cells when adding new row
Comment 11 Gerhard Weydt 2019-07-18 21:35:20 UTC
Comment on attachment 152866 [details]
Writer doc which shows change in table header and cells when adding new row

I created Attachment 152866 [details] to show a similar malfunction:
I created a new document and a table with style "standard" (or may be "default", I didn't check in English). I then created a new table style "demo", which simply copies "standard", because it seems that the error occurs only with table styles other than "standard" or "none".
I then created paragraph styles "demoHeading" and "demoCell" for the first and second row, respectively, and applied them to these. That is the state you see in the document.
Now place the cursor in the bottom right cell, and key Tab: the formattings caused by these two paragraph styles will vanish.
Comment 12 Harald Koester 2019-07-19 10:44:05 UTC
*** Bug 120068 has been marked as a duplicate of this bug. ***
Comment 13 Seán Ó Séaghdha 2019-10-16 05:25:50 UTC
Still the same bug from 5.3?

Just created a new table in a new document in 6.3.2.2 and the bug still lives.
Comment 14 Aron Budea 2020-06-16 05:15:16 UTC Comment hidden (obsolete)
Comment 15 Jim Raykowski 2020-06-17 20:21:06 UTC
(In reply to Aron Budea from comment #14)
> This is a regression that started from the following commit, bibisected
> using repo bibisect-linux-64-6.1, and Dieter's steps from comment 5.
> Turns out this commit was never reverted in the end? Jim, can you please
> comment?
> 
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=d1b13f486eacc60c9b71ec9f1b29cde2f4504d4e
> author		Jim Raykowski <raykowj@gmail.com>	2018-02-06 22:50:02 -0900
> committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2018-02-13 15:00:06
> +0100
> 
> tdf#108227 Set table style so it is highlighted in Sidebar styles list

commit d1b13f486eacc60c9b71ec9f1b29cde2f4504d4e was superseded by
commit 1dc25980171ff79345484631882d6ea0eb6f9388 and
commit 1d5b89eccdccb3090b5503a60f829c54c077f328

IIRC, a table having a chosen table style will replace any direct formatting with the table style formatting when rows or columns are inserted or deleted or upon reloading of the document. 'Default Table Style' is a table style that apparently has Liberation Serif 12 font and left justification. I believe this has always been the behavior.
Comment 16 Aron Budea 2020-06-18 04:05:56 UTC Comment hidden (obsolete)
Comment 17 Jim Raykowski 2020-06-19 01:51:28 UTC
(In reply to Aron Budea from comment #16)
> Thanks! Do you know what the reason for that could be? It's really not clear
> to me why everything should be reset to the table style, it makes any direct
> formatting in a table useless. I think the reasonable expectation would be
> that nothing changes when deleting a row/column, and when adding a
> row/column, the previous row/column's table style and direct formatting are
> applied together to the new one. Are there arguments against that?

AFAIK this is how table styles was designed. I suggested that table styles could be used as a template by programmatically changing to no table style after table style was used for initial creation of a table or application to existing table. This allows inserts and deletes to be done without loosing direct formatting. https://bugs.documentfoundation.org/show_bug.cgi?id=107555#c15
Default used to be what is now None.
Comment 18 Maxim Monastirsky 2020-06-19 10:51:42 UTC
(In reply to Aron Budea from comment #16)
> Do you know what the reason for that could be? It's really not clear
> to me why everything should be reset to the table style, it makes any direct
> formatting in a table useless.
As Jim said, that's how table styles were implemented right from the beginning. Here are the relevant commits:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=ac6f8bc92b1abe995694602f43d8ad108b7030fb

https://cgit.freedesktop.org/libreoffice/core/commit/?id=73f4a06c0bce51c7c8b9ae9adfdc7ffac27d06b4

I don't think that the current behavior was on purpose; it just that the implementation was not completed, and no one made any fixes to it since initial introduction. 

> I think the reasonable expectation would be
> that nothing changes when deleting a row/column,
It's not that simple, e.g. table styles support banded columns and a different last column, so when deleting columns the formatting of the nearby columns might need to be adjusted. Of course this should not touch direct formatting that was explicitly applied by the user.

> Also, the steps in comment 5 certainly have a different outcome before the
> mentioned commit and now.
That commit only made the table insert dialog apply the table style, instead of just direct formatting based on it. You could reproduce the bug before it, by manually applying a table style from the sidebar.

(In reply to Jim Raykowski from comment #17)
> I suggested that table styles
> could be used as a template by programmatically changing to no table style
> after table style was used for initial creation of a table or application to
> existing table.
Table templates ("AutoFormat") is exactly how it used to work before the table styles work. I'm not sure that reverting the table styles work is good idea in the long run. It will be better to find and fix the bugs in it.
Comment 19 Maxim Monastirsky 2020-06-24 07:57:28 UTC
Just like to point out that there was a partial solution applied with commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=09fc6fef2d03ca8558dd6f0eec45d61ceb282cb5. One problem is that it was applied only to cell properties (e.g. cell background, vertical alignment), but not to text properties. By itself this isn't something hard to fix, but actually there's much bigger problem: There is no way to store this "direct formatting applied" flag in ODF, so this works only in the same editing session, but not the next time the file is opened. The problem is that as of now table styles are really applied as a direct formatting, so a fix would need to compare the actual cell formatting and the formatting of the table style, to try to figure out which part of the direct formatting came from the table style and therefore allowed to be changed, and which was applied by the user and should be retained.

A much better (but likely harder to implement) approach might be to make table styles work as real styles, and not as a direct formatting. In terms of the file format, we already have the formatting of table styles exported and imported as cell styles under <office:styles>, so we can make it possible to reference those styles by table cells, or to be listed as parents of cell styles from <office:automatic-styles>. One problem however is that according to the ODF spec, paragraph styles take precedence over the text properties inside a cell style. Which means that we'll need also a "no style applied" state for paragraph styles, which complicates this even more.
Comment 20 Maxim Monastirsky 2020-07-17 08:18:06 UTC
*** Bug 134462 has been marked as a duplicate of this bug. ***
Comment 21 Sahraiee 2020-07-25 16:21:25 UTC
Created attachment 163531 [details]
table styles reset when adding a new row in the writer

I have the same issue in the v: 6.4.5.2.
that the table styles reset when adding a new row in the writer.
also when the format was reset, the undo command not working.
Comment 22 Aron Budea 2020-07-25 16:53:56 UTC Comment hidden (obsolete)
Comment 23 Maxim Monastirsky 2020-09-03 15:20:19 UTC
*** Bug 136424 has been marked as a duplicate of this bug. ***
Comment 24 briandb1222 2020-09-08 15:56:21 UTC
*** Bug 136532 has been marked as a duplicate of this bug. ***
Comment 25 briandb1222 2020-09-08 20:18:46 UTC
I can confirm with 

Version: 7.0.1.2
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 26 digg33 2020-11-16 16:05:08 UTC
I can confirm the same for any operation involving adding rows and/or columns left/right/above/below using any of the commands under [Table > Insert] . Tested in blank new Writer doc with Default template. Can also confirm the steps given in Comment 5.

Version: 6.4.5.2
Build ID: 6.4.5.2-5.fc32
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

Please let me know if I can do any further testing to help.
Comment 27 fmgtack+libreoffice 2021-04-14 09:25:16 UTC
A fundamental omission currently is that there appears no possibility to remove/deactivate a Table Style from a table.

On can indeed create a new table with Style "None". If later on a Table style is applied, there is no possibility anymore to remove that style: one can change, but never remove again.

There should be a way (exposed to the user) to remove a Table Style from an existing table. Now, a user applying a style to find out it does not fit the user case in its current implementation, is trapped, and has to create the table anew to get it to work.
Comment 28 fmgtack+libreoffice 2021-04-14 09:26:00 UTC
*** Bug 141462 has been marked as a duplicate of this bug. ***
Comment 29 Andy 2021-05-07 08:37:01 UTC
Confirm that table styles reset to default (and in my case to the non-showing Liberation Serif Cyrillic font - another bug) in Writer when a row or column is added or deleted. Has been happening for a long time. Very annoying.
Comment 30 Dieter 2021-05-07 08:44:13 UTC
We have five duplicates and 19 user in cc, so I think we should raise importance =>I changed it.

After reading comment 15 to comment 19 (I admit, I don't understand everything), I also removed regression keyword (everybody with more knowledge should feel to add it back, if I'm wrong).
Comment 31 João Pedro 2021-07-06 17:29:52 UTC
I can confirm the same for Windows 7 & 10/Linux Mint & Ubuntu SOs for adding and deleting rows and/or columns left/right/above/below.

I tried to fix this bug by adding another font name before Liberation font in the Expert Configuration (Tools → Options… → Advanced → Open Expert Configuration) but the same problem occurs with the new font.

Version: 7.0.6.2
Build ID: 00(Build:2)
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: pt-BR (pt_BR.UTF-8); Interface: pt-BR
Ubuntu package version: 1:7.0.6-0ubuntu0.20.04.1_lo1
Calc: threaded
Comment 32 Aron Budea 2021-07-26 01:24:53 UTC
*** Bug 143347 has been marked as a duplicate of this bug. ***
Comment 33 Buovjaga 2021-08-26 07:54:43 UTC Comment hidden (obsolete)
Comment 34 Timur 2021-09-09 09:59:38 UTC
*** Bug 144046 has been marked as a duplicate of this bug. ***
Comment 35 Timur 2021-09-09 10:01:42 UTC
*** Bug 144383 has been marked as a duplicate of this bug. ***
Comment 36 Timur 2021-09-09 10:10:10 UTC
*** Bug 120634 has been marked as a duplicate of this bug. ***
Comment 37 Timur 2021-09-09 10:14:14 UTC
*** Bug 140819 has been marked as a duplicate of this bug. ***
Comment 39 Hans Zekl 2021-09-15 12:11:03 UTC
Very annoying bug! It is still present in Version 7.1.5.2.
Comment 40 Hans Zekl 2021-09-15 12:32:25 UTC
By the way: in Calc it works!
Comment 41 Hans Zekl 2021-09-15 12:36:05 UTC
Correction: The new line gets the format of the currently selected line. If the background of the current line is colored the new line looks the same.
Comment 42 xaviermdq 2021-09-22 23:19:59 UTC
Confirmed with:

Version: 7.2.1.2 (x64) / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: es-AR (es_AR); UI: es-ES
Calc: threaded
Comment 43 Ann 2021-10-29 16:11:13 UTC
Bug observed in:

Version: 6.4.7.2
Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5
OS: Mac OS X 10.16

Given a table in a Writer document with some rows with italic and bold formatting, adding a new row to the bottom removes bold and italic formatting. 

In provided attachment (example 3), this problem can be demonstrated by going to the table on page 2 and adding a row at the bottom by selecting the row "Chairing a productive discussion" and using [right click] > insert > rows below. 

The formatting change occurs as soon as the row is inserted, before anything is typed in the cell. Furthermore, if you undo the action, the row is removed but the formatting is not restored.
Comment 44 Ann 2021-10-29 16:12:50 UTC
Created attachment 176005 [details]
Example 3 - document which can be used to replicate the bug
Comment 45 Ulrich Gemkow 2022-02-05 13:47:37 UTC
Still present in Libreoffice 7.3.0.3, first reported for Libreoffice 6.1
Comment 46 Maxim Monastirsky 2022-03-08 10:51:29 UTC
*** Bug 146104 has been marked as a duplicate of this bug. ***
Comment 47 Dieter 2022-05-26 04:59:37 UTC
*** Bug 149299 has been marked as a duplicate of this bug. ***
Comment 48 Dieter 2022-05-26 05:06:26 UTC
Still present in

Version: 7.3.4.1 (x64) / LibreOffice Community
Build ID: 13668373362b52f6e3ebcaaecb031bd59a3ac66b
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Miklos, Xisco, any chance, that this bug (with at least 12 duplicates) will get fixed within the next months? (I know, eveyone is free to pick up a bug or not).
Comment 49 Matt K 2022-08-07 02:29:03 UTC
Fix is tracked in https://gerrit.libreoffice.org/c/core/+/137915.
Comment 50 Michael Stahl (allotropia) 2022-08-11 08:55:29 UTC
i agree with Maxim in comment #19, the main problem is that Writer's table styles aren't actually styles but rather some kind of template that is re-applied on structural changes to the table.

implementing this as real styles is a lot of work though.
Comment 51 Ulrich Gemkow 2022-08-11 11:32:12 UTC
Yes, converting this to real styles may be a lot of work.
But the current situation is not acceptable.

It would really help when user would have a chance to remove
a table "style" from an existing table (see comment #27) so
setting it to "None" and prevent further "forced formatting".

Currently a table has to be deleted and newly created
using "None" as table style.

Or add a BIG warning that table styles should not be used
because they are one-way.
Comment 52 Eyal Rozenberg 2022-08-11 18:08:26 UTC
(In reply to Michael Stahl (allotropia) from comment #50)
> implementing this as real styles is a lot of work though.

(In reply to Ulrich Gemkow from comment #51)
> Yes, converting this to real styles may be a lot of work.

I would object to this framing, which may imply this work should not be undertaken.

Table Styles are a significant feature - that LO is essentially missing. Obviously it takes work to implement a significant feature, and it's not a trivial bug fix. But - is there something particularly hairy/problematic about implementing it? If not, isn't it just the "right amount of work" for a significant missing feature?
Comment 53 Regina Henschel 2022-08-11 21:03:57 UTC
A problem with Example 3 is, that the paragraph styles are not included in the "demo" table-template (although that is possible) and thus they cannot be applied, when the template is applied to the table.

(In reply to Eyal Rozenberg from comment #52)
> But - is there something particularly hairy/problematic
> about implementing it?

Styles would add a totally new way to handle tables in ODF. Currently a table has a reference to a table:table-template [1] and has attributes, which parts of the template to use [2]. And it has a reference to a table style [3]. The style contains such things as margins, writing-mode, breaks. 

In my opinion, not a new concept "style" should be implemented, but the existing means "table:table-template" should first be implemented cleanly and with full UI, especially in Calc. Only then it should be considered how the file format should be extended. Since not only Excel but also Gnumeric is affected by changes to tables, decisions in the ODF TC are not easy.


[1] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#element-table_table-template
[2] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#element-table_table
[3] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#element-style_table-properties
Comment 54 Timur 2022-09-05 07:56:24 UTC
*** Bug 150528 has been marked as a duplicate of this bug. ***
Comment 55 Timur 2022-09-05 08:02:22 UTC
*** Bug 150152 has been marked as a duplicate of this bug. ***
Comment 56 Telesto 2022-09-08 21:27:43 UTC
*** Bug 150870 has been marked as a duplicate of this bug. ***
Comment 57 Kamil Landa 2022-09-19 17:55:44 UTC
I think the bug 143234 is related, maybe duplicate.
Comment 58 Dieter 2022-09-21 06:33:48 UTC
(In reply to Matt K from comment #49)
> Fix is tracked in https://gerrit.libreoffice.org/c/core/+/137915.

Matt, are you still working on it? As far as I understand comments in gerrit, it isn't fixed. Since importance is highest, it would be nice to have an update about your work. If you're not longer working on it, please remove yourself as assignee. Thank you.
Comment 59 lachend 2022-09-21 14:47:46 UTC
I can confirm this for Lubuntu for adding and deleting rows and/or columns left/right/above/below.
Version: 7.3.6.2 / LibreOffice Community
Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e
CPU threads: 2; OS: Linux 5.15; UI render: default; VCL: qt5 (cairo+xcb)
Locale: uk-UA (uk_UA.UTF-8); UI: uk-UA
Calc: threaded
Comment 60 João Pedro 2022-10-04 15:00:13 UTC
Created attachment 182827 [details]
Loss of font formatting in Writer tables.

Loss of font formatting in Writer tables. Insert table crashes font format.
Comment 61 Rafael Lima 2022-10-17 22:35:08 UTC
*** Bug 151601 has been marked as a duplicate of this bug. ***
Comment 62 Rafael Lima 2022-10-17 22:36:00 UTC
*** Bug 149105 has been marked as a duplicate of this bug. ***
Comment 63 Eyal Rozenberg 2022-10-18 21:13:53 UTC
(In reply to Regina Henschel from comment #53)
Well, rephrasing your comment, I read it as saying that "table styles" do exists, but only encompass a limited set of properties; and some of what they're missing exists in "table templates".

Now, let's assume for the sake of discussion that neither templates nor table styles were part of the spec, i.e. that we're redesigning this aspect of the ODF spec from scratch.

Well, we already have the concept of "style": We have character, paragraph, list and page styles. Styles of the same kind have a tree inheritance structure, and styles can also contain other styles - at least implicitly: The default character style of of a paragraph. We also have a rich UI for working with styles, particularly in Writer.

With that in mind - what is the benefit of having "table templates" in the spec, which are non-styles? It seems to me a better idea to unite table templates and table styles, and have them be proper styles, so that when we change the style, the tables created using it will themselves change. Of course that will also entail table cell styles being full-fledged styles, which we can also edit using the Styles sidebar. ... I suspect this might even shorten the spec!

Now, if you are arguing that the current spec should be implemented as-is before changes are considered - I think I would disagree, because if we decided that proper table styles are the way to go, then expanding the implementation of table-templates as a sui-generis feature would entail significant effort which would later probably be either lost or require major refactoring. 

At the very least I think we should reach tentative consensus here on what we want the ODF spec to have; then - assuming we decide we want proper table styles - we sound off the TC about this possibility to get some initial feedback. That feedback (e.g. "No way in hell", "Great idea let's do it" or "Nice idea but it's a lot of effort so not so fast" etc.) should guide a decision on how to proceed.

... and excuse me for making grandiose diplomatic plans for everyone :-)
Comment 64 Maxim Monastirsky 2022-10-19 00:04:57 UTC
(In reply to Eyal Rozenberg from comment #63)
> With that in mind - what is the benefit of having "table templates" in the
> spec, which are non-styles? It seems to me a better idea to unite table
> templates and table styles, and have them be proper styles,
What makes table templates to be "non-styles"? The fact that they have different markup in the file format shouldn't really matter, as long as they can be interpreted and work like styles. So I see no point in mixing a discussion about the file format quirks into a discussion about the app problematic behavior, unless it's proven that a particular desired behavior can't be implemented with the current format.

In fact, I see nothing in the spec that mandates applying a template using direct formatting rather than real styles. Actually, if we read the spec literally it seems to suggest otherwise, for example: "16.21.2 <table:first-row> ... specifies a cell style that shall be applied to the first row of a table.". This sounds like the cell style itself should be applied, and not that its formatting should be copied and applied inline (like what is done currently by Writer).

> so that when we
> change the style, the tables created using it will themselves change.
There's no reason why it can't work with templates. The fact that templates assigned to tables (via the table:template-name attribute), suggests that applying a template isn't a one-time thing. And so it's reasonable to expect that template changes will be reflected in all tables that reference that given template.
Comment 65 Emanuele Gissi 2022-10-20 09:42:03 UTC
This bug keeps appearing in all Libreoffice versions I am using.

It is still present in:
Version: 7.3.6.2
Build ID: 30(Build:2)
CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3
Locale: it-IT (en_US.UTF-8); UI: en-US
Calc: threaded

Each time you modify a table you need to reapply all the styles.
This is unacceptable, even for us the LO lovers ;-)

There are currently 37 users in the CC List, because this is really a blocking issue.
Comment 66 Eyal Rozenberg 2022-10-22 16:00:32 UTC
(In reply to Maxim Monastirsky from comment #64)

Bottom-line of my reply: If we at least had cell styles as proper styles, that would already resolve this bug, since inserting a new row/column would should keep other cells adhering to their cell styles. We don't have to decide whether and when a template is actually a style.

Now for some details:

> What makes table templates to be "non-styles"?

The fact that, when you change them, the tables created using them don't change. i.e. the link of the template to the table is broken right after table creation.

> So I see no point in mixing a
> discussion about the file format quirks into a discussion about the app
> problematic behavior, unless it's proven that a particular desired behavior
> can't be implemented with the current format.

But, Maxim, you're the person who brought them up in comment 19, where you said:

> A much better (but likely harder to implement) approach might be to make table styles work as real styles, and not as a direct formatting. 

You claim we should not consider this solution unless all options are exhausted using the current format. I disagree! If we reach an agreement that table styles are the way to go, it may be inadvisable to invest even more effort in a mechanism which may be discarded later.

> In fact, I see nothing in the spec that mandates applying a template using
> direct formatting rather than real styles.

Well, they're called "templates". That's what templates are. Just like if I create a new Writer document from a template, then change the template's ODT, I wouldn't expect the document to change.

> Actually, if we read the spec
> literally it seems to suggest otherwise, for example: "16.21.2
> <table:first-row> ... specifies a cell style that shall be applied to the
> first row of a table.". This sounds like the cell style itself should be
> applied, and not that its formatting should be copied and applied inline
> (like what is done currently by Writer).

Now this is actually a different point and an interesting one. i.e. you're saying "Let's not have a change to the template affect the table, but let's have the template use styles as much as possible, so that we can get most of the benefits of using styles.

And - that's already half-way to proper table styles, because we will at least need "table cell styles" which we don't have now on the styles sidebar.

> > so that when we
> > change the style, the tables created using it will themselves change.

The cell style yes, the template no.

> There's no reason why it can't work with templates. 

The fact that they're templates. A style is not a template after all.

> The fact that templates
> assigned to tables (via the table:template-name attribute), suggests that
> applying a template isn't a one-time thing. And so it's reasonable to expect
> that template changes will be reflected in all tables that reference that
> given template.

I disagree. However, if we just adopted cell-styles, that would probably resolve this bug without deciding the deeper argument
Comment 67 Maxim Monastirsky 2022-10-22 19:06:36 UTC
(In reply to Eyal Rozenberg from comment #66)
> Bottom-line of my reply: If we at least had cell styles as proper styles,
> that would already resolve this bug
We agree on this. This is what I proposed in comment 19, and in fact how it works in Impress/Draw already, so there's no reason it wouldn't work also for Writer.

> since inserting a new row/column would
> should keep other cells adhering to their cell styles.
This is not accurate. The whole point of table styles is to keep the table formatted consistently after row/column insertion/removal, so e.g. a row that used to be odd, will become even after another row was inserted above it, and it should replace the cell style associated to it. The benefit of using cell styles is that it makes it easy to distinguish between the formatting that comes from the style, and the manual formatting applied by the user on top of it, and only swap the underlying style on row insertion, keeping the manual formatting intact.

> > What makes table templates to be "non-styles"?
> 
> The fact that, when you change them, the tables created using them don't
> change.
It shouldn't be like this, in *in fact* this is not the case. While there is no UI to edit the styles, you can use the "Update Selected Style" action to modify them, and you can see how other tables update as well. And yes, there are bugs in this mechanism currently, but you can see the intention anyway.

And that's the case also in Impress/Draw, where editing a style (possible with https://gerrit.libreoffice.org/c/core/+/140943) updates all the tables that use it, although it uses the very same "table templates" ODF thing as the on-disk format.

> i.e. the link of the template to the table is broken right after
> table creation.
That's surely not the case. As mentioned in my previous comment, the spec defines the table:template-name attribute on tables to keep that link. With your interpretation of templates, that part of the spec makes no sense.

Also - the pure existence of this bug proves otherwise, as the source of it is in applying the linked template on row insertion (but in an unhelpful way - direct formatting instead of cell styles).

> > So I see no point in mixing a
> > discussion about the file format quirks into a discussion about the app
> > problematic behavior, unless it's proven that a particular desired behavior
> > can't be implemented with the current format.
> 
> But, Maxim, you're the person who brought them up in comment 19,
No at all. I was talking about *cell* styles that should be used by templates instead of direct formatting, and that already exist in ODF, *not* about a new kind of "table styles" (whatever that means).

> You claim we should not consider this solution unless all options are
> exhausted using the current format.
Not true. I fully support using *cell* styles as part of templates, which is what I suggested in comment 19. I do not support a new kind of "table styles".

> > In fact, I see nothing in the spec that mandates applying a template using
> > direct formatting rather than real styles.
> 
> Well, they're called "templates". That's what templates are.
With your analogy, it should not be possible to define paragraph styles in a Writer template, because a template should be direct formatting all the way. Much like you create a Writer template with paragraph styles, and then use those styles as real styles in your document, you can also create a table template with cell styles, and use them as real cell styles.

Besides, "templates" is just a technical term used in the spec, which makes no difference to the end user, that only wants the software to behave in a certain way. I think that our mission as an office suite, is to provide users the functionality they want, not to design beautiful on-disk format specs. So we should concentrate on implementing the functionality first, while adapting/replacing the on-disk format as needed.

> create a new Writer document from a template, then change the template's
> ODT, I wouldn't expect the document to change.
This actually sounds like a potentially useful feature. If you have several documents created from the same template, and now want to change some style in them. Instead of going one-by-one to change the styles, what if we had a (optional) mechanism to update them all at once based on the template.

> you're
> saying "Let's not have a change to the template affect the table, but let's
> have the template use styles as much as possible
No. I do want changes to the template itself to be also applied to tables that use the template. For example, if a template defines that the table header row should be using the cell style "A", and I change the template so that the header row should be using the cell style "B" instead, I expect all the tables that use this template to switch to style "B" for their header rows.
Comment 68 João Pedro 2022-10-24 13:17:34 UTC
That bug happens whenever you insert or delete any row or column, even using table styles and it appeared from version 4 or 5 (I don't remember exactly which one). I already tried to edit the fonts in the settings for experts, but it only changes the problem for another one, because it changes the font for the one indicated there.
Comment 69 Matt K 2022-11-25 05:34:31 UTC
(In reply to Dieter from comment #58)
> (In reply to Matt K from comment #49)
> > Fix is tracked in https://gerrit.libreoffice.org/c/core/+/137915.
> 
> Matt, are you still working on it? As far as I understand comments in
> gerrit, it isn't fixed. Since importance is highest, it would be nice to
> have an update about your work. If you're not longer working on it, please
> remove yourself as assignee. Thank you.

I'm no longer working on it.  My fix is simple for the simple situations (most common?), but it seems additional behavior is wanted.