diff options
author | Regina Henschel <rb.henschel@t-online.de> | 2023-06-15 22:18:34 +0200 |
---|---|---|
committer | Regina Henschel <rb.henschel@t-online.de> | 2023-06-16 10:35:23 +0200 |
commit | 2b1b2a758cc4666c6cf6b147722223281dfe1f30 (patch) | |
tree | d3644e84cf4aa4fb14e7541e3cf5da7d801c6291 /basegfx | |
parent | c66afb209de6132deac8fee9425a351391edc89e (diff) |
tdf#155852 same method for StepCount in OOXML as in rendering
Rendering of stepped gradients uses a method that doesn't take the
color from a cut point, but before or after respectively. For example,
for StepCount 4, the colors at relative positions 0, 1/3, 2/3 and 1
are used. So sections are 'start color', '1/3 color', '2/3 color' and
'end color'. The output to OOXML now uses the same method. That way
rendering in a produced pptx-file is the same as in the original
odp-file. Since OOXML has nothing similar to StepCount, it is an export
only problem.
A second problem comes from the cuddle with StepCount in Gradient
struct in API and FillStepCount in shape property set. The
draw:gradient-stop-count attribute in ODF belongs to the graphic style
of the shape. The gradient definition itself in the <draw:gradient>
element has nothing about step count. When a file is opened, it can be
that the StepCount component in the Gradient struct still has the
default value 0, but the FillStepCount property has the correct value
of the shape.
The Gradient struct in the API should not have a component StepCount
to be compatible with ODF. But the API is published and changing that
struct is far-reaching in the code. So the fix here is not a general
solution but solves the problem for export to OOXML by reading the
FillStepCount property while exporting.
Change-Id: Ie1cafe6bdda7c4d74b05f279f0d8212ff67ecc92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153154
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Diffstat (limited to 'basegfx')
-rw-r--r-- | basegfx/source/tools/bgradient.cxx | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/basegfx/source/tools/bgradient.cxx b/basegfx/source/tools/bgradient.cxx index d46530074787..7b62a19c9ad6 100644 --- a/basegfx/source/tools/bgradient.cxx +++ b/basegfx/source/tools/bgradient.cxx @@ -746,7 +746,6 @@ void BColorStops::doApplySteps(sal_uInt16 nStepCount) // the same color as the previous one ended aNewColorStops.push_back(*aColorL); } - if (!basegfx::fTools::equalZero(fDelta)) { // create in-between steps, always two at the same position to @@ -757,20 +756,21 @@ void BColorStops::doApplySteps(sal_uInt16 nStepCount) if (rStartColor != rEndColor) { // get relative single-step width - const double fSingleStep(1.0 / static_cast<double>(nStepCount)); + // tdf155852 Use same method for the color as in rendering. + const double fSingleStep(1.0 / static_cast<double>(nStepCount - 1)); + const double fOffsetStep(fDelta / static_cast<double>(nStepCount)); for (sal_uInt16 a(1); a < nStepCount; a++) { - // calculate position since being used twice - const double fPosition(fStart - + (fDelta * (static_cast<double>(a) * fSingleStep))); + // calculate stop position since being used twice + const double fPosition(fStart + fOffsetStep * static_cast<double>(a)); - // add start color of sub-segment + // add end color of previous sub-segment aNewColorStops.emplace_back( fPosition, basegfx::interpolate(rStartColor, rEndColor, static_cast<double>(a - 1) * fSingleStep)); - // add end color of sub-segment + // add start color of current sub-segment aNewColorStops.emplace_back( fPosition, basegfx::interpolate(rStartColor, rEndColor, static_cast<double>(a) * fSingleStep)); |