Description: Hello everyone. This is my last bug report here, I think. I'm too tired of this software and of its bugs. OK, the issue. The issue is that Writer applies direct formatting no matter how accurate, professional, and minimalistic my typeset workflow is. Although this bug happens very often for me, it is very hard to notice the exact moment, and so it is hard to provide an exact way to reproduce it. Here is how it happens with me again: 1. I opened my template to start writing a short document about useful Writer keyboard shortcuts. 2. The document is just 7 small tables, nothing more, no weird tricks, no fine tuning. Inside tables, I use "Default Paragraph Style" (Ctr+A > Ctrl+Shift+0). I never use "Table Contents" style, which is applied by default, and so it has red hatch. (You can create a new table to see what I mean.) 3. I also have the style "__small" which is the same as "Default Paragraph Style", but is 8 pt instead of 10 pt. 4. So, I have wrote my document. The only style I have used during writing was "Default Paragraph Style". And I have neither used "direct formatting" manually, nor I have used "clone formatting" tool. Everything looks fine... But then I want to change the text in tables to smaller. So I apply "__small" style to each table. And what I see? Heck. I see that some words in some cells are still 10 pt and not 8 pt. This is because Writer applied direct formatting to them somehow, for some weird reason. See tables "Defaults", "Panes", "Insert", and "Tables". Steps to Reproduce: see above Actual Results: see above Expected Results: see above Reproducible: Always User Profile Reset: No Additional Info: see above
Created attachment 175164 [details] test file 1
Created attachment 175165 [details] test file 2
Created attachment 175168 [details] original tables were full of spans and direct table formatting cleared them here and applied the _small style See if this is more what you expected. Open in a Zip and view/edit the context.xml for your samples compared to this.
Hello, Stuart. Yes, I know how to "fix" this bug when it happens. I need to select a table and press Ctrl+M to remove direct formatting. But this doesn't answer the question why the issue happens. I just create a table, then applying default paragrpah text to it, and then start writing. Nothing more. There is no reason to have random direct formatting there.
> I just create a table, then applying default paragrpah text to it should be > I just create a table, then apply default paragrpah style to it Sorry.
Probably a duplicate of bug 134426, which I agree needs to be fixed ASAP! It's a regression that has been open far too long.
Yes, these issues seem to be closely related.
The issue will be less painful in case it will be press Ctrl+A Ctrl+M in any moment of time and get the direct formatting away. However, if you have protected sections (such as ToC, for example), this doesn't work. I mean, in such a case it doesn't work even for non-protected text. You need to manuall and carefully select everything **except** protected sections. And even worse, there is no warning this doesn't work.
// fixed typos. The issue will be less painful in case it will be possible to press Ctrl+A Ctrl+M in any moment of time and get the direct formatting away. However, if you have protected sections (such as ToC, for example), this doesn't work. I mean, in such a case it doesn't work even for non-protected text. You need to manually and carefully select everything **except** protected sections. And even worse, there is no warning this doesn't work.
@Mike, Justin -- what's your take on behavior of Table Cell content entered with Default paragraph template 'Standard' formatting. Should it be getting unique text span and RSID assignment for each word? A usage issue? Avoid an un-styled cell entry, or should Table Cells get styling other than template 'Standard'?
(In reply to V Stuart Foote from comment #10) If David is right, and this is related to tdf#134426, we need to revert that, since the author of the fix is not responding...
(In reply to V Stuart Foote from comment #10) Wrt RSIDs - the spans should be created regardless of the style used; they only need to reflect the changes themselves. They onlu should be not used if they are disabled in options.
John, please have a look at bug 141498. Direct Formatting is added after overwriting text. Does this covers your problem?
(In reply to Mike Kaganski from comment #11) > > If David is right, and this is related to tdf#134426, we need to revert > that, since the author of the fix is not responding... As done for work on bug 79717 https://gerrit.libreoffice.org/c/core/+/67597/ https://gerrit.libreoffice.org/c/core/+/69323/
Hopefully this is fixed in 7.1.7, since the suspected commits have been reverted.
*** This bug has been marked as a duplicate of bug 134426 ***