Created attachment 126000 [details] Textdocument m
Created attachment 126001 [details] test4.odt example text document with a frame on the right side of the first page with border='none'
Created attachment 126002 [details] how test4.odt is displayed in LibreOffice (5.0)
Created attachment 126003 [details] how test4.odt is imported and displayed in MS Word 2013
This bug seems to be related to tdf:53992, but is not exactly the same, since here it is about an formatting / interoperability issue regarding text frames in LibreOffice and MS Word and the handling of (the graphic-style) fo:wrap-option. How to reproduce the issue: - there's a document test4.odt that was created with LibreOffice and stored to ODF - open the attached document test4.odt in LibreOffice (find attached how test4.odt should be displayed in LibreOffice) - open the attached document test4.odt in MS Word 2013 (find attached how test4.odt is currently displayed in MS Word) You can see, that Word is not able to display the document correctly. The frame on the right side of the first page is much too large and the text wrapping is wrong. This is how the document was created: - opened a new writer document - insert->frame - options set on the frame: - unset option for automatic height - kept text wrapping "quadratic" - choose no border - moved the frame to the top right corner of the text area - resized it to be about 5cm wide and fill the height of the text area - add some text (bt<F3>) into the text area and into the frame to see how wrapping works - saved as ODF Analysis: For me it seems that LibreOffice and MS Office behave different regarding the graphic-style option fo:wrap-option. By introspecting styles.xml of test4, you can see, that LibreOffice sets fo:wrap-option='no-wrap' as default graphic format. The corresponding Textframe-style "fr1" is derived from the graphic style "Frame" and this style sets style:wrap='parallel' (and more wrapping relevant options). So if 'Frame's behaviour should enable text wrapping, why is fo:wrap-option not set to fo:wrap-option='wrap'? If I add fo:wrap-option='wrap' to the style-definition of 'Frame', the document IS displayed correctly in MS Word. So obviously both implementations behave different in when and how fo:wrap-option is interpreted. According the the ODF 1.2 spec, I cannot find any reason why LibreOffice should not write fo:wrap-option='wrap' whenever text wrapping should be active. So I have to argue that even if LibreOffice is able to display the document correct, It doesn't produce correct ODF according to the spec (regarding fo:wrap-option). This bug should be fixed in LibreOffice to improve interoperability with other ODF implementations.
already mentioned bug 53992 which describes a similar issue for Calc and suggests a similar solution
Could you please explain how the document was created? To me it seems like the problem is in MSO Word, not in LibreOffice. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information is provided
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 INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/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 MassPing-NeedInfo-Ping-20180302
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA 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 our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20180404
Created attachment 141121 [details] same test4-document with manually added fo:wrap-option='wrap' attribute that is displayed correct in MS-Office
This interoperability issue still occurs in combination with LibreOffice 6.0.2.1 and MSO (used Office 365 Web-view for the above ODT-Documents): test4.odt is displayed wrong in MS-Office, test4_added_fo_wrap_option_wrap.odt is displayed correct in MS-Office. The only difference between these two documents is, that in the second one I manually added fo:wrap-option='wrap' attribute near the place where style:wrap='parallel' is set. So to summarize the above request: To improve compatibility for ODT between LibreOffice and MSO, I suggest to automatically add fo:wrap-option='wrap' whenever style:wrap='parallel' is set. --- more details (just because you asked for) - I don't think they are required: a) Tested with LibreOffice 6.0.2.1 on a current ubuntu bionic snapshot. MSO is run as Office 365 in the Browser (in the previous try I used a MS-Office 20xx fat client). b) reproduce? open the mentioned documents in MSO c) see b). Sorry, there's nothing to add. d) already added - see above.
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
CCing Regina: Is this something LibreOffice should take care of or is it not our bug? Has ODF spec an idea about such interoperability issues?
It is not only a question of interoperability. It is a real bug in LibreOffice. LibreOffice does not write the attribute fo:wrap-option in general, but only if you set is explicitly. But such is not possible in Writer, neither for a Frame nor for a graphic Text-Box. It is only possible for a Custom-Shape. If a graphic property is not set at the style of the object, nor at any of its parent styles, then the settings in style:default-style of the same family (here graphic) has to be used. And there fo:wrap-option="no-wrap" is set. So Word shows the file exactly as it is written by LibreOffice. But LibreOffice wraps the text although it writes "no-wrap". The same problem is in Impress. There too the standard graphic style has no setting for fo:wrap-option and the element <style:default-style> has set fo:wrap-option="no-wrap". A solution is possible in several steps: 1. Write fo:wrap-option="wrap" in the default style, so that file format and actual behavior fit together. 2. Write this attribute for all "frame"-graphic styles in Writer, because they are treated different from graphic objects in LibreOffice. 3. Bring this attribute to UI in all graphic styles, not only in Custom-Shapes.
*** Bug 125127 has been marked as a duplicate of this bug. ***
Dear Christoph Lutz, 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 https://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
*** Bug 113926 has been marked as a duplicate of this bug. ***
The problem exist still in Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: e718f0e703c0fb33a0b1b5efe7b13b02c25f3335 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
Dear Christoph Lutz, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug