Bug 49102 - Writer: Incorrect numbering when cells are merged in the table
Summary: Writer: Incorrect numbering when cells are merged in the table
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version: PreBibisect
Hardware: Other All
: highest major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: PreBibisect
Keywords:
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2012-04-24 02:48 UTC by bfoman
Modified: 2014-11-29 17:34 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Numbering is incorrect when merged cells in a table (17.00 KB, application/msword)
2012-04-24 02:48 UTC, bfoman
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
Details

Description bfoman 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 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 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 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 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 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
Ok. let's move it to the mab4.0 list.
Comment 12 Joel Madero 2013-10-29 02:53:48 UTC
PreBibisect so at least 3.5.0beta0, updating version and whiteboard status
Comment 13 Björn Michaelsen 2014-01-17 09:58:26 UTC
(This is an automated message.)

Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Comment 14 chtfn 2014-02-12 08:12:28 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.