Created attachment 79569 [details]
ZIP file which contains the original docx file and screenshots from google drive, libreoffice 22.214.171.124 and Microsoft Office 2010
I have a docx file which contains two images in the top part of the document. These images contain drop shadows and/or borders which look great when viewed in Microsoft Office but look awful when viewed in LibreOffice 126.96.36.199.
Steps to reproduce:
1. open the docx file attached to this post.
2. compare to the attached screenshot on how it looks in Mircosoft Word 2010.
Dropshadow is very hard and black (contains right angles)
Nice soft shadow like the MS Word version and the nice border around the FITA logo in the top right of the document.
Operating System: Windows 7
This one is a bit tricky, what I think happened is that prior to 188.8.131.52 release drop shadows on images for docx just weren't supported. What I can confirm is that prior to version 4 it looks like images imported correctly just without the shadow - now they import incorrectly with the shadow. Either way it's wrong but what I did was bibisect to at least give an idea as to where the code is, IMO this is not a regression, just not the greatest filter for importing shadowed images from docx.
I have been able to confirm the issue on:
Platform: Bodhi Linux 2.2 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
As I've been able to confirm this problem on an earlier release I am changing the version number as version is the earliest version that we can confirm the bug, we use comments to say that the bug exists in newer versions as well.
Normal - can prevent high quality and/or professional work
High - broken enough with just regular shadowed images, seems like this could affect quite a few users.
Whiteboard Status - bibisect40 (just for code pointers as I don't think it's a regression)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/.
Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
5132488fc8156d7eec31097f0e8036dbb6612b10 is the first bad commit
Author: Bjoern Michaelsen <email@example.com>
Date: Mon Dec 10 15:28:32 2012 +0000
Author: Caolán McNamara <firstname.lastname@example.org>
AuthorDate: Sun Nov 20 21:49:04 2011 +0000
Commit: Caolán McNamara <email@example.com>
CommitDate: Fri Sep 28 08:48:04 2012 +0100
need to think about the toplevel dialog resize
:100644 100644 0863ab0e8be4a2ddafd9dddc93ab1fece1d3531d 66afa24b4b34cc1d198b4a9564ede557456555c3 M autogen.log
:100644 100644 b2f4fccbfb31eeecda38bcf1e8530f4bcfe6404d 592002353c9c447688ae5ed55b4ec616e85568a3 M ccache.log
:100644 100644 644c844c8c7f37845bcd509b30274fb3171f1b19 0b4eee5b69c2cc366273a7e684ebea96d6a49004 M commitmsg
:100644 100644 079818d37a3d997fb0b0444f800def75421c0006 1424b8601b3a84d22208d2ad9fa54bd6aa940713 M dev-install.log
:100644 100644 94f774aa4e04a6a7af6ef5a36b8bfdbd2a14b563 99903952fe667006084e3f44517e56af706a6fcf M make.log
:040000 040000 9d835c4339fa31db59424d45d5ac26a83cbdc83b 1b572f2dde3a8e76bcad94e0fba6e0632bfcab87 M opt
# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
# bad: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect bad 114fd3b76bcba890e6d702d00cef910f1493c262
# good: [6af64581913aa7ce3fcf0890fe671830d416a6ea] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f
git bisect good 6af64581913aa7ce3fcf0890fe671830d416a6ea
# bad: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f
git bisect bad 7e20e241c1d8819d8d5edb7894baeddde33f9d3a
# bad: [18ab426f67674e3ca169118f1f7a3527613374a4] source-hash-4df639baacd871cb2793e75dd9721ad2ae715e20
git bisect bad 18ab426f67674e3ca169118f1f7a3527613374a4
# good: [8004efc7f77e76e1dc66eeb0fa7f2b9b2cf9cc05] source-hash-9351d0e4181924c3f72be24081fc7af027aa41f7
git bisect good 8004efc7f77e76e1dc66eeb0fa7f2b9b2cf9cc05
# bad: [5132488fc8156d7eec31097f0e8036dbb6612b10] source-hash-fba5febdf60b37be69d2ffc66445d3e324826346
git bisect bad 5132488fc8156d7eec31097f0e8036dbb6612b10
Sorry wrong version on that comment that I left - I confirmed on version 184.108.40.206 release
(In reply to comment #2)
Thanks to Joel the bisect range is: http://cgit.freedesktop.org/libreoffice/core/log/?id=9351d0e4181924c3f72be24081fc7af027aa41f7&qt=range&q=9351d0e4181924c3f72be24081fc7af027aa41f7..fba5febdf60b37be69d2ffc66445d3e324826346
@Noel: These changes, in mentioned range, looks related to mentioned behavior:
Any chance to have a closer look?
Thanks in advance,
(In reply to comment #4)
> (In reply to comment #2)
> @Noel: These changes, in mentioned range, looks related to mentioned
> Any chance to have a closer look?
no, not really, I am only the committer, those patches are from Eilidh, I would guess she know this stuff best, unfortunately I don't know what ( if any ) freedesktop account she has
adding Eilidh as per Comment 5
Remove comma from whiteboard.
Bulk change: Bibisected bugs can be assumed to be regressions.
Confirmed on 4.3 built: Sun Mar 23 23:07:35 2014 +0100
Confirming that priority is correct - normal (can prevent high quality work) and high because of regression.
Created attachment 103678 [details]
how it looks in libreoffice 4.3.1
How it looks in Version: 220.127.116.11.0+
Build ID: 0d5d8c22f7be41d408d8ee4012ef1a6f4368423e
TinderBox: Win-x86@51-TDF, Branch:libreoffice-4-3, Time: 2014-07-23_05:34:04
replace bibisected40 by bibisected
(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".
Migrating Whiteboard tags to Keywords: (bibisected)
Still buggy in 5.2.
removing regression as per comment 1 and thus lowering importance to medium.
LibreOffice simply has never had the wealth of drop-shadow types that MSOffice 2007+ has. For example, the FITA symbol has a perspective shadow (it is not the black border line around the image, but that little coin shadow a centimetre below it). In addition, MSOffice considers the FITA image as a circle, while LO treats it as a rectangle.
So this is currently more of an enhancement request than a bug report (at least from the current perspective of LO5.4 [the cropping of the FITA image has been fixed, and the shadows are much softer]). Modified the subject accordingly.
Created attachment 129562 [details]
ABC TAXUS fita_LO53beta.pdf: It looks presentable at least in LO5.3beta
** 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!
(In reply to Justin L from comment #16)
> ABC TAXUS fita_LO53beta.pdf: It looks presentable at least in LO5.3beta
No change up to LO 6.3. It still looks presentable, but the border and shadow are still big squares.
Created attachment 163191 [details]
ABC Taxus file LO7.0.pdf: bibisect-linux-x64-7.0 commit de9c98af030cd9adcaac32fc4229af708e1386b9
In LO 7.0, The shadow is now about the right size, rotation, and distance, but in the wrong direction.
[Also the image is on the wrong side of the page (reported in bug 128877).]
The most recent chagne likely comes from
Author: Miklos Vajna <on Fri May 8 16:43:22 2020 +0200
Related: tdf#129916 svx: improve shadow size of custom shapes
Earlier in 7.0, the shadow was lost with
Author: Gülşah Köse on Tue Apr 14 15:49:28 2020 +0300
tdf#130058 Import shadow size.
In LO 6.3, the image/shadow changed from a square into a circle and at the same time it also moved from the right side to the left side with commit f4ba484183a1e7b9824f10580d633466c266828f
Author: Tamas Bunth on Mon May 13 01:02:07 2019 +0200
ooxml import: supprt cropping to shape
Created attachment 174050 [details]
The example file in current master
Looks somewhat better in:
Version: 18.104.22.168.alpha0+ (x64) / LibreOffice Community
Build ID: 7c38362dbe1922c9825dffb463072030948d406b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: en-US (hu_HU); UI: en-US
as long as the shape filled with the FITA image is on the right side again.
The Distance, Transparency and Color look correct.
The shadow is still imported incorrectly, starts on the top left instead of below.
The UI shows 17 pt blur instead of 30 pt.
Also there are no controls for Angle (90° in Word) and size (1% in Word, but that can't be right, since growing that value makes the shadow barely visible...) - so I can't see what does Writer think about those values.