Bug 80294 - FORMATTING: Image background color missing when at 0% transparency
Summary: FORMATTING: Image background color missing when at 0% transparency
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 89438 (view as bug list)
Depends on:
Blocks: Image-Dialog Image-Crop
  Show dependency treegraph
 
Reported: 2014-06-20 14:57 UTC by Matthias Basler
Modified: 2023-01-09 10:11 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document, corresponds to the result after step 5. (71.36 KB, application/vnd.oasis.opendocument.text)
2014-06-20 14:57 UTC, Matthias Basler
Details
Picture with 0% transparency on picture, and color background (48.96 KB, application/vnd.oasis.opendocument.text)
2014-06-23 19:42 UTC, Regina Henschel
Details
document with 3 images all showing the problem (996.68 KB, application/vnd.oasis.opendocument.text)
2014-06-24 03:48 UTC, Yousuf Philips (jay) (retired)
Details
the 3 images that are found in the example odt (953.28 KB, application/zip)
2014-06-24 03:49 UTC, Yousuf Philips (jay) (retired)
Details
how attachment 101608 looks in 4.3 and 4.4 on linux (57.72 KB, image/png)
2014-06-24 03:56 UTC, Yousuf Philips (jay) (retired)
Details
how attachment#101608 looks in 4.3 and 4.4 on linux (196.34 KB, image/png)
2014-06-24 03:59 UTC, Yousuf Philips (jay) (retired)
Details
zip with PNGs -- converted with Alpha chnl transparency (57.75 KB, application/zip)
2014-11-23 22:55 UTC, V Stuart Foote
Details
zip of sample .odt and PDFs of 4.3.4.1 and 4.4.0beta1 renderings (246.12 KB, application/zip)
2014-11-23 23:22 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Basler 2014-06-20 14:57:06 UTC
Created attachment 101438 [details]
Test document, corresponds to the result after step 5.

Playing a bit with image formatting I encountered something I felt was rather unintuitive and confusing.

To reproduce:
1. Insert an image into an empty writer document and position it in front of text (with text running behind it).
2. Double-click the image in order to bring up the image properties dialog.
3. Change to the "Crop" tab and enter *negative* values to for, lets say, left and right side. 
4. Klick OK. The image frame now becomes wider than the image (as expected and shown on the preview.).
5. Re-open the same dialog and change to the 8th tab ("Bereich" in German, probably "Area" in English.) Choose a nice color for the background, e.g. green. Klick OK to close the dialog. 

Expected result: The area between frame and image turns green.
Actual result: Nothing happens. (Actually, if you have a border around the image, that border will now get a slight green inner border.)

Lets continue:
6. Click on the image and make sure the "Image" toolbar is visble
7. In the image toolbar, there is a spinner text field for transparency, by default set to 0%. Change it to 1%.

Expected result: Almost no difference
Actual result: Now the green border left and right of the image becomes visible. The one I found missing after step 5.

Lets continue:
8. Increase the transparency to 50% and watch how the image turns more and more green. OK.
9. Remove the green background. Now the image becomes semi-tramsparent and the text behind it can be seen. Makes sense.
10. Set the transparency in the image toolbar to 1% (not 0!).
11. Open up the image properties dialog. Again set the background color to green
12. Change to the adjacent "transparency" tab and change the transparency to 50%.

Expected result: The same as in step 8: The image becomes rather greenish.
Actual result: The green background becomes semi-transparent.

Conclusion:
The "Transparency" section in the image properties only controls the transparency of the background color (if any). Without a background color it has no effect.
The "Transparency" in the image toolbar, however, effects the image itself.
The different effect of the two is completely undocumented. Even the LibO help does not make it clear, the transpacency of *what* is actually changed.

Proposed changes:
1. The background transparency settings should be located in the same tab as the background color. These settings should only be visible if the user has selected a background at all (since, as we saw, it has no effect otherwise).
2. If there is to be a separate "Transparency" setting at all in the image properties dialog, it should imho have the same effect as the transparency spinner on the toolbar, that is, it should control the transparency of the image itself.
4. The help should make it clear to the user what objects are affected by which transparency setting.
5. For reasons of consistency the image background must be also visible if the image transparency is set to 0%, not just if it is set to 1% or above.

Does this make sense?
Operating System: Windows 7
Version: 4.3.0.1 rc
Comment 1 Yousuf Philips (jay) (retired) 2014-06-23 02:05:25 UTC
Hi Matthias,

I'm confirming this behaviour on Linux Mint in 4.3 regarding the missing background color of steps 1 to 5. This is a regression as it works correctly in 4.2.5. I have created another bug (bug 80373) for the issue of the transparency tab not working the way it should.
Comment 2 Regina Henschel 2014-06-23 19:19:08 UTC
No it is not a regression but a new feature. Frames (and so images) in Writer have got the same Area properties as other drawing objects e.g. rectangles. Formerly frames had only the property background color. Together with the change from "background" to "Area" the transparency of these fillings has been introduced, which is the same as for e.g. rectangles.

The feature comes from AOO r1579280, and has been integrated by  http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e61ecd09679a66060f932835622821d39e92f01

The issue is, that there exists no help text for the new feature.
Comment 3 Regina Henschel 2014-06-23 19:42:59 UTC
Created attachment 101608 [details]
Picture with 0% transparency on picture, and color background

