Created attachment 161349 [details] Comparison MSO 2010 and LibreOffice 7.0 master Steps to reproduce: 1. Open attachment 112462 [details] from bug 88583 -> Frame is at the top. it should be at line 3. See comparison Reproduced in Version: 7.0.0.0.alpha1+ Build ID: 82894d85147840f1f587e9530b12f0058f2ef2c3 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded [Bug found by office-interoperability-tools]
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f5636817e7677a3081263df9004940a7d5ac54af author Tibor Nagy <nagy.tibor2@nisz.hu> 2020-05-06 11:15:35 +0200 committer László Németh <nemeth@numbertext.org> 2020-05-12 11:12:23 +0200 commit f5636817e7677a3081263df9004940a7d5ac54af (patch) tree 722b61349db662fa411a82c1b1eaee0e7b610cee parent 902e69d1a5473155915522d49f730720797a384f (diff) tdf#112287 DOCX frame import: fix default vAnchor Bisected with: bibisect-linux64-6.5 Adding Cc: to Tibor Nagy
I don't think this is a valid problem. The example file was saved by Writer from attachment #112460 [details] which is an odt. It contains gradient paragraph background for the third paragraph, but no frame, as it was made to demonstrate paragraph background export. When this file is saved to docx (even with current master) the third paragraph somehow is inserted into a frame, but the gradient paragraph background is lost - not a surprise because Word has no such feature (only solid color shading + character level highlight). Also Word does not seem to notice this frame whatsoever. I think the real problem is that we export the third paragraph inside a (broken) frame.
(In reply to NISZ LibreOffice Team from comment #2) > I think the real problem is that we export the third paragraph inside a > (broken) frame. I havee now bibisected this with bibisect-44max and it's strange: $ git bisect bad 698479bf692653dc6fe52e8105d60a80e995c615 is the first bad commit commit 698479bf692653dc6fe52e8105d60a80e995c615 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sun Mar 15 02:52:51 2015 +0800 source-hash-7fc08970894aea2b771bf7be409b72845c96d10a commit 7fc08970894aea2b771bf7be409b72845c96d10a Author: Matthew J. Francis <mjay.francis@gmail.com> AuthorDate: Thu Sep 18 18:33:00 2014 +0800 Commit: Tor Lillqvist <tml@collabora.com> CommitDate: Thu Sep 18 12:59:32 2014 +0000 fdo#69090 Avoid using a string after free Change-Id: I9020b595e434b4de8aa6a14c20d6c98fa619b96a Reviewed-on: https://gerrit.libreoffice.org/11502 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> :040000 040000 48e137e9baf8bb45e9580d5b8c21e903d56b2c4c 86513dfd67cb135311cd68d2566bf1a512a9ed6a Mopt This seems unrelated to DOCX export, yet the previous commit in the bibisect repo does not produce the extra frame: commit 5f57cff2582b6e5e3921c929197f7d006194386e Author: Matthew Francis <mjay.francis@gmail.com> Date: Sun Mar 15 02:52:48 2015 +0800 source-hash-a1740a682a6c46c57dc6a356299f6c9a92eb4af6 commit a1740a682a6c46c57dc6a356299f6c9a92eb4af6 Author: Noel Grandin <noel@peralex.com> AuthorDate: Thu Sep 18 14:44:39 2014 +0200 Commit: Noel Grandin <noel@peralex.com> CommitDate: Thu Sep 18 14:47:28 2014 +0200 use vcl::Font
Wrong bibisect: <w:framePr fillcolor="#FCE94F"/> is the offending part, which just started to have an effect on the editor/navigator in the bibisected commit, but it was already exported before that.
Another round of bibisect: https://cgit.freedesktop.org/libreoffice/core/commit/?id=9746dc9ad62e7f3a39961733f2ac204e90289034 the stray <w:framePr fillcolor="#FCE94F"/> started to be exported after this, although this one is about ODF so maybe this just exposed some deeper problem.
Tibor Nagy committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6c14c87cad6a3c38d7e597932ec591f4bc610be8 tdf#133457 DOCX import: fix frame position regression It will be available in 7.1.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.
Verified in Version: 7.1.0.0.alpha0+ Build ID: ff508f6d8a3e58d29e9e7622006a7103fb0a2849 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Tibor Nagy, thanks for fixing this issue!!
Tibor Nagy committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/067f7548f4e4cebcfcbc38457201d1c112ad80c3 tdf#133457 DOCX import: fix frame position regression It will be available in 7.0.0.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.