# Writer: How to get rid of "Character_20_style" ? [closed]

A lengthy .odt document is based on a template. The template has been updated and contains only desired styles. The old long document has been opened for review and the styles were reimported as a result of the template "refresh".

But now, I see a Character_20_style among the character styles. I right-click on its name and select Delete. The deletion is accepted as the style is nowhere used.

After saving and reopening, the Character_20_style is back and seems particularly sticky. Unfortunately, since it is a character style, I cannot use Edit>Find & Replace... to search for usage to make really sure it is not used.

This strange style is not present in the template. It was probably in the document before template refresh but I did not check.

The document is quite old (in digital standards) and I don't remember if it has ever been in contact with Word. I had the same issue with character style Zeichenformat although the document never included any part in German. Zeichenformat was deleted on first attempt and did not come back.

I guess that the sequence _ 20 _ in the name is an hexadecimal replacement for an ASCII space and that the original offending object was something called "Character style", but I can't fancy where I can find it to get rid of it.

I'd prefer not to dig into the XML to clean the ODF stream because 1) the document is long, 2) the process is highly error-prone.

Does someone know a way to eradicate unwanted sticky character styles?

LO v5.2.6 - OS Linux/Fedora 24

UPDATE 1

As suggested by @Lupp, I typed a new paragraph with the @#!* style, changed some style attributes (making it bold read) so that I can visually spot any occurrence, gave it new name zombie, saved and reopened.

Now things get really funny.

I restyle whole paragraph as (character) Default style, save, try to delete but "style is in use". I save-reopen. Paragraph characters are back in zombie style but display looks like Default style! I create a second paragraph with only one word in zombie, save-reopen. I style everything in Default style, save-reopen. Offending style does not look applied and I can delete it.

I save-reopen and, wow!, Character_20_style is back again in the character style list!

I'll experiment with the XML ODF stream and come back here.

UPDATE 2

Playing too much with the file, the style name is now Character_5f_20_5f_style (with the underscores becoming part of the name).

I found one definition in the XML for list style Numbering 1 where all levels reference

text:style-name="Character_5f_20_5f_style"
which explains why it comes back.

From this diagnostic, I fixed Numbering 1 (right-click, Modify..., Options tab), restoring Character style to Numbering symbols in the original file and problem is cleared.

edit retag reopen merge delete

### Closed for the following reason the question is answered, right answer was accepted by ajlittoz close date 2017-05-13 22:21:08.750121

Did you already try to first apply the style somewhere, then edit and rename it in advance of trying to delete it? This might make the zombie style living again and thus "killable".
(Just a faint idea not actually expected to work.)

( 2017-05-13 14:10:59 +0200 )edit

It's easy to work on the xml saving the file as flat odt, because then it's only one text file, so easy to open - search - replace - update.

( 2017-05-13 14:25:36 +0200 )edit

@m.a.riosv: not that easy; newlines are not very frequent in the XML and lines may endup lionger than internal buffer in text editor. It already happened to me and you must add newlines with an hexadecimal editor, which is not very convenient. Anyway, I am doomed to do it.

( 2017-05-13 15:18:40 +0200 )edit

Sort by » oldest newest most voted

Problem comes from unexpected interference between style categories.

For an unknown reason, character style for "number" symbols in list style Numbering 1 was suddenly damaged to Character_20_style (which is by the way the title of the drop-down menu), causing the zombie behaviour: style was effectively not applied to text but used by a style definition. Whenever LO reinitialised, this style was recreated so that Numbering 1 was complete.

Reverting to standard Numbering 1 definition solved the problem.

more