Bug 147646 - Fileopen DOCX: Values are skipped in a numbered list within a table when cells are split/merged
Summary: Fileopen DOCX: Values are skipped in a numbered list within a table when cell...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: SATYA SRINIVAS K
URL:
Whiteboard: target:7.5.0
Keywords:
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2022-02-24 21:40 UTC by viewer
Modified: 2022-12-26 08:12 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document that fails to view correctly (as seen in Word) (16.50 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-02-24 21:41 UTC, viewer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description viewer 2022-02-24 21:40:02 UTC
Description:
When a Word (docx) document has a table which contains a numbered list (one value per table row), the values can be skipped when the document is opened with LibreOffice if additional formatting was used in the table such as Merge Cells and Split Cells.
To reproduce the issue, cells in the column next to the number must be split into multiple rows; or multiple cells which contain values of the numbered list must be merged into a single cell. Word displays the numbered list correctly under these conditions, but LibreOffice will skip those values as if they are hidden.
In addition to apparently missing/skipping number values, the numbered list displayed in LibreOffice makes it appear as if there were more steps which are not displayed. In the example, the original list ended at 16 but as displayed in LibreOffice it ends at 24.
This problem can also be reproduced natively within LibreOffice when creating a similar document but steps are provided based on MS Word as this is what the customer is using to create the original files.

Steps to Reproduce:
1.View the sample Word document provided. 
Alternately
In MS Word, create a 3 column table.
Select the entire first column and click Numbered List from the Home tab.
Add additional rows to the table as needed.
To reproduce the merged cell result:
Select 2 or more cells in the first column where the numbered list values exist.
On the Layout tab of the ribbon, click Merge cells.
MS Word will adjust the numbered list to make the values consistent.
To reproduce the split cell result:
Pick one of the other cells from the middle column (do not select the same rows used as the merge example).
On the Layout tab of the ribbon, click Split Cells and select to create 2+ additional rows.
Save the Word document as docx.
Open the document in LibreOffice Writer and check the display of the numbered list within the table.

Actual Results:
Some values are skipped in the numbered list (Skipped 4,5, 17, 18, 21, 22)

Expected Results:
The numbered list is reproduced in the same way Word displays it.


Reproducible: Always


User Profile Reset: No



Additional Info:
Also reproducible with LibreOffice 7.2
Comment 1 viewer 2022-02-24 21:41:03 UTC
Created attachment 178525 [details]
Sample document that fails to view correctly (as seen in Word)
Comment 2 Timur 2022-03-02 14:33:37 UTC
Bug is reported as fileopen DOCX and I'll confirm like that. OO and 7.4+.
Comment 3 Gabor Kelemen (allotropia) 2022-08-09 10:27:55 UTC
Same issue with doc format was fixed in bug 49102
Comment 4 Mike Kaganski 2022-08-16 06:32:02 UTC
Not a real code pointer, just some direction: the relevant code could likely be in writerfilter/source/dmapper/DomainMapperTableHandler.cxx or writerfilter/source/dmapper/DomainMapperTableManager.cxx.
Comment 5 Mike Kaganski 2022-08-16 06:50:34 UTC
The two codes (ww8 and OOXML import) would indeed do something different with internal structures - but my first idea would be, that in the end, they would call the same code to format the Writer document model (not necessarily, but that would be the first thing I would check)
So I'd try to debug the ww8 code until I see the actual call merging the cells in the document model, and then tried to put a breakpoint there, and then check if it gets hit when loading merged cells from DOCX.
If successful, you would need to check where the merge cell data comes from, and if it's possible to insert a similar logic like in https://gerrit.libreoffice.org/c/core/+/32512 in some place in the merged cells data flow - so that the paragraphs of those hidden cells don't contain the numbering info.
Comment 6 SATYA SRINIVAS K 2022-08-16 11:36:53 UTC
Mike Kaganski,Thanks for the inputs,I will try to figure out.
Comment 7 Commit Notification 2022-09-06 22:33:40 UTC
Satya committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/88338b6bf1fdf9420d9ae9d1c78dc8b897f0ad7d

tdf#147646 Auto numbering is wrong when the row has split/merged cells.

It will be available in 7.5.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 8 Commit Notification 2022-09-14 00:50:16 UTC
Satya committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7e8ba44fed9a20b5d226b9d3733b79a35acbbe00

tdf#147646 Add unit test

It will be available in 7.5.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 9 Timur 2022-09-30 13:57:51 UTC
This looks fixed to me for fileopen and for save. Satya, thanks.
Comment 10 Timur 2022-09-30 14:02:04 UTC
MSO saved DOC also opens fine.