Description: Source: https://ask.libreoffice.org/en/question/145799/lo-6003-writer-tables/ Problem with formatting when inserting a new row in a table. Steps to Reproduce: 1. Insert a table 2. Remove all borders from the table 3. Add a row pressing tab (border is back) Second one: 4. Select the table 5. Change the font setting for the table 6. Add a row using table 6. Press CTRL+Z. Table font setting back to default Actual Results: Borders aren't permanent Expected Results: Adding a table row shouldn't affect formatting Reproducible: Always User Profile Reset: No Additional Info: Version: 6.1.0.0.alpha0+ Build ID: 8a0b61172a14b8b766a2e85f27762db3558d3af7 CPU threads: 4; OS: Windows 6.3; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2018-02-06_03:28:54 Locale: nl-NL (nl_NL); Calc: CL User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
@Jim Raykowski Adding you for the record, another "default table style" (https://gerrit.libreoffice.org/#/c/46842/)
Created attachment 139719 [details] Bibisect log Bisected to: author Jan Holesovsky <kendy@collabora.com> 2015-09-26 16:19:24 +0200 committer Jan Holesovsky <kendy@collabora.com> 2015-09-27 22:48:21 +0200 commit ac6f8bc92b1abe995694602f43d8ad108b7030fb (patch) tree ae8ed9337704cd83ab10e4c9cce4b7e06aaa7e8e parent 5c26f79467e4c5f920b77a058aa079654c322c25 (diff) sw table styles: Implement table styles in Writer. This extends the table auto formats so that SwDoc keeps track of the auto formats used in the document. With this in mind, we can update the format of the table with every operation like adding/removing a line, splitting a table, etc. So far we only have the core functionality, and cover inserting a line in the table; more to come. Based on work of Alex Ivan <alexnivan@yahoo.com> during GSoC 2013 - thank you!
*** Bug 115482 has been marked as a duplicate of this bug. ***
*** Bug 115572 has been marked as a duplicate of this bug. ***
Adding CC to Jan Holesovsky
*** Bug 115606 has been marked as a duplicate of this bug. ***
*** Bug 115613 has been marked as a duplicate of this bug. ***
*** Bug 115468 has been marked as a duplicate of this bug. ***
GetDocShell()->GetFEShell()->UpdateTableStyleFormatting(); removing this from https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/tblrwcl.cxx#638 seems to fix the inserting a row issue and... removing it from https://opengrok.libreoffice.org/xref/core/sw/source/core/docnode/ndtbl.cxx#2135 seems to fix the deleting a row issue
*** Bug 115677 has been marked as a duplicate of this bug. ***
Has been around since 5.3 if a document is opened with a table style applied a table. Ljiljan will submit a sample document for it. It is only more prevelant now as we are applying the default table style to all inserted tables.
When posting Bug 115677 I did not realize there was a link with styles. However, I have now tried to take the table back to default text style before editing, but the formatting loss is still there. Also, I tried to change the "table style" before editing, bot no. Nothing changes and the problem is still there. So I can see no workaround to this afforded by fiddling with style, eithre text or table ones. If anyone has suggestions for a workaround please forward it ASAP. My daily workload has increased significantly (5 to 10%) due to this, having to often work with tables.
Created attachment 139918 [details] working file Go to the last column, last row, and press Tab. Table formatting will be changed.
*** Bug 115743 has been marked as a duplicate of this bug. ***
*** Bug 115761 has been marked as a duplicate of this bug. ***
(In reply to Ljiljan from comment #13) > Created attachment 139918 [details] > working file > > Go to the last column, last row, and press Tab. Table formatting will be > changed. I applied Jim's patch https://gerrit.libreoffice.org/#/c/49831/ but unfortunately the problem did not go away.
(In reply to Buovjaga from comment #16) > (In reply to Ljiljan from comment #13) > > Created attachment 139918 [details] > > working file > > > > Go to the last column, last row, and press Tab. Table formatting will be > > changed. > > I applied Jim's patch https://gerrit.libreoffice.org/#/c/49831/ but > unfortunately the problem did not go away. Yes it does not work with this attachment since the table in the attachment was created prepatch. Try recreating the table after the patch is applied. You should notice in the sidebar styles table styles that the table style changes from highlighting whatever the initial chosen style is, Default Style if no style is selected when created, to no style highlighted when a change is made to the table using the table properties dialog. Also I just noticed, and this may work pre patch, if the table is copied and pasted the initial table style is not highlighted in the sidebar styles for the pasted table. When the tab key is pressed in the last cell or insert or delete row or column is done on the pasted table it does not lose formatting. Another thing I just noticed is it does not work if formatting changes to borders are made using the table toolbar unless the table properties dialog has been used to change a table property first. This patch simply sets the table style of the table to none when the ok button is pressed in the table properties dialog.
(In reply to Jim Raykowski from comment #17) > (In reply to Buovjaga from comment #16) > > (In reply to Ljiljan from comment #13) > > > Created attachment 139918 [details] > > > working file > > > > > > Go to the last column, last row, and press Tab. Table formatting will be > > > changed. > > > > I applied Jim's patch https://gerrit.libreoffice.org/#/c/49831/ but > > unfortunately the problem did not go away. > > Yes it does not work with this attachment since the table in the attachment > was created prepatch. > > Try recreating the table after the patch is applied. You should notice in > the sidebar styles table styles that the table style changes from > highlighting whatever the initial chosen style is, Default Style if no style > is selected when created, to no style highlighted when a change is made to > the table using the table properties dialog. Ah, I confirm the problem is gone when I do the steps from Telesto's description.
With LO 6.0.0.3 on Windows 10 Pro I'm affected from this bug too. According to Andy this is a very severe bug for me, because I often work with tables with complex formatings in writer, which is now nearly impossible.
There is a workaround for the problems that are being reported here. 1. insert a table using menu > Table > Insert Table... or Ctrl+F12 2. click on Auto Format button None is selected in the Format list box 3. click OK 4. click Insert 5. Make format changes to the table
When certain format changes are made to a table (font, font size, border, background, etc) the current table style of the table should be replaced with no table style. Patch set 2 doesn't do this but it does allow tables that are created using the toolbar table insert item and the Menu > Table > Insert Table... > Insert Button to not be reverted to the Default Style when formatting changes are made.
Changing font attributes for style table content is reverted or ignored. 1. create a table (2 column, 6 row) 2. Change the font and font size for the tyle element "table contents" apply change 3. Edit some cell contents - the changed attributes are not used, they should be 4. Select all cells in the table 5. Double click the table contents style to apply it - it is applied 6. Insert a row above some other row - those changed attributes disappear, the default values for table contents is applied - should not happen 7. Press Ctrl-z - this removes the inserted row however, it does not revert the changed font attributes incorrectly applied when the new row was inserted. LO 5.3.7.2 does not have this issue.
(In reply to Jim Raykowski from comment #20) > There is a workaround for the problems that are being reported here. > > 1. insert a table using menu > Table > Insert Table... or Ctrl+F12 > 2. click on Auto Format button > None is selected in the Format list box > 3. click OK > 4. click Insert > 5. Make format changes to the table Hi, I am trying to follow your advice but... when I click on the autoformat button in the toolbar, the dialog window that is shown has a list of styles on the left and the one selected is "default style". THere is no such a thing as a "none" item in the list, if that is what you mean.... Or, I can find no way to deselect that one without selecting another item in the list, if you meant to deselect all items. Please help understand what I am missing. thanks
When certain format changes are made to a table (font, font size, border, background, etc) the current table style of the table should be replaced with no table style. Patch set 2 doesn't do this but it does allow tables that are created using the toolbar table insert item and the Menu > Table > Insert Table... > Insert Button to not be reverted to the Default Style when formatting changes are made. (In reply to Andy from comment #23) > (In reply to Jim Raykowski from comment #20) > > There is a workaround for the problems that are being reported here. > > > > 1. insert a table using menu > Table > Insert Table... or Ctrl+F12 > > 2. click on Auto Format button > > None is selected in the Format list box > > 3. click OK > > 4. click Insert > > 5. Make format changes to the table > > Hi, I am trying to follow your advice but. > when I click on the autoformat button in the toolbar, the dialog window that > is shown has a list of styles on the left and the one selected is "default > style". > THere is no such a thing as a "none" item in the list, if that is what you > mean.... > Or, I can find no way to deselect that one without selecting another item in > the list, if you meant to deselect all items. > Please help understand what I am missing. thanks Hi Andy, To use this work around you need to insert the table by opening the Insert Table dialog and then clicking on the AutoFormat button. There are two ways I know of how to open the Insert Table dialog. 1. menu > Table > Insert Table... 2. Ctrl+F12 Another work around is to copy and paste the table. The pasted table will not loose formatting changes.
@Buovjaga I'd like your thoughts on patch set 2 when you have time. Thanks.
In my earlier comment I said that LO 5.3.7.2 does not have this issue. LO 5.3.7.2 on XP did not have the issue however LO 5.3.7.2 taken from the archive on a Unix (deb) system does have the issue.
There have been some work-around comments that mention using the 'none' option on the auto format button. I too cannot find a 'none' option. The only possibility is to make a selection of one of the styles presented. If the default style is taken, it is not the current default style but the original style before the 'table contents' style was updated. For whatever reason, after selecting something - it doesn't matter what - Ctl-Z can be used to remove the selection. At this point, the table appears like it should. In short, a work around might be: 1. Select the auto-format button 2. Choose any of the available styles 3. After it has been applied, use Ctl-Z to remove the choice Any chance we'll see a real fix soon?
(In reply to Jim Raykowski from comment #25) > @Buovjaga > I'd like your thoughts on patch set 2 when you have time. Thanks. Ok, I built it and did 1. Insert table 2. Change style to Box List Green 3. Formatted one row to be different color Table style stayed Box List Green.
The following paragraph is from my interpretation of the AutoFormat code. AutoFormat is not the same as a style or template. Once an AutoFormat is set for a table that table will lose user formatting when adding or removing a row or column because that is what it has been set to do. The recent change to using the AutoFormat 'Default Style' when inserting a new table has caused the problems being reported. Patch set 2 removes the 'Default Style' style name from the inserted table so user formatting will work as expected. To see this is happening: 1. apply patch set 2 2. open the Sidebar - Styles - 'Table Styles' 3. insert a table using the toolbar 'Insert Table' tool item or Ctrl-F12 to open the 'Insert Table' dialog Notice after the table is inserted 'Default Style' in the Sidebar is not highlighted. 4. make user format changes to the table 5. insert or delete row or column My results: table does not lose formatting
(In reply to Jim Raykowski from comment #29) > 1. apply patch set 2 > 2. open the Sidebar - Styles - 'Table Styles' > 3. insert a table using the toolbar 'Insert Table' tool item or Ctrl-F12 to > open the 'Insert Table' dialog > > Notice after the table is inserted 'Default Style' in the Sidebar is not > highlighted. > > 4. make user format changes to the table > 5. insert or delete row or column > > My results: table does not lose formatting I confirm with your patch. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: c902cbc7dc5294ab721a9aef3a152aa243d00011 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on February 17th 2018
*** Bug 115929 has been marked as a duplicate of this bug. ***
*** Bug 115864 has been marked as a duplicate of this bug. ***
*** Bug 115936 has been marked as a duplicate of this bug. ***
Jim, in [1] the conclusion is that the patches for bug 108227 and bug 107555 need to be reverted for now, can you please give an update on that? [1] https://gerrit.libreoffice.org/#/c/49831/
(In reply to Aron Budea from comment #35) > Jim, in [1] the conclusion is that the patches for bug 108227 and bug 107555 > need to be reverted for now, can you please give an update on that? > > [1] https://gerrit.libreoffice.org/#/c/49831/ Hi Aron, Yes these patches should be reverted for now. I believe both are good ideas but need to wait until autoformat and user direct formatting of tables can be made to work well together. I have thought of two ways this can be accomplished and have had some success with both: 1. When direct formatting is made to a table then the table's autoformat style is no longer used. This results in no table style highlighted in the sidebar styles table styles panel after a direct format is made. Autoformatting is no longer applied to the table afer row/column additions/deletions so that direct formatting is preserved. 2. The table retains the autoformat style for table boxes (cells) that do not have direct formatting by the user. This results in the sidebar style table style remaining highlighted after user direct formatting. When rows/columns are inserted/removed direct formatted cells are untouched by autoformatting. The table follows autoformatting style on inserts/removes. Background color position dependency is one advantage I can see with this approach. When insertions or deletions are made the row or column background color still follows the autoformat style. Approach 1 may be easier to implement. I have made some progress on approach 2 where table boxes keep their direct formatting of borders, line styles, number formatting, and background color, after insertion/deletions. Working on font retention. Insertions and deletions are made with autoformat style so the table keeps the autoformat style for table boxes that are not direct formatted. Other ideas are welcome. What is the best way to do the revert? I will do a revert patch if needed.
*** Bug 116114 has been marked as a duplicate of this bug. ***
A solution seemingly not discussed here at all, but from my point of view the most preferrable, would be to allow a user to create his own "Default Style", which of course then has to be part of the users standard template. This way every new table would have exactly the style intended by the user without fiddling with AutoFormat options. Certainly any style applied directly to cells should dominate over the ones from the template and e.g. kept also for new lines/columns. Also I would like to have the option to disable AutoFormat globally.
*** Bug 116135 has been marked as a duplicate of this bug. ***
Here is a patch that keeps direct formatting after rows/cols are inserted/deleted or table style is changed for cells with character attribute direct formatting. https://gerrit.libreoffice.org/#/c/50612/
(In reply to Jim Raykowski from comment #40) > Here is a patch that keeps direct formatting after rows/cols are > inserted/deleted or table style is changed for cells with character > attribute direct formatting. > > https://gerrit.libreoffice.org/#/c/50612/ Unfortunately after document reload the table loses direct formatting on ins/del.
If a space or other character(s) are added to a table cell before changing font attributes the changed font attributes are not lost on row insert or delete or table style change and also remain after reloading the document and inserting or deleting a row or table style change. Here are steps to confirm: 1. Insert a table 2. Enter a space or some characters in a cell 3. Select a font and enter more characters 4. Insert or delete a row result: font is not lost 5. Save the document and reload 6. Insert or delete a row result: font is not lost
With regard to comment 42, That first character should be formatted according to the "table content" style. Selecting a font changes the font characteristics for the reset of the cell, as would be expected. This bug is that the current definitions in the "table content" style are not applied where they should be, that being everywhere except those cells where a specific font treatment is individually applied cell by cell. The font characteristics are taken using the default value of the "table content" style, not the value of the "table content" style as modified for the document. It is the current definition of the "table content" style element is not used until auto-format is invoked (table->auto_format_styles) then reverted (Ctrl-Z).
Slight typing error in comment 43 for the reset of the cell should be for the rest of the cell
*** Bug 116178 has been marked as a duplicate of this bug. ***
Created attachment 140335 [details] 1 paragraph of writing, Colour formated table, resets on edits For Diagnosis , if it helps. File contains a table whos format resets on copy paste and editing in some cases.
*** Bug 116191 has been marked as a duplicate of this bug. ***
Hi Jim, (In reply to Jim Raykowski from comment #36) > I have thought of two ways this can be accomplished and have had some > success with both: Thanks for iterating on this! I'm not familiar with the inner working of autoformat styles... is it possible to know what formatting comes from direct formatting, and what comes from autoformat style in an existing cell/row/column? > What is the best way to do the revert? I will do a revert patch if needed. I'd suggest reverting the mentioned commits in branch libreoffice-6-0, so they don't cause regressions. In master they can be kept, except maybe if they clash with the eventual fix, then reverting them there would make the actual fixing commit cleaner (just my two cents).
*** Bug 116207 has been marked as a duplicate of this bug. ***
(In reply to Aron Budea from comment #48) Hi Aron, great to be able to discuss this with you. > is it possible to know what formatting comes from > direct formatting, and what comes from autoformat style in an existing > cell/row/column? The ability to know cells that have direct formatting is here [1] but there seems to be no provision for persistence. Using this is how the most recent patch submitted for cell font attributes works [2]. This can also be used for cell borders, cell number formatting, and cell background. How to make this persistent is beyond my knowledge. [1] https://opengrok.libreoffice.org/xref/core/sw/inc/swtable.hxx#433 [2] https://gerrit.libreoffice.org/#/c/50612/
*** Bug 116311 has been marked as a duplicate of this bug. ***
*** Bug 116380 has been marked as a duplicate of this bug. ***
*** Bug 116379 has been marked as a duplicate of this bug. ***
(In reply to Jim Raykowski from comment #50) > Hi Aron, great to be able to discuss this with you. I'm sorry, I can't offer any useful advice on this. Let me see if I'm able to find someone who can. In the meantime please revert the responsible commits in branch libreoffice-6-0, to stop the bug reports coming in. Thank you!
I wonder if this is conceptually different from working with text/paragraphs based on styles plus direct formatting over them. Obviously there must be some table-specific oddities, but maybe the logic used there can be used for reference? Or is this too naive of a thought? :)
*** Bug 116366 has been marked as a duplicate of this bug. ***
(In reply to Aron Budea from comment #55) > I wonder if this is conceptually different from working with text/paragraphs > based on styles plus direct formatting over them. Obviously there must be > some table-specific oddities, but maybe the logic used there can be used for > reference? Or is this too naive of a thought? :) I'm not sure where to look but I do think this thought is worth looking into :) Here is a link to a revert patch: https://gerrit.libreoffice.org/#/c/51253/
(In reply to Jim Raykowski from comment #57) > Here is a link to a revert patch: > https://gerrit.libreoffice.org/#/c/51253/ Thank you! Please prepare one for libreoffice-6-0 as well, and when that's released, for libreoffice-6-0-3 so it's included in the 6.0.3 update.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eeb4a2ec37bf88b26a9f243cc5682e96c9e35df6 tdf#115573 Revert: tdf#107555 Apply 'Default Style' table style It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Jim Raykowski from comment #57) > Here is a link to a revert patch: > https://gerrit.libreoffice.org/#/c/51253/ Can you back port it into 6.0 branch?
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fbe3b762e8e96f96afe5c79d1b9db5be3c7141a8 uitest for bug tdf#115573 It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 116469 has been marked as a duplicate of this bug. ***
*** Bug 116493 has been marked as a duplicate of this bug. ***
*** Bug 116554 has been marked as a duplicate of this bug. ***
@Jim, Can this bug be closed? Do you plan to port the revert to 6-0 ?
(In reply to Xisco Faulí from comment #65) > @Jim, Can this bug be closed? Do you plan to port the revert to 6-0 ? The revert has been ported to 6-0 but has not been merged as of yet. https://gerrit.libreoffice.org/#/c/51362/
*** Bug 116564 has been marked as a duplicate of this bug. ***
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=30db8c9b1d9654e62c11657140fac24f0f52c547&h=libreoffice-6-0 tdf#115573 Revert: tdf#107555 Apply 'Default Style' table style It will be available in 6.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 116652 has been marked as a duplicate of this bug. ***
*** Bug 116674 has been marked as a duplicate of this bug. ***
Jim Raykowski committed a patch related to this issue. It has been pushed to "libreoffice-6-0-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=55a27458831d1a7d203479c9d713d2f3e57c25a4&h=libreoffice-6-0-3 tdf#115573 Revert: tdf#107555 Apply 'Default Style' table style It will be available in 6.0.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 116719 has been marked as a duplicate of this bug. ***
*** Bug 116610 has been marked as a duplicate of this bug. ***
*** Bug 116740 has been marked as a duplicate of this bug. ***
*** Bug 116764 has been marked as a duplicate of this bug. ***
*** Bug 116819 has been marked as a duplicate of this bug. ***
I just got my 6.0.3 upgrade (Version: 6.0.3.2; Build ID: 1:6.0.3-0ubuntu1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group) -- and sadly, NOT FIXED. When I add a row, the formatting is reset for the whole table. Nasty. :( I was hopeful that this was squashed, but it seems not to be.
Sorry -- was a little hasty! I read some of the earlier comments, and noticed in #17 that you needed to start with a doc created in 6.0.3n. So: - If I use a "fresh" doc created in 6.0.3.2, then either create a table, or copy/paste one from an older (6.0.2) doc, then the table format is NOT reset when adding a row, etc. - If I simply load up a doc created in an earlier version, then the table re-formatting still occurs in 6.0.3n. So, FIXED, then! But people concerned about this bug should be made aware of this behaviour: edit your tables in docs *created* in 6.0.3+. (In reply to David from comment #77) > I just got my 6.0.3 upgrade (Version: 6.0.3.2; Build ID: 1:6.0.3-0ubuntu1 > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB > (en_GB.UTF-8); Calc: group) -- and sadly, NOT FIXED. > > When I add a row, the formatting is reset for the whole table. Nasty. :( I > was hopeful that this was squashed, but it seems not to be.
needs this one to be set fixed, or kept open for the long term solution?
*** Bug 117387 has been marked as a duplicate of this bug. ***
(In reply to Cor Nouws from comment #79) > needs this one to be set fixed, or kept open for the long term solution? Works with a new table in a new document .. Let me set to fixed and see what people think :) Version: 6.1.0.0.alpha1+ Build ID: 8a2745e1beee722c8c9691c397e493cc1160bedf CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-30_23:34:23 Locale: nl-NL (nl_NL.UTF-8); Calc: group
*** Bug 117775 has been marked as a duplicate of this bug. ***
*** Bug 117802 has been marked as a duplicate of this bug. ***
*** Bug 117909 has been marked as a duplicate of this bug. ***
Hi, For few month I kept LibreOffice 5.4 because it don't have the bug. But today I tried newer versions : 6.0.6 / 6.1.0 / and even future 6.1.1 The 2 latest versions have the bug, and it's very annoying. Example : I open any of my ODT document (LibreOffice Writer) with table, I delete a column : table formatting is lost (font, size, bold). Also, if I use Ctrl+Z it will not restore the formatting, I must close LibreOffice and open my ODT document again. 2 differents ways to have the bug : 1) Add or Delete a column 2) Add or Delete a row With that bug, I can't use tables, it's a big problem to me, it's unusable. Please, do you plan to fix 6.0.x and 6.1.x versions ? With 5.4.7 : no problem. Thank you.
(In reply to Maxime THEPAULT from comment #85) > . . . > Example : I open any of my ODT document (LibreOffice Writer) with table,... Hi Maxime - did you read the earlier comments in this thread? See, for example, my notes at #78 (referring to #17!): https://bugs.documentfoundation.org/show_bug.cgi?id=115573#c78 If you're opening your *old* documents, the bug "persists". You need to copy/paste those tables into a document created in the newer ("fixed") version. Cumbersome, but that's the way it is at the moment.
Is it a joke ? Create again all my documents ?? I'm very surprised bug is not fixed, it's very annoying, you can't seriously propose to create new documents, with all lost work time... I have many documents since about 10 years ago, I will not create my documents again... it's crazy. Why 5.4.7 don't have the bug ? You can't copy working code from this version ? I hope bug will be fixed, it's not possible to work as is, how can you imagine LibreOffice will be kept into companies with a big bug like this one.
I agree with maxime who recently posted a comment. Although it is possible to make tables obey the current table styling by placing them into a new document, that is awkward and costly. Consider a large document for which an individual is responsible for only a portion of one chapter. Who would be the appropriate person to restart the entire document? Who would be responsible for proof reading the new document? To what part of the organization should this cost be assigned? Perhaps the status of this bug should be changed as it is not yet resolved.
(In reply to Maxime THEPAULT from comment #87) > Create again all my documents ?? > > I'm very surprised bug is not fixed, it's very annoying, you can't seriously > propose to create new documents, with all lost work time... > > I have many documents since about 10 years ago, I will not create my > documents again... it's crazy. No, only documents that have been saved with versions 6.0.0-6.0.2. > Why 5.4.7 don't have the bug ? You can't copy working code from this version > ? That's exactly what happened, it's the same code now as before. And older versions can't handle the bad files without the one-time manual fix, either. If you see something else, it's a different bug.
(In reply to Aron Budea from comment #89) > (In reply to Maxime THEPAULT from comment #87) > > Create again all my documents ?? > > > > I'm very surprised bug is not fixed, it's very annoying, you can't seriously > > propose to create new documents, with all lost work time... > > > > I have many documents since about 10 years ago, I will not create my > > documents again... it's crazy. > No, only documents that have been saved with versions 6.0.0-6.0.2. > > > Why 5.4.7 don't have the bug ? You can't copy working code from this version > > ? > That's exactly what happened, it's the same code now as before. And older > versions can't handle the bad files without the one-time manual fix, either. > If you see something else, it's a different bug. I see... I checked : I have recent (2018) documents with the bug, and older documents without the bug, so it seems you are right. Thank you, it relieves me...
I can NOT reproduce Version: 6.2.0.0.alpha0+ Build ID: 9a9b81c7212fa6a6762246593acf3f1950677a22 CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-08_00:00:43 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
Created attachment 145202 [details] not solved. Video See the video. This bug it is not yet solved. Tested on: Version: 6.2.0.0.alpha0+ Build ID: 66232248ff55639052ddb76918d555e21dc9c46b CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-09-20_19:40:04 Locale: ro-RO (ro_RO.UTF-8); Calc: threaded
No Issues under this version Version: 6.1.1.2 (x64) Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-PH (en_PH); Calc: threaded
(In reply to perie_gut from comment #93) > No Issues under this version > > > Version: 6.1.1.2 (x64) > Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b > CPU threads: 4; OS: Windows 10.0; UI render: default; > Locale: en-PH (en_PH); Calc: threaded Please try with the document from comment 13. I reply like you that it is not my case, but after trying this document, I could test this bug.
(In reply to BogdanB from comment #94) > (In reply to perie_gut from comment #93) > > No Issues under this version > > > > > > Version: 6.1.1.2 (x64) > > Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b > > CPU threads: 4; OS: Windows 10.0; UI render: default; > > Locale: en-PH (en_PH); Calc: threaded > > Please try with the document from comment 13. I reply like you that it is > not my case, but after trying this document, I could test this bug. Yes, if I am going to use the said sample document, I can reproduce the issue. However, I cannot reproduce the said issue if I am going to copy the table (from the sample) to a new writer document.
(In reply to BogdanB from comment #94) > Please try with the document from comment 13. I reply like you that it is > not my case, but after trying this document, I could test this bug. Please see previous replies, eg. comment 78. Buggy files that were edited between versions 6.0.0-6.0.2 keep this issue, and require manual fix, but with files not touched with a buggy LO version the issue is gone.
(In reply to Aron Budea from comment #96) > (In reply to BogdanB from comment #94) > > Please try with the document from comment 13. I reply like you that it is > > not my case, but after trying this document, I could test this bug. > Please see previous replies, eg. comment 78. Buggy files that were edited > between versions 6.0.0-6.0.2 keep this issue, and require manual fix, but > with files not touched with a buggy LO version the issue is gone. What's the use of having this issue open when in fact we cannot reproduce this using the newer LO versions? This is already a file issue that originated from a faulty LO writer version. Yes, I do understand your point but forcing the community to fix a certain file issue that originated from a bleeding edge version is already a waste of time given the fact that none of the stable versions encountered it.
(In reply to perie_gut from comment #97) > What's the use of having this issue open when in fact we cannot reproduce > this using the newer LO versions? This is already a file issue that > originated from a faulty LO writer version. It's not open (status is RESOLVED), and I agree. Let's set this to verified.
I'm unsure if the bug needs to be reopened but I'd like to add that this happens also from files created using templates that have been previously edited under the affected versions, so the manual fix must be done to those files also.
Also, does somebody know which part of the XML files in the document is corrupted by the bug in the saved files? I ask this so that we can manually fix the files without having to copy/paste the content in new files. If the content that makes the issue persist in older files is identified I could probably code a small utility that to batch fix the affected files for all to use. I tried to diff (after delinearization) the XML files in hopes to find the corrupted section but the differences were too many to understand what went wrong. Can anybody help me?
Created attachment 148171 [details] Demonstation that bug 115573 still exists in 6.1.3.2 Bug 115573 Table loses formatting when inserting a new row in a table. Status: Verified Fixed. Attached video shows it is still a bug in v6.1.3.2
(In reply to J. Mahun from comment #101) > Created attachment 148171 [details] > Demonstation that bug 115573 still exists in 6.1.3.2 > > Bug 115573 Table loses formatting when inserting a new row in a table. > Status: Verified Fixed. > Attached video shows it is still a bug in v6.1.3.2 Thanks for the report. Already report. See bug 120068
Just created a new table in 6.3.2.2 and this bug is still there. These reports keep getting closed for one reason or another - the current one seems to be 126008.
I can confirm this bug too. Libreoffice 6.4.4.2 on Ubuntu Linux 20.04
(In reply to Emanuele Gissi from comment #104) > I can confirm this bug too. > > Libreoffice 6.4.4.2 on Ubuntu Linux 20.04 Please, report it in a new ticket. thanks
(In reply to Xisco Faulí from comment #105) > (In reply to Emanuele Gissi from comment #104) > > I can confirm this bug too. > > Libreoffice 6.4.4.2 on Ubuntu Linux 20.04 > > Please, report it in a new ticket. thanks Please report *only* if you reproduce with new document, and link to this bug. If it's old documents per comment 78, do not report, it's as it is.
Bug 126008 is open on a leftover part of this bug.