Bug 155537 - MCGR FILESAVE OOXML Combining Color and Transparent Gradient could be smarter
Summary: MCGR FILESAVE OOXML Combining Color and Transparent Gradient could be smarter
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
7.6.0.0 alpha1+
Hardware: All All
: medium normal
Assignee: Armin Le Grand (allotropia)
URL:
Whiteboard: target:7.6.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: OOXML-Object-Fill
  Show dependency treegraph
 
Reported: 2023-05-28 17:34 UTC by Regina Henschel
Modified: 2023-06-07 12:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Original shape (16.03 KB, application/vnd.oasis.opendocument.text)
2023-05-28 17:34 UTC, Regina Henschel
Details
Screenshots (239.50 KB, image/png)
2023-05-28 17:35 UTC, Regina Henschel
Details
Screenshot 7.5 vs 7.6 odt, 7.5 docx vs 7.6 docx word (980.20 KB, image/png)
2023-05-30 00:34 UTC, m_a_riosv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2023-05-28 17:34:10 UTC
Created attachment 187559 [details]
Original shape

The attached document contains a shape with color and transparency gradient, both "radial" with X-offset 50% and Y-offset 0%. So the gradients have the same geometry and can be combined for OOXML.

Open the file in LO 7.5 and save it to docx. Open the file in current master and save it to docx. Open the saved files in  Word. Notice that the version from LO 7.5 is nearer to the original than the version from current master.

Looking into the markup produced from current master you see, that the transparency has wrong values.

This bug report is only about transparency. In addition the form of the gradient is different in LibreOffice and Word. But reason for that is, that we do not export 'tileRect'.
Comment 1 Regina Henschel 2023-05-28 17:35:18 UTC
Created attachment 187560 [details]
Screenshots

The left part shows rendering and export from LO 7.5, the right part shows rendering and export form current master.
Comment 2 m_a_riosv 2023-05-30 00:34:31 UTC
Created attachment 187597 [details]
Screenshot 7.5 vs 7.6 odt, 7.5 docx vs 7.6 docx word

Reproducible
Version: 7.5.4.1 (X86_64) / LibreOffice Community
Build ID: 3a6a10a8a824826630ea908dcaea93b45a6a0af1
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 20873f073ae4a9478f0a84355f779a2176bd2ec8
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Comment 3 Gabor Kelemen (allotropia) 2023-06-01 12:29:28 UTC
This seems to have started with

https://git.libreoffice.org/core/+/bb198176684c3d9377e26c04a29ec66deb811949

author	Armin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de>	Fri Apr 21 15:18:09 2023 +0200
committer	Armin Le Grand <Armin.Le.Grand@me.com>	Wed May 03 17:38:46 2023 +0200

MCGR: Make MCGR default for oox im/export, cleanup
Comment 4 Armin Le Grand (allotropia) 2023-06-06 10:22:41 UTC
Extracted data from source ODF file is:

draw:fill-gradient-name="Gradient_20_1" (CG) which is:

  <draw:gradient draw:name="Gradient_20_1" draw:display-name="Gradient 1" draw:style="radial" draw:cx="50%" draw:cy="0%" draw:start-color="#4169e1" draw:end-color="#ffa500" draw:start-intensity="100%" draw:end-intensity="100%" draw:border="30%"/>

draw:opacity-name="Transparency_20_1" (TG) which is:

  <draw:opacity draw:name="Transparency_20_1" draw:display-name="Transparency 1" draw:style="radial" draw:cx="50%" draw:cy="0%" draw:start="20%" draw:end="100%" draw:border="10%"/>

As you can see the CG and the TG both do not use MCGR/ColorStops at all, so classic start/EndColor situation.

BUT: CG has a 30% border, TG has a 10% border. If we take these values serious, we have to apply them. The new algorithm for export does exactly that, so aplying that borders gets us to:

CG:
    ColorStop[0]: StartColor, pos 0.3
    ColorStop[1]: EndColor, pos 1.0

and TG:
    ColorStop[0]: StartOpcty, pos 0.1
    ColorStop[1]: EndOpcty, pos 1.0

These do not match. Still, the new algorithm creates a matched version due to the export *has* to have a ColorStop per value  so interpolating the values as needed. Both get three positions doing so, that gets us to:

MIX:
    ColorStop[0]: StartColor, MxOpcty, pos 0.1
    ColorStop[1]: StartColor, MxOpcty, pos 0.3
    ColorStop[2]: EndColor, EndOpcty, pos 1.0

The StartColor in [1] is used since there is no Color 'before' to interpolate with. The MxOpcty is interpolated btw StartOpcty and EndOpcty at the needed position.

Thus: Keep in mind that the new export does different things to allow higher quality export of 'mixed' definitions of CG and TG.

BUT: I indeed saw that the adapted TG values are *strange* and *wrong* and after debugging through it I found the error at basegfx/source/tools/gradienttools.cxx:468 which is

                    rAlphaStops = aNewColor;

but should be

                    rAlphaStops = aNewAlpha;

what means that by this error the created color values were by error alsu used for transparency. ARGH!
That might be the (simple) reason for other errors with transparency. Correcting, checking again...
Comment 5 Commit Notification 2023-06-06 13:44:58 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bda52485d63e4cfc58453d9f46bf26c3ea078ed7

MCGR: tdf#155537 correct usage of wrong result in tooling

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.