Bug 67797 - FORMATTING: Creating Manual Numbered List Fails, parses C. as Roman numeral "C" (Comment 11)
Summary: FORMATTING: Creating Manual Numbered List Fails, parses C. as Roman numeral "...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.7.1 rc
Hardware: All All
: low minor
Assignee: Justin L
URL:
Whiteboard: BSA target:26.2.0
Keywords:
: 150748 166539 (view as bug list)
Depends on:
Blocks: AutoCorrect-Complete Bullet-Number-Outline-Lists Tab-Stops
  Show dependency tree / graph
 
Reported: 2013-08-05 17:55 UTC by Toby
Modified: 2025-08-22 18:59 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Toby 2013-08-05 17:55:47 UTC 
Problem description: 
When you create a list by manually typing in the elements with the first row of the entry number and following rows indented using tabs with a letter prefix for each row fails when you hit return on the third lettered entry. That entry then moves to the left margin instead of remaining indented.

Steps to reproduce:

1. Create a list with a return and at end and a tab at the beginning of each line, for example:

1. Text 
    A. Text
    B. Text
    C. Text

2. With the cursor at the end of the third entry (C) and then hitting return you will get:

1. Text
    A. Text
    B. Text
C. Text

The third entry moves back to the margin.

Current behavior:

See step 2 above:

Expected behavior:

This is what I would expect:

1. Text 
    A. Text
    B. Text
    C. Text
    D. Text
    E.  Text
    etc...

The same behavior exists on Mac OS X 10.7.5, 10.8.4, and Window 7.

Thanks,
Toby

Operating System: Mac OS X
Version: 4.1.0.4 release
Comment 1 Michael 2013-08-06 18:13:19 UTC 
Hi, 
I can reproduce it with 4.1.0.4 on OSX 10.8.4 and Ubuntu 12.04.
Earliest version I had installed is 3.6.7.1 with that behavior.
LO 3.3.0 produces the following:
	A. Text
	B. Text
            C. Text
            CI. 

Workaround for now seems to be to retab at the end of the list creation.
Comment 2 QA Administrators 2015-04-01 14:40:02 UTC Comment hidden (obsolete)
Comment 3 Buovjaga 2015-04-19 14:29:14 UTC 
Reproduced.

