https://bugs.documentfoundation.org/show_bug.cgi?id=155537

Armin Le Grand <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|[email protected] |[email protected]
                   |desktop.org                 |

--- Comment #4 from Armin Le Grand <[email protected]> ---
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...

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to