Steps to reproduce: 1. Open attachment 80056 [details] from bug 65187 2. Save it as DOC 3. Open the new file -> Observed behaviour: 2 page is almost empty, having a page break before the bullets list Reproduced in Version: 6.1.0.0.alpha1+ Build ID: 1e2afc9bd3062cfba6b65b45c17a08f298014239 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group [Bug found by office-interoperability-tools]
Regression introduced by: author Miklos Vajna <vmiklos@collabora.co.uk> 2018-02-19 22:37:58 +0100 committer Miklos Vajna <vmiklos@collabora.co.uk> 2018-02-20 08:11:57 +0100 commit a16275a3647a2fba9913ed23e8329e45b02123b4 (patch) tree fd02655cd83c0bf92e0c255031b6c4b456236208 parent 19a906f09688f06ee90cac2a50126aeba749a331 (diff) tdf#112694 DOCX import: handle <w:titlePg> when turning on follow style header Bisected with: bibisect-linux64-6.1 Adding Cc: to Miklos Vajna
I don't reproduce it when I export it to DOCX
Same behaviour reproduced also with attachment 89461 [details] from bug 71784
Hi, I can't reproduce the problem with the first document. I can reproduce a problem with the second one, but that seems to be a DOC export problem (Word says the table is corrupted in the export result). It's rare that a DOCX import change affects the result of DOC export + DOC open. Could you please confirm that git bisect points out the above commit also for the second problem? Thanks!
Created attachment 141980 [details] output file after RT
According the b(In reply to Miklos Vajna from comment #4) > Hi, > > I can't reproduce the problem with the first document. I can reproduce a > problem with the second one, but that seems to be a DOC export problem (Word > says the table is corrupted in the export result). It's rare that a DOCX > import change affects the result of DOC export + DOC open. > > Could you please confirm that git bisect points out the above commit also > for the second problem? > > Thanks! Yep, I do confirm the commit mentioned above makes the document to have a page break on the second page, which is the same problem as in the second document. I've attached the output document generated
OK, thanks. I'll need to investigate that later, it's pretty strange. :-)
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b7ae863efeb082816cc4fe660527a9650d90e186 tdf#117503 DOCX import: fix out of sync first/later top margin It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=02a924831933d964cda209897bab27c48803c891&h=libreoffice-6-1 tdf#117503 DOCX import: fix out of sync first/later top margin It will be available in 6.1.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 6.1.0.0.beta1+ Build ID: 2a0d8106a558845357d39648656e08ec6f091cf8 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded @Miklos, Thanks for fixing this!!
*** Bug 128765 has been marked as a duplicate of this bug. ***