I can see the problem with your picture, but cannot reproduce it with a new document. See attached file, all works as expected. The transparency in the picture is a transparent color in the color palette of the inserted image.
I use Version: 4.4.0.0.alpha0+ Build ID: 18c786cbcd45ee314bed6303c62e23ecf4022a8b
Comment 4 Yousuf Philips (jay) (retired) 2014-06-24 03:47:10 UTC
I was mistaken to think that the image background color being missing when the image transparency is set to 0% was a regression, as it has been there since OO, but it only shows up with particular images. I will attach an odt file showing this behaviour along with the 3 images found in the file, so they can be tested and examined.
Comment 5 Yousuf Philips (jay) (retired) 2014-06-24 03:48:13 UTC
Created attachment 101627 [details]
document with 3 images all showing the problem
Comment 6 Yousuf Philips (jay) (retired) 2014-06-24 03:49:03 UTC
Created attachment 101628 [details]
the 3 images that are found in the example odt
Comment 7 Yousuf Philips (jay) (retired) 2014-06-24 03:56:16 UTC
Created attachment 101629 [details]
how attachment 101608 [details] looks in 4.3 and 4.4 on linux

(In reply to comment #3)
> Created attachment 101608 [details]
> Picture with 0% transparency on picture, and color background
> 
> I can see the problem with your picture, but cannot reproduce it with a new
> document. See attached file, all works as expected. The transparency in the
> picture is a transparent color in the color palette of the inserted image.
> I use Version: 4.4.0.0.alpha0+ Build ID:
> 18c786cbcd45ee314bed6303c62e23ecf4022a8b

In 4.2.5, there wasnt any problem with your sample file, but with 4.3 and 4.4, this is how it looked for me.
Comment 8 Yousuf Philips (jay) (retired) 2014-06-24 03:59:55 UTC
Created attachment 101630 [details]
how attachment#101608 [details] looks in 4.3 and 4.4 on linux
Comment 9 Regina Henschel 2014-06-24 14:55:17 UTC
I have found, that the behavior depends on the transparency of the picture itself. If I use a png without transparency, then the background of the property area is ignored and whatever is behind the cropped part is rendered. If I use a png, which has a kind of transparency itself, for example a transparent color, then the background of the area is used.

I don't know, what is the "correct" behavior. Cropping is done by the fo:clip attribute http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1419798_253892949, which comes from http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#clip, which itself refers to http://www.w3.org/TR/CSS2/visufx.html#propdef-clip. But I find no hint there, what has to be rendered in case the clipping rectangle exceeds the picture.
Comment 10 Yousuf Philips (jay) (retired) 2014-06-24 19:52:25 UTC
None of the 3 images i provided have any transparency in them and Matthias's sample image didnt either. Matthias, can you attach that image?
Comment 11 V Stuart Foote 2014-11-23 21:06:10 UTC
*** Bug 86578 has been marked as a duplicate of this bug. ***
Comment 12 V Stuart Foote 2014-11-23 22:55:57 UTC
Created attachment 109914 [details]
zip with PNGs -- converted with Alpha chnl transparency

Another twist to this feature change in 4.4 builds.  

If JPEGs are converted to PNG with alpha channel, transparency of that area of image is as expected. But, when a an area fill color for the frame is assigned. On save that area fill will retain the transparency values, but loses the fill color--reverting to white.

Unzip, and insert into Writer. Bcz PNG with Alpha, transparent over any lettering. Then, set Area fill and then make it transparent. Will display as such while Writer session is open. But on save the Area fill color value is being lost, on reopen area fill color comes up white but retains transparency.  Alpha channel transparency of PNG is not affected.

-=ref=-
A reminder, compliments of the ImageMagick folks, JPEGs will not honor transparency, see http://www.imagemagick.org/Usage/formats/#jpg_trans
Comment 13 V Stuart Foote 2014-11-23 23:22:49 UTC
Created attachment 109915 [details]
zip of sample .odt and PDFs of 4.3.4.1 and 4.4.0beta1 renderings

Attached a zip'd test kit with sample .ODT and PDFs rendered in 4.3.4.1 and 4.4.0beta1 showing mishandling of Area Fill color in 4.4.0, and not affected in 4.3.4.1
Comment 14 V Stuart Foote 2014-11-26 06:07:57 UTC
Issues with transparency of coincident text frames and image frames are confined to 4.4 branch. Returning those issues to bug 86578
Comment 15 V Stuart Foote 2015-02-17 22:58:15 UTC
*** Bug 89438 has been marked as a duplicate of this bug. ***
Comment 16 QA Administrators 2016-02-21 08:36:38 UTC Comment hidden (obsolete)
Comment 17 Matthias Basler 2016-02-21 09:35:17 UTC
Issue still exists in version 5.0.4.2, exactly as originally documented.
Comment 18 QA Administrators 2018-07-21 02:39:45 UTC Comment hidden (obsolete, spam)
Comment 19 QA Administrators 2020-07-21 03:47:21 UTC Comment hidden (obsolete)
Comment 20 Stéphane Guillou (stragu) 2021-06-14 13:04:54 UTC
Reproduced as described in:

Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: bb54d6d8241a06a6772052b77b67d6a4f686426c
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-11_20:14:38
Calc: threaded