Bug 49102 - Writer: Incorrect numbering when cells are merged in the table
Summary: Writer: Incorrect numbering when cells are merged in the table
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: highest major
Assignee: Justin L
URL:
Whiteboard: target:5.4.0
Keywords:
: 99820 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-24 02:48 UTC by bfoman (inactive)
Modified: 2022-12-26 08:13 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Numbering is incorrect when merged cells in a table (17.00 KB, application/msword)
2012-04-24 02:48 UTC, bfoman (inactive)
Details
Autonumbering issue and regression LO 3.5.5.3, 3.6.0.4, Word 2010 (13.06 KB, image/png)
2012-08-21 11:20 UTC, bfoman (inactive)
Details
it is also incorrect after merge cells (7.76 KB, image/png)
2016-04-06 01:38 UTC, aqcoder
Details
numberedMergedCells.odt: create your own merged cells - none merged yet. (12.05 KB, application/vnd.oasis.opendocument.text)
2016-12-30 14:43 UTC, Justin L
Details
numberedMergedCells.odt: a more comprehensive testing environment. (13.22 KB, application/vnd.oasis.opendocument.text)
2016-12-31 04:41 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bfoman (inactive) 2012-04-24 02:48:00 UTC
Created attachment 60516 [details]
Numbering is incorrect when merged cells in a table

LibreOffice 3.5.2 and 3.5.3rc1.

Numbering in a table with merged cells is not correct. Instead 1, 2, 3... we have 1, 3, 5 in case, when there are two rows near merged cells. Numbering depends of number of rows involved (more rows=bigger number). 
Also LO changes the proper numbering soon after opening the file in Word format. For example I attached doc file with correct numbering and it is changed to incorrect by LO. Interestingly after saving it back and opening in Word the numbering is correct.

Steps to reproduce:
1. Create table.
2. Merge two cells in first column.
3. Repeat few times.
4. Paste numbering in first column.
5. Autonumber depends of rows count near merged cells.

Expected result:
Numbering should not depend on rows count near merged cells.
Comment 1 bfoman (inactive) 2012-08-21 11:20:57 UTC
Created attachment 65878 [details]
Autonumbering issue and regression LO 3.5.5.3, 3.6.0.4, Word 2010

Confirmed with:
LO 3.5.5.3 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

This is still an issue. Autonumbering in example file: 1, 4, 7, 11 instead of 1, 2, 3, 4.

Confirmed with:
LO 3.6.0.4 
Build ID: 932b512
Windows 7 Professional SP1 64 bit

In this version there is a major regression - merged cells are unmerged - autonumbering is 1, 2, 4, 5, 7, 8, 10, 11. Cells 3, 6, 9 are without left and bottom borders. First column layout is destroyed. See attached comparison screenshot.
Comment 2 bfoman (inactive) 2012-08-21 11:42:09 UTC
Confirmed with:
LO 3.7.0.0.alpha0+
Build ID: a8647dd
Windows 7 Professional SP1 64 bit 

