| Summary: | FILEOPEN Content of Table of Content not imported (.doc) | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Oliver Specht <o.specht> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | cno, pje335-lo, stephane.guillou, stx123, thomas.lendo, timur, xiscofauli |
| Priority: | medium | Keywords: | bibisected, bisected, filter:doc, regression |
| Version: | 4.0.4.2 release | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=31379 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 112862 | ||
| Attachments: |
sample document containing a TOC
ooxml version of the document Sample DOC Compare MSO OO LO4.4 LO5.4+ |
||
Hi Olivier ;) Thanks for the report. Indeed I see no TOC. And that is the same in LibreOffice 3.3.0. Do you have a version of the docx file to? And do you mean with the report, that initialy the docx was opend, then saved as .doc and that then the TOC was missing? Regards, Cor Created attachment 82663 [details]
ooxml version of the document
AFAIK the doc has been created by Word (2010 or 2013). The TOC is not imported since the following commit: commit d36940de4f88bc4f190dcddb79568ef0d08b8427 Author: Cédric Bosdonnat <cedricbosdo@openoffice.org> Date: Tue Oct 12 10:15:39 2010 +0200 WW8: Fixed the import of nested SET / FILLIN fields n#634478 This could be fixed with the following diff: diff --git a/sw/source/filter/ww8/ww8par5.cxx b/sw/source/filter/ww8/ww8par5.cxx index 1f4d9e8..63fe016 100644 --- a/sw/source/filter/ww8/ww8par5.cxx +++ b/sw/source/filter/ww8/ww8par5.cxx @@ -1007,9 +1007,11 @@ long SwWW8ImplReader::Read_Field(WW8PLCFManResult* pRes) bool bOk = pF->GetPara(pRes->nCp2OrIdx, aF); OSL_ENSURE(bOk, "WW8: Bad Field!\n"); if (aF.nId == 33) aF.bCodeNest=false; // do not recurse into nested page fields bool bCodeNest = aF.bCodeNest; - if ( aF.nId == 6 ) bCodeNest = false; // We can handle them and loose the inner data + if ( aF.nId == 6 || aF.nId == 13) + bCodeNest = false; // We can handle them and loose the inner data maFieldStack.push_back(WW8FieldEntry(*pPaM->GetPoint(), aF.nId)); ->Cédric: Could you please have a look? 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 Office 2007 Is this a regression then? If it is please add regresion to the keywords. Restricted my LibreOffice hacking area I can reproduce this with 4.1.5.1 (Build ID: e0a1805d063a472a7b281ae3977a26d42a48b20) using the two attachments provided. Could anyone test the diff provided in Comment 4? ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02 Test Version: 4.4.2.2 on Windows 10 Pro Technical Preview The bug occurs differently now: The text of the TOC is visible now but it is no TOC but simple text. ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920 With: LO 5.1.5.2 (Build ID: 1:5.1.5~rc2-0ubuntu1~trusty1) on KXStudio 14.04 Both sample documents now show the headings in the table of content. The behaviour is inconsistent though: the .doc has page numbers that are clickable with ctrl+click, whereas it is not possible to use that shortcut with the .docx. The issue(s) seem(s) different to the original bug report, should we close this one and open a new one? Created attachment 130788 [details] Sample DOC Compare MSO OO LO4.4 LO5.4+ This bug started as "Table of Content not imported (.doc)" and as noted, it was changed at least from LO 4.4. Same is now with 5.4+ master. So I'd say yes to Comment 11: close this one and possibly open a new for specific issues, if not already reported and worth reporting: - TOC in DOC has Contents style but it's simple text and not proper TOC - First heading in TOC is not properly imported - instead of "1. jupp" just "upp" is imported, "1. j" missing, which may be related to not proper TOC - DOCX page numbers not clickable with ctrl+click - until right-click "Update index" when they become clickable Proper bug report would not only report DOC and DOCX separately, but test to see if this is related to this specific document only. stragu and Timur, inconsistent or buggy behavior should be handled in new, separate bug reports. If the ToC is imported, this bug should be closed as WORKSFORME. But if there is a main bug which makes the import incomplete, this bug can be renamed to reflect the current problem. For the several bugs both of you found, please search for already reported ones in Bugzilla and comment there or make new bugs with a actual test file. (In reply to Thomas Lendo from comment #13) > stragu and Timur, inconsistent or buggy behavior should be handled in new, > separate bug reports. If the ToC is imported, this bug should be closed as > WORKSFORME. But if there is a main bug which makes the import incomplete, > this bug can be renamed to reflect the current problem. > > For the several bugs both of you found, please search for already reported > ones in Bugzilla and comment there or make new bugs with a actual test file. I agree, the ToC is imported in Version: 6.0.0.0.alpha0+ Build ID: 34e8fd7e99489e9f50a512b07c6f3923b358b4d3 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group Closing as RESOLVED WORKSFORME |
Created attachment 82585 [details] sample document containing a TOC Load bugdoc. On Page 1 there's only the heading of the table of contents but no entries. The same file in .docx is loaded correctly.