Created attachment 136159 [details]
Sample ODT, save as DOCX
Open the attached ODT, containing an inserted image, and text above and below.
Save it as DOCX.
Reopen the DOCX.
=> The bottom text is repositioned next to the image.
Observed using LO 220.127.116.11 & 18.104.22.168 / Windows 7.
Not reproduced using LO 22.214.171.124.
Bibisected to the following range, but the results seem wrong:
Arch Linux 64-bit, KDE Plasma 5
Build ID: 09122a537318f7ada075820f3b1ef83a64e56751
CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on September 10th 2017
Created attachment 137576 [details]
text-image_8f8b31abd02876c3601e343b8b3274754f8a61b6.pdf: what completely broken means
First broken completely in 4.2 by commit 8f8b31abd02876c3601e343b8b3274754f8a61b6 Author: Luboš Luňák CommitDate: Tue Aug 6 17:17:53 2013 +0200
compatibility setting for MS Word wrapping text in less space (bnc#822908)
Created attachment 137579 [details]
text-image_word2003.pdf: how it looks in MS Office 2003
I'd probably flag this as notabug. The document is DESIGNED to have the text flow optimally, which implies that if there is room, the text should go beside. Microsoft Office wraps the text around too - thus it makes sense that LO should do the same. If there is any bug here, it is the difference in how the wrapping is taking place. This should be checked with Word 2013 as well, for recent confirmation (and also see how Word handles the original .odt).
Created attachment 137680 [details]
Original ODT saved as PDF from MSO 2013
Created attachment 137681 [details]
DOCX from LibreOffice saved as PDF from MSO2013
Removing keyword bibisectRequest as is was already bibisected.
Adding keyword bisected as the first bad commit seems been identified.
Dear Aron Budea,
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!
This image is horizontally positioned as "Center" to "Paragraph area" and with optimal wrap.
This is similar to the example file in bug #124059 - the image of the shopping cart has the same settings.
Now to reproduce the original layout in docx you need to set it as No wrap (Writer) / Below&above (in Word).
Setting "No Wrap" does not change the layout in Writer, but retains it after saving to docx when it is then reopened in Word (tested with my 2013) and Writer.
Created attachment 168231 [details]
The example file after manually changing the wrapping to None
Created attachment 168232 [details]
The changed example file saved to DOCX with current Writer
Version: 126.96.36.199.alpha0+ (x64)
Build ID: 59301a1cadd87a63276650975252d14e8477e632
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Created attachment 168233 [details]
The modified docx side by side in Word and Writer
Just checked the images in bug #117611 - those are also centered to paragraph, with optimal wrap.
Setting no wrap in docx restores the intended layout for those too.
There is however a bit more spacing between the image and the text in that mode, as seen on the previous attachment #168233 [details] .
That causes some layout difference with the example in bug #124059, making paragraphs at the bottom of the first page wrap to the next page.
Playing a bit with resizing the image horizontally, it seems that in odt there is no wrap if the horizontal space between the image and the page margin is less than 2 cm, but in docx this magic value is 1 cm.
Word on the other hand measures whether the space between the image and the page margin is enough to fit the actual text - so in the same space the wrap will happen (or not) differently for text like "x x x x x x x x" and "xxxx xxxx" and "xxxxxxxx xxxxxxxx".
It's way worse than just switching up wrap options on export :(.
Created attachment 173534 [details]
The example file and its docx version in Writer showing their 2/1 cm limits
odt does not wrap below 2 cm spacing, docx does not wrap below 1 cm - but it does between 1 and 2.
Created attachment 173535 [details]
Example from Word showing that it does measure text length before wrapping
Created attachment 173536 [details]
The Word example file
For the first image there is about 1 cm on the left, but xxxxx does not fit, so no wrap.
For the second image there is the same 1 cm on the left but words around it are shorter "xx" so they fit and wrap the image.
For the third image there is 2 cm space to the margin but the words around it are even longer than that so there is no wrap.
*** Bug 144197 has been marked as a duplicate of this bug. ***
*** Bug 135155 has been marked as a duplicate of this bug. ***
*** Bug 139260 has been marked as a duplicate of this bug. ***