Bug 126008 - TABLES STYLES: If you insert a row or column (with cursor in a cell), the formatting of the whole table changes (steps in comment 5)
Summary: TABLES STYLES: If you insert a row or column (with cursor in a cell), the for...
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 (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: 2021-10-29 16:12 UTC (History)
25 users (show)

See Also:
Crash report or crash signature:


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

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
(In reply to Xisco Faulí from comment #7)
> is this the same as bug 105799  ?

Bug 105799 isn't about inserting new row

> Could you please try with a recent master build ?

Also present in actual master

Version: 6.4.0.0.alpha0+ (x64)
Build ID: ae823e4633a76d13cebc6432b9e44b9b2862326b
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-26_23:06:07
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded
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
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
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
(In reply to Jim Raykowski from comment #15)
> 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.
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?

Also, the steps in comment 5 certainly have a different outcome before the mentioned commit and now.
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