Bug 166229 - Bullet style does not change anymore with list indentation level
Summary: Bullet style does not change anymore with list indentation level
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
25.2.2.2 release
Hardware: All All
: medium minor
Assignee: Miklos Vajna
URL:
Whiteboard: target:25.8.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Bullet-Number-Outline-Lists
  Show dependency treegraph
 
Reported: 2025-04-17 14:40 UTC by Henning
Modified: 2025-09-05 16:36 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henning 2025-04-17 14:40:32 UTC
Description:
Before, when I created a bulleted list, the bullet's style used to follow the indentation level like so: filled circle, empty circle, filled square, etc.
Now, it stays a filled circle.
Even in an existing document with a bulleted list of the former style, when I create a new list it does not change the bullet style anymore with indentation.
The workaround for the time being is to copy a bit of an old list, which seems to retain the old style inside of it, and modify it.

I guess the overall template has changed, what I consider a problem:
- First, when looking at the style in the list templates, I can only edit each indentation level individually, afraid of maybe missing something else under the hood. I would like to take over the whole list template as it was before.
- Second, I don't want to need to edit the default style, because it will make LO Writer behave differently on different computers.

Steps to Reproduce:
1. create new document in Writer
2. create a bullet list
3. indent

Actual Results:
a. bullet style stays the same: a filled circle
b. in an existing document, a newly created list will differ in style from existing ones

Expected Results:
1. bullet style changes with indentation level
2. in an existing document, the style should remain as it is


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac
CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: de-DE (en_DE); UI: de-DE
Calc: CL threaded
Comment 1 m_a_riosv 2025-04-18 10:20:19 UTC
I think the bug is with 
Bug 108697 - New default set of bullet characters
https://bugs.documentfoundation.org/show_bug.cgi?id=108697
@Heiko what do you think about?

Reproducible
Version: 25.2.0.3 (X86_64) / LibreOffice Community
Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded


Latest version that works on the ones I have installed.
Version: 24.8.6.2 (X86_64) / LibreOffice Community
Build ID: 6d98ba145e9a8a39fc57bcc76981d1fb1316c60c
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 2 Ezinne 2025-05-01 04:49:08 UTC
Git Bisect shows the regression started from:

commit 626357f53c934e7f57dc80c3c83ad080767961f3
Author: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Date:   Thu Jul 11 12:48:29 2024 +0200

    Use configured bullet symbol when clicking bullets button
    
    Instead of the generic default symbol
    
    Change-Id: I0923d4ede5d7cc09d61bb57d5cb6dbf6f2af8058
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170373
    Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
    Tested-by: Jenkins

diff --git a/sw/source/uibase/wrtsh/wrtsh1.cxx b/sw/source/uibase/wrtsh/wrtsh1.cxx
index e243beb22ea8..78170708ebad 100644
--- a/sw/source/uibase/wrtsh/wrtsh1.cxx
+++ b/sw/source/uibase/wrtsh/wrtsh1.cxx
@@ -1584,11 +1584,6 @@ void SwWrtShell::NumOrBulletOn(bool bNum)
         // Append the character template at the numbering.
         SwCharFormat* pChrFormat;
         SwDocShell* pDocSh = GetView().GetDocShell();
