Created attachment 152989 [details]
Test sample showing the bug.

I just tested the given sample with the most recent development vesion:

Version: 6.4.0.0.alpha0+
Build-ID: 9ee5ad5a0b84bfa652da34694ba4f75668f06087
CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-07-30_13:21:44
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded


It is still there.

I confirm the described behaviour with

Version: 6.4.0.0.alpha0+ (x64)
Build ID: 3e64065612acec2eb29aa21e2b515953422256d7
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-15_22:57:26
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

But I'm not sure, if this is a bug: Character Style in the paragraphs is "FontStyle27" (Arial 9pt). If you change character style to default style, everything is correct. So I assume - but I'm not sure, because I copuldn't find anything about it in LO help - that default character style adopt font settings of paragraph style while other character styles are dominant against font settings of paragraph style.

(In reply to Dieter Praas from comment #3)
> But I'm not sure, if this is a bug: Character Style in the paragraphs is
> "FontStyle27" (Arial 9pt). If you change character style to default style,
> everything is correct. So I assume - but I'm not sure, because I copuldn't
> find anything about it in LO help - that default character style adopt font
> settings of paragraph style while other character styles are dominant
> against font settings of paragraph style.

Documentation chapter "working with styles", page 9: "Double-click the required character style, or double-click Default Style to remove the character style."

It's confusing, that "Default Style" seems to be the same as "no style" or "style defined in paragraph style" 

Input from Design-Team? (For me again an example, that relation between paragraph style and character style is not clear)

(In reply to Dieter Praas from comment #4)
> It's confusing, that "Default Style" seems to be the same as "no style" or
> "style defined in paragraph style" 
> 
> Input from Design-Team? (For me again an example, that relation between
> paragraph style and character style is not clear)

See also discussion in bug 108498 and bug 128960

(In reply to Dieter Praas from comment #4)
> Input from Design-Team? 

See bug 128960

> (For me again an example, that relation between
> paragraph style and character style is not clear)

Renaming the CS from Default to None (or whatever) wont solve the problem. Neither the proposed Styles Inspector makes it perfectly clear (only RTFM) but improved feedback is at least a step forward.

(In reply to Dieter Praas from comment #3)
> If you change character style to default style, everything is correct.

=> NEEDINFO

Created attachment 161391 [details]
Trying the same bug with the old example, added one other observation

The bug is still there, see my new example file. I loaded my old example file to Version: 7.0.0.0.alpha1+
Build ID: 0677d46bcc56c1f6c27b9331662990b38fd452d6
CPU-Threads: 4; BS: Linux 5.3; UI-Render: Standard; VCL: gtk3; 
Locale: de-DE (de_DE.UTF-8); UI: de-DE
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-05-21_12:54:11
Calc: threaded

and there I tried out what I did before. I added some screenshots and found out an interesting thing: The maze however goes away for this file when I delete the character style "Font Style 27" which is associated to whatever new paragraphs are added to the file, impeding the character fonts associated to the paragraph styles in the file's template.

Adalbert, it's not clear for me, if you've followed my tip in comment 3: "If you change character style to default style, everything is correct."

Of course, Dieter, if I mark the added paragraph in the development version with which I re-tested the issue and if I then go to <F11> under Character Style and reassign "Default Paragraph Font", then it the text appears as Liberation Sans 11 pt, the default for standard "Absatzvorlage Standard".

After marking everything (Ctl-A) I could not apply this procedure. Probably because there is a table of contents in the document. Although it was generated automatically it would not really change if reset to its default Character font. Its immutability probably prevents me from reassigning the  "Default Paragraph Font" to the whole document. 

Now looking closer into my issue and after adding a remark to https://bugs.documentfoundation.org/show_bug.cgi?id=128960#c23 earlier today I see that in my original bug example the very first line "This is a sample file to ..." has the paragraph style "Absatzvorlage Standard" but in addition the text in it has the character format "Font Style27", which is probably a leftover from the MS Word file which was among the ancestors of that file (although not a single line of that remained in it. But former formatting may have infectiously spread to what I wrote around the original text from the MS Word document).

If you place the insertion mark at the very end of that very first line and press ENTER, a new paragraph is created with paragraph style "Absatzvorlage Standard", because that's the successor style for it from the last paragraph. But in addition the characters in it inherit the damned "Font Style27"!

Probably much of the formatting quirk is due to this. Of course when pressing ENTER at directly in front of the paragraph mark, I expect that a new (empty) paragraph to be created without any direct formatting and without any other character style from the style sheet (aka template). 

So pressing ENTER just at the very end of a paragraph should

1. start a new paragraph with the default paragraph style as defined as the successor paragraph style from the last one (it may be different than that, e.g. for headlines in general it will be not the headline style),

2. reset any assignment of different character style that might have been in vigor before for the last characters in the old paragraph,

3. reset any assignment of direct formatting that might have been in vigor before for the last characters in the old paragraph.

This part of my bug report might be considered an UI issue, because it improves the usability of LO Writer by making the formatting "teachable to a novice". Currently, there are far too many methods to achieve the same formatting, but they have inconsistent and divergent consequences for further formatting.

To better explain why a character is formatted as it is (i.e. if  its appearance is from the paragraph, the character or from direct formatting (which takes precedence over the others and can be removed by Ctl-M), a small indicator on the bottom line (e.g. next to the Text Language) showing a P for Paragraph, a C for Character or a D for direct formatting would help to understand why a character left to the insertion point appears exactly the way it does. Currently to find out by which means a specific character in a document got its formatting is really cumbersome.

There may be (or not?) a bug in the import filter for doc and rtf files. I have seen that lots such "Font Style xy" can be imported into a LO Writer Document.

Do you know what is defined to happen if one removes such character fonts? Where is it described in the manual? Apparently the right thing seems to happen: Assign the default character formatting as defined in the paragraph style. But what is assigned if one deletes a used style should be described in the documentation and one should find it by searching for delete and style.

And of course something to get rid of the many unused styles which tend to accumulate in a stylesheet is also something on my wish list!

Created attachment 167941 [details]
example file

During the last six month nobody commented to this bug report. Perhaps it's also, because your comments are very long. so there is one wish from my side: Please keep it as short as possible.

So after reading all, I try to summarize with this steps:
1. Open attacehd file
2. Place cursor at the end of the first line. See, that paragraph style is "Default Paragraph Style" and character style is "Font Style27"
3. Press enter

Actual result:
The new paragraph has paragraph style "Default Paragraph Style" and character style "Font Style27"

Adalbert, you expect the following result:
The new paragraph has paragraph style "Default Paragraph Style" (because that's the next style rule of that style) and character style "Default Character Style (all different character styles should be removed as well as all direct formatting)

Adalbert, did I understand you correctly?
=> NEEDINFO

(In reply to Dieter from comment #12)
> Created attachment 167941 [details]
> example file
> 
> ...
> 
> Adalbert, you expect the following result:
> The new paragraph has paragraph style "Default Paragraph Style" (because
> that's the next style rule of that style) and character style "Default
> Character Style (all different character styles should be removed as well as
> all direct formatting)
> 
> Adalbert, did I understand you correctly?
> => NEEDINFO

Yes, Dieter! (See in #10 after the words "So pressing ENTER just at the very end of a paragraph should...")

I would love when such bug report is made because of a clean OpenDocument file without import problems and style/direct formatting mix.

Anyway, the supposed change has a huge impact on the way how Writer works. Before I say something as a reflex of my long work with Writer and styles and "dirty" DF documents ... What is the OpenDocument specification saying about that?

I am not a norm expert, so read this with some caveat in mind. Looking at page 99 of 846 in OpenDocument-v1.2-os-part1, which is part of chapter "3.17 Foreign Elements and Attributes", I see:

"Conforming extended producers should not use foreign elements and attributes for features defined in the OpenDocument specification.
A conforming consumer that encounters an OpenDocument defined attribute that has a value that
is not defined by OpenDocument, then it should:
1) If the attribute has a specified default value, use its default value, or
2) If the attribute does not have a specified default value, ignore the attribute."

To my understanding a not used character style might be considered to be a "foreign element". 1) and 2) then would be exactly what I proposed.

(In reply to Thomas Lendo from comment #14)
> Anyway, the supposed change has a huge impact on the way how Writer works.
> Before I say something as a reflex of my long work with Writer and styles
> and "dirty" DF documents ... What is the OpenDocument specification saying
> about that?

Thomas, does comment 15 give enough informations or should we as Regina or somebody else?

Thanks for reporting this issue.
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.

Created attachment 179971 [details]
revisiting the old bug report with current version, conclusion about it

The most probable reason is MS Word's generosity about creating all sorts of numbered character format styles with names like "Font Style 27". The attached file tells about my findings and conclusions with 

Version: 7.3.3.2 / LibreOffice 
Community Build ID: d1d0ea68f081ee2800a922cac8f79445e4603348
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: CL

Missing clear steps to reproduce (STR) (and a more focused example). So my reply is rather generic: Paragraph styles (PS) contain font attributes and character styles (CS) do. If you apply Foo-PS with some font modifications and apply on top of that bar-CS with different settings those will be used (and direct formatting (DF) both the paragraph and character level would overwrite all). If you paste unformatted text it will take the predefined settings from tools > options > writer > basic fonts or the template into default ps. "No Character Style" will remove the CS but not DF.

We introduced the Styles Inspector to investigate the hierarchy of attributes.

Smells like NAB, in particular to "we need a tool to manage" but perhaps you can submit better STR with what you expect.

(In reply to Heiko Tietze from comment #20)

> ...
> Smells like NAB, in particular to "we need a tool to manage" but perhaps you
> can submit better STR with what you expect.

Sorry, I overlooked the last sentence of you. Today I went into this issue again with my last attachment https://bugs.documentfoundation.org/attachment.cgi?id=179971.

I found out that you can reproduce it by going the end of any paragraph before the headline “2022-05-06_Conclusion” in it.
    1. put the insertion pointer immediately before the paragraph mark
    2. then press Enter
    3. then start typing something.

You will observe that the font will be Arial, stemming from character style (CS) “Character_Style_20”, the strange heirloom from Microsoft Windows in that file. (The other paragraph don’t have this CS)

So the strange behavior is caused by LibreOffice transferring
    1. CS
    2. direct formatting (DF)
from before paragraph mark to the first character of a newly started paragraph. The paragraph formatting (PS) order as specified for the above paragraph is applied, but the character formatting does not seem to be followed due to this transfer from CS and DF. (I have tested this with some examples and think this is an inappropriate feature, because the general rule is to mainly use styles and use DF as little as possible (in the manual it says “using styles means that you shift the emphasis from what the text (or page, or other element) looks like, to what the text is”).

I would rather expect that when a new paragraph is started, PS formatting is applied, discarding any CS and DF formatting currently carried over from the last character of the previous paragraph. At the very least, there should be an option for LibreOffice to always behave this way, and on a newly installed system it should default to it to avoid such questions and discussions as here in the future.

Now I have understood the reason of all these formatting glitches. I looked up https://books.libreoffice.org/en/GS73/GS7303-StylesAndTemplates.html#toc7 to see, if this carrying over is documented there (I expect it to be documented there, if it were really intended that way). Searching for the keywords “ enter” and “ return” I found nothing of that type.

1. BTW: Reading this chapter let me recognize the subchapter on “Fill Format mode (Writer and Calc)” fro the first time. I did not know that and this is really very useful in using styles.

2. BTW: The hierarchy of formatting DF precedes CS and CS precedes PS is not described in the manual. Ana additional paragraph should be added one level below “Types of styles in LibreOffice” in the Getting Started Guide:
“In LibreOfficeWriter the following hierarchy applies to formatting attributes:
* Direct formatting (DF) precedes all other formatting,
* Formatting with Character Style (CS) precedes formatting through Paragraph Style (PS).”

If my suggestion is followed, two more sentences should be added:
“If a new Paragraph is started, all direct formatting and DF and CS are reset, the newly assigned PS applies to the newly begun paragraph. If PS is applied to an existing paragraph, any existing DF and CS remain unaltered, therefore all existing text without DF and without CS (i.e. “No Character Style”) use the character properties set forth in PS.”

To cut a long story short: paragraph breaks continue with the new PS but keep the previous CS. Which makes sense within the paragraph but not necessarily across.

Mike, any concerns to switch off the CS after a paragraph break?

First of all, comment 23 mentions CS, but not character DF. Is this intentional?

I would tell that dropping CS, but not character DF, is sane. That would bring inconsistencies to people using character styles, and sometimes direct formatting.

And dropping character DF on the paragraph boundary would break the workflow of people who don't use styles.

So generally - I'm against.

(In reply to Mike Kaganski from comment #24)
> I would tell that dropping CS, but not character DF, is sane.

Sorry, I meant to write that I **doubt** that dropping one, but not the other, is sane.

(In reply to Mike Kaganski from comment #24)
> First of all, comment 23 mentions CS, but not character DF. Is this
> intentional?

Nope, and you are right DF remains after breaks too. And my take it shouldn't likewise CS.

We keep the currently enabled format until it's disabled for good reasons. Like you want to write some words in bold / strong emphasis. But what reason could exist to keep it for the next paragraph?

Let's say I'm a basic user. I open Writer, set up my font (TNR 14), and start typing. After typing my first paragraph, I suddenly see that my font became Liberation Serif 12 pt.

(In reply to Mike Kaganski from comment #27)
> Let's say I'm a basic user. I open Writer, set up my font (TNR 14), and
> start typing. After typing my first paragraph, I suddenly see that my font
> became Liberation Serif 12 pt.

Convincing example. So better WF/NAB but let's wait for other opinions.

(In reply to Adalbert Hanßen from comment #30)
> I doubt that many people really expect CS and DF to
> continue after beginning a new paragraph. It looks more natural to me to
> start from the default settings for a new paragraph.
I disagree. I can't remember a bug reports who suggests to change the current situation. So do you have some empirical evidence for your statement?

So I agree with Heiko. I'm convinced that a change would result in frustrated users.

(In reply to Adalbert Hanßen from comment #30)
> Unfortunately the documentation neither tells about the formatting behavior
> when a new paragraph or line is begun

This is actually a program-defined behavior, and is decided based on UX considerations. Given that there's no duplicates to this thus far, I doubt that the proposed change is really demanded by many (and I do think so: unlike the common belief, people *do* file bugs/enhancements, and advanced features like TeX-like image positioning have several duplicates more than ten years old).

> nor tells it anything about the precedence of formatting options.

It is clearly defined in ODF standard, even if not in Help. It is not to be changed arbitrarily.

> Advanced users who use style sheets should not be hindered and for them it
> is probably more natural to end the previous DS and DF with a new PS, which
> Heiko also agreed with. 

This needs proving; and I already mentioned that I don't see any demand of this so far except for this tdf#126546. The issues in See Also are absolutely different, even though having them in See Also is reasonable.

Adding ajlittoz to CC, whom I consider to be a really professional styles user: do you have any input on this?

How can you actually tell for sure and at a glance what actually made an effective formatting: PS, CS or DF?

First you have to remove DF and observe, what happens.

Then you have to use the Styles inspector <F11> and set it to Character Styles, in order to see, if there is any CS other than "No Character Style". If there is one, you even have to enter its modify dialogue to see, how it is defined or reset the CS to No CS and see, what happens.

Once you have excluded this, you can rely on the PS being effective at the current editing position.

Unfortunately many users have no idea about styles. If they ever try styles, they easily give up because it appears to be very complicated. See my question and my answer above!

The basic idea using styles is to use direct formatting as little as possible. Then of course, switching off DF and CS at a form feed and possibly also after a forced linefeed looks natural, especially because switching off both CS and DF requires more than one step.

If the tool buttons for bold, italic, underline, ... , color would appear different depending on how the current editing position is effectively formatted: by PS, CS or by DF, *and* if there were a button "get rid of all special formatting" (i.e. drop CS and DF) my argument would weigh much less. Are there such a featurea?

I think this is primarily a psychological problem. New users have a real difficulty to switch from a past (successful) routine to a new workflow. They don't even read the basics about the application they want to try. And this carries over when they use it regularly. Adalbert Hanßen has nevertheless quoted the most relevant argument in comment 22:

>in the manual it says “using styles means that you shift the emphasis from what the text
>(or page, or other element) looks like, to what the text is”

but failed the implication. He still thinks about appearance, not about significance which is the ultimate goal of style markup: add semantic value to runs of character.

In Writer, the three main formatting layers are independent from each other except for the precedence rule when it comes to display the final result. The markup has boundaries in each layer. After all document encoding is XML and boundaries <xxx> … </xxx> are "natural". And XML never constrained the markup to be "strictly nested". This fact allows the independence of each layer.

In the paragraph layer, the boundaries are at paragraph marks. By default, the same PS is applied when you press Enter or you switch to the configured Next_Style. Otherwise you must assign manually a new style.

In the character layer, there are no implicit boundaries. You enabled some CS and you disable it manually. IMHO, this is a good thing. When I type a series of contiguous semantically-related paragraphs, I expect all my significance markup (PS+CS) to be kept when I start a new paragraph. As an example, imagine the following scenario:

- my main topic is Text_Body
- I want to add a few caveats about my main topic but this is not different enough to deserve another PS. I then assign Strong_Emphasis at the start of the caveats paragraphs and type them
- when I return to my standard main topic, I just disable Strong_Emphasis (applying No_Character_Style)

Also, when I split a paragraph, I expect *all* layers to keep their present settings. Since this is a split, it would not make any sense to reset CS (and DF) even if I add a word at start of new paragraph. I want to remain in control of what I typed because semantic markup is author's responsibility and Writer can by no means guess what is in my head.

There is also a point that Adalbert missed. A paragraph can be associated with a list style. There are two schools for this: the style one where the list style is declared in the PS, making the PS dedicated to list item, and the DF one where a toolbar button is pressed to turn the paragraph into a list item. When Enter is pressed, most users expect the "list attribute" to remain active so that the next item is entered without any other manual operation. If CS+DF should be reset at end of paragraph, I imagine most users will then complain that this behaviour is not "intuitive" at all.

As a conclusion, if the request to reset CS+DF at end of paragraph is submitted to vote, my opinion is "against".

PS: (see end of comment 33) the present formatting state is reflected in the toolbar buttons. Of course, this doesn't tell which layer activated it (PS, CS, DF). But colouring the button might be impossible because of the "themes". Status colouring would override theme colouring (or conflict with it) and I already anticipate complaints on AskLO by users trying to understand why some buttons become suddenly unreadable.

I seems to me, that we start a discussion here and we loose focus. Heiko made a suggestion in comment 23 and changed status to NEW. Mike has cerncerns and is against that proposal. 

Heiko, do you agree with Mike? What informations are needed to make a final decision (NEW or WF or improve documentation?). We can discuss a lot and write long comments, but at least for me this is at a certain point a waste of time.

(In reply to ajlittoz from comment #34)
> ...
> 
> Also, when I split a paragraph, I expect *all* layers to keep their present
> settings. 

I agree *if there are characters right to the split point*. When sketching some document, I start with headings only. In order to add on, I enter a space before the paragraph mark and split before that space, then a headline of the same level is created (otherwise it would continue with TextBody, the default after any heading in my default stylesheet). I remove the space immediately when actually writing the next heading. If I wnat to change levels, I look up at the display of the headline-level and press <Ctl-number> as needed.

The general rule seems to be: Continue formatting in the same way as *to the left of the insertion point*. This rule is broken by <Return>.

normal*bold*   in a line, adding xyz after normal continue normal. It yields
normalxyz*bold*


However: pressing <Return> and continue writing xyz yields

normal
*xyzbold*

Try it!

> 
> ... A paragraph can be associated with a list style. There are two 
> schools for this: the style one where the list style is declared in 
> the PS, making the PS dedicated to list item, and the DF one where 
> a toolbar button is pressed to turn the paragraph into a list item. 
> When Enter is pressed, most users expect the "list attribute" to
> remain active so that the next item is entered without any other manual
> operation. 

agreed for the next line becoming a list item. You can easily terminate the list property by pressing <Enter> twice. You can easily prevent a number or bullet by pressing <Backspace> after <Enter>. Getting rid of formatting can be more difficult since it can stem from DF or CS.

>...
> PS: (see end of comment 33) the present formatting state is reflected in the
> toolbar buttons. Of course, this doesn't tell which layer activated it (PS,
> CS, DF). But colouring the button might be impossible because of the
> "themes". Status colouring would override theme colouring (or conflict with
> it)

agreed: Then we need other means to see it a glance. Two years ago, Heiko Tietze made a nice proposal: https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/

(In reply to Dieter from comment #35)
> Heiko, do you agree with Mike?

See comment 28; we could also keep the ticket open for reference

(In reply to Mike Kaganski from comment #32)
> (In reply to Adalbert Hanßen from comment #30)
> > Unfortunately the documentation neither tells about the formatting behavior
> > when a new paragraph or line is begun
...
> 
> Adding ajlittoz to CC, whom I consider to be a really professional styles
> user: do you have any input on this?

I just came back to this issue and searching if it has been treated elsewhere, I came across a post from ajlittoz from May 2017 (!) dealing with such "zombie fonts" and how to remove them: https://ask.libreoffice.org/t/writer-how-to-get-rid-of-character-20-style/25429.

He gives some other examples, He makes plausible assumptions about the observed behavior and what causes this bug. Of course, something like this can only be checked and, if necessary, really fixed, if someone analyzes the code at that point (and for that you have to find it in the first place!).

In the current development Version: 

7.6.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 70fd835b4cf75e386ee115c705241a4059fb68a8
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded 

I still encounter this bug: Now the zombie format character format is called Character_20_Style. It is listed among the used character formats, but after a search with AltSearch_1.4.2.oxt on [:::CharStyleName=Character_20_style::] I can't find a single occurrence in my (huge) document!

I want to point to this other reference from ajlittoz. Maybe someone will take care of this bug and possibly encounter some more unclean programming around the place causing this mess (once it is spotted).

(In reply to Adalbert Hanßen from comment #38)
> I just came back to this issue and searching if it has been treated
> elsewhere, I came across a post from ajlittoz from May 2017 (!) dealing with
> such "zombie fonts" and how to remove them:
> https://ask.libreoffice.org/t/writer-how-to-get-rid-of-character-20-style/
> 25429.

The faulty behaviour described in question 25429 is not related to the present request to reset character style on paragraph break. It is a matter of corruption of the style dictionary. Of course, it would be nice if some developer could find the cause of it and fix it. However, this corruption happens rather rarely and is therefore very difficult to characterise. This is needed for a fix.

> In the current development Version: 
> 
> 7.6.0.alpha1+ (X86_64) / LibreOffice Community
> Build ID: 70fd835b4cf75e386ee115c705241a4059fb68a8
> CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
> Locale: de-DE (de_DE.UTF-8); UI: en-US
> Calc: threaded 
> 
> I still encounter this bug: Now the zombie format character format is called
> Character_20_Style. It is listed among the used character formats, but after
> a search with AltSearch_1.4.2.oxt on [:::CharStyleName=Character_20_style::]
> I can't find a single occurrence in my (huge) document!

If you're really in the same context as question 25429, you probably have (or had) list item paragraphs using list styles. Take a look at the list styles (NOT paragraph styles applied to the items). See which character style is configured in Customize tab. Either select level 1-10 (the style in the drop-down menu is blank if levels are individually styled) or process each level to reset the style to factory "Numbering Symbols". You can then delete the offending Character_20_style (or any other spurious style).

(In reply to ajlittoz from comment #39)
> ...
> If you're really in the same context as question 25429, you probably have
> (or had) list item paragraphs using list styles. Take a look at the list
> styles (NOT paragraph styles applied to the items). See which character
> style is configured in Customize tab. Either select level 1-10 (the style in
> the drop-down menu is blank if levels are individually styled) or process
> each level to reset the style to factory "Numbering Symbols". You can then
> delete the offending Character_20_style (or any other spurious style).

I think I am in the context of 25429. My document probably had contact with Microsoft Word files (either by an ancestor stemming from it which I had emptied to maintain a previous collection of styles which I frequently use or it had contact by copy/paste insertions of paragraphs from *.doc or *.docx files.

If I look at the Styles sidebar and activate List Styles (the fifth one from left), it shows an empty work area when "Applied Styles" is selected. There were some Custom Styles with names starting with "www" which I have never actively made. Since they were not applied I could delete them all.

After I had done this, I deleted Character_20_style, stored my document and quit LO Writer. Then I started it again and looked, if the offending Character_20_style re-appeared: It didn't. I'll keep an open eye if it mysteriously re-appears in the near future.