Created attachment 108792 [details]
Writer fails to preserve the background image transparency settings in this sample document. Attached is also a picture showing how it looks like in Office.
Created attachment 108793 [details]
I confirm bug under Win7x64 using LibO 184.108.40.206+ master, 220.127.116.11 and 18.104.22.168.
Transparency isn't set in 3.3.4 too. So prolly never worked. (However the position is much better now then in 3.3.4)
*** Bug 92436 has been marked as a duplicate of this bug. ***
*** Bug 89442 has been marked as a duplicate of this bug. ***
Created attachment 122056 [details]
last edited with Word2003. LO sets image to white background on save
Another example document. Most of the page is a large transparent picture. After saving with LO, when *Word* opens the document all of the text is "missing" because the image has background color set to "White, transparency 0%" instead of "no fill". This happens already in 3.5 (oldest in bibisect43-max)
Assuming bisected to imply bibisected, thus adding the latter. This is to make queries for "bibisected" not miss out bisected bugs.
I've checked it with 22.214.171.124:
- docx: it doesn't work on read and write
- doc: it doesn't work on write
- pdf : it doesn't work on read
@thomas: why is this blocking 38233? Is that assumed to be a META-issue?
No, but bug 38233 isn't just about transparency.
(In reply to Thomas Bertels from comment #10)
> No, but bug 38233 isn't just about transparency.
I can't see why it makes sense. Is your idea to let all issues about wrong opening of docx block bug 38233 ?
(In reply to Cor Nouws from comment #11)
> (In reply to Thomas Bertels from comment #10)
> > No, but bug 38233 isn't just about transparency.
> I can't see why it makes sense.
OK, checked and clarified 38233 - I understand it now ;)
Deleting 'bisected' and 'bibisected' from keywords as the problematic commits hasn't been identified.
Only regressions should use the keyword 'preBibisect'. Removing it...
*** Bug 107112 has been marked as a duplicate of this bug. ***
see simple test file https://bugs.documentfoundation.org/attachment.cgi?id=132506
and screenprint from Word settings https://bugs.documentfoundation.org/attachment.cgi?id=132507 from bug 107112
(In reply to Cor Nouws from comment #16)
> see simple test file
( You can get the pictures context menu, using Navigator, clicking
WordPictureWatermarkxxx, then F6, F6, ESC, Shift+F10 ... )
after saving and reopening in Writer, it is a 'normal' image, of which transparency can be set in the image toolbar.
Created attachment 132514 [details]
cleaner test case with only background image and no other objects
Still reproducible in
Build ID: 34e8fd7e99489e9f50a512b07c6f3923b358b4d3
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
** 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!
Tested with Version: 126.96.36.199 (x64)
Build ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU threads: 8; OS: Windows 10.0; UI render: default;
Locale: es-MX (es_MX); Calc: CL
and Microsoft Word 2007
The first and last test documents when are opened in Word 2007, the transparency is present in their original state. Which can be verified in the “Image Format” option of the context menu of the image, that has set a predefined “Watermark” preset. This condition is not imported to Writer.
With the second test document I can confirm what Justin L said in comment 6
My original bug 89442 it was about the transparency lost in a Writer file with an image background that had set a transparency and this definition was not saved when opening again the file. But this issue is fixed now.
But I am glad that had the opportunity to test this issue.
Still not fixed in 7.0 master. OP's 2014 X-Country Schedule v 4.docx still opens with a very black watermark image.
The image opens as a "drawing object" instead of an "image". When round-tripped, it is considered as a regular image as noted in comment 17.
https://askubuntu.com/questions/570789/fading-image-in-libre-office indicates how you can set transparency on the image itself. Note that the properties tab for "transparency" is for the Area color and not the image itself.
So the key would be to figure out why this background image is first inserted as a draw object, and then exported as a regular image. If it could be imported as a regular image, then for sure the transparency settings could be applied.
Alternatively, it MIGHT be possible to set transparency on the drawing object, and just wasn't done?
OK - I was mislead and therefore became misleading again in return.
This really is about brightness/contrast as noted in the subject heading, not transparency.
Also the picture is anchored in the header. I believe that also automatically makes it slightly transparent in Word.
There are two images in the header2.xml. One is a true picture, but the one we are focusing on is an auto-shape/picture, which has
<v:imagedata r:id="rId3" o:title="" gain="19661f" blacklevel="22938f"/>
LO recognizes blacklevel as a legit tag, but doesn't do anything with it. So this is a missing feature problem.
bug 38410 has a unit test called msobrightnesscontrast.doc in ww8export.
see commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=1139d618b8bc6ab823a96184bd0f0257980aad24