Bug 67797 - FORMATTING: Creating Manual Numbered List Fails at third entry
Summary: FORMATTING: Creating Manual Numbered List Fails at third entry
Status: NEW
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: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: TableofContents-Indexes
  Show dependency tree / graph
 
Reported: 2013-08-05 17:55 UTC by Toby
Modified: 2023-04-19 08:05 UTC (History)
2 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.