Looking into the content.xml subfile, it appear that once it was a .doc(x) file. May it be so? If yes, this is the culprit.
the subject at hand. </text:span><text:span text:style-name=“T160”>Setting up</text:span> the G1000 Trainer for one of these scenarios is a little tricky at first. This section will help you to master this “art”.</text:p><text:p text:style-name=“Text_20_body”><text:span text:style-name=“T46”>The key to setting
Actually no. I started this document in LibreOffice. But I might have copy pasted parts from old doc files, although I can’t really recall having done that. Anyway, how could that have caused the problem and what could I do to avoid it in the future? Would copying the document into a new odt file help? Or is there some way to modify any of the subfiles to prevent that problem from occurring again?
I have been doing a lot of work updating old documents. There is one icon that I always add to the Standard toolbar (Tools > Customise) and that is Paste as unformatted text. It has saved a lot of trouble and is much easier than the keyboard shortcut.
Nice idea! Yes, I use Paste as unformatted text a lot, but I use the Strl+Shift+Alt+V keyboard shortcut.
Here is some more input for this “mystery” and I think we might be getting closer to the real problem now. I have tried to isolate the problem and could create a single paragraph document, in which I can reproduce the behavior.
UnintendedDirectFormattingTest3.odt (16.7 KB)
This file is actually the same one page document as in the upload before, but before the change and reduced to a single paragraph. Select the phrase “To setup” in the second paragraph and then type “Setting up” (by keyboard). Then change the font in paragraph style Text Body to Arial 6pt and you will see that newly typed phrase does not change, but carries this direct formatting (at least I think that’s what it is).
I played around a little with it and what I can find is:
So, is selecting text and overtyping it the culprit here?
Can anyone reproduce this behavior? Or is it my (pretty standard) environment that is causing this?
Got the same behaviour. Never seen that before.
I activated the style inspector:
select existing text, type: direct formatting appears with exactly the same properties as paragraph style
Consequently, when you change paragraph style, direct formatting takes precedence. And even stranger: if, instead of modifying the paragraph style, you assign another style, a tab character pops up in the middle of inserted text!
select existing text, erase with Bksp, type new text: everything OK
I could not identify any pattern in the .fodt other than the “Tx” direct formatting (which are the same as those shown by the style inspector). I didn’t find any weird setting in Tools>Options. There may be something in “Advanced configuration” but I am no developer.
I initially suspected something in relation with “Track changes” because all edits create a direct formatting sort-of with attribute rsidxxxxxxxx but when completely disabled, bad behaviour persists.
Summary
Thanks everyone for your help and your suggestions, even those that did not directly lead to a solution of the problem. As ajlittoz recommended I will submit a bug report and see what comes about. It is likely in my opinion that this is indeed a bug in Writer and one that is hard to spot.
Here is the final outcome: I sent a bug report (tdf#145176) and it has been marked as duplicate to another report (tdf#134426), which has been identified as bug and has meanwhile been resolved. Writer version 7.1.7 is planned to include the fix for this problem. As the current download version is already 7.2.1 the newest release should have this bug fixed.
Thanks again to everyone to trace this problem down!
I just installed 7.2.1 and the problem still persists! Either the bug has not been fixed in 7.1.7 or it is recurring in 7.2. and someone forgot to merge the bugfix into the new version.
Sorry, no “all-clear” yet!
7.1.7.1 RC1 is available in the development version but has not yet been released (still has RC2 to go before final release), see Development versions | LibreOffice - Free Office Suite - Based on OpenOffice - Compatible with Microsoft .
Release 7.1.7.x is expected to be available during the first week of November according to https://wiki.documentfoundation.org/ReleasePlan/7.1
I don’t think you will see the fix in the 7.2 series until 7.2.3.x due towards end of November. It isn’t in 7.2.2.2 on Windows 10.
You can usually get direct formatting removed quite easily.
Select the entire text Ctrl+A and then
delete the direct formatting with Ctrl+M.
The problem you describe can be caused by not working cleanly with styles from the start.
I.e. you start with a blank page and apply the above procedure and then assign a desired style (e.g. “Textbody”).
Then save this formatted blank page as a document template.
Thank you for your reply. I am aware of using Ctrl+M to get rid of direct formatting. But I find it annoying that direct formatting pops up again in the middle of a clean paragraph just after some editing. And as it is not visible at first sight this is a great trap to run into. For now I am using the work around of changing the Body Text font to some really small size, in order to check for those direct formatting islands after every editing run. But this is just annoying.
I don’t understand your example of “not working cleanly”. What exactly is wrong with the example of saving a document with a single Textbody paragraph as a template?
What exactly is wrong with the example of saving a document with a single Textbody paragraph as a template?
There is nothing wrong if you proceed as described.
Regardless, there are other possibilities for incorrect formatting, for example, pasting text with copy and paste.
And @ajlittoz has shown you even further problem areas.
Annotation:
I hope you save your file in ODT format.
@Hrbrgr gave you the main reason for direct formatting forwarding. You just need to start typing at an edge between no formatting and direct formatting, and this edge may be an empty paragraph!
Another reason could be the use of extensions. Almost all extensions I know proceed by altering text with direct formatting instead of styling. So, check your eventual extensions.
Even Writer itself could be the culprit. “Recently” (release 6 I think), table “styles” were added. They are in fact a set of macros (in other words, it is an integrated extension) and directly reformat your tables causing the loss of your own “pure” styling formatting.
Thank you for your comment. But none of the causes you mentioned seems to apply to my situation. The edits I did were just in the middle an otherwise clean paragraphs. I have a couple of extensions installed, like writer2xhtml, but those are supposed to touch any text only on command and not while editing. I have nothing installed that does any in-place replacements of text - at least I believe so. I am on LibreOffice version 7.1.1.2 and all those direct formatting errors happened outside of tables.
If it’s not a bug, then how can I avoid such unintended direct formattings to happen? What do have to look out for or do differently in order to avoid them?
Can you attach a 1-page problematic document for further forensics analysis?
Of course! Here is a page that I just edited. The only thing I did was to replace “To setup …” with “Setting up”. I selected the original phrase and typed in the new phrase that replaced it. So, there are no extensions in play and it’s right in the middle of an otherwise clean paragraph. Originally, it Body Text was set in 9 pt Arial. To make the unintended direct formatting visible I changed the Body Text style to 6 pt. As you can see, the phrase “Setting up” remained in 9pt. Perhaps this little example helps to find out how this can happen.
Any help is highly appreciated!
UnintendedDirectFormattingExample.odt (30.8 KB)
There is nothing unusual here. Your “Setting up …” paragraph is styled Heading 2 which is not a descendant of Text Body. Therefore changing attributes in Text Body has no effect on Heading 1.
The relations between those styles are:
Default Paragraph Style --+-- Heading --+-- Heading 1
| +-- Heading 2
| +-- …
+-- Text Body --+-- …
To see the style hierarchy, select Hierarchical in the bottom menu of the style pane.
To sum up, no direct formatting is involved here, only style relationship.
Note Writer already has several built-in sub-hierarchies targeting various “components” of a book: Heading, Header, Index, Text Body, … This is a very powerfool and useful tool.
Please see my response to Zizi64.
I think, there is indeed direct formatting involved here. the string “Setting up” is not formatted in style Heading2! And it reverts to normal when Ctrl+M is applied. How would you explain that?