Created attachment 98020 [details] showing how the table looks in LibO 4.2 and 4.1 I download the .docx file found at < http://download.microsoft.com/documents/customerevidence/Files/710000003670/Xiamen_Tungsten_Group_unifies_enterprise.docx > and opened it with kingsoft writer and then saved it as an DOC. When i opened the DOC in LibO, on page 2, text is wrapping the left side of the table when it shouldnt. Regression starting in 4.2. Tested on 4.3 as well.
Created attachment 98021 [details] kingsoft writer produced .doc file
Reproducible, tested using Windows 8.1 with LibreOffice Version: 4.3.0.0.alpha1+ Build ID: f4a6837025a293312cbc43b9c527851362f11030 TinderBox: Win-x86@47-TDF, Branch:MASTER, Time: 2014-04-26_09:21:18 This wrapping is not present using Word 2013. Indeed regression. Not reproducible, tested using Windows 8.1 with LibreOffice Versie: 4.1.5.3 Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24 Kind regards, Joren
Made a mistake about it being a table, it is an image. :) The image should have wrap set to 'no wrap' but instead its set to 'optimal page wrap'.
2db25049517ac5b1567e9d42733fe65d3ba2fd80 is the first bad commit commit 2db25049517ac5b1567e9d42733fe65d3ba2fd80 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Thu Oct 17 22:20:58 2013 +0000 source-hash-89aeec9b1d2f771310eeb0fa4c820c19599df0f7 commit 89aeec9b1d2f771310eeb0fa4c820c19599df0f7 Author: Luboš Luňák <l.lunak@suse.cz> AuthorDate: Tue Aug 6 23:30:28 2013 +0200 Commit: Luboš Luňák <l.lunak@suse.cz> CommitDate: Tue Aug 6 23:30:28 2013 +0200 remove unused variable Change-Id: Iaf22f259fa396deee3cab84cc9549427b76017c2 :100644 100644 d35616cd13b3464614c4ea7f19de0b5fd896cb16 e45fdabf18736545b41132e1fda4f59911357d37 M autogen.log :100644 100644 52fc9f22d94afc40ef61e23c357dc7e0f9d2a4fd 0cb98ee181f4b9db5d136455ddb13f3829854d49 M ccache.log :100644 100644 42bee39af0bdddae12cc95ffbbbe4b87095f3023 9ccbd06f24d165ed9e4d00de1d4f723bc7f98dfc M commitmsg :100644 100644 86e4986c08d48d57776b2d2dc8e0bf2e3741ba39 fefef950e909e02916e93259c31b7fce1375bcdc M dev-install.log :100644 100644 6dfffb6da3ef540763fa3ed85ef2b4863a7db2fc 8ba4fd5c9afa0897119e72d09fce25468cdb7f20 M make.log :040000 040000 14a0727fd795a4c854d6e7d45f0b60ab59cd54c2 b4c0e400f66b81f53315ea13993a0017fd3176fc M opt # bad: [793dbf6f80f497dfe587d560d6257f42a24273f6] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [8092559c5013969ebda017d79200463b9b975038] source-hash-fd84daf696a368c2c7561b5253b32a63ecdeca4a git bisect good 8092559c5013969ebda017d79200463b9b975038 # good: [0270ef1b76a6de423b30f7927362cc01c1a0fc38] source-hash-b1f7dd66b898b03cb4bd8d434b6370310ea95946 git bisect good 0270ef1b76a6de423b30f7927362cc01c1a0fc38 # skip: [ddb123cad22440994cd332d9985dd9558fd07e07] source-hash-647fb29f528b891a1c92846640f7865f5c1fbe7f git bisect skip ddb123cad22440994cd332d9985dd9558fd07e07 # skip: [9d357dc6201f7cd91448595e0a3f89dfdae81946] source-hash-2304beaca33c63b94df99cb827716f00ce259f9a git bisect skip 9d357dc6201f7cd91448595e0a3f89dfdae81946 # good: [ef72aa34cf4ee6399b192de28708d621c9680a50] source-hash-7e07a45500dcbb891a85f0bc9b7049cf4d50bba1 git bisect good ef72aa34cf4ee6399b192de28708d621c9680a50 # bad: [2472598a0b04eef3038d56137f27dc6dc1edf9e5] source-hash-5050dfc73f194d1d59222cac72e69a917655d816 git bisect bad 2472598a0b04eef3038d56137f27dc6dc1edf9e5 # bad: [f7c906a1908211e1da263a58e40cc8a3b227fcd9] source-hash-d3ff876f3c7f441fd72a037ed31fb973f223ca6d git bisect bad f7c906a1908211e1da263a58e40cc8a3b227fcd9 # bad: [a2051f95d4e218b2cf99db275d9def985e40a082] source-hash-4450b1b93f7f7b5f97c631fe767b1156350a9227 git bisect bad a2051f95d4e218b2cf99db275d9def985e40a082 # bad: [1a9fd5fd81783fc13cf0b021e264215b81e9477a] source-hash-417d1c2b13cbd70300d2921b5667dfadc7e25895 git bisect bad 1a9fd5fd81783fc13cf0b021e264215b81e9477a # bad: [8adb68cd4f1764a2492a0d3ba21c760c3ed4a47f] source-hash-3cf0b5cdb05e1d77610431b1b1328102bf05b602 git bisect bad 8adb68cd4f1764a2492a0d3ba21c760c3ed4a47f # good: [3735bbcf0efcfc2e1bafed4b030f197646c06825] source-hash-a4c385f1aa98b5fb2d85136b653365fb6baa33f8 git bisect good 3735bbcf0efcfc2e1bafed4b030f197646c06825 # bad: [2db25049517ac5b1567e9d42733fe65d3ba2fd80] source-hash-89aeec9b1d2f771310eeb0fa4c820c19599df0f7 git bisect bad 2db25049517ac5b1567e9d42733fe65d3ba2fd80 # first bad commit: [2db25049517ac5b1567e9d42733fe65d3ba2fd80] source-hash-89aeec9b1d2f771310eeb0fa4c820c19599df0f7
Thanks Joel for bibisecting. This is the range: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=a4c385f1aa98b5fb2d85136b653365fb6baa33f8..89aeec9b1d2f771310eeb0fa4c820c19599df0f7 Looks like http://cgit.freedesktop.org/libreoffice/core/commit/?id=8f8b31abd02876c3601e343b8b3274754f8a61b6 (compatibility setting for MS Word wrapping text in less space (bnc#822908)) and http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b6cad89690a1188c6628c68d62108866b837779 are quite related. @Lubos: ping :-) ^ Kind regards, Joren
Yes, it's 8f8b31abd02876c3601e343b8b3274754f8a61b6 . Setting TEXT_MIN_SMALL in b/sw/source/core/text/txtfly.cxx to 1134 in practice reverts the commit, but that breaks the document from that bugreport, and there's no value that'd work for both. The fix is admitedly a bit of a hack, but until somebody has a better look at the issue, let's leave it this way. Clearly we want to be compatible with MSOffice if we have to choose, let alone that this bugreport looks like merely a made-up scenario rather than an actual problem.
Opening the original .docx or the converted .doc in word 2013 has the wrapping set to 'in line with text', which i see LibO doesnt have an option for. Is this why 'optimal page wrap' is being set to it?
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
This issue is still present in Version: 5.0.1.2 Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: es-ES (es_ES) on Windows 7 (64-bit)
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
adding filt:doc keyword.
This issue is still present in Version: 5.4.0.0.alpha0+ Build ID: 33f5bc54aaa7fe7aa9335726e30f9c349155e04d CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-12-01_23:21:05 Locale: nl-NL (nl_NL); Calc: CL
Still present. LO opens it as anchor 'As Paragraph' and wrap Optimal, while MSO and WPS opens wrapped as 'In Line with Text'. Version: 6.0.0.0.alpha0+ Build ID: 8d2a287da3abb0576512406227d0a3acd602123e CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group
Dear Yousuf Philips (jay) (retired), 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
Repro 7.0+ I round-tripped Xiamen_Tungsten_Group_unifies_enterprise [doc].doc with both Word 2003 and 2016. LO opened both of the round-tripped files with as-character anchoring - which is correct. So do we really care about this one?
(In reply to Justin L from comment #15) > I round-tripped Xiamen_Tungsten_Group_unifies_enterprise [doc].doc with both > Word 2003 and 2016. LO opened both of the round-tripped files with > as-character anchoring - which is correct. So, because I am confusing even myself... as-character anchoring by definition means no wrapping in this case since it is the only thing in the paragraph. This is defined as a character shape. (placeholder 0x01 instead of 0x08). I think that LO is just expecting something extra that is missing, but graphics import is rather confusing. GDB located ww8graf2.cxx::ImportGraf where these images are type (0x64 == aPic.MFP.mm), and imports using filter/source/msfilter/msdffimp.cxx, so I hardly want to start monkeying around in that area. This low-priority bug probably should only be handled by a professional. It seems like the default anchor type is paragraph, but in the 0x01 case, the default should be as_char.
Still reproducible in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 8043fe3e45c8999c8eaf475ba46d50b125e38b93 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
This still occurs in latest version 7.2.4.1, Windows 10/64 bit. All formatting for images reverts to Optimal when saving to .docx, no matter what is selected.
(In reply to Justin L from comment #16) > This is defined as a character shape. (placeholder 0x01 instead of 0x08). From SPRMS WW8.pdf: "1.3.5 Pictures Pictures in the Word Binary File format can be either inline or floating. An inline picture is represented by a character whose Unicode value is 0x0001 and has sprmCFSpec applied with a value of 1 and sprmCPicLocation applied to specify the location of the picture data. A floating picture is represented by an anchor character with a Unicode value of 0x0008 with sprmCFSpec applied with a value of 1. In addition, floating pictures are referenced by a PlcfSpa structure which contains additional data about the picture. A floating picture can appear anywhere on the same page as its anchor. The document author can choose to have the floating picture rearrange the text in various ways or to leave the text as is." Proposed fix at http://gerrit.libreoffice.org/c/core/+/138234
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ba8f6ca5b3f7710a27928add8e29c725d9f40901 tdf#77964 doc import: 0x1 placeholder is for AS_CHAR It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/1539a0fcd31f4ba7ef71adf4ae7761dc445199f5 tdf#77964 doc import: 0x1 placeholder is for AS_CHAR It will be available in 7.4.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/ef5a7ab81cdee4c1e861d49ea79b6924a01a8792 fix tdf#77964 patch: don't change DefaultFormat It will be available in 7.4.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eb8252f738bfd1689edee205c6a5e13643f89c29 fix tdf#77964 patch: don't change DefaultFormat It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 116375 has been marked as a duplicate of this bug. ***