Bug 146851 - The logic of Cross Reference representing Paragraph Numbering is different between MSOffice and LibreOffice
Summary: The logic of Cross Reference representing Paragraph Numbering is different be...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.2.5.2 release
Hardware: All All
: medium normal
Assignee: Vasily Melenchuk (CIB)
URL:
Whiteboard: target:7.4.0 target:7.3.3
Keywords: bibisected, bisected, regression
: 147937 (view as bug list)
Depends on:
Blocks: DOCX-Fields
  Show dependency treegraph
 
Reported: 2022-01-19 04:26 UTC by softdev1029
Modified: 2022-06-21 06:11 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
cross-reference-test-file (616.94 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-01-20 01:57 UTC, softdev1029
Details
cross-reference-test-2 (189.64 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-01-21 03:45 UTC, softdev1029
Details

Note You need to log in before you can comment on or make changes to this bug.
Description softdev1029 2022-01-19 04:26:57 UTC
Description:
some cross-references have a full-stop added to the end of the cross-reference.

Clause 6.3 has a x-ref to clause "6", and displays it as "6." .

The targeted x-ref should be displayed as "6" without the full-stop. 

If you update the x-ref in MS Word it will be updated to "6" .

Steps to Reproduce:
1. Try to update the cross references after opening the document in Libreoffice.

Actual Results:
1. Clause 6.3 has a x-ref to clause "6", and displays it as "6." .

Expected Results:
1. The targeted x-ref should be displayed as "6" without the full-stop. 
2. If you update the x-ref in MS Word it will be updated to "6" .


Reproducible: Always


User Profile Reset: No



Additional Info:
It is related to https://bugs.documentfoundation.org/show_bug.cgi?id=145215#c21
Comment 1 softdev1029 2022-01-20 01:38:45 UTC
./soffice --version
LibreOfficeDev 7.3.0.0.alpha1 b8d17d754830ab57099dcdfa72a96bfad404ab1a

Ubuntu 20.04
Comment 2 softdev1029 2022-01-20 01:56:09 UTC
I downloaded the latest version from https://www.libreoffice.org/donate/dl/deb-x86_64/7.2.5/en-GB/LibreOffice_7.2.5_Linux_x86-64_deb.tar.gz

LibreOffice 7.2.5.2 499f9727c189e6ef3471021d6132d4c694f357e5

And this version also has the same issue.
Comment 3 softdev1029 2022-01-20 01:57:42 UTC
Created attachment 177662 [details]
cross-reference-test-file
Comment 4 softdev1029 2022-01-20 02:11:45 UTC
I found another bug.

I tested this document (https://bugs.documentfoundation.org/attachment.cgi?id=177662)

The x-refs targeting clause 2.1 are updated to `Error: Reference source not found`. 

On page 5, the x-ref that is broken should be updated and display `2.1` after updating the cross-references.

My Ubuntu 20.04 includes LibreOffice 6.4.7.2 as default.
And LibreOffice 6.4.7.2 doesn't have the above issue and the full-stop issue.

I think these issues were introduced by the fix of https://bugs.documentfoundation.org/show_bug.cgi?id=145215#c21
Comment 5 softdev1029 2022-01-21 03:45:29 UTC
Created attachment 177683 [details]
cross-reference-test-2

I found the 3rd bug.

The "Schedule" heading on page 14 is removed from the document when updating the cross references and accordingly any x-refs that target that heading has been removed.

- I tested LibreOfficeDev 7.3.0.0.alpha1. And, the targeted referee’s content is removed. x-ref itself exists and it just displays as an empty string.

- I tested the latest version is 7.2.5. And,  the targeted referee’s content is changed to 15. x-ref also shows 15.

- And I tried the 6.2.4 of Ubuntu 20.4. And,  the targeted referee’s content is not changed and it still shows Schedule. But x-ref becomes the empty string.
Comment 6 softdev1029 2022-01-21 03:58:06 UTC
I found the 4th bug when testing with https://bugs.documentfoundation.org/attachment.cgi?id=177662

When updating the cross references, the document produces paragraph numbering that continues from a previous paragraph number instead of restarting at 1.

Please review "Schedule 6".
Schedule 6 starts at paragraph numbering 19.
But the original document restarts numbering at 1.

It happens at all below versions.

7.3.0.0.alpha1
7.2.5
6.2.4 of Ubuntu 20.4
Comment 7 softdev1029 2022-01-24 01:42:41 UTC
In 6.2.4 of Ubuntu 20.4, the following error doesn't happen.
I believe this regression might be by https://bugs.documentfoundation.org/show_bug.cgi?id=145215#c21


```
When updating the cross references, the document produces paragraph numbering that continues from a previous paragraph number instead of restarting at 1.

Please review "Schedule 6".
Schedule 6 starts at paragraph numbering 19.
But the original document restarts numbering at 1.
```
Comment 8 thomas.bullock 2022-02-07 02:28:01 UTC
I am encountering the same issues as softdev1029@outlook.com 
Can we get some action on this?
Comment 9 yilin 2022-02-07 02:48:12 UTC
Same problem as softdev1029@outlook.com, 
Looking forward to your response asap, thank you!
Comment 10 Gabor Kelemen (allotropia) 2022-03-11 10:52:33 UTC
(In reply to softdev1029 from comment #4)
> I found another bug.
> 
> I tested this document
> (https://bugs.documentfoundation.org/attachment.cgi?id=177662)
> 
> The x-refs targeting clause 2.1 are updated to `Error: Reference source not
> found`. 
> 

This issue is solved in 7.3 by:

https://git.libreoffice.org/core/+/0ad78d7c1148fd7cde305eb34ab3a921a18632a0

author	László Németh <nemeth@numbertext.org>	Thu Dec 02 17:45:46 2021 +0100
committer	László Németh <nemeth@numbertext.org>	Sat Dec 11 10:47:05 2021 +0100

tdf#145720 DOCX export: fix loss of tracked moving
Comment 11 Gabor Kelemen (allotropia) 2022-03-11 11:35:50 UTC
(In reply to softdev1029 from comment #5)
> Created attachment 177683 [details]
> cross-reference-test-2
> 
> I found the 3rd bug.
> 
> The "Schedule" heading on page 14 is removed from the document when updating
> the cross references and accordingly any x-refs that target that heading has
> been removed.
> 
This was fixed in 7.3 by:

https://git.libreoffice.org/core/+/66a7f8a49d2db1829dd533f32ae5818499f8544b

Author	Vasily Melenchuk <vasily.melenchuk@cib.de>	Sat Sep 25 19:06:11 2021 +0300
committer	Vasily Melenchuk <vasily.melenchuk@cib.de>	Mon Oct 04 15:29:07 2021 +0200

tdf#144609: numbering "None" should still show prefix/suffix

> - I tested LibreOfficeDev 7.3.0.0.alpha1. And, the targeted referee’s
> content is removed. x-ref itself exists and it just displays as an empty
> string.
> 

This is still present in 7.4 master, for example at the very bottom of page 13:

Workplace has the meaning given in Item 8 of the Schedule.

becomes after pressing F9

Workplace has the meaning given in Item 8. of the .

> - I tested the latest version is 7.2.5. And,  the targeted referee’s content
> is changed to 15. x-ref also shows 15.
> 

This was solved in 7.3 by:

https://git.libreoffice.org/core/+/3e09e0784ad7669d3e0a7655f5e604a2387b1b5d

author	Justin Luth <justin_luth@sil.org>	Thu May 13 13:50:56 2021 +0200
committer	Miklos Vajna <vmiklos@collabora.com>	Tue Jul 06 08:52:55 2021 +0200
tree 1b2b34076c4e9d344135a88aa7bd2a429eeae3ba
parent cfc677d667e118bfe7f092b584c4773476b9b906 [diff]

tdf#141966 writerfilter CN: fix chapter number identification

Side effect is that this started the above issue; before this the incorrect "15" prefix was updated in the x-ref ("Item 8 of the Schedule." -> "Item 8. of the 15."), now it's empty ("Item 8. of the .") upon F9.
Comment 12 Commit Notification 2022-03-16 03:43:38 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "master":

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

tdf#146851: writerfilter: do not recreate list levels on override

It will be available in 7.4.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 13 Commit Notification 2022-03-16 03:44:47 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "master":

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

tdf#146851: sw: even numbering=None is still a numbering

It will be available in 7.4.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 14 Vasily Melenchuk (CIB) 2022-03-16 06:58:54 UTC
*** Bug 147937 has been marked as a duplicate of this bug. ***
Comment 15 Commit Notification 2022-03-16 10:45:33 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

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

tdf#146851: writerfilter: do not recreate list levels on override

It will be available in 7.3.3.

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 16 Commit Notification 2022-03-17 11:24:55 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

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

tdf#146851: sw: even numbering=None is still a numbering

It will be available in 7.3.3.

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 17 ajlittoz 2022-06-21 06:08:43 UTC
The implemented fix assumes that the "after" separator of numbered item is always a full stop. A user may customise the numbering and set any string. The suppression should target the effective "after" separator.

See bug 149635 (feature request)