Bug 75297 - FORMATTING: Number Styles, character style of "None" is ignored
Summary: FORMATTING: Number Styles, character style of "None" is ignored
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Justin L
Whiteboard: target:7.5.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Styles-Character ODF-export-invalid
  Show dependency treegraph
Reported: 2014-02-21 04:55 UTC by Dale
Modified: 2022-09-07 14:42 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:

Example document (34.32 KB, application/vnd.oasis.opendocument.text)
2014-02-21 04:55 UTC, Dale

Note You need to log in before you can comment on or make changes to this bug.
Description Dale 2014-02-21 04:55:13 UTC
Created attachment 94475 [details]
Example document

Background: In Numbering Styles, the style of the number character is set by the specified character style.
The default character style is "Numbering Symbols", and by default there are no attributes set for that style. In other words the visual behaviour is the same as if "None" was specified as the character style.

The Problem: In LibreOffice 4.x if the character style has been defined as "None", it is automatically changed to "Numbering Symbols", which of course produces a different visual result *IF* that character style has been changed from its default.
This problem is observed in LO, LO, and LO
This problem is not observed in LO 3.3.4, LO 3.4.6, LO
Platform is Windows XP.

The example document demonstrates this and contains images of the relevant settings and the effects.
Comment 1 sophie 2014-02-26 17:23:43 UTC
Hi, I can see what you said in your sample document, but what is the difference? you can still define the character style "numbering symbol" in the Style and formatting window? I don't see how it is a bug because now you have a defined style instead of none. Sophie
Comment 2 Dale 2014-02-26 21:00:22 UTC
Hi Sophie, Unless there has been a specification change and LO4 is implementing that change, the document should look the same regardless of which tool it is opened in. LO3 and OOo3&4 render the document as I expect. LO4 renders it differently. (It is applying a style of its choice iff one is not already specified for the numbering.)

The purpose (as far as I can tell) for having the ability to set the character style of numbering is to allow the numbering to be rendered differently to the paragraph it is applied to. However if we wish the numbering style to render the text the *same* as the underlying paragraph, then we do *not* want to apply a character style. We could set the character style to match the paragraph style (as you suggest), but that breaks the ability to change the paragraph style and have the numbering automatically change to match.
Comment 3 Dale 2014-02-27 02:38:16 UTC
More details:
When editing with LO 4.x, setting the relevant character style to None produces the same rendering behaviour as it does in LO 3.x.

Editing with LO 4.x, setting the relevant character style to None, then saving the document, results in it being saved as expected.

This is demonstrated by opening the newly-saved document with LO 3.x or OOo; it looks the same as it did in LO 4.x at the point of saving.

However if that newly-saved document is reopened in LO 4.x, it now looks different - that is a bug.
Comment 4 Yousuf Philips (jay) (retired) 2014-07-11 03:11:45 UTC
Confirmed that the document looks different in 3.6.7 from 4.0 and above on Linux Mint.
Comment 5 Xisco Faulí 2014-11-06 14:27:44 UTC
 2e0fa432485d1db6abd355dad8ccb06f0b97e4fb is the first bad commit
commit 2e0fa432485d1db6abd355dad8ccb06f0b97e4fb
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue Dec 11 09:32:19 2012 +0000

    commit ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
    Author:     Luboš Luňák <l.lunak@suse.cz>
    AuthorDate: Sun Dec 2 22:35:57 2012 +0100
    Commit:     Luboš Luňák <l.lunak@suse.cz>
    CommitDate: Mon Dec 3 18:04:24 2012 +0100
        fixes for where fast string operator+ is not perfectly source compatible
        Change-Id: I80af0399037e4f68113338139e7f2ad2400e65ab

:100644 100644 d6a3e35f1dc57a7469408bdb1aaa587ba6cf3cfe b4973c1d86cfd5c0d550e84e7e483802d979829e M	ccache.log
:100644 100644 a2d3790ddaa245f4d56968133ce5be440af2c033 a0e5b02e554537a0bed70a3203ca3995bb6972bd M	commitmsg
:100644 100644 3fad2a60908b6b6bc1de0af560f7239a89b54e73 6ba1538977f3fb5b8f0ee54bbd04be28afdd85e3 M	dev-install.log
:100644 100644 2df1def8f8a08f16f92540ae4eab28de4984a88f dc4842a6e74513bbe562bb0d78a1ed545ead53e7 M	make.log
:040000 040000 0dc3db85f8784d986d2364a0972044d502c2a5e3 e70233c1668fc1da017a420ac2ed5ee366e253ad M	opt

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28
# bad: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
git bisect bad d65a58c31c8da044ef66ae4517fa2fe74cec0019
# good: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73
git bisect good 79e02001f27d33b3b478324ab6fba5683413b4d9
# good: [1e04c3b7ef40994ada3236fa8f90fbd1cdcea47e] source-hash-11e776023c89b3de690b37ffaed18ec996b9c207
git bisect good 1e04c3b7ef40994ada3236fa8f90fbd1cdcea47e
# good: [c3482ad95176ec6762ef03e95d3287ebd5e84905] source-hash-3d4288c1c0b593421c7f6619c88584bdb7c53337
git bisect good c3482ad95176ec6762ef03e95d3287ebd5e84905
# bad: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
git bisect bad 2e0fa432485d1db6abd355dad8ccb06f0b97e4fb
# good: [16817aeb240d8066676540c467a7e4aac00ed008] source-hash-4026e1824de8ff9b5d006ae6eba491f91bc4e599
git bisect good 16817aeb240d8066676540c467a7e4aac00ed008
# first bad commit: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
Comment 6 Robinson Tryon (qubit) 2014-12-23 22:09:02 UTC
Whiteboard: Remove 'needQAAdvice' once bug is NEW/RESOLVED.
Comment 7 Matthew Francis 2015-01-08 08:37:32 UTC
The behaviour seems to have changed as of the below commit.

