Bug 69655 - FILEOPEN: DOCX import of Table-of-Contents renders the ToC's levels wrong
Summary: FILEOPEN: DOCX import of Table-of-Contents renders the ToC's levels wrong
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Vinaya Mandke
QA Contact:
URL:
Whiteboard: BSA Confirmed:4.2.0.1:OSX10.9 target:...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-21 17:08 UTC by Adam CloudOn
Modified: 2014-02-14 16:05 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
DOCX containing table-of-contents with 2 levels (34.23 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-09-21 17:08 UTC, Adam CloudOn
Details
Screenshot comparison between MS Word and LibreOffice (127.05 KB, image/png)
2013-09-21 17:13 UTC, Adam CloudOn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam CloudOn 2013-09-21 17:08:45 UTC
Created attachment 86275 [details]
DOCX containing table-of-contents with 2 levels

Problem description: 
When LO loads the attached DOCX with the ToC - it imports and renders the levels of the ToC wrong - instead of 2 levels, there is only one level in the ToC (see comparison screenshot).

Steps to reproduce:
1. Load the attached DOCX in LO
2. The ToC's levels are wrong

Current behavior:
LO imports and renders the Table-of-Contents with a single level

Expected behavior:
LO should import and render the Table-of-Contents with 2 levels like MS Word
              
Operating System: All
Version: 4.2.0.0.alpha0+ Master
Comment 1 Adam CloudOn 2013-09-21 17:10:17 UTC
This has to do with the '\o' field in the 'document.xml'.

TOC Field Flags:
http://office.microsoft.com/en-001/word-help/field-codes-toc-table-of-contents-field-HP005186201.aspx
Comment 2 Adam CloudOn 2013-09-21 17:13:15 UTC
Created attachment 86276 [details]
Screenshot comparison between MS Word and LibreOffice
Comment 3 Thomas van der Meulen 2013-09-29 07:00:31 UTC
Thank you for your bug report,
I can reproduce this bug running LibreOffice: 
Version: 4.2.0.0.alpha0+
Build ID: 164b6ce7b27c0a9ec19019e7b078b9f8f382007d
TinderBox: Win-x86@39, Branch:master, Time: 2013-09-28_16:39:4
And Mircosoft Word 2007

But aren't there any duplicate's of this bug?
Comment 4 Thomas van der Meulen 2013-09-29 07:05:35 UTC
*** Bug 69649 has been marked as a duplicate of this bug. ***
Comment 5 Adam CloudOn 2013-10-02 16:19:52 UTC
(In reply to comment #4)
> *** Bug 69649 has been marked as a duplicate of this bug. ***

Thomas. These are not duplicates.

Bug 69655 talks about the level of the Table-of-Contents, meaning - in the original file you have in the ToC - 'Heading 1', 'Heading 1.1' etc.. and in the exported file you only have the first level ('Heading 1', 'Heading 2', etc..)

Bug 69649 talks about the actual page numbers in the ToC that are being imported wrong.
In the original file the page number of the last entry is page #15, and in the file imported by LO - the page number of the last page is page #16.

So these are 2 different import bugs (that both relate to Table-of-Contents).
Comment 6 Jorendc 2014-01-03 12:33:32 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > *** Bug 69649 has been marked as a duplicate of this bug. ***
> These are not duplicates.

Correct :-). 

As Vinaya Mandke mentions in his comment on that bug, the commit applied to 69649 (http://cgit.freedesktop.org/libreoffice/core/commit/?id=9679e9c23216decb5f9f25f85b04cb3f25211111) also fixes this behaviour. :)

And I can confirm that, tested using Linux Mint 16 x64 with LibreOffice Version: 4.3.0.0.alpha0+ Build ID: 308fdfb1a9176f65c11d82b95e3aa73b87e2fe47

Kind regards,
Joren
Comment 7 Jorendc 2014-02-14 16:05:33 UTC
Marking as RESOLVED FIXED