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.
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.
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.
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).
Added "regression" keyword" according to comment #1 and screenshot (attachment 65878 [details]).
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).
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.
@ 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!
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.
@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?
(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
Ok. let's move it to the mab4.0 list.
PreBibisect so at least 3.5.0beta0, updating version and whiteboard status
(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.
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
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.
issue still persist in 4.2.x branch moving to the mab4.2 list since 4.1.x is EOL
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?
(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.
@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.