Adding Cc: to cedric.bosdonnat.ooo@free.fr. It sounds from the commit message like there is a larger context to this commit, but perhaps you might have some idea about what caused this behaviour change?

commit d9ef61fb546af443736057557552e3a95c569c11
Author: Cédric Bosdonnat <cedric.bosdonnat@free.fr>
Date:   Mon Dec 3 17:48:40 2012 +0100

    API CHANGE: roll back the XStyle changes to add a new Hidden property on Style
    Change-Id: If6d23925567fb184cd8fc4e00fc72fe4d216e756
Comment 8 Xisco Faulí 2015-11-23 12:23:09 UTC
This issue is still present in 

Build ID: e6fade1ce133039d28369751b77ac8faff6e40cb
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-16_00:12:42
Locale: es-ES (es_ES)

on Window 7
Comment 9 Robinson Tryon (qubit) 2015-12-13 11:09:32 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2017-01-03 19:46:32 UTC Comment hidden (obsolete)
Comment 11 Dale 2017-01-03 22:00:42 UTC
This issue is still present in 

Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; 
Locale: en-AU (en_AU); Calc: group

on Windows 7
Comment 12 QA Administrators 2018-01-04 03:34:38 UTC Comment hidden (obsolete)
Comment 13 Thomas Lendo 2019-08-29 22:59:30 UTC
Still reproducible that LibreOffice opens the file with character style 'Numbering style' despite that character style 'None' was selected and the file was saved and reloaded.

Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: de-AT (de_AT.UTF-8); UI-Language: en-US
Comment 14 Regina Henschel 2020-09-12 16:40:08 UTC
It is a problem in file open. When set to "none" and then saved, there exists no attribute "text:style-name" in element <text:list-level-style-numeric>. That is correct. But after opening the style "Numbering Symbol" is used.

Problem still exists in Version: (x64)
Build ID: 1e0cfd5662d95cea84e80e4fe10d52c3b1101ae6
CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL
Comment 15 Justin L 2021-07-12 12:53:54 UTC
It seems to be "fixed" for me since LO 6.1 (which conflicts with comment 13) with commit 74c527abc0f3b5aa0fa179401ad05a79dc889973
Author: Yousuf Philips on Tue Dec 5 13:54:29 2017 +0400
    tdf#106988 New names for the new numbering styles

Steps I am taking:
1.) Open the file. (Notice that the number 1 is a normal size.)
2.) Format -> Bullets and Numbering shows char style "Numbering Symbols"
but with the above commit is is "None" (and still true after round-tripping).

Well, that commit doesn't SOUND like it should really fix the problem, so what are the steps to reproduce still?
Comment 16 Regina Henschel 2021-12-05 19:40:36 UTC
The problem still exists.
Tested with Version: (x64) / LibreOffice Community
Build ID: 4ac9032163cf55c160145373e7c41741c9c339ca
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL

Steps to reproduce.
1. Write some lines and apply list style "Numbering 123".
2. Change character style "Numbering Symbols" to use a larger font size or to use a color in the font effects. The numbers will change accordingly.
3. Go to style "Numbering 123" and set the character style to "None". The numbers are now shown same as the rest of the text in the list item.
4. Save the document.
5. Open the document. The numbers are again as specified in "Numbering Symbols". Go to list style "Numbering 123" and look at character style. You see "Numbering Symbols" and not "None". Look at "Organizer" tab. It (correctly) does not contain a character style.

Look at it with the new "Development Tools", find "CharStyleName" in "Numbering Rules". After opening from file it has "Numbering Symbol". After setting "None" it has an empty string. It should be an empty string too after loading the file. Saving is correct, the <text:list-level-style-number> element has not attribute text:style-name.
Comment 17 Justin L 2022-05-25 06:51:04 UTC
(In reply to Justin L from comment #15)
> It seems to be "fixed" for me since LO 6.1 (which conflicts with comment 13)

The example document in comment 0 is based on "Numbering 1" which is no longer a built-in name for a list style. So that specific document is working as desired now. But if the name matches one of the new pre-defined names, then the existing character style is retained.

Proposed fix at https://gerrit.libreoffice.org/c/core/+/134888
Comment 18 Commit Notification 2022-06-10 20:28:37 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf#75297 sw uno: override default num char style when NONE

It will be available in 7.5.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:

Affected users are encouraged to test the fix and report feedback.
Comment 19 Justin L 2022-06-10 20:31:57 UTC
no desire to backport this. I left it alone until 7.5 branch off.
Comment 20 Commit Notification 2022-09-07 14:42:22 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf#149547 fix "tdf#75297 sw uno: override default num char style"

It will be available in 7.5.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:

Affected users are encouraged to test the fix and report feedback.