Win 7 Pro 64-bit Version: 5.0.0.0.alpha0+ (x64)
Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-18_01:51:17
Locale: fi_FI
Comment 4 QA Administrators 2016-09-20 09:31:58 UTC Comment hidden (obsolete)
Comment 5 Thomas Lendo 2018-03-05 00:15:30 UTC 
Buovjaga, can you still reproduce this issue?
I can't.
Comment 6 Buovjaga 2018-03-05 08:59:28 UTC 
(In reply to Thomas Lendo from comment #5)
> Buovjaga, can you still reproduce this issue?
> I can't.

Still repro. Note that the reproduction does not involve activating numbered list - we are just supposed to start typing 1. Text etc.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 13164cc99dc6184fb2c12e56e9c0dea0d5692eec
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 4th 2018
Comment 7 Thomas Lendo 2018-03-05 20:42:22 UTC 
Ah, manually entered I reproduce this issue. Very weird.
Comment 8 QA Administrators 2019-03-06 03:42:42 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2021-03-06 03:45:46 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2023-03-07 04:18:19 UTC Comment hidden (obsolete)
Comment 11 Andreas Heinisch 2023-04-04 16:05:15 UTC 
I investigated the problem and it seems LO checks for roman numberings and starts a new enum out of it. So all the strings in the roman numbering alphabet (mdclxvi) lead to this problem.
Comment 12 Andreas Heinisch 2023-04-19 08:05:01 UTC 
Abandoned patch at: https://gerrit.libreoffice.org/c/core/+/150028 including comments in order to solve this issue.
Comment 13 QA Administrators 2025-04-19 03:11:09 UTC Comment hidden (obsolete)
Comment 14 Takenori Yasuda 2025-05-24 07:52:01 UTC 
Reproduced.

Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 3158b14e0b26875300a8098bc117a5e69b76f48f
CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: default; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: threaded


I have a question: is tdf#166539 the same issue as this one?
Having investigated and commented on tdf#166539 myself, I believe they are the same bug.
It would be helpful if someone could take a look and confirm.
Comment 15 Dieter 2025-06-01 10:01:11 UTC 
*** Bug 166539 has been marked as a duplicate of this bug. ***
Comment 16 Dieter 2025-06-01 10:08:12 UTC 
Steps:

1. Open attachment 200752 [details] (from bug 166539)
2. Place cursor at end of item 3. and presse enter

Actual result:
Tab before 3. disappears

Expected result:
Tab should remain

Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL threaded
Comment 17 V Stuart Foote 2025-06-01 14:46:44 UTC 
Remains an issue at 25.8

manual entered text numbering with Roman numerals strips leading blanks--so hits in a list when numbered with "C". Likewise for I,X,M,V,D,L

An editshell Autocorrection that is not exposed to the Autocorrect dialog to disable?

Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 043b186d10fca4a613ce62c1e0d04f86ec63799c
CPU threads: 8; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 18 Mike Kaganski 2025-06-01 15:24:16 UTC 
Code pointer: SwAutoFormat::BuildEnum in sw/source/core/edit/autofmt.cxx, which generally checks m_aFlags before ~all modifications, but not before calling DeleteLeadingTrailingBlanks().
Comment 19 Takenori Yasuda 2025-06-02 02:10:44 UTC 
I'm not sure if this will help narrow down the issue, but I’d like to share the conditions I previously noted in Bug 166539 that reliably trigger this bug.

Occurs under the following conditions:
Tools -> AutoCorrect -> AutoCorrect Options -> Options
- Delete spaces and tabs at beginning and end of paragraph: ON
- Apply Styles: OFF

Note:
The help page "Delete spaces and tabs at beginning and end of paragraph" says, "To use this option, the Apply Styles option must also be selected."

Help page URL: 
https://help.libreoffice.org/25.2/en-GB/text/shared/01/06040100.html?System=WIN&DbPAR=WRITER&HID=cui/ui/applyautofmtpage/ApplyAutoFmtPage#bm_id3147527
Comment 20 Justin L 2025-08-21 22:31:39 UTC 
There are (at least) two paths using BuildEnum. The one discussed here is "[T] as you type", and the other is "[M] Tools - AutoCorrect - Apply". Both of these only affect Default/Body Text styles.

In the [M] path (!m_aFlags.bAFormatByInput), it removes the spacing and applies a "Numbering X" style. It probably also "Combines single line paragraphs if length greater than 50% (m_aFlags.bRightMargin)".

In my [T] typing testing (and as expected because it is listed as an [M]-only option), I could not trigger bRightMargin - so it ought to be equivalent to 
!bAFormatByInput.


Also note that "[T] Bulleted and Numbered Lists." (m_aFlags.bSetNumRule) comes into play here. Although comment 0 tested with this turned off, comment 1 tested with it turned on. If we do (annoyingly) turn it into a numbered list, then certainly the leading blanks need to be deleted still.

So we need to delete the leading blanks if bSetNumRule or !bAFormatByInput.

P.S. It is somewhat unclear what should happen with relation to comment 19 if Apply Styles is turned ON. In that case no style change happens to an IsEnumericChar - so lets strip there as well just to match previous behaviour.
Comment 21 Justin L 2025-08-21 23:07:24 UTC 
*** Bug 150748 has been marked as a duplicate of this bug. ***
Comment 22 Commit Notification 2025-08-22 13:33:30 UTC 
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8dbe20acb5ec2d01c88f040bb42cc49cc9167b84

tdf#67797 autofmt: don't delete leading blanks without bSetNumRule

It will be available in 26.2.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 23 Justin L 2025-08-22 13:42:24 UTC 
Marking this as fixed, since it no longer causes the problem reported in comment 0.

The patch fixes it so that (by default) none of these are affected during typing:
    1. single-indented text
        A. double-indented text
        B. double-indented text
        C. double-indented text
a. non-indented text

If someone wants to argue that LO should be smarter about creating "[T] Bulleted and Numbered Lists. ..." then that should be created as a separate bug report.
Comment 24 BogdanB 2025-08-22 18:59:02 UTC 
Verified with
Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1a62a694aa31e754b8cecc6505a9ed32ba96b3c3
CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Tab now remains