Bug 85757 - FILEOPEN: Background image in docx looses 'transparency' (brightness/contrast settings) (see comment #16)
Summary: FILEOPEN: Background image in docx looses 'transparency' (brightness/contrast...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: interoperabillity
Keywords: filter:doc, filter:docx, filter:pdf
: 92436 107112 (view as bug list)
Depends on:
Blocks: 38233 DOCX-Images DOC
  Show dependency treegraph
 
Reported: 2014-11-02 12:58 UTC by Anonymous Helper
Modified: 2019-04-19 13:50 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document (48.98 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-11-02 12:58 UTC, Anonymous Helper
Details
image_transparency_MSOffice (98.79 KB, image/jpeg)
2014-11-02 12:59 UTC, Anonymous Helper
Details
last edited with Word2003. LO sets image to white background on save (76.50 KB, application/msword)
2016-01-18 13:45 UTC, Justin L
Details
cleaner test case with only background image and no other objects (441.29 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-04-12 10:58 UTC, Cor Nouws
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anonymous Helper 2014-11-02 12:58:29 UTC
Created attachment 108792 [details]
Sample document

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.
Comment 1 Anonymous Helper 2014-11-02 12:59:32 UTC
Created attachment 108793 [details]
image_transparency_MSOffice
Comment 2 tommy27 2014-11-02 16:44:39 UTC
I confirm bug under Win7x64 using LibO 4.4.0.0+ master, 4.3.2.2 and 4.2.0.4.
Comment 3 Cor Nouws 2014-11-03 08:34:01 UTC
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)
Comment 4 Alex Thurgood 2015-07-01 07:49:01 UTC
*** Bug 92436 has been marked as a duplicate of this bug. ***
Comment 5 Alex Thurgood 2015-07-01 07:50:36 UTC
*** Bug 89442 has been marked as a duplicate of this bug. ***
Comment 6 Justin L 2016-01-18 13:45:04 UTC
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)
Comment 7 Björn Michaelsen 2016-08-24 22:00:28 UTC
Assuming bisected to imply bibisected, thus adding the latter. This is to make queries for "bibisected" not miss out bisected bugs.
Comment 8 Thomas Bertels 2016-08-30 12:27:58 UTC
I've checked it with 5.2.0.4:
- docx: it doesn't work on read and write
- doc: it doesn't work on write
- pdf : it doesn't work on read

+filter keywords
Comment 9 Cor Nouws 2016-08-30 12:40:43 UTC Comment hidden (obsolete)
Comment 10 Thomas Bertels 2016-08-30 12:42:48 UTC Comment hidden (obsolete)
Comment 11 Cor Nouws 2016-08-30 12:49:42 UTC Comment hidden (obsolete)
Comment 12 Cor Nouws 2016-08-30 13:26:18 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2016-09-14 14:41:02 UTC
Deleting 'bisected' and 'bibisected' from keywords as the problematic commits hasn't been identified.
Comment 14 Xisco Faulí 2016-09-14 14:45:05 UTC
Only regressions should use the keyword 'preBibisect'. Removing it...
Comment 15 Xisco Faulí 2017-04-12 09:47:45 UTC
*** Bug 107112 has been marked as a duplicate of this bug. ***
Comment 16 Cor Nouws 2017-04-12 10:17:23 UTC
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
Comment 17 Cor Nouws 2017-04-12 10:19:19 UTC
(In reply to Cor Nouws from comment #16)
> see simple test file
> https://bugs.documentfoundation.org/attachment.cgi?id=132506

  ( 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.
Comment 18 Cor Nouws 2017-04-12 10:58:19 UTC
Created attachment 132514 [details]
cleaner test case with only background image and no other objects
Comment 19 Xisco Faulí 2017-10-03 15:32:17 UTC
Still reproducible in

Version: 6.0.0.0.alpha0+
Build ID: 34e8fd7e99489e9f50a512b07c6f3923b358b4d3
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 20 QA Administrators 2018-10-04 02:55:20 UTC Comment hidden (obsolete)
Comment 21 Robert Gonzalez MX 2018-10-06 22:28:04 UTC
Tested with Version: 6.1.2.1 (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.