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
Migrating Whiteboard tags to Keywords: (preBibisect) [NinjaEdit]
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).
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!
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.
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
*** Bug 99820 has been marked as a duplicate of this bug. ***
Only regressions should use the keyword 'preBibisect'. Removing it...
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.
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.
Proposed fix for the UI component: https://gerrit.libreoffice.org/32518
Created attachment 130047 [details] numberedMergedCells.odt: a more comprehensive testing environment.
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.
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.
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.
Hi Justin L, The same fix is not working for DOCX files, I think the code areas are different for DOC and DOCX files, Do you have any idea where should I look into, to identify the fix for DOCX files ? Reards, Satya