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.
Created attachment 152291 [details] screen capture of table after insertion
I can't confirm this with Version: 6.2.4.2 (x64) Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded and also not 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 Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it)
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.
[Automated Action] NeedInfo-To-Unconfirmed
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.
@Jim, @Miklos, I thought you could be interested in this issue...
(In reply to Dieter Praas from comment #5) > 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 I can't reproduce it in Version: 6.4.0.0.alpha0+ Build ID: a294457eb95e60028539b6783abac78b56561fe2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded is this the same as bug 105799 ? Could you please try with a recent master build ?
(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
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...
Created attachment 152866 [details] Writer doc which shows change in table header and cells when adding new row
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.
*** Bug 120068 has been marked as a duplicate of this bug. ***
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.
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
(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.
(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.
(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.
(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.
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.
*** Bug 134462 has been marked as a duplicate of this bug. ***
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.
Resetting assignee, assuming taking the bug was unintentional.
*** Bug 136424 has been marked as a duplicate of this bug. ***
*** Bug 136532 has been marked as a duplicate of this bug. ***
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
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.
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.
*** Bug 141462 has been marked as a duplicate of this bug. ***
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.
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).
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
*** Bug 143347 has been marked as a duplicate of this bug. ***
*** Bug 144046 has been marked as a duplicate of this bug. ***
*** Bug 144383 has been marked as a duplicate of this bug. ***
*** Bug 120634 has been marked as a duplicate of this bug. ***
*** Bug 140819 has been marked as a duplicate of this bug. ***
I added this under https://wiki.documentfoundation.org/Development/Budget2021#Most_annoying_bugs.
Very annoying bug! It is still present in Version 7.1.5.2.
By the way: in Calc it works!
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.
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
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.
Created attachment 176005 [details] Example 3 - document which can be used to replicate the bug
Still present in Libreoffice 7.3.0.3, first reported for Libreoffice 6.1
*** Bug 146104 has been marked as a duplicate of this bug. ***
*** Bug 149299 has been marked as a duplicate of this bug. ***
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).
Fix is tracked in https://gerrit.libreoffice.org/c/core/+/137915.
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.
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.
(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?
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
*** Bug 150528 has been marked as a duplicate of this bug. ***
*** Bug 150152 has been marked as a duplicate of this bug. ***
*** Bug 150870 has been marked as a duplicate of this bug. ***
I think the bug 143234 is related, maybe duplicate.
(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 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
Created attachment 182827 [details] Loss of font formatting in Writer tables. Loss of font formatting in Writer tables. Insert table crashes font format.
*** Bug 151601 has been marked as a duplicate of this bug. ***
*** Bug 149105 has been marked as a duplicate of this bug. ***
(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 :-)
(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.
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.
(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
(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.
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.
(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.
*** Bug 153056 has been marked as a duplicate of this bug. ***
Reproduced in a recent master build: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 69c6f7bccec838b7288a25a29a83b7f782ba7586 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Also reproduced as described in comment 5 with: Version: 6.0.0.3 (x64) Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: en-GB (en_GB); Calc: group
OS :linux mint LIBRE OFFICE VERSION:7.3.7.2 STEPS: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. RESULT:bug partially reproduce reason:font size is automatically changed and left alignments are not changed
*** Bug 153639 has been marked as a duplicate of this bug. ***
This bug was never tagged as an implementationError but I think it is fair to call it that.
The problem persists in libreoffice version 7.5 also
*** Bug 154053 has been marked as a duplicate of this bug. ***
I've also experienced the same problem. In Version: 6.4.7.2 libreoffice write
*** Bug 148307 has been marked as a duplicate of this bug. ***
*** Bug 147675 has been marked as a duplicate of this bug. ***
In comment 18, Maxim suggests it's an implementation error that started with Jan's work first available in 5.1. However, in duplicate bug 148307, raal bibisected the issue to commit 40fba0f4418084d50cc5c388cb0b6e1abe395d61, which first made it into 5.3. It think the confusion lies in availability of specific table styles / autoformats in different versions. I just tested 5.2.7.2 and could reproduce the issue when applying an autoformat that was available back then, so I am marking 5.1 as first affected, and confirming this is most likely an implementation error.
Here is a small patch that makes font and alignment changes not change when a row or column is inserted or removed: https://gerrit.libreoffice.org/c/core/+/151936
I can reproduce it Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 4:7.5.5~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded
*** Bug 156421 has been marked as a duplicate of this bug. ***
I've tried using styles, changing the font in the settings for experts, inserting rows or columns of all shapes (Tab key, by the menu and interactive menu, toolbar) but whenever a row or column change is made the table loses all formatting. I changed the fonts in the settings [Expert settings / org.openoffice.VCL/DefaultFonts/LocalizedDefaultFonts] but even that doesn't solve the problem; Writer now uses this font in the formatting break. It's a shame that such good software doesn't have this problem fixed.
I can confirm it in all 6 and 7 versions. Inserting or deleting any row or column reverts font formatting to the font set in Tools / Options / Advanced / Expert Settings / org.openofficeVCL / DefaultFonts and crashes all paragraph formatting.
*** Bug 157229 has been marked as a duplicate of this bug. ***
*** Bug 158050 has been marked as a duplicate of this bug. ***
I can confirm this on the following build. I can also confirm that choosing Undo *does not* revert the automated formatted changes, which makes this bug even more infuriating. Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 24; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.3 Calc: threaded
Hi Friends, On my end I don't consider this bug as really one, but instead as an Writer ergonomic : the "problem" is that each time you change anything in your table format or size, Writer re-apply the table autoformat style applied when you created it (normally the "table default style"). That's also the reason why the "Undo" command has no effect. The (or MY) solution is : 1. Create your table and put some content in it. 2. Apply all style parameters you can directly to this embryonic table : characters (font, size, colors, italic, bold..), cells back colors, everything you want. 3. Record the new style your have defined in "Autoformat style..." under a new name. From now on, your table is affected with your new autoformat style and it will not crash down when you add/remove lines. And to be icing on the cacke, the next time you create a table, no need to redefine everything : you have only to apply your personalized autoformat style which is now recorded.
(In reply to Michel AUTEM from comment #89) You can't seriously call "ergonomic" a functionality which deletes user-made changes while it only claims to add a new line to the table. *And*, on the top of that, Undo doesn't work to restore user-made changes. I'm honestly very surprised by this bug and the fact that it has existed for so long time. I'm a very casual user of word processing tools, and I'm also a big fan of free software (and a long-time contributor thereof). I was naively assuming that LibreOffice is mature software nowadays.
(In reply to Antoine Pitrou from comment #90) > I'm honestly very surprised by this bug and the fact that it has existed for > so long time. I'm a very casual user of word processing tools, and I'm also > a big fan of free software (and a long-time contributor thereof). I was > naively assuming that LibreOffice is mature software nowadays. That's likely because you've used Writer or Calc more than Impress. Impress is in a far less robust and rounded-out state than those two. I don't mean to denigrate the important work developers have been doing - and there's certainly gradual improvement over time - but I do believe those two modules, especially Writer, get more attention and work than Impress does.
(In reply to Eyal Rozenberg from comment #91) > > That's likely because you've used Writer or Calc more than Impress. Impress > is in a far less robust and rounded-out state than those two. I don't mean > to denigrate the important work developers have been doing - and there's > certainly gradual improvement over time - but I do believe those two > modules, especially Writer, get more attention and work than Impress does. Hmm, this bug is for Writer, not Impress.
Created attachment 190692 [details] A file containing a table that does NOT exhibit this bug. I am the person who originally submitted this bug report and I have recently created a file with a table in which the bug does not occur. Perhaps if you Compare the attached file's innards to those of the file I originally submitted and other test files you may have created it will help find the source of the problem.
*** Bug 158757 has been marked as a duplicate of this bug. ***
As a random user passing by, I will comment on the behavior that I expected to see in Writer and was surprised that it did not exist. When I open the Styles panel, I see Paragraph, Character, Frame, Page, List, and Table Style Icon/tabs. When I check each one, I see that I can right-click on an existing entry and a pop-up menu gives me the options of New/Modify/Hide. However, when I go to the Table Styles tab and right click on the options, I am only given the Hide menu option. I expected to see New and Modify menu options here as well, and expected to be able to create and modify styles for tables the same way I can for Paragraphs, Characters, and so forth. Is this possible to implement? If we can create our own styles, then it might resolve the issue?
*** Bug 161243 has been marked as a duplicate of this bug. ***
*** Bug 161505 has been marked as a duplicate of this bug. ***
I can confirm this bug to be still present in LibreOffice 7.6.7.2 Steps to reproduce it together with some additional effects of this bug: 1. Create new Writer Document 2. Assign an exotic (i.e. easily recognizable) font to paragraph style "Table content" (de: "Tabelleninhalt") 3. Insert a paragraph with some text 4. Insert a table choosing one of the proposed styles (this is crucial) 5. Enter text into (at least some) of the table cells 6. Select the whole table 7. Confirm the style "Table content" (resp. de: "Tabelleninhalt") via the formatting bar or the styles side bar 8. Set the cursor into the last cell of the last column and press the Enter button to add a further row Unexpected behavior: - After step 4 and still after step 5: while the field "paragraph style" in the formatting bar shows "Table content" (as expected), the field "font" in the formatting bar and the contents of the table itself have a wrong font (probably that of the default paragraph style). Interestingly the selected entry in the styles side bar is correct and also formatted correctly. - Step 7 corrects all these errors - Step 8 makes these errors reappear Note: If instead of step 4 a table without style is inserted, this bug seemingly does not appear, even when the table is formatted afterwords. The bug is persistent when saving and opening the document in odt format.
I can confirm that bug to be still present in • LibreOffice 6x • LibreOffice 7x • LibreOffice 24x on OSs • Windows 10; • Windows 11; • Linux Mint 21x; • Ubuntu 24x; • Big Linux. Every time you add or remove any rows or cols in the table, for any method, the Writer loses • font formatting done directly (bold, italics...); • font formatting using styles (strong, emphasis...); • paragraph formatting done directly (centered or right-aligned using toolbar); • paragraph formatting by styles (table header, table content). On all occasions, the Ctrl + Z command does not recover the formatting.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a7c1163684fa5c0376efebe8dc6225a7dfb8e700 (related tdf#126008) sw: allow removing table autoformat from a table It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1e978fffddc3d7044f3def026340844b59d2d656 (related tdf#126008) sw: when removing table auto format, don't... It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/27198ec7031e9ef3bbc592423e5c12e333e206ee (related tdf#126008) sw: add config to disable table autoformat ... It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/ef58ed2ca776cbdb2ce8cc8ece72fcb971d12ac1 (related tdf#126008) sw: allow removing table autoformat from a table It will be available in 24.8.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/2f56c6d90211d29fbae9c4bbee3f020df9bbba65 (related tdf#126008) sw: add config to disable table autoformat ... It will be available in 24.8.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/54d931b5359822c2d10fa4a7e50abe31b7424d1e (related tdf#126008) sw: when removing table auto format, don't... It will be available in 24.8.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/828cc5e63ece8a9c1004c3cc9213e004871871f7 (related tdf#126008) sw: allow removing table autoformat from a table It will be available in 24.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/50d13c89f2420971047f25d40493b85c964fd54b (related tdf#126008) sw: when removing table auto format, don't... It will be available in 24.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/cee20c94bbbf39dbd9ae407c4d3ce225288332ed (related tdf#126008) sw: add config to disable table autoformat ... It will be available in 24.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 162773 has been marked as a duplicate of this bug. ***
How can this bug be marked 24.8.0.2 if it wasn't fixed by that release on the 24.8 branch? :-(
*** Bug 162744 has been marked as a duplicate of this bug. ***
Still present in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f7fbf6504fd6190187f6e4d092af880ba8c7bf6a CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded Michael, thank you for previous work on that very annoying bug (30 duplicates might be a record). Are you still working on it?
*** Bug 163533 has been marked as a duplicate of this bug. ***