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
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.
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.
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
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.
Created attachment 101627 [details] document with 3 images all showing the problem
Created attachment 101628 [details] the 3 images that are found in the example odt
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.
Created attachment 101630 [details] how attachment#101608 [details] looks in 4.3 and 4.4 on linux
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.
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?
*** Bug 86578 has been marked as a duplicate of this bug. ***
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
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
Issues with transparency of coincident text frames and image frames are confined to 4.4 branch. Returning those issues to bug 86578
*** Bug 89438 has been marked as a duplicate of this bug. ***
** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
Issue still exists in version 5.0.4.2, exactly as originally documented.
** 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! Warm Regards, QA Team MassPing-UntouchedBug
Dear Matthias Basler, 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 https://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! Warm Regards, QA Team MassPing-UntouchedBug
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