Problem description: LibreOffice's Table of Contents style is not protected by saving as *.doc and *.docx file formats. Steps to reproduce: 1. Create a new document including a table of content(or convert an odf) and save it as doc or docx 2. Open it with Microsoft Office 2007 or 2010 Current behavior: ToC style is not protected and Microsoft Office impelents it own style, which looks crappy and shifts the document layout. I am attaching 3 files: odt(master) and doc and docx files created from it. And also attaching 3 screenshots showing how different it looks from LibreOffice to Microsoft Office **Also doc and docx seems to read the toc different, as doc has intends from left on number side This is a very important problem of compatibility because, this mixes all the layout, 1 page toc consist 2 pages and think that it is a 200 paged thesis or a business report and you want to print. I don't think nobody wants to face such situation. You have to re arrange all page layouts separately. Yes using PDF's is a solution but it is a matter of compatibility Expected behavior: Protecting the (default)Table of content style while saving as doc or docx Best regards, Zeki Operating System: All Version: 4.0.3.3 release
Created attachment 79914 [details] Toc saved in doc format
Created attachment 79915 [details] Toc saved in docx format
Created attachment 79917 [details] Toc saved in odf format
Created attachment 79918 [details] ODT file
Created attachment 79919 [details] Saved as doc
Created attachment 79920 [details] Saved as docx
Zeki: So far, I can obtain the same result as you show using your file, and Times New Roman as typeface with LibO 4.0.3, but not with LibO 3.5, so it's a regression. But it seems to be a weirder bug, because I imported a DOC file created with LibO 4.0.3 into Calligra Words 2.6.1, and the styles are there (nevertheless, there are some other issues in this case) What I see here, in my case, is that Word 2007 is not changing the style, but adding a newline after the number of the page (I mean, like locating the cursor after any pagenumber of the table of content and then pressing the Enter key). Don't know why, but it is doing it. If I open your DOC file with Word 2007 I see the same result you already shown in the 5th attachment. But if I open the same file with LibO 3.5.7 or 4.0.3, the "newline" isn't there. Interestingly, if one updates the table (right click->Update field) the table is shown as in LibO Moreover, the one thing I see LibO is doing wrong, even with version 3.5, is that it's changing the style "Content 2" and Content 3", etc., adding some kind of indent after the line, that isn't shown in the paragraph information. I mean, indentation after text is "0", but this indent is there! But this becomes even weirder, when I tried to check the styles used in Word 2007. Fast styles are shown properly on the Ribbon, but when the styles panel is opened, nothing is shown there. Creating a new file and pasting all the content of the file created with LibO shows in this case all the styles used in the panel. And the style shown for the table of contents seems to be the same I see in LibO. I suggest you to do some other tests, if you'd mind.
(In reply to comment #7) > Zeki: >Hi, > Moreover, the one thing I see LibO is doing wrong, even with version 3.5, is > that it's changing the style "Content 2" and Content 3", etc., adding some > kind of indent after the line, that isn't shown in the paragraph > information. I mean, indentation after text is "0", but this indent is there! There are bug reports related to them and other issues about toc: https://bugs.freedesktop.org/buglist.cgi?list_id=311242&short_desc=table%20of%20contents&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&short_desc_type=allwordssubstr&product=LibreOffice > I suggest you to do some other tests, if you'd mind. I think the problem is quite clear, i don't see any further test is needed to confirm this bug and mark as NEW also i do not have the knowledge to spot the issues on doc and docx filter. Regards, Zeki
> I think the problem is quite clear, i don't see any further test is needed > to confirm this bug and mark as NEW Your bug report states that TOC's is not proteced while saving a document as DOC and DOCX, and that MS Word implements its own styles. I have told you that that's not what I've found: I have done some tests with those files, and although I did found issues, they *doesn't* correspond with you have reported. Yes, I'm just asking you, please, confirm, reject, complete or correct what I have found, which I try to describe the best I could. > also i do not have the knowledge to spot the issues on doc and docx filter. Neither do I.
(In reply to comment #9) > I have told you that that's not what I've found: I have done some tests with > those files, and although I did found issues, they *doesn't* correspond with > you have reported. I think line spacing(adding newlines) and intends are components of "styles". > Yes, I'm just asking you, please, confirm, reject, complete or correct what > I have found, which I try to describe the best I could. Yes i can confirm your findings. But i can see them as style problems(whether not saved properly or not be read properly)the TOC. Regards, Zeki
Dear Bug Submitter, Please read the entire message before proceeding. This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
The bug is present, but the title itself does not describe what's happening. As in comment 7, styles are not changes, but an extra line is inserted and *no*, that's not a problem in style because Line Spaces *is not* affected. I really suggest to change the title, or at least, delete the word "styles" as they aren't affected
As far as I can see, this bug seems t be a dup of Bug 66165, which has been solved for LibO 4.2, supposedly. Zeki, could you check if it has been solved?
(In reply to comment #13) > As far as I can see, this bug seems t be a dup of Bug 66165, which has been > solved for LibO 4.2, supposedly. Zeki, could you check if it has been solved? Hi, Sorry, i still reproduce with 4.2. The style, and layout is not protected. I still got the results as attachements above. Best regards, Zeki
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO
f) I'm praying to god to make someone see this bug report to confirm as new.
I'm setting it as new, even though I think the description of the problem is wrong. The bug is present so at least I'll change the title to reflect the problem, which is *NOT* the style applied to the ToC.
Created attachment 135633 [details] screenshot of new testcase I can't replicate the problem in version 5.4.0.3 (7556cbc6811c9d992f4064ab9287069087d7f62c) on fedora xfce 64 bit. When exporting a document in *.doc file format looks the same as original *.odt and in the case of exporting to OOXML or Word 2007-2013 XML, only the page numbers are not well aligned, something that is best described in Bug 92786. For the test I used the original file presented here as other new ones created by me. The same screenshot results occur when opening documents exported by LibreOffice using MS Office 2013 - MS 2016 (Windows 10), WPS Office Writer 10.1.0.5707 (gnu/linux) and OnlyOffice desktop editors 4.4.1.338 (gnu/linux). I think it's better to close this ticket and contribute to other more delimited reports. Cheers
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 145521 [details] TOC Adsız 1 compared in LO: ODT and MSO: DOC DOCX I agree with the previous comment and I'll close as WFM.
Note: I may have not fully understood the description because it doesn't have expected and experienced details. But current test done from LO 6.2+ doesn't confirm the issue. I reported a few bugs for TCO, such as bug 118972.