Looks the same as in LO 3.6.0.4.
Comment 3 bfoman (inactive) 2012-08-21 11:48:08 UTC
On behalf of ~100 potential users of 3.6.x (and current users of 3.5.x) I am nominating this bug as 3.6 MAB - major regression in merged cells layout was discovered (apart from fixing autonumbering when cells are merged).
Comment 4 Roman Eisele 2012-08-21 13:33:54 UTC
Added "regression" keyword" according to comment #1 and screenshot (attachment 65878 [details]).
Comment 5 Roman Eisele 2012-08-21 16:44:13 UTC
I can CONFIRM [REPRODUCIBLE] at least the regression part of this bug (see comment #1):

When I open the sample .doc file with LibreOffice 3.5.6.2 (Build-ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0), the cells are merged correctly, but when I open the same document with LibreOffice 3.6.1.1 (Build ID: 4db6344), the cells are merged only in part and even look corrupted -- just like on bfoman’s screenshot (attachment 65878 [details]).

Test were done on MacOS X 10.6.8 (Intel).
Comment 6 Roman Eisele 2012-08-21 16:55:56 UTC
I think I can CONFIRM also the first part of this bug ("Incorrect numbering when cells are merged in the table"), both with LibreOffice 3.5.6.2 and 3.6.1.1 on MacOS X 10.6.8: the numbering appears to be a valid enumeration (I can even change the format from 1. 2. 3. to (a) (b) (c) etc.), but

* in LibreOffice 3.5.x, the numbering jumps immediately from 1. to 4. to 7. etc.;
* in LibreOffice 3.6.x, the additonal re-appearing cells (which should be merged)
  contain additional numbering of 1. 2. 3. ...,

just like bfoman’s screenshot shows it.
Comment 7 Roman Eisele 2012-08-21 17:01:20 UTC
@ our Writer experts:
Hello Cédric, Michael, and Miklos,

this is an important bug report for Writer. The form of the report is a bit unlucky (IMHO there are two bugs involved in this issue; if you want I can split the bug into two distinct reports), but it is nevertheless really important. Especially the second part of the bug (see comment #1, comment #5), which is about a nasty regression in LibreOffice 3.6.x, is well worth to get fixed soon ...

So please take a look at this report. Tell me if I (as a simple bugwrangler) can do anything to help you with this issue.

Thank you very much in advance!
Comment 8 bfoman (inactive) 2013-05-08 12:09:35 UTC
Confirmed with:
LO 4.0.2.2
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Regression is gone, but this is still an issue. Autonumbering in example file: 1, 4, 7, 11 instead of 1, 2, 3, 4.
Comment 9 tommy27 2013-08-05 14:23:44 UTC
@bfoman

Hi, I'd like to review this bug on 4.0.4, 4.1.0 and 4.2alpha.
would you please tell me where's the command to execute autonumbering?
Comment 10 bfoman (inactive) 2013-08-05 15:02:08 UTC
(In reply to comment #9)
> @bfoman
> Hi, I'd like to review this bug on 4.0.4, 4.1.0 and 4.2alpha.
> would you please tell me where's the command to execute autonumbering?

Just use Numbering On/Off button (F12).
BTW: nothing has changed since comment 8, it is still an issue in:
Version: 4.2.0.0.alpha0+
Build ID: 087a610fcd5c0c354a9ed6bfccd3451b667d62a3
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_21:41:24
Comment 11 tommy27 2013-08-05 18:06:48 UTC Comment hidden (obsolete)
Comment 12 Joel Madero 2013-10-29 02:53:48 UTC Comment hidden (no-value)
Comment 13 Björn Michaelsen 2014-01-17 09:58:26 UTC Comment hidden (obsolete)
Comment 14 Stéphane Guillou (stragu) 2014-02-12 08:12:28 UTC Comment hidden (obsolete)
Comment 15 Mike Kaganski 2014-02-23 00:52:19 UTC
Well, the "regression" part has already been fixed somewhere, as noted in comment 8. And anyway, that part didn't fit into the original bug description, and had been added later (comment 1). Let's concentrate this bug on the numbering issue, as per comment 0.

Numbering issue is already reproducible with OOo 3.3.0, still reproducible with LO 4.2.1.1, and also in AOO 4.0.1. Thus, I clear the "regression" keyword, and set the version appropriately.
Comment 16 tommy27 2014-05-02 06:57:06 UTC
issue still persist in 4.2.x branch 
moving to the mab4.2 list since 4.1.x is EOL
Comment 17 tommy27 2014-11-26 06:28:15 UTC
looks like autonumbering is even worse in 4.3.x
just tried to replicate the bug and anytime I applicate autonumbering I always get 1, 1, 1, 1 regardless the cells are united or single.

can you confirm this?
Comment 18 Mike Kaganski 2014-11-26 11:37:07 UTC
(In reply to tommy27 from comment #17)
> looks like autonumbering is even worse in 4.3.x
> always get 1, 1, 1, 1 regardless the cells are united or single.

Confirm. But I think this should be filed as another regression report.
Comment 19 tommy27 2014-11-29 17:34:15 UTC
@Mike
considering that the current bug is even worst than the original and that 4.2.x is already an end of life release, I will not separate the two in different reports

Im moving this to mab4.3 list as well
Comment 20 Robinson Tryon (qubit) 2015-12-14 05:40:05 UTC Comment hidden (no-value, obsolete)
Comment 21 Joel Madero 2016-03-18 15:21:24 UTC
Is this bug actually being looked at by someone? We have someone assigned and in QA Contact (why in QA contact....we don't use that field at all).
Comment 22 zinph 2016-03-18 15:23:46 UTC
Lakshiya and I are working on this bug together. Do you know where we can locate the files associated with numbering inside the table? Thanks!
Comment 23 Joel Madero 2016-03-18 15:40:40 UTC
Ah that makes more sense. I don't sorry. Best bet is to ask in the #libreoffice-dev IRC channel and email the dev mailing list to ask.
Comment 24 aqcoder 2016-04-06 01:38:19 UTC
Created attachment 124113 [details]
it is also incorrect after merge cells

it is also incorrect after merge cells.

Version: 5.2.0.0.alpha0+
Build ID: 3cccd
on ubuntu 15.10 64-bit
Comment 25 m_a_riosv 2016-05-14 14:03:26 UTC
*** Bug 99820 has been marked as a duplicate of this bug. ***
Comment 26 Xisco Faulí 2016-09-14 14:46:16 UTC
Only regressions should use the keyword 'preBibisect'. Removing it...
Comment 27 Justin L 2016-12-29 14:46:54 UTC
Unassigning due to inactivity.
Confirmed still 1,4,7,11 (and then jumps to 1,3,6,10 if you toggle F12) in LO5.4alpha.
Comment 28 Justin L 2016-12-30 14:43:46 UTC
Created attachment 130032 [details]
numberedMergedCells.odt: create your own merged cells - none merged yet.

proposed fix for this bug: https://gerrit.libreoffice.org/32512

This gets interesting because it exposes another bug in Libreoffice - namely that what this bug is complaining about (the merged-out cells retaining their numbering) is exactly what you also see in the UI when you merge numbered cells.  Merging horizontal cells reduces the numbering as expected, but merging vertical cells leaves the numbering unaffected (until saving and reloading).

I conclude that this vertically merging UI behaviour is buggy because:
1.) the behaviour of merging horizontally or vertically ought to be the same.
2.) when the unchanged-numbers vertically-merged file is saved and reloaded, the numbers change - they don't match what was saved.
3.) MS Word's UI works similar to LO's horizontal behaviour for both directions.
Comment 29 Justin L 2016-12-30 19:25:54 UTC
Proposed fix for the UI component: https://gerrit.libreoffice.org/32518
Comment 30 Justin L 2016-12-31 04:41:45 UTC
Created attachment 130047 [details]
numberedMergedCells.odt: a more comprehensive testing environment.
Comment 31 Commit Notification 2017-01-03 08:20:32 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=53fd124d2488977af8536f439874a15de375dc40

tdf#49102 - UI: remove list numbering from merged cells

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 32 Justin L 2017-01-03 08:35:36 UTC
This bug is fairly obscure, so I'm not planning to backport it.  The MAB status came from other regressions noted in various comments, not from the actual bug reported/fixed here.

Therefore, the first fixed version will be in 5.4 (released around Aug 2017) unless a backport to 5.3 (released Feb 2017) is requested soon.
Comment 33 Commit Notification 2017-01-05 09:55:32 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4b12246a6c2285a9d4fe20e665028b6f8a68b018

tdf#49102 - remove list numbering from merged cells

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 34 SATYA SRINIVAS K 2022-08-16 07:21:16 UTC Comment hidden (no-value)