Bug 128891 - FILEOPEN: Level 2 chapter enumeration doesn't reset counter
Summary: FILEOPEN: Level 2 chapter enumeration doesn't reset counter
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2019-11-19 09:12 UTC by David
Modified: 2022-11-06 03:39 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
odt with Bugged subchapters (837.23 KB, application/vnd.oasis.opendocument.text)
2019-11-19 09:14 UTC, David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2019-11-19 09:12:34 UTC
Description:
I have a odt document including chapters and subchapters.
1. Chapter1
 1.1 subchapter 1.1
2. Chapter2
 2.1 subchapter 2.1
3. Chapter3
 3.1 subchapter 3.1

Everytime y save to odt file the subchapters are renumbered:
* 2.1 to 1.2
* 3.1 to 1.3

if I clean direct format (Ctrl+M) on these subchapters, it corrects and go back to 2.1 and 3.1 but when saving and loading, it becomes bugged again

Steps to Reproduce:
1. Open attached file. See subchapters enumerations
2. use Ctrl+M to clean direct formats on every subchapter
3. Save file.

Actual Results:
Loading the file the subchapters are bugged again and Ctrl + M must be pressed again on every subchapter

Expected Results:
Subchapters should have clean direct formats, but not...


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 David 2019-11-19 09:14:27 UTC
Created attachment 155936 [details]
odt with Bugged subchapters
Comment 2 Durgapriyanka 2019-11-19 16:39:06 UTC
Thank you for reporting the bug. I can confirm the bug present in

Version: 6.4.0.0.alpha1+ (x86)
Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
	

But, not in

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 3 Xisco Faulí 2019-12-02 16:48:49 UTC
This is a FILEOPEN problem
Comment 4 Xisco Faulí 2019-12-02 16:59:26 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=bafd49fb4d72b6dbb10b2fea1386d295dc9d435c

author	Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>	2018-10-14 22:55:25 +0200
committer	Björn Michaelsen <bjoern.michaelsen@libreoffice.org>	2018-10-15 21:56:55 +0200
commit bafd49fb4d72b6dbb10b2fea1386d295dc9d435c (patch)
tree c7f8273d9f7d51839411b051494208f53733f94d
parent aa75bf8b11c6e2e4fd7e9988c3c9d7db2420389a (diff)
tdf#118049 tdf#118833 tdf#118725: Fix some SwDepend regressions

Bisected with:

Adding Cc: to Bjoern Michaelsen
Comment 5 BogdanB 2020-09-28 05:40:37 UTC
Still present in
Version: 7.0.1.2
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 6 Justin L 2021-03-23 11:44:37 UTC
repro 7.2+

Note that in an earlier time, this document was in an MS Format.
Comment 7 Björn Michaelsen 2021-10-31 20:00:45 UTC
The subchapter style is not a renames "Heading 2", but a custom style. Why should this even work? If anything, the bug is that those headers are "2.1" and "3.1" in the first place ...
Comment 8 Jean-Baptiste Faure 2022-04-05 10:06:18 UTC
Hi David,

Your test file has been created by conversion from a doc/docx file. Please could you provide the original MS-Word file to check how current version of LibreOffice import that file.

To restore the expected behavior, you need to modify the style "Default Paragraph Style":
- edit its style
- in tab Outline & List, change List style to "No List" (instead of WW8Num10)
- Apply then OK

I do not see any good reason to have a numbering style there for the style "Default Paragraph Style"

Best regards.
JBF
Comment 9 QA Administrators 2022-10-06 04:11:09 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2022-11-06 03:39:42 UTC
Dear David,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp