Bug 64789 - enhancement requests: non-rectangular images, more shadow types (perspective)
Summary: enhancement requests: non-rectangular images, more shadow types (perspective)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
Whiteboard: BSA interoperability
Keywords: bibisected, bisected, filter:docx
Depends on:
Blocks: DOCX-Images
  Show dependency treegraph
Reported: 2013-05-20 12:06 UTC by Remco Meeder
Modified: 2023-05-05 23:37 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

ZIP file which contains the original docx file and screenshots from google drive, libreoffice and Microsoft Office 2010 (194.62 KB, application/zip)
2013-05-20 12:06 UTC, Remco Meeder
how it looks in libreoffice 4.3.1 (37.43 KB, image/jpeg)
2014-07-30 10:07 UTC, Xisco Faulí
ABC TAXUS fita_LO53beta.pdf: It looks presentable at least in LO5.3beta (139.60 KB, application/x-msdownload)
2016-12-13 07:21 UTC, Justin L
ABC Taxus file LO7.0.pdf: bibisect-linux-x64-7.0 commit de9c98af030cd9adcaac32fc4229af708e1386b9 (127.74 KB, application/pdf)
2020-07-17 15:09 UTC, Justin L
The example file in current master (250.10 KB, image/png)
2021-08-03 14:25 UTC, NISZ LibreOffice Team

Note You need to log in before you can comment on or make changes to this bug.
Description Remco Meeder 2013-05-20 12:06:25 UTC
Created attachment 79569 [details]
ZIP file which contains the original docx file and screenshots from google drive, libreoffice and Microsoft Office 2010

Problem description: 
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

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.

Current behavior:
Dropshadow is very hard and black (contains right angles)

Expected behavior:
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
Version: unspecified
Comment 1 Joel Madero 2013-05-20 16:25:23 UTC
This one is a bit tricky, what I think happened is that prior to 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.

Marking as:

New (confirmed)
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.

Keywords - 

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
Comment 2 Joel Madero 2013-05-20 16:26:31 UTC
 5132488fc8156d7eec31097f0e8036dbb6612b10 is the first bad commit
commit 5132488fc8156d7eec31097f0e8036dbb6612b10
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Mon Dec 10 15:28:32 2012 +0000

    commit fba5febdf60b37be69d2ffc66445d3e324826346
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Sun Nov 20 21:49:04 2011 +0000
    Commit:     Caolán McNamara <caolanm@redhat.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
Comment 3 Joel Madero 2013-05-20 16:27:02 UTC
Sorry wrong version on that comment that I left - I confirmed on version release
Comment 5 Noel Power 2013-05-30 12:00:37 UTC
(In reply to comment #4)
> (In reply to comment #2)

> @Noel: These changes, in mentioned range, looks related to mentioned
> behavior:
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=57633e42ffba2f495fd685233695acad6b9dde94
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=63a7550931c88ce06e4ab6f258121061c1f2dcf2
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=e1a509f4a362d21248b439c99e3b55f4fa9ba1bd
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=f0efecfb69b336e064e7c8dd2597655eff07944f
> 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
Comment 6 Björn Michaelsen 2013-07-18 16:33:52 UTC
adding Eilidh as per Comment 5
Comment 7 Robinson Tryon (qubit) 2013-10-19 00:11:56 UTC
Remove comma from whiteboard.
Comment 8 Björn Michaelsen 2014-02-28 12:45:52 UTC
Bulk change: Bibisected bugs can be assumed to be regressions.
Comment 9 Joel Madero 2014-03-25 23:32:54 UTC
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.
Comment 10 Xisco Faulí 2014-07-30 10:07:22 UTC
Created attachment 103678 [details]
how it looks in libreoffice 4.3.1

How it looks in Version:
Build ID: 0d5d8c22f7be41d408d8ee4012ef1a6f4368423e
TinderBox: Win-x86@51-TDF, Branch:libreoffice-4-3, Time: 2014-07-23_05:34:04
Comment 11 Xisco Faulí 2014-07-30 10:09:34 UTC
replace bibisected40 by bibisected
Comment 12 Björn Michaelsen 2014-10-16 14:59:06 UTC Comment hidden (obsolete)
Comment 13 Robinson Tryon (qubit) 2015-12-13 11:16:17 UTC Comment hidden (obsolete)
Comment 14 Aron Budea 2016-08-15 18:59:42 UTC
Still buggy in 5.2.
Comment 15 Justin L 2016-12-13 07:18:17 UTC
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.
Comment 16 Justin L 2016-12-13 07:21:03 UTC
Created attachment 129562 [details]
ABC TAXUS fita_LO53beta.pdf: It looks presentable at least in LO5.3beta
Comment 17 QA Administrators 2017-12-14 07:09:00 UTC Comment hidden (obsolete, spam)
Comment 18 Justin L 2019-08-02 05:58:56 UTC
(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.
Comment 19 Justin L 2020-07-17 15:09:41 UTC
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
commit e2b0e614e1185c960b3015414919f69a1ed35aa0
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
commit 6454b6336b8de9a4c5899adeab552af6f794cdc4
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
Comment 20 NISZ LibreOffice Team 2021-08-03 14:25:33 UTC
Created attachment 174050 [details]
The example file in current master

Looks somewhat better in:

Version: (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
Calc: CL

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.