Shadow, when shadow not set, shows on inserted images in doc/pdf files if below 100% zoom.
Steps to Reproduce:
1. Create an image. Do not use shadow option.
2. Open or create a doc or pdf file in Writer and insert image
3. Zoom below 100%
Image has shadow lines
No shadow lines
User Profile Reset: No
Reproduced by ebot when discussed on forum, they worked out the zoom issue
Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug.
I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document.
(Please note that the attachment will be public, remove any sensitive information before attaching it.)
How can I eliminate confidential data from a sample document?
I am using Windows 10 - I don't know how to provide foo/bar - I have a .docx document which shows the problem but it keeps asking for foo/bar instead.
(In reply to griffinit from comment #2)
> I am using Windows 10 - I don't know how to provide foo/bar - I have a .docx
> document which shows the problem but it keeps asking for foo/bar instead.
Please provide the .docx file mentioned then
Created attachment 151637 [details]
Document with inserted images at varying zoom levels
This document shows how shadow (when not set in image) appears on inserted images, and zoom level at which it disappears. In this case this was 200%.
The document contains screenshots taken of LibreOffice Writer documents (4) with image inserted, then set at varying zoom levels.
Please attach either the document itself or the image file. Thank you.
I did. In my previous message. attachment 151637 [details]
I don't know what more I can do to demonstrate it.
Really, you need to create an image (save selection). Then in LibreWriter new document. Insert the image. Then play around with Zoom levels - at some level(s) you will see the bug.
If my attachment was no use - that is what you need to do.
(In reply to griffinit from comment #6)
> I did. In my previous message. attachment 151637 [details]
Attachment in comment 4 is not a document but an image.
(In reply to Dieter Praas from comment #7)
> (In reply to griffinit from comment #6)
> > I did. In my previous message. attachment 151637 [details]
> Attachment in comment 4 is not a document but an image.
Yes, please provide the document itself, not an image of the problem
It is not possible to supply a document like that.
The image in the document (docx) attachment I supplied shows the error where zoom levels are varied. There is no other way of showing the error.
You have to create the document yourself to see the error for yourself.
It's quite simple.
Create an image. Save it as "save selection".
Open LibreWriter new document.
Vary the zoom level.
At some zoom levels you will see the shadow. At other zoom levels you won't.
Please do this. It is not difficult. Stop pestering me for something that is impossible. If you follow those instructions you will see why your requests are impossible.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to griffinit from comment #9)
> It is not possible to supply a document like that.
> The image in the document (docx) attachment I supplied shows the error where
> zoom levels are varied. There is no other way of showing the error.
> You have to create the document yourself to see the error for yourself.
I can't reproduce it with an own image. So please at least attach the image you used. Back to NEEDINFO.
Created attachment 151914 [details]
An image to insert in LibreWriter to see Shadow
Ok. Here is the image which I see a shadow on.
1. Open Writer
2. Insert => Image => Insert Image from attachment 12 => everything looks fine
3. change zoom level => thin line on the right and / or at the buttom appears and disappears
if you add several copies of that image, you can get different results at the same zoom-level
PDF Export is fine
Version: 188.8.131.52.beta1 (x64)
Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
Locale: en-US (de_DE); UI-Language: en-GB
Not reproduced in
Build ID: 4136757b4e51c4e6f7cb4132c95538a7f831ef2c
CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk3; Layout Engine: new;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Bibisected with Linux 6.0 repo to range https://git.libreoffice.org/core/+log/51ee0c5ba6b0ffcd4b12e652de48e3f775cccc7d..d74b26b41bfea3ba7a1834953b2bfe9b7ff0d70f
All commits are about RotateFlyFrame3
Note that the borders are not seen, if you turn off View - Text Boundaries
I still repro with latest master
Adding Cc: to Armin Le Grand
Took a look to see if I can reproduce - the last comments show more that it cannot be reproduced? Used the image provided in comment 12.
I get a slight gray edge on the right. If that is meant, this is no shadow. It is a highly system-dependent obstacle of painting a pixel-based bitmap to a pixel-based target in a AA-based in-between-pixel position. So - no model data, just display quirks.
In that step the backend AKA system-graphics-layer outside LO scales the image to get it where it is commanded to be painted. The choosen color for filling up the possible 'gap' is up to that target graphics system.
It would be nice if these systems would use the BG color (what may require read access what many systems do not have anymore nowadays).
It would be inside our influence to render all BM as having an alpha channel, then those systems may (no guarantee) use the correct BG color due to scaling BM+alpha and keeping that 'gap' semi-transparent (it's a sub-pixel, never gets the size of one full pixel). That would be potentially massively more expensive.
You may try on different LO backends to see different behaviours.
-> nothing we can do about that would have predictable results (system. backend, even version of GS on backend) or is not expensive I fear