Created attachment 118134 [details]
Source document 'word inside word.docx'
This occurs in 126.96.36.199 (Windows 7), and appears to be a regression from LibreOffice 188.8.131.52 (Ubuntu 14.04).
The bug is that on page 2 the embedded office file is scaled incorrectly (only a single large line of text is shown at the bottom of the second page, when it should render multiple lines -- I'll attach PDFs showing this)
Created attachment 118135 [details]
Rendering in LibreOffice 184.108.40.206
The rendering that appears to be scaled incorrectly.
Created attachment 118136 [details]
Rendering in LibreOffice 220.127.116.11
The expected rendering, from LibreOffice 18.104.22.168
tested under Win8.1 x64
works fine in LibO 4.3.1 and bug starts in LibO 4.3.2
so the guilty commit is among these:
apart from the incorrect scaling there's also much slower loading of the file.
status NEW. version 22.214.171.124. regression. bibisectRequest.
I (bi)bisected this bug.
The two regressions (slow loading of the document and incorrect scaling) actually do start at the same commit.
cc44ace348bc71b8e0411f3c4a3dbcec4852c8a5 is the first bad commit
Author: Matthew Francis <email@example.com>
Date: Sun Mar 15 01:57:21 2015 +0800
Author: Miklos Vajna <firstname.lastname@example.org>
AuthorDate: Wed Aug 27 15:24:37 2014 +0200
Commit: Miklos Vajna <email@example.com>
CommitDate: Wed Aug 27 15:34:41 2014 +0200
DOCX import: fix handling of embedded DOCX files
The problem was that SwXTextEmbeddedObject::getEmbeddedObject() returned
an empty reference for those embedded objects, so the HTML filter
couldn't extract their content when it wanted to do so.
It turns out the reason for this was that the DOCX importer only handled
the replacement image + raw native data for the object. Fix this by
creating the embedded object with the correct CLSID and import the
raw data into the empty embedded document model.
This is similar to what is done for XLSX-in-PPTX in
oox::drawingml::ShapeExport::WriteOLE2Shape(), just for the import part.
:040000 040000 e8cb4e3b985c04b5016f70818a5e2706a479eac8 5e02d229804ec183756cea153845f8c59530ea74 M opt
$ git bisect log
# bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2
# good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
git bisect start 'latest' 'oldest'
# good: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4
git bisect good 8cf60cc706948588e2f33a6d98b7c55d454e362a
# bad: [7beddf3808dadd525d7e55c00a5a90a2b44c23d3] source-hash-2f10386ce577f52e139aa23d41bc787d8e0b4d59
git bisect bad 7beddf3808dadd525d7e55c00a5a90a2b44c23d3
# bad: [7d319609d8266af06aa3256fd3773d052b9150dc] source-hash-1fec67aab152e0c0ad6dd85082c50f1beff7d520
git bisect bad 7d319609d8266af06aa3256fd3773d052b9150dc
# bad: [ff24df9a7aadef7aaf721b131c9e06f19fa9239a] source-hash-653025e6f10d07d0a95f7b75d56ff457f1902e82
git bisect bad ff24df9a7aadef7aaf721b131c9e06f19fa9239a
# good: [9460f8d13abf06281723950db84607788db19966] source-hash-2a93ed09240c6e9871593641dabbb7502af87986
git bisect good 9460f8d13abf06281723950db84607788db19966
# bad: [f44a1fe93fe524dedbabd854b038fc047b1d38f4] source-hash-4e96f7ffdb5d7b84ea70888626523dcdc5dfe0ac
git bisect bad f44a1fe93fe524dedbabd854b038fc047b1d38f4
# bad: [62faa37985c66e2f50919f9392257d209d21520a] source-hash-7db1ac59128ecc175ec1fd943ee77d469dcb0ea1
git bisect bad 62faa37985c66e2f50919f9392257d209d21520a
# good: [bdcbaae61e7c235354288d519d1b594f07fcece0] source-hash-aebcabd54cc5587f3856c48db0a4c4fc0f3f8ce8
git bisect good bdcbaae61e7c235354288d519d1b594f07fcece0
# good: [8a57560ef0c2aea5599c42505850ffbf4cbcb97b] source-hash-2fb876d85ddbfea0e6b6a38f71135e3dbe4233bb
git bisect good 8a57560ef0c2aea5599c42505850ffbf4cbcb97b
# bad: [50a379bc8660b76fcefac17317f4c1602db662a6] source-hash-56c9850145faa9ac04c3f09633e56b6c8c22c6c4
git bisect bad 50a379bc8660b76fcefac17317f4c1602db662a6
# good: [031648eed9b726609afbdac0f32b9fd4b0abda71] source-hash-b77bf9759a74454391fa5d2f4a6ec4594d6d3e89
git bisect good 031648eed9b726609afbdac0f32b9fd4b0abda71
# good: [961df52bc82aa28f9afaeac1878343cc25c47d62] source-hash-be84c0e8752cff050fbf8056848fa47a56be6b03
git bisect good 961df52bc82aa28f9afaeac1878343cc25c47d62
# bad: [ee2d6fb217add1dfeb44a80bfa2071d93f310309] source-hash-804d60d2ee4c099f685a6e42438fa0de15ca29be
git bisect bad ee2d6fb217add1dfeb44a80bfa2071d93f310309
# bad: [cc44ace348bc71b8e0411f3c4a3dbcec4852c8a5] source-hash-41aa970b3120837ca9cadb12997a53ad322145a4
git bisect bad cc44ace348bc71b8e0411f3c4a3dbcec4852c8a5
# first bad commit: [cc44ace348bc71b8e0411f3c4a3dbcec4852c8a5] source-hash-41aa970b3120837ca9cadb12997a53ad322145a4
@Miklos: Could you possibly have a look at this?
Migrating Whiteboard tags to Keywords: (bibisected)
Adding Cc: to Miklos Vajna
I'm not sure this is a regression. The relevant option is Tools -> Options -> Load/Save -> Microsoft Office -> WinWord to Writer or reverse.
In case that's enabled (and that's the default), we load the embedded docx, and underlying SwViewShell::PrtOle2() call updates the preview of the document, that takes a lot of time. This is something to fix, but it was like this forever.
This is now more visible as the option is now respected in the DOCX import filter, but the root cause is not new at all.
I found another document that introduced a regression by the same commit: attachment 101597 [details].
** Please read this message in its entirety before responding **
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!
Build ID: 00m0(Build:2)
Thread CPU: 4; SO: Linux 4.14; Resa interfaccia: predefinito; VCL: gtk3;
Versione locale: it-IT (it_IT.UTF-8); Calc: group
Created attachment 139423 [details]
Document exported with LibO 126.96.36.199.0+
FWIW the above commit unconditionally enabled the actual load of embedded Word files, but then commit 4034d96aeee07f069a6fb9e0445436577a6065e3 (writerfilter: respect WinWordToWriter config setting, 2014-08-28) made this conditional. So based on that I'm leaving this bug open for the performance part, but I'm removing the regression flag, comment 8 explains this problem was there before the above commit already.
Scaling problem of this issue has been fixed, see Bug 99631.
*** Bug 106700 has been marked as a duplicate of this bug. ***