-        // #i63395#
-        // Only apply user defined default bullet font
-        const vcl::Font* pFnt = numfunc::IsDefBulletFontUserDefined()
-                           ? &numfunc::GetDefBulletFont()
-                           : nullptr;
 
         if (bNum)
         {
@@ -1615,13 +1610,14 @@ void SwWrtShell::NumOrBulletOn(bool bNum)
 
             if (! bNum)
             {
-                // #i63395#
-                // Only apply user defined default bullet font
-                if ( pFnt )
-                {
-                    aFormat.SetBulletFont( pFnt );
-                }
-                aFormat.SetBulletChar( numfunc::GetBulletChar(nLvl) );
+                uno::Sequence<OUString> aBulletSymbols(
+                    officecfg::Office::Common::BulletsNumbering::DefaultBullets::get());
+                uno::Sequence<OUString> aBulletSymbolsFonts(
+                    officecfg::Office::Common::BulletsNumbering::DefaultBulletsFonts::get());
+                aFormat.SetBulletChar(aBulletSymbols[0].toChar());
+                vcl::Font aFont;
+                aFont.SetFamilyName(aBulletSymbolsFonts[0]);
+                aFormat.SetBulletFont(&aFont);
                 aFormat.SetNumberingType(SVX_NUM_CHAR_SPECIAL);
                 // #i93908# clear suffix for bullet lists
                 aFormat.SetListFormat(u""_ustr, u""_ustr, nLvl);
Comment 3 Miklos Vajna 2025-05-08 11:37:37 UTC
I intend to look at this. Sounds like we always take the first item from that list, while the config has multiple items, so it would be possible to work with the config + have different characters at the same time.
Comment 4 Commit Notification 2025-05-12 14:27:24 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d32dd7675b36952dd38e6c9b7d280ff2c4008404

tdf#166229 sw: make bullet style change again with list indentation level

It will be available in 25.8.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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Miklos Vajna 2025-05-12 14:29:11 UTC
I think this works now.
Comment 6 Buovjaga 2025-09-03 20:01:24 UTC
Heiko, Stuart: seeing your comments in bug 167464, maybe you want to consider this change that went into 25.8. As Heiko put it in the other report: "Only one kind of glyph looks more professional; the indentation is sufficient to indicate the level. And changing the bullets is simple and easy."

To me it looks like an accidental change created a behaviour that appealed to Stuart and Heiko. In 25.8 this is no longer the case, but we are back to multiple kinds of glyphs by default.

I found this report after investigating this Reddit post by bibisecting: https://old.reddit.com/r/libreoffice/comments/1n6cjep/do_not_update_252_to_258/
Comment 7 V Stuart Foote 2025-09-03 21:17:15 UTC
Hmm, actually this is a problem.

For bug 108697 we adjusted the 8 glyphs as used for the Unordered list picker.
https://gerrit.libreoffice.org/c/core/+/174028

They applied to the Unordered list split button, and to the Customize tab for 'Bullets' in the 'Bullets and Numbering...' dialog.

The patch by Miklos has now removed, 4 of those glyphs and the Unordered list split button picker repeats the 4 remaining.
https://gerrit.libreoffice.org/c/core/+/185208

I think those slots were significant as they are also used to populate the 'Bullet Library' split button and the 'Bullets and Numbering...' dialog.

And as a side note something has gotten munged with this at 26.2--the 'Bullets and Numbering' dialog is now showing the 'Ordered list' preview buttons on selecting the 'Unordered' "tab". And the 'Unordered list' preview buttons (with just the 4 glyphs repeating) on selecting the 'Ordered' tab.  That could be around the Vertical Tab VT work.
Comment 8 Buovjaga 2025-09-04 08:54:18 UTC
(In reply to V Stuart Foote from comment #7)
> And as a side note something has gotten munged with this at 26.2--the
> 'Bullets and Numbering' dialog is now showing the 'Ordered list' preview
> buttons on selecting the 'Unordered' "tab". And the 'Unordered list' preview
> buttons (with just the 4 glyphs repeating) on selecting the 'Ordered' tab. 
> That could be around the Vertical Tab VT work.

I have a patch for that: https://gerrit.libreoffice.org/c/core/+/190571
Comment 9 Miklos Vajna 2025-09-04 14:03:11 UTC
My above patch is still in, and contains a testcase which continues to pass. Could we please close this bug again and open a follow-up bug for the problem you still have? Thanks.
Comment 10 V Stuart Foote 2025-09-04 14:23:17 UTC
(In reply to Miklos Vajna from comment #9)
> My above patch is still in, and contains a testcase which continues to pass.
> Could we please close this bug again and open a follow-up bug for the
> problem you still have? Thanks.

Hmm, kind of feel like the patch clobbered the list of preselect bullets available for the Unordered list while "reestoring" the sequence on indentation changes.

The two behaviors probably needed to be split rather than the simple change to the 'List of default bullets' tweaked in common.xcs, where bullets are repeated and the additional two added for the 9th and 10th indentation level.
Comment 11 Heiko Tietze 2025-09-04 15:59:25 UTC Comment hidden (off-topic)
Comment 12 Heiko Tietze 2025-09-04 16:03:14 UTC Comment hidden (off-topic)
Comment 13 Heiko Tietze 2025-09-04 16:22:21 UTC
Another observation: Applying the LS via Style > Bullet * List Style (or per context menu or the Stylist) results in equal bullets on level change. However, the unordered list applied per toolbar (Shift + F12) does the expected bullet change.
Comment 14 Heiko Tietze 2025-09-05 16:36:27 UTC
We discussed the topic during the conference and the actual issue has been solved. What happens depends heavily on the workflow, though. I filed two follow-up tickets (bug 168288 and bug 168289) to deal with the problem. There is no